RE: GeronimoTransactionManager IllegalStateException: Status is STATUS_NO_TRANSACTION

[Cameron, David A]

I honestly can't say that I understand why that final rollback is even there or if there are cases where it actually does perform the rollback.  It certainly is redundant in the scenario I'm seeing.   My gut says to fix it for the scenario and not remove something that may have a purpose.  What I would do is add a check to verify that the TransactionImpl is not in STATUS_NO_TRANSACTION status before trying to roll it back.  It has other, similar checks already.  Just not that one.   I'm going to be looking into getting a build of the Geronimo Transaction Manager this morning.  If that work I can try to come up with a patch of some sort. From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 6:05 PM To: user@geronimo.apache.org Subject: Re: GeronimoTransactionManager IllegalStateException: Status is STATUS_NO_TRANSACTION On Aug 18, 2006, at 5:36 PM, Cameron, David A wrote: Hi, 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?   thanks david jencks Thanks! Dave