No way to determine transaction timeout

[miroch41]

There used to be a quite old discussion to this topic but I have a new comment related to Atomikos Transaction Essentials 6.0.0. I would like to interrupt the application thread if the associated transaction times-out, just in order to spare computational resources: the timeout is there exactly for this purpose. There were many discussions why Atomikos does not throw an exception in this case and I more or less agree that it is neither the responsibility of Atomikos to rollback the transaction immediately after timeout, nor to throw an exception. Well, there really can be XAResources which do not like rolling-back the transaction from within another thread.

Thus, it should be an application component (for example, in Spring, JtaTransactionManager) who should initiate the rollback after timeout. And indeed, there is a configuration parameter (failEarlyOnGlobalRollbackOnly of JtaTransactionManager) influencing exactly that. However, it does not work with Atomikos. And the reason is on Atomikos side. If the application component should initiate rollback on timeout, it must have been informed that the timeout has occurred (or must be able to actively retrieve this information). But Atomikos lacks such API: if a transaction times-out, Atomikos logs the warning and adds the RollbackOnlyParticipant. Well, this effectively disallows final commit but contributes nothing to propagating the information to the outside world. Actually, the transaction remains in status TxState.ACTIVE. Maybe, because of some internal reasons, may be it is because of some application cleanup (which is doubtful, as commit is already prohibited), but it is still active.

And the outside world (e.g. JtaTransactionManager) has the only API to call: userTransaction.getStatus(). Unfortunately, as the transaction remained active after timeout occurred, nothing suspicious is revealed and JtaTransactionManager must continue as if there were no timeout. The information about timeout is just actively hidden in Atomikos.

Compare this behaviour with another situation: if the application calls userTransaction.setRollbackOnly(). Now, irrespective of the true transaction state in Atomikos, this operation sets a TxRollbackOnlyStateHandler and thus a response from call to userTransaction.getStatus() signals an intention to abort.

Threfore, IMHO, there either should be a way, how to obtain the information about TX-timeout from Atomikos, or (preferred), after transaction times-out, not only RollbackOnlyParticipant should be added but also TxRollbackOnlyStateHandler set (similar to explicit call). This no way manipulates transaction from within another thread. Alternatively, this behaviour shall be configurable.