Relating the Xids in log messages to specific resource managers is non-trivial, making debugging unnecessarily complex. In particular,

      "[com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource"

      is not helpful in relating which RM is believed to own the Xid. This stems from the XA API providing no metadata with the XAResource during enlistment with a transaction. To address this we add support for, an XAResource extension that provides for querying of the RM name, version and JNDI bind address. This information is provided by e.g. IronJacamar when enlisting resources from xa-datasource connection pools.

      The information provided is transcribed into the XAResourceRecord from where it can be used in trace and warn messages and also serialised to the tx log to ensure availability at recovery time. Additionally, for branches created by the TM (i.e. not subordinate/inflow), the jndi name can be encoded into the Xid itself for availability in cases where the RM but not the TM retains the Xid.

      Additional work may encompass a) using this information to allow automatic cleanup of the logs in cases where the RM has committed the branch but the TM has not yet deleted its log, and b) using it to distinguish RMs in subordinate/inflow recovery cases where they share the same Xid. These are tracked separately.

        Gliffy Diagrams


            Issue Links



                • Assignee:
                  jhalliday Jonathan Halliday
                  jhalliday Jonathan Halliday
                • Votes:
                  0 Vote for this issue
                  0 Start watching this issue


                  • Created: