Connection with associated transaction in invalid state is placed back in the pool?

[ksengupta]

We have a customer implemented on 4.2.2 and MSSql 2005. They intermittantly get the following exception in the UI.

java.lang.RuntimeException: Error obtaining connection: org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: a121b27:554e:4a165703:2cef816 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: a121b27:554e:4a165703:2cef816 status: ActionStatus.ABORT_ONLY >))

This implies that a connection with invalid transaction is put back in the connection pool and when a new connection is requested using the data source and the same transaction is returned from the pool we get the above exception.

Is this a bug in the jboss code? Or is there are way by which we can correct this?

We tried to catch the exception in the our factory class which gets the connections. In the catch block we invoke the flush method of the ConnectionPoolManager Mbean. But this seems to be a little risky.

Please suggest if there is a patch or a workaround for this issue?

[marklittle]

As the error indicates, the transaction associated with the thread has been marked as rollback-only. That means any attempt to do further work within the scope of that transaction will fail. That's not a bug in the code: it's a clear attempt by the transaction system to ensure data integrity.

You need to figure out why the transaction has been marked for rollback-only. It could be as relatively simple as the fact that the transaction has timed out, in which case either decrease the amount of work done within that transaction or increase the timeout associated with it. Or it could be something else, in which case attach a debugger (or turn on debug in the logger).

[ksengupta]

Thanks Mark. It is indeed due to transaction timeout. But the question here is when the associated transaction is marked as rollback-only, how does the connection make its way back to the pool?

[mmusgrov]

What are the other errors in the stack trace.

[marklittle]

What makes you think it's being put back into the pool?

[ksengupta]

Because the exception is thrown when a connection is requested from the DataSource.

ds.getConnection();

[marklittle]

Have you tried this with a more up-to-date version of JBossAS?

[ksengupta]

The version of our product supports Jboss 4.2.2 only and many customers are using this configuration. Even if higher Jboss version solves the problem we cannot advise that. That is why we are trying to see if this kind of issue has been reported and a patch is available for Jboss 4.2.2

[mmusgrov]

The stack trace says "see the previous warnings". What were these warnings?

[marklittle]

Try a later version yourself. If it's not a problem there then you can work backwards.

[jhalliday]

> Unabled to enlist resource... status: ActionStatus.ABORT_ONLY

> This implies that a connection with invalid transaction is put back in the connection pool and when a new connection is requested using the data source and the same transaction is returned from the pool we get the above exception.

No it doesn't. There is no indication the connection itself is at fault - it may be valid and usable. Connections in the pool are not associated to any tx- the association happens at checkout time and connections are not returned to the pool until disassociated.

.

It's not spec compliant to enlist a resource into a transaction that has been marked rollback only - hence the error. To avoid this problem you should check the transaction status before calling getConnection or doing anything else that may enlist a resource.

[ksengupta]

Thanks, I will try it out and update the thread with both the suggestions.