Describe the bug
When a transaction is imported via WS-AT the Liberty TM allocates a different XID locally, it should be using the imported GlobalID from the WS-AT context.
If there is a stack trace, please include the FULL stack trace (without any [internal classes] lines in it). To find the full stack trace, you may need to check in $WLP_OUTPUT_DIR/messages.log
Steps to Reproduce
Import transaction via WS-AT, note XID in use (eg via trace or lock contention)
Expected behavior
The XID used by the local transaction in Liberty should be the same as the WS-AT CoordinationContext's Identifier (which represents the global id of the transaction)
Diagnostic information:
OpenLiberty Version: pre 24.0.0.5
Affected feature(s) transactions, WS-AT
Additional context
NOTE this issue has been created to backport an iFix for PR 28316 (which addresses the problem) from 24.0.0.5
Describe the bug
When a transaction is imported via WS-AT the Liberty TM allocates a different XID locally, it should be using the imported GlobalID from the WS-AT context.
If there is a stack trace, please include the FULL stack trace (without any
[internal classes]
lines in it). To find the full stack trace, you may need to check in$WLP_OUTPUT_DIR/messages.log
Steps to Reproduce
Import transaction via WS-AT, note XID in use (eg via trace or lock contention)
Expected behavior
The XID used by the local transaction in Liberty should be the same as the WS-AT CoordinationContext's Identifier (which represents the global id of the transaction) Diagnostic information:
Additional context
NOTE this issue has been created to backport an iFix for PR 28316 (which addresses the problem) from 24.0.0.5