On Aug 18, 2006, at 5:36 PM, Cameron, David A wrote:


I'm using GeronimoTransactionManager with Jencks 1.2, ActiveMQ 4.0 and a third-party XA capable database.

What I'm seeing is during the prepare phase of the commit the third-party database XAResource is throwing an XAException which causes the TransactionManager to roll back the transaction.

It appears that the TransactionManager seems to be getting confused during the course of the rollback.

I can see that TransactionImpl.commit detected the failure, set it's status to STATUS_MARKED_ROLLBACK, rolled back the remaining resource then threw a RollbackException.

Before this the jvm goes to unwind the stack it calls the finally of TransactionImpl.commit which sets the status to STATUS_NO_TRANSACTION.

InheritableTransactionContext.complete catches this exception as Throwable then calls rollbackAndThrow.

rolllbackAndThrow seems to get into trouble by calling rollback on the transaction which is also STATUS_NO_TRANSACTION.

This is where it throws an IllegalStateException becausee rollback was called on something that no longer had a transaction in process.

Am I missing something in the config of the TransactionManager?

As I read this blow-by-blow I come to realize that rollbackAndThrow is attempting to roll back a transaction that is already cleaned up.  Should I just add a check if that transaction has been cleaned up before it calls rollback on it?  It just looks like the transaction has been rolled back and has been asked to roll back again.

Any suggestions on workarounds or a compatible version where this is fixed would be appreciated.

I've seen this or a similar problem too IIRC.  Does it cause an actual error in your code or just an annoying error message to be logged?

I think that the latest code does away with the TransactionContextManager entirely which might remove this problem.  However I don't think this version of jencks has been released: certainly the geronimo code it uses hasn't been released officially.

I think we could still patch the geronimo code similar to what's used in jencks 1.2 to avoid this problem in the g 1.1.2 release.

I suspect the final call to rollback can be removed entirely.  What do you think?  

david jencks