| Previous | Next |
| XACT_S_READONLY | XACT_S_OKINFORM |
XACT_S_SOMENORETAIN
Some enlisted resources could not retain after abort
XACT_S_SOMENORETAIN is HRESULT 315395 (0x0004D003) from winerror.h. AllStat describes it as “The transaction was successfully aborted; However, this is a coordinated transaction, and some number of enlisted resources were aborted outright because they could not support abort-retaining semantics.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.
In the COM transaction and MSDTC protocol, this result means that the transaction was successfully aborted; However, this is a coordinated transaction, and some number of enlisted resources were aborted outright because they could not support abort-retaining semantics. Acceptance depends on the returned state and outputs, not only on the cleared severity bit.
Where the status is encountered
- ITransaction commit or abort processing; log the exact method and object state instead of interpreting the constant outside that contract.
- Resource-manager enlistment and coordinated outcomes; log the exact method and object state instead of interpreting the constant outside that contract.
- Transaction event-sink notification passes; log the exact method and object state instead of interpreting the constant outside that contract.
Because it is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.
What must be true before accepting it
Verify that the caller knows which resources ended outright and does not reuse them as members of a retained transaction. This check separates a legitimate it outcome from code that ignores an incomplete or altered operation.
Before retrying it, classify its effects as completed, partial, pending, cancelled, adapted, or terminal.
Evidence and telemetry
- preserve retaining flags.
- preserve resource-manager votes.
- preserve resources aborted outright.
- preserve new transaction identity.
- preserve session objects retained or recreated.
Also record xact_s_somenoretain_operation, xact_s_somenoretain_state_before, xact_s_somenoretain_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. When logging it, redact secret payloads but preserve stable identifiers and hashes needed for correlation.
Difference from nearby results
It must be distinguished from ordinary S_OK and from failure-severity values in the same API family; its documented state changes control the next action.
The distinction around it determines whether the caller stops, waits, consumes output, or changes state.
Correct handling and recovery
Enumerate resource outcomes, recreate non-retaining enlistments, and continue only after a new transaction boundary is established for those resources.
Retry it only when a documented input or state has changed. Do not immediately repeat it when the same stable state would produce the same informational result.
Practical scenario
A coordinated abort requests retaining semantics. One resource cannot retain, so the application reopens that session before starting follow-up work.
A regression test should reproduce it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
References
- Microsoft: COM transaction status codes — official Microsoft material used to interpret it.
- Microsoft: ITransaction::Commit
- Microsoft: ITransaction::Abort
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.