| Previous | Next |
| XACT_E_ALREADYOTHERSINGLEPHASE | XACT_E_COMMITFAILED |
XACT_E_CANTRETAIN
Retaining completion asks for a new unit of work in the same context
XACT_E_CANTRETAIN is returned when the caller requests retaining commit or abort semantics that the transaction implementation cannot provide. Retaining completion is not the same as keeping a COM interface pointer alive: it ends the current unit of work and immediately establishes a successor transaction while attempting to preserve selected context.
Treat this as a capability mismatch, not as a transient commit failure. Record the retaining flag and the transaction implementation in use, then change the application to begin a fresh transaction explicitly if retention is optional. When isolation, enlistment, or propagation state cannot safely cross the boundary, retrying the identical retaining call will not make the transaction manager support it.
Questions to answer before changing transaction demarcation
- Was retaining behavior explicitly requested by the application or framework?
- Which isolation and timeout settings were expected to survive completion?
- Do enlisted resources support a successor unit of work without reenlistment?
- Can the workflow create a new transaction and reacquire its resources instead?
References
- Microsoft MS-DTCO: transaction lifetime and completion
- Microsoft MS-DTCO: commit, abort, and special cases
- The Open Group: XA transaction demarcation and branches
Looking for a different code? Search another status or error code.