[jbossts-issues] [JBoss JIRA] Closed: (JBTM-859) support XAResourceWrapper

[Jonathan Halliday (JIRA)]

     [ https://issues.jboss.org/browse/JBTM-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Halliday closed JBTM-859.
----------------------------------

    Resolution: Done


> support XAResourceWrapper
> -------------------------
>
>                 Key: JBTM-859
>                 URL: https://issues.jboss.org/browse/JBTM-859
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Recovery
>    Affects Versions: 4.15.0
>            Reporter: Jonathan Halliday
>            Assignee: Jonathan Halliday
>             Fix For: 4.15.2, 5.0.0.M1
>
>
> 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 org.jboss.tm.XAResourceWrapper, 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira