[jbossts-issues] [JBoss JIRA] Commented: (JBTM-602) XA recovery fails to span XAResources

[Michael Harvey (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBTM-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12480778#action_12480778 ] 

Michael Harvey commented on JBTM-602:
-------------------------------------

<mharvey> Hi Ivo
<mharvey>Should https://jira.jboss.org/jira/browse/JBPAPP-2413 be assigned to Jonathan Halliday?
<mharvey> I notice that it is linked to: https://jira.jboss.org/jira/browse/JBTM-602
<istudens No, it has been already fixed in the 4.6.1.CP branch of JBossTS which is targeted to EAP5 CR3. 

> XA recovery fails to span XAResources
> -------------------------------------
>
>                 Key: JBTM-602
>                 URL: https://jira.jboss.org/jira/browse/JBTM-602
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Application Server Integration, Recovery
>    Affects Versions: 4.2.3.CP05, 4.6.1, 4.7.0
>            Reporter: Jonathan Halliday
>            Assignee: Jonathan Halliday
>             Fix For: 4.2.3.SP8, 4.2.3.CP06, 4.8.0, 4.6.1.CP02
>
>
> XARecoveryModule runs scans against XAResource and holds the results. On the next invocation it compares the new and old scan results to determine which xids are still outstanding, assumes they are in need of recovery and deals with them. This two stage process is to avoid rolling back tx branches that are still live and just between the prepare/[commit|rollback] phases. The idea, whilst good in principle, is flawed in execution.
> It operates on the assumption that consecutive scans against a given RM will use the same (as defined by hashcode/equals semantics) XAResource. This assumption fails where a different connection to the same RM is used and the driver is implemented such that the XAResource identity is tied to the [XA]Connection. This occurs particularly with AppServerJDBCXARecovery, which uses a fresh connection on each pass to ensure that recovery scans don't blow up because of stale connections, such as occur when a db bounces but the AS keeps running. More generally, the contract between XARecoveryModule, the XAResourceRecovery impls and XAResourceRecoveryHelper impls needs to be flexible enough to accommodate this.
> The upshot of this is that XARecoveryModule can't assume a given RM will be represented by the same XAResource on different passes and must therefore cache Xids between passes using a different structure. It's actually not required to hold the XAResource itself between passes, since the resource for the current pass will always be available. Thus keeping only the Xids from the previous scan would seem best.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira