[jbossts-issues] [JBoss JIRA] Commented: (JBTM-602) XA recovery fails to span XAResources
Michael Harvey (JIRA)
jira-events at lists.jboss.org
Fri Aug 14 07:17:32 EDT 2009
[ https://jira.jboss.org/jira/browse/JBTM-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12480776#action_12480776 ]
Michael Harvey commented on JBTM-602:
Hi Jonathan, Are you able to look into this problem? This also appears in EAP5 as a critical bug JBPAPP-2413. I'm not sure why this bug is a major and
JBPAPP-2413 is marked as critical. One question is: Is there some reasonable work around that can be documented in EAP5 release notes? Should EAP5 be held up for this fix?
> 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
More information about the jbossts-issues