[jbossts-issues] [JBoss JIRA] (JBTM-1354) JCA recovery race condition

Tom Jenkinson (JIRA) jira-events at lists.jboss.org
Mon Nov 26 09:55:21 EST 2012

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

Tom Jenkinson commented on JBTM-1354:

I think maybe we should do the xaRecovery in two phases, the first one collects all the XAR and this can be locked, the next one does the work and this is not locked
> JCA recovery race condition
> ---------------------------
>                 Key: JBTM-1354
>                 URL: https://issues.jboss.org/browse/JBTM-1354
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>             Fix For: 4.17.3, 5.0.0.M2
> Evidenced in SimpleIsolatedServers::testSimultaneousRecovery
> Basically XATerminatorImple -> SAA::activate() -> XAResourceRecord::restore_state() -> getNewXAResource() -> XARecoveryModule::getNewXAResource()
> At this point _xidScans may be none-null but still only partial from the first scan: periodicWorkSecondPass -> bottomUpRecovery -> resourceInitiatedRecoveryForRecoveryHelpers -> xaRecovery 
> if (_xidScans == null)
> 				_xidScans = new Hashtable<XAResource,RecoveryXids>();
> What I am not sure of is whether we should synchronize bottomUpRecovery and getNewXAResource as that would stop this race condition. Gonna give that a whirl.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

More information about the jbossts-issues mailing list