|
Running JBoss 7.2 and Hibernate 4.2.0CR1 we ran into a problem where multiple commits in this manner:
tx = session.beginTransaction(); session.,saveOrUpdateobj); session.flush(); tx.commit();
back to back would result in a "Transaction is no longer valid" error for the second transaction. The cause of this exception is that the same transaction was being returned by getTransaction() inside of the session.beginTransaction().
But why should the same transaction be returned? It stems from the fact that JTA managing the transaction means we are not the initiator. So inside of the first that runs commit(), there is a check for isInitiator and if it is the initiator then a proper TransactionCoordinatorImpl.afterTransaction() should end up being called and the reset() in there causes the currentHibernateTransaction to be reset.
But because this wasn't happening, the second transaction was getting the same transaction object, but marked invalid by the invalidate() call in the commit of the first.
I worked with Steve Ebersole on IRC and we resolved upon a solution for the problem that has worked for my environment. Sorry for the lack of a "patch" file on here. I don't have the ability to create on on the system I am on. But I have attached the 3 modified files (you can diff them from 4.2.0.CR1) and I am also going to identify the changes below:
add to org.hibernate.engine.transaction.spi.TransactionCoodinator : public void afterNonInitiatorTransaction();
add to org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl: public void afterNonInitiatorTransaction() { currentHibernateTransaction = transactionFactory().createTransaction(this); if( transactionContext.shouldAutoJoinTransaction() ) { currentHibernateTransaction.markForJoin(); currentHibernateTransaction.join(); }
}
add the following method body to existing method in org.hibernate.engine.transaction.internal.jta.JtaTransaction
protected void afterTransactionCompletion(int status) { if(!isInitiator) transactionCoordinator().afterNonInitiatorTransaction(); }
This seemed to resolve the problem for us, submitting it for more formal review and inclusion as a patch.
|