Can't commit because the transaction is in aborted state

[javacory]

We have an application that processes many large flat files. With much of the processing we are creating container managed XA transactions that simply update an Oracle database and publish JMS messages via JBoss messaging. We are also using the same Oracle database as our JMS datastore.

Quite randomly and without reason we receive this exception:
javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:243)
at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:501)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:361)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:648)
....

This happens without a JDBC or JMS exception being thrown as the cause.

We are using:
JBoss 4.2.0 GA
Oracle 10g 10.2.0.3.0 Database
10.2.0.2.0 JDBC driver

Any help would be appreciated.

Thanks much,

Cory.

[adinn]

If your files are very large and require a long time to process then you may be running up against transaction timeouts. Check your log to see if the TransactionReaper thread has generated any messages saying that the transaction has been rolled back? If so then you need to specify a larger timeout for your transactions.

[javacory]

Thanks for the reply.

Yes, we are very familiar with the transaction timeouts. This is what we get when that happens:

java.lang.IllegalStateException: [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] The transaction is not active!; - nested throwable: (java.lang.IllegalStateException: [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] The transaction is not active!)

From the behavior of what we are seeing, it's almost like the transactional data associated with the thread is already in the "rolled back" state. Then when we go to use it in a transaction it immediately throws a "RolledBackException".

Cory.

[marklittle]

Have you checked the wiki?

[javacory]

Thanks again for the reply.

Yes, I have looked at this. I don't believe this is the issue. There is only one thread participating in the transaction and it's not a timeout scenario. The stateless session bean methods that fail normally take a max of 3-4 seconds.

We simply have a web thread that calls many stateless session bean methods that start/stop a transaction in a serial fashion. The service methods themselves execute very small transactions where we update the Oracle DB and post a message to the JMS Queue. There may be many of these web threads running at the same time, but they should obviously be starting/stopping their own transactions.

I have seen the "com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted" message before, but there is always an underlying reason ( oracle error, jms error, etc. ), but for whatever reason this scenario doesn't give a reason.

Cory.

[javacory]

The only consistency that I can find when this "randomly" happens is in the fact that when it happens we have sent multiple JMS messages. Each JMS message that gets sent is sent within its own JMS session ( not transacted ) as we expect the container XA transaction to manage that.

Does anyone know if it is a bad thing to create multiple JMS sessions under one XA transaction?

Thanks much,

Cory.