| Previous | Next |
| XACT_S_LOCALLY_OK | CO_S_NOTALLINTERFACES |
XACT_S_LASTRESOURCEMANAGER
Resource requests last-resource-manager coordination
XACT_S_LASTRESOURCEMANAGER is HRESULT 315408 (0x0004D010) from winerror.h. AllStat describes it as “The resource manager has requested to be the coordinator (last resource manager) for 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 requested to be the coordinator (last resource manager) for the transaction. Consumers of it must decide from the API contract whether to stop, wait, continue, or expose a reduced outcome.
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 requesting resource manager.
- preserve other enlistments and capabilities.
- preserve last-resource policy.
- preserve prepare and commit ordering.
- preserve recovery record location.
Also record xact_s_lastresourcemanager_operation, xact_s_lastresourcemanager_state_before, xact_s_lastresourcemanager_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. A diagnostic bundle for this HRESULT should preserve correlation fields without copying tokens, keys, or private media.
What must be true before accepting it
Verify that the transaction manager accepts the one-phase resource role without creating multiple uncoordinated last resources. Checking the boundary keeps it from hiding stale data, pending work, or a deliberately reduced result.
Do not compensate for this HRESULT until the caller knows which sub-operations actually occurred.
Correct handling and recovery
Verify policy permits the last-resource optimization, ensure only one such resource exists, and record the recovery implications before proceeding.
Retry it only when a documented input or state has changed. Continuation after it may be appropriate, but an identical restart is not automatically recovery.
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 practical value of distinguishing it is choosing the right wait, stop, retry, or user-notification behavior.
Practical scenario
A transactional system combines a durable two-phase database with one legacy one-phase queue. The queue requests last-resource-manager status and the coordinator validates exclusivity.
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.