[jbossts-issues] [JBoss JIRA] (JBTM-751) Dirty transaction remains if rollback failed

Andreas Liebscher (Commented) (JIRA) jira-events at lists.jboss.org
Wed Oct 19 12:17:45 EDT 2011 

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

Andreas Liebscher commented on JBTM-751:
----------------------------------------

The try-catch-log in BaseWrapperManagedConnection.unlock solved the problem for us with 5.1.0.GA.

As described above the bug produces threads that if used the next time throw
javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassocia
ted] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction!

Such a thread continues to handle a JMS message that will fail, because the thread does not have a valid transaction, so e.g. Hibernate will complain. The following rollback does not prevent the JMS message from being acknowledged, what seems to be another bug! This way JMS messages get lost!

The reason seems to be: Because of the NotSuportedException above LocalDemarcationsStrategy is used instead of XATransactionDemarcationStrategy (MDB).
                
> Dirty transaction remains if rollback failed
> --------------------------------------------
>
>                 Key: JBTM-751
>                 URL: https://issues.jboss.org/browse/JBTM-751
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA
>    Affects Versions: 4.6.1
>         Environment: Jboss 5.1.0GA
>            Reporter: Teofilis Martisius
>            Assignee: Jonathan Halliday
>            Priority: Minor
>              Labels: Arjuna, JTA, dirty, rollback, thread, transaction
>             Fix For: 4.14.0
>
>         Attachments: patch1, patch2
>
>
> Hi,
> I noticed that in some cases when transaction rollback fails, remaining dirty transaction is left associated with the thread when it gets returned to thread pool. Same thread gets used again producing errors. I have attached a patch I have used successfully for a while in my deployment. This patch is applicable to v4.6.1GA, but I think other versions are also affected.
> This issue gets triggered by exception like this one:
> ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (WorkManager(2)-17) Could not synchronize database state with
>  session
> org.hibernate.exception.LockAcquisitionException: could not update: [org.jbpm.graph.exe.Token#15022]
>         at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:105)
>         at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
>         at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2453)
>         at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2335)
>         at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2635)
>         at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115)
>         at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
>         at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
>         at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168)
>         at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
>         at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
>         at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027)
>         at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365)
>         at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:88)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101)
>         at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:269)
>         at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89)
>         at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1475)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137)
>         at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
>         at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:657)
>         at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:243)
>         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)
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>         at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
>         at com.mysql.jdbc.Util.getInstance(Util.java:381)
>         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1045)
>         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
>         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515)
>         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447)
>         at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951)
>         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
>         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)
>         at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761)
>         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2046)
>         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1964)
>         at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1949)
>         at com.mysql.jdbc.jdbc2.optional.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:874)
>         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
>         at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2435)
>         ... 25 more
> When same thread gets reused later, it produces following exception:
> ERROR [org.jboss.resource.adapter.jms.inflow.JmsServerSession] (WorkManager(2)-90) org.jboss.resource.adapter.jms.inflow.Jm
> sServerSession$DemarcationStrategyFactory at 42bae587 error creating transaction demarcation
> javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassocia
> ted] [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)
> If you need any help or information, feel free to contact me.
> Sincerely,
> Teofilis Martisius

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

More information about the jbossts-issues mailing list