| Previous | Next |
| XACT_S_DEFECT | XACT_S_SOMENORETAIN |
XACT_S_READONLY
Transaction completed through the read-only path
XACT_S_READONLY is HRESULT 315394 (0x0004D002) from winerror.h. AllStat describes it as “The method call succeeded because the transaction was read-only.” 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 method call succeeded because the transaction was read-only. 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.
Evidence and telemetry
- preserve unit of work.
- preserve enlisted resource list.
- preserve read and write operations observed.
- preserve prepare votes.
- preserve final transaction outcome.
Also record xact_s_readonly_operation, xact_s_readonly_state_before, xact_s_readonly_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.
What must be true before accepting it
Verify that no enlisted resource produced durable changes and the optimized outcome matches the application operation. 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.
Correct handling and recovery
Accept the optimized completion, but verify that no expected write was silently skipped. Record which resources voted read-only and close the transaction normally.
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
A reporting transaction queries two databases and performs no updates. Both resources vote read-only, allowing the coordinator to avoid write-phase 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.