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

[Torsten (JIRA)]

    [ https://jira.jboss.org/browse/JBAS-5801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12539452#action_12539452 ] 

Torsten commented on JBAS-5801:
-------------------------------

Just want to mention that we had a very similar issue on JBoss 4.3.0 GA_CP04 with Oracle driver 10.2.0.1.0 - about every 4th transaction failed with the IllegalMonitorStateException.

The mentioned workaround <track-connection-by-tx/> was already in place.

As a guess we updated the Oracle driver to 11.2.0.1.0 for JDK 6 - and the problem was gone.

So I guess there might have been an issue with the XA datasource in the older Oracle driver version that has been fixed.

Cheers,
Torsten

> New ManagedConnection locking does not play nicely with transaction interleaving
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-5801
>                 URL: https://jira.jboss.org/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: Adrian Brock
>             Fix For: JBossAS-5.0.0.CR2
>
>
> 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/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira