Hibernate version: 3.0rc1
JOTM: 2.0.5

Hi All,

I have an ID generator running within a JTA environment using the JOTM TransactionManager.
Subsequent to doWorkInCurrentTransaction() failing with an SQLException (due to a silly DB setup error on my part, but not the issue), the finally block attempts to resume the originally suspended transaction which is causing JOTM to throw a JTA exception on tm.resume().
The transaction on which the SQLException occurred is still in play (and bound to the current thread of execution) because the error handling code in org.hibernate.engine.TransactionHelper didn't commit it or roll it back.
Also, it should be noted that this JTA exception is effectively masking the original SQLException thereby making the cause difficult to ascertain without stepping through with a debugger.

My question is:
should tm.rollback() be called in the event of an SQLException being thrown by doWorkInCurrentTransaction()?

Let me know if more details are needed...
Thanks!

you mean that JOTM can't resume a tx context if the second tx is neither commited or rollbacked. Is it correct?

Yes, that appears to be exactly what is happening.

OK, I've patched it in my box. I'll be applied soon.