[jboss-jira] [JBoss JIRA] Updated: (JBAS-5801) New ManagedConnection locking does not play nicely with transaction interleaving

[Adrian Brock (JIRA)]

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

Adrian Brock updated JBAS-5801:
-------------------------------

    Description: 
The new locking in the jms resource adapter to avoid race conditions between the asynch rollback
and the normal usage is not playing nicely with transaction interleaving.

When we are using transaction interleaving, there is no such race condition because the "normal usage"
has already been suspended and the managed connection (for normal usage) given to another transaction.

In fact, the new locking in this case could cause over contention because besides the lock being irrelevant,
it could actually cause the real current usage of the managed connection to block.

The problem has actually first show up as incorrect release of the lock:

java.lang.IllegalMonitorStateException
 at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:125)
 at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1137)
 at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
 at org.jboss.resource.adapter.jms.JmsManagedConnection.unlock(JmsManagedConnection.java:401)
 at org.jboss.resource.adapter.jms.JmsXAResource.commit(JmsXAResource.java:102)
 at org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.commit(JcaXAResourceWrapper.java:53)
 at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:502)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3107)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3022)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2126)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1819)
 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)

but this is really a symptom of taking the lock unnecessarily/wrongly in the first place
when somebody else should really own it.

The fix would be to spot that we are transaction interleaving by keeping track of the "active" xid in 
JmsXAResource wrapper and only doing the locking in the 2PC callbacks if we are the active xid.

The active xid is defined as the one on which start() has been invoked but not end().

For completeness, the same fix is also required in the jdbc xa resource adapter, 
but none of the current commercial xa datasources actually support transaction interleaving
so it is not really an issue there.

  was:
The new locking in the jms resource adapter to avoid race conditions between the asynch rollback
and the normal usage is not playing nicely with transaction interleaving.

When we are using transaction interleaving, there is no such race condition because the "normal usage"
has already been suspended and the managed connection (for normal usage) given to another transaction.

In fact, the new locking in this could cause over contention because besides the lock being irrelevant,
it could actually cause the real current usage of the managed to block.

The problem has actually first show up as incorrect release of the lock:

java.lang.IllegalMonitorStateException
 at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:125)
 at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1137)
 at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
 at org.jboss.resource.adapter.jms.JmsManagedConnection.unlock(JmsManagedConnection.java:401)
 at org.jboss.resource.adapter.jms.JmsXAResource.commit(JmsXAResource.java:102)
 at org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.commit(JcaXAResourceWrapper.java:53)
 at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:502)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3107)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3022)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2126)
 at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1819)
 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)

but this is really a symptom of taking the lock unnecessarily in the first place.

The fix would be to spot that we are transaction interleaving by keeping track of the "active" xid in 
JmsXAResource wrapper and only doing the locking in the 2PC callbacks if we are the active xid.



> New ManagedConnection locking does not play nicely with transaction interleaving
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-5801
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5801
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.0.CR1, JBossAS-4.2.3.GA
>            Reporter: Adrian Brock
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.0.0.CR2, JBossAS-4.2.4.GA
>
>
> The new locking in the jms resource adapter to avoid race conditions between the asynch rollback
> and the normal usage is not playing nicely with transaction interleaving.
> When we are using transaction interleaving, there is no such race condition because the "normal usage"
> has already been suspended and the managed connection (for normal usage) given to another transaction.
> In fact, the new locking in this case could cause over contention because besides the lock being irrelevant,
> it could actually cause the real current usage of the managed connection to block.
> The problem has actually first show up as incorrect release of the lock:
> java.lang.IllegalMonitorStateException
>  at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:125)
>  at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1137)
>  at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
>  at org.jboss.resource.adapter.jms.JmsManagedConnection.unlock(JmsManagedConnection.java:401)
>  at org.jboss.resource.adapter.jms.JmsXAResource.commit(JmsXAResource.java:102)
>  at org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.commit(JcaXAResourceWrapper.java:53)
>  at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:502)
>  at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3107)
>  at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3022)
>  at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2126)
>  at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1819)
>  at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
>  at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
> but this is really a symptom of taking the lock unnecessarily/wrongly in the first place
> when somebody else should really own it.
> The fix would be to spot that we are transaction interleaving by keeping track of the "active" xid in 
> JmsXAResource wrapper and only doing the locking in the 2PC callbacks if we are the active xid.
> The active xid is defined as the one on which start() has been invoked but not end().
> For completeness, the same fix is also required in the jdbc xa resource adapter, 
> but none of the current commercial xa datasources actually support transaction interleaving
> so it is not really an issue there.

-- 
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