3:29 p.m.
Tom Jenkinson created JBTM-1354:
-----------------------------------
Summary: 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
3:41 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
Tom Jenkinson commented on JBTM-1354:
-------------------------------------
Can't lock bottomUp as other thread needs to be able to get in there and
getNewXAResource so end up with deadlock
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
3:55 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
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
5:34 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1354:
--------------------------------
Component/s: JCA
JTA
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)
Components: JCA, JTA
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
5:34 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1354:
--------------------------------
Component/s: Recovery
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)
Components: JCA, JTA, Recovery
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
5:36 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1354:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/150/
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)
Components: JCA, JTA, Recovery
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
3 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1354:
--------------------------------
Status: Pull Request Sent (was: Pull Request Sent)
Git Pull Request: https://github.com/jbosstm/narayana/pull/150/,
https://github.com/jbosstm/narayana/pull/156 (was:
https://github.com/jbosstm/narayana/pull/150/)
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)
Components: JCA, JTA, Recovery
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
12:58 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
Tom Jenkinson edited comment on JBTM-1354 at 11/29/12 6:58 AM:
---------------------------------------------------------------
testSimultaneousRecover 0
was (Author: tomjenkinson):
simpleisolatedservers 0
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)
Components: JCA, JTA, Recovery
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
12:58 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
Tom Jenkinson commented on JBTM-1354:
-------------------------------------
simpleisolatedservers 0
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)
Components: JCA, JTA, Recovery
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
12:38 p.m.
[
https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated JBTM-1354:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
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)
Components: JCA, JTA, Recovery
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
4166
days inactive
4170
days old
jbossts-issues@lists.jboss.org
9 comments
1 participants
participants (1)
-
Tom Jenkinson (JIRA)