runtime attributes of transactions subsystem

[claudio4j]

Hi, I am interested to better understand some runtime attributes of transactions subsystem.

1) Does the "number-of-heuristics" counts only as rollbacks ?

I did some tests with a sample application and whenever there is a

count for "number-of-heuristics" there is also a count for "number-of-aborted-transactions"

2) Does "number-of-application-rollbacks" total also counts "number-of-timed-out-transactions" ?

Thanks

Claudio

[tomjenkinson]

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

[mmusgrov]

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.)

[claudio4j]

Hello Michael, thanks for sharing your opinion. However there is some confusing numbers for the statistics I want to share with you. I run the transaction-analyser/demo at master · jbosstm/transaction-analyser · GitHub application, and these are he runtime attributes after several invocations:

1) clicked at "Successful Transaction" two times, it generates the following:

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

"number-of-application-rollbacks" => 0L,

"number-of-committed-transactions" => 2L,

"number-of-heuristics" => 6L,

"number-of-inflight-transactions" => 0L,

"number-of-nested-transactions" => 0L,

"number-of-resource-rollbacks" => 0L,

"number-of-system-rollbacks" => 0L,

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

"number-of-transactions" => 2L,

I found it strange, heuristics is 6, is that correct ?

2) Run the "Transaction Timeout" one time

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

"number-of-application-rollbacks" => 0L,

"number-of-committed-transactions" => 2L,

"number-of-heuristics" => 9L,

"number-of-inflight-transactions" => 0L,

"number-of-nested-transactions" => 0L,

"number-of-resource-rollbacks" => 0L,

"number-of-system-rollbacks" => 0L,

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

"number-of-transactions" => 3L,

Heuristics increased 3 times, aborted 1 and timed-out 1.

So, every timed-out transaction also counts as aborted ?

3) Run "Participant Fails to Prepare"

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

"number-of-application-rollbacks" => 0L,

"number-of-committed-transactions" => 2L,

"number-of-heuristics" => 12L,

"number-of-inflight-transactions" => 0L,

"number-of-nested-transactions" => 0L,

"number-of-resource-rollbacks" => 1L,

"number-of-system-rollbacks" => 0L,

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

"number-of-transactions" => 4L,

Heuristics increased 3 times, aborted 1 and resource-rollback 1.

So, every resource-rollback also counts as aborted ?

Is it safe to say

a) the sum of all *-rollbacks and timed-out should be equal to aborted transactions ?

b) the sum of aborted and committed should be equal to number of transactions ?

[mmusgrov]

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

[mmusgrov]

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).