| Previous | Next |
| XACT_S_MADECHANGESINFORM | XACT_S_ABORTING |
XACT_S_ALLNORETAIN
Abort succeeded without retaining the transaction
XACT_S_ALLNORETAIN is HRESULT 315399 (0x0004D007) from winerror.h. AllStat describes it as “The transaction was successfully aborted; However, the abort was non-retaining.” 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, the abort was non-retaining. Before reporting completion for this HRESULT, the caller must reconcile the code-specific state transition and every usable output.
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 every participant treats the old transaction as finished and no retained continuation is assumed. Without that proof, it can mask a caller error even though HRESULT failure severity is not set.
Reconcile side effects associated with it before compensation or a second invocation is attempted.
Evidence and telemetry
- preserve unit of work.
- preserve requested retaining behavior.
- preserve resource outcomes.
- preserve objects invalidated by abort.
- preserve new transaction identifier.
Also record xact_s_allnoretain_operation, xact_s_allnoretain_state_before, xact_s_allnoretain_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. Telemetry for this HRESULT should omit credentials while retaining nonsecret object identities and version data.
Correct handling and recovery
Release or recreate transactional objects before further work. Do not reuse the old unit of work or resources that require a retained abort boundary.
Retry it only when a documented input or state has changed. An unchanged retry after it is useful only when the API explicitly advances through repeated calls.
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.
Correctly separating it from neighboring values selects the proper continuation and cleanup path.
Practical scenario
An application aborts with a retaining request but receives this status. It closes the old sessions and begins a new transaction before retrying the business operation.
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.