JTS vs. JTA transaction timeout behavior during 2PC prepare

[ochaloup]

Hi guys,

I have here another question on behavior of TM. Now it's about transaction timeout. I do have a test which simulates a transaction being timeouted during prepare phase of 2PC. In my case just prepare phase takes long enough to transaction time to live expires.

I can observe different behavior of JTA and JTS implementation

For JTA it just ignores the fact that timeout occurs. The prepare phase waits till process which delays processing is finished and then transaction is committed.

For JTS timeout is counted and if occurs (either it's hit in prepare phase) the transaction is rollbacked.

I would like just check if this is correct from your point of view? Especially the JTA behavior.

Thanks for your input

Ondra

[marklittle]

Have you confirmed this behaviour with the unit tests in the repo? Sounds very strange to me the way you are describing it because a timeout mandates the transaction rolls back as long as it has not got past the prepare phase.

[ochaloup]

Ok, I see. Till prepare phase does not end the hitting timeout time should cause that transaction is aborted.

Nope, I haven't run unit tests. But I can try. My test runs as integration ones with WFLY.

Thank you. hope looking at it at the start of the next.

[ochaloup]

Ok, I've investigated a bit more on this issue and those my observations.

What I can say the transaction timeout is considered for txn reaper rolling back the transaction till time first XAResource is prepared. It means if transaction timeout occurs at the start of 2PC prepare phase where no XAResource was successfully prepared t hen transaction is aborted. If transaction timeout occurs during 2PC prepare phase when any XAResource was successfully prepared then the transaction continues to finish with commit. Could this be considered correct?

I've found out that the trouble that I've referred to was problematic as it was more complicated. I haven't realized that the core of difference is that I've used distributed transaction. One server pass to second one and transaction timeouts on the second one. Then I could see the difference between JTA and JTS where JTA commits and JTS rolls back.

After checking logs I can say that the reason why JTS rolls back is that underlying local JMS transactions timeouts before XAResource.prepare is called.  Then the prepare fails with XAException.XAER_NOTA (discussed at https://developer.jboss.org/thread/269850). Meaning prepare fails and transaction abort is then called. Transaction itself tries to process with commit just as one XAResource fails it fails whole txn.

Interesting is that when JTA is play the jms broker local transaction is not aborted. It seems that subordinate transaction does not call setTransactionTimeout on XAResources it manages when JTA is used. It can be seen in log files that enlisted XAResources does not possess the timeout value which global txn has. I've created a jira on this as I consider it as an issue: JBTM-2674 If you don't agree with me, please, feel free to reject it.

My simpler additional test is following

Running on one server, behavior is the same for JTA and JTS.

• enlist test xa resource
• enlist jms xa resource
• prepare test xa resource
• before jms xa resource is prepared, transaction expires (timeout is hit)
• as this waits  at the start of jms  xa resource prepare method timeout occurs on jms broker local transaction as well
• jms broker local transaction is removed from broker transaction log
• jms xa resource prepare call is finished and XAER_NOTA returned
• with such error returned on XAResource.prepare transaction as whole is aborted

So far I haven't found any data inconsistency that would be caused by the current behavior.

My tests are JBoss EAP integration tests.

For looking on an unit test I would need some guide where to start. What are tests which touching this behavior.

[marklittle]

One of the things we try very hard to avoid is generating heuristics. If you check the docs you'll see that any resource can autonomously commit or roll back after it has prepared, and in a distributed environment it's much more likely. I haven't checked the code but I suspect in JTS we are just trying really hard to commit the transaction after prepare irrespective of the timeout because of the inherent risk of causing a heuristic decision.

[ochaloup]

Ok, I see and I do understand.

The behavior is expected as commit of the transaction is preferred way.

Thank you for clarification.