Hi Claudio,

1) You can see the number of heuristics incremented in here: narayana/BasicAction.java at master · jbosstm/narayana · GitHub

2) It does. Any kind of abort will increment that counter: narayana/BasicAction.java at master · jbosstm/narayana · GitHub

It might seem unusual to consider it an application rollback rather than a system rollback but the rollback has been caused by application behaviour.

Thanks,

Tom

Tom is correct but to expand on his comment:

1) If there is a heuristic during prepare or during the commit of the first participant or during abort then we always abort and increment both the "number-of-aborted" transactions and "number-of-heuristics" counts. Otherwise (ie If the heuristic occurs after successfully committing the first participant) then we increment the "number-of-committed" transactions count as well as the "number-of-heuristics" count.

2) Yes, if the transaction times out then it counts as an application rollback (ie we increment both "number-of-application-rollbacks" and "number-of-timed-out-transactions". (As an extra I believe the only time we increment the "number-of-system-rollbacks" count is if we are unable to create a transaction log.)

Those stats look odd - let me investigate and then get back to you.

I checked it and there is an issue, we always increment the number of heuristics (once for each participant) regardless of whether or not it generated a heuristic. I raised a JIRA ([JBTM-2926] "number-of-heuristics" statistic is inaccurate - JBoss Issue Tracker ) to get it fixed.

None of the scenarios should produce heuristics so once JBTM-2926 is fixed the "number-of-heuristics" statistic will be zero.

So in scenario 1) when you clicked the successful transaction you got 6 heuristics (2 transactions and 3 participants makes 2 x 3 heuristics because of the bug).

In scenario 2) Run the "Transaction Timeout" one time

• if the transaction times out then you should see

        "number-of-aborted-transactions" => 1L,

        "number-of-application-rollbacks" => 1L, // this is different from what you report

        "number-of-timed-out-transactions" => 1L,

Without studying the details of the demo app I cannot say why "number-of-application-rollbacks" is zero - my guess is that the TM rolled back the transaction because a resource participant returned an exception when asked to commit.

But you are correct when you say that every timed-out transaction also counts as aborted (and it should also be counted as an application rollback).

And in scenario 3 a resource rollback during prepare will cause the TM to rollback the transaction and therefore the "number-of-aborted-transactions" (and number-of-resource-rollbacks) are incremented (but number-of-application-rollbacks should be unchanged).