tm.suspend does what you need, it is safe too as all it can do is return null if there is no transaction associated with the thread or the transaction object if there is one.

tm.suspend would work with Narayana as it is a JTA spec thing.

Hope that helps,

Tom

No, I said that JTA 1.1 section 3.2.2 states that rollback() disassociates the transaction with the current thread. Hence having a status of ROLLEDBACK is a getStatus() on a cached transaction handle in your code.

As Tom says tm.suspend() does a disassociate too, with a possible null return value - so that will work.

However, that isn't the point - you shouldn't cache the transaction handle in the first place. And you need to look into why there is a transaction still associated with the thread.

tm.rollback() disassociates per the spec. tx.rollback() is not required to and doesn't.

I wouldn't cache the transaction handle - if you need to check if a transaction has changed I would use a identity hash (System.identityHashCode(tx)).

However, if the reaper canceled the transaction then tm.getTransaction() should return null according to 3.2.2.

> However, if the reaper canceled the transaction then tm.getTransaction() should return null according to 3.2.2.

Nonsense. If the tx is rolledbackvia tm.rollback() then yes. Otherwise it's outside the scope of that section. The reaper does not use tm.rollback, because the tx is not associated to the reaper thread. It uses basically the internal equivalent of tx.rollback() - which takes us back to my prior post.

k, I was assuming that the reaper was using the same call path as tm.rollback().

So there are two cases then, reaper => tm.getTransaction() != null, and tm.rollback() => tm.getTransaction() == null. So the tm.suspend() call is needed if != null && ROLLBACKED.

the requirement to keep the tx context on the thread until explicitly removed actually stems from the way the JCA works

begin();

// the following sql is under the control of the JTA tx commit

doSomeSQL();

// the following sql will autocommit independent of the jta tx, which is probably not what the user wants

doSomeMoreSQL();

commit();

why? because the tx timed out and rolled back between the two SQL statements, causing the latter to revert to the connection's default auto-commit mode.  This is a Bad Thing.  Hence we don't work that way - the rolled back tx sticks around and causes the second SQL statement to fail, hopefully dropping us into an exception handler that calls rollback or suspend.  Having to clean up the context by hand is a small price to pay to being able to write code that will behave safely.  On the other hand it causes hibernate lazy loading to fail too, which causes no end of fun. You just can't win.

This is an EJB3 case

Discussion is followed up over here: how EJB3 CMT should handle different tx status flags