5 Replies Latest reply on Sep 8, 2017 4:16 PM by mmusgrov

    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

        • 1. Re: runtime attributes of transactions subsystem
          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

          • 2. Re: runtime attributes of transactions subsystem
            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.)

            • 3. Re: runtime attributes of transactions subsystem
              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 ?

              • 4. Re: runtime attributes of transactions subsystem
                mmusgrov

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

                • 5. Re: runtime attributes of transactions subsystem
                  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).