| Previous | Next |
| XACT_S_ABORTING | XACT_S_LOCALLY_OK |
XACT_S_SINGLEPHASE
Resource manager performed a single-phase commit
XACT_S_SINGLEPHASE is HRESULT 315401 (0x0004D009) from winerror.h. AllStat describes it as “The resource manager has performed a single-phase commit of the transaction.” 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 resource manager has performed a single-phase commit of the transaction. The high-level request can be considered complete after it only when its documented postcondition has been checked.
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.
Evidence and telemetry
- preserve resource manager identity.
- preserve enlistment count.
- preserve single-phase eligibility.
- preserve durable commit record.
- preserve coordinator completion status.
Also record xact_s_singlephase_operation, xact_s_singlephase_state_before, xact_s_singlephase_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. Protect user data in logs and keep only the identifiers required to reproduce component state.
What must be true before accepting it
Verify that the single-phase optimization is permitted and the resource manager’s durable result is authoritative. The verification prevents it from being promoted to broader success than the producing API promised.
The component may have changed durable or in-memory state before returning it; inspect that state first.
Correct handling and recovery
Record the optimization and final resource result. Do not attempt a second prepare or commit; handle recovery according to the resource manager’s single-phase contract.
Retry it only when a documented input or state has changed. Retry policy must follow the owning state machine rather than a generic transient-error loop.
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 nearby-status comparison controls whether outputs are usable and whether more work is expected.
Practical scenario
A transaction has one durable resource manager, which completes single-phase commit. The coordinator records the optimized path and closes the unit of 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.