Some events (such as connection loss, process death, resource manager failure, etc.) might result in the creation of 'in-doubt' XA transactions. Such transactions are created when one or more RMs enlisted in an XA transaction have not completed or have failed on the second phase of a syncpoint (either commit or a rollback). When this happens, the XA transaction left in the resource manager in a "prepared" state is called an in-doubt transaction. It is the role of the XA transaction manager such as COBOL Server to resolve these in-doubt transactions.
In order to recover XA transactions, the transaction manager logs the outcome of the syncpoint-related XA verbs. It uses this information to make a decision on how to syncpoint an in-doubt transactions if one is left in one or more resource managers. During region startup, on SEP abend, on XA errors RMFAIL and RMERR returned on phase 2 of a syncpoint, the XA recovery transaction will be triggered. Using the information contained in the XA log, this system transaction will then commit or rollback the XA transactions returned by the resource manager.
When an XA transaction is recovered, you receive the following type of messages:
CASXO0027I XA recovery committed in-doubt transaction 177969 branch 1 on RM XADB2 CASXO0027I XA recovery committed in-doubt transaction 249152 branch 3 on RM ESMQXA4 CASXO0027I XA recovery committed in-doubt transaction 1539000001 branch 3 on RM DB51
At region start up, if in-doubt transactions were created during the last region run, you receive the following type of messages:
CASXO0029I XA log reported in-doubt transaction 1443000001 branch 3 CASXO0029I XA log reported in-doubt transaction 03456 branch 1
It is possible that some of these XA transactions were resolved or recovered during the previous region run. If not they should be recovered shortly after these messages are displayed. Another message should then be displayed and it confirms the XA recovery at startup:
CASXO0027I XA recovery committed in-doubt transaction 03456 branch 1 on RM XADB2
XA logging is the mechanism underpinning the recovery of in-doubt transactions. By default, XA logging is enabled for RMs that present a xa_recover entry point. XA logging is bypassed for an RM which does not present the xa_recover() capability.
Depending upon your environment, logging might degrade performance. You can disable XA logging by setting the following environment variable:
ES_XA_LOG_SUPPRESS=Y
For the two-phase commit batch program DSNRLI, XA processing is optimised when only one RM participates in the XA transaction.