Hi,
I have noticed the following behaviour while using TransactionTemplate with Spring JTA Transaction Manager backed up by Atomikos and Hibernate as JPA provider.
Within a transaction scoped through a transaction template, two entities are persisted into two different data stores, each entity managed by a different entity manager factory. The thread sleeps for a second more than the transaction timeout before exiting. Atomikos clearly marks the transaction coordinator implementation as rollback only as soon as the transaction timeout expires.
But the transaction template code is unaware of this status and proceeds calling commit() on the transaction manager. In the commit() implementation of Spring's JTATransactionManager, a check is of course implemented to ensure that the underlying user transaction status is not for rollback only. If so, it raises an UnexpectedRollbackException with a message suggesting that it may be due to a timeout.
However, the entities are persisted into the database successfully. Atomikos logs that the application has done a commit, even though the afterCompletion() logs has all of the transaction statuses as STATUS_ROLLEDBACK.
The question I have is, is it an appropriate implementation for the TransactionTemplate to call commit() when the underlying transaction has been marked as rollback only? Should it rather not assert the underlying transaction status before making that decision?
I have noticed the following behaviour while using TransactionTemplate with Spring JTA Transaction Manager backed up by Atomikos and Hibernate as JPA provider.
Within a transaction scoped through a transaction template, two entities are persisted into two different data stores, each entity managed by a different entity manager factory. The thread sleeps for a second more than the transaction timeout before exiting. Atomikos clearly marks the transaction coordinator implementation as rollback only as soon as the transaction timeout expires.
But the transaction template code is unaware of this status and proceeds calling commit() on the transaction manager. In the commit() implementation of Spring's JTATransactionManager, a check is of course implemented to ensure that the underlying user transaction status is not for rollback only. If so, it raises an UnexpectedRollbackException with a message suggesting that it may be due to a timeout.
However, the entities are persisted into the database successfully. Atomikos logs that the application has done a commit, even though the afterCompletion() logs has all of the transaction statuses as STATUS_ROLLEDBACK.
The question I have is, is it an appropriate implementation for the TransactionTemplate to call commit() when the underlying transaction has been marked as rollback only? Should it rather not assert the underlying transaction status before making that decision?