Hi,

Can anyone shed some light on this:

It appears that if the transaction manager is unable to rollback a transaction on MySQL connector, possibly because the server has died or because a lock is held on a resource by another transaction, that the thread is returned to the pool while still associated with the transaction.

Actually, I cannot be sure of the reason as I've never been able to reproduce the problem in a controlled manner. I would have attached a unit test if I could have. The last time we saw it was due to MySQL going down while there were something in the region of 100 transactions active.

In any case the problem is genuine. In the exception (below) you can see that the JMS resource adapter acquires a thread from the JCA thread pool and finds that it's already associated with a transaction. Once the problem occurs, the thread is rendered useless and every time it's fetched from the pool it will cause the JMS consumer to throw the same exception.

My colleague reported this on JIRA and the issue was rejected because it was not reproducible. I appreciate this as we do the same: we reject issues that we cannot reproduce. However, regardless of how the problem manifests, the fact that a thread acquired from the JCA thread pool has not been correctly disassociated, would suggest that Arjuna is failing to clean-up the thread in certain conditions.

(https://issues.jboss.org/browse/JBTM-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587110#comment-12587110)

The fact is that a thread should never be returned to the pool when it's still associated with a transaction.

How are failed rollbacks handled by Arjuna? Are there any cases where a thread might be returned to the pool in a dirty state?

Thanks,

Kayvan

Environment:

JBoss-5.1.0.GA

MySQL 5.1.x (XA Connector)

JBoss Messaging (JmsXA)

2011-03-10 09:03:33,124 ERROR [JmsServerSession] (WorkManager(2)-165) org.jboss.resource.adapter.jms.inflow.JmsServerSession$DemarcationStrategyFactory@2fa10a9d error creating transaction demarcation

javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction!

        at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:80)

        at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:65)

        at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.<init>(JmsServerSession.java:560)

        at org.jboss.resource.adapter.jms.inflow.JmsServerSession$DemarcationStrategyFactory.getStrategy(JmsServerSession.java:295)

        at org.jboss.resource.adapter.jms.inflow.JmsServerSession.createTransactionDemarcation(JmsServerSession.java:252)

        at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:224)

        at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)

        at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)

        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

        at java.lang.Thread.run(Thread.java:619)