When using Spring and Atomikos, the timeout of a transaction is propagated to the next transaction in the same thread.
The problem occurs when the first transaction sets a timeout but the second one does not, leaving it as TransactionDefinition.TIMEOUT_DEFAULT.
If the timeout of the second transaction is set to zero the problem goes away.
Not sure if this is a Spring or a Atomikos bug.
Attached project shows the problem.
To my surprise, the JTA 1.2 UserTransaction.setTransactionTimeout javadoc indeed states the following: "Modify the timeout value that is associated with transactions started by the current thread with the begin method" as well as "If the value is zero, the transaction service restores the default value."
Even if Java EE arrangements typically interpret this as applying to the next transaction on the current thread only, the definition does imply that all subsequent transactions on the current thread could use this timeout. So to be on the safe side, we should explicitly reset the timeout through a setTransactionTimeout(0) call on the UserTransaction after each such transaction... I'll have a look at this for 4.3 still.
Willian Constâncio da Silva opened SPR-14239 and commented
When using Spring and Atomikos, the timeout of a transaction is propagated to the next transaction in the same thread.
The problem occurs when the first transaction sets a timeout but the second one does not, leaving it as TransactionDefinition.TIMEOUT_DEFAULT.
If the timeout of the second transaction is set to zero the problem goes away.
Not sure if this is a Spring or a Atomikos bug.
Attached project shows the problem.
Affects: 4.2.5
Attachments:
Referenced from: commits 1be544f
The text was updated successfully, but these errors were encountered: