Uploaded image for project: 'JBoss Transaction Manager'
  1. JBoss Transaction Manager
  2. JBTM-2813

Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 5.5.0.Final
    • 5.4.0.Final
    • JTS
    • None
    • Hide

      Crashrecovery testsuite could be used for reproducing the issue (the method rmerrWithRecovery at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase needs to be unignored

      mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTA -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery
      Show
      Crashrecovery testsuite could be used for reproducing the issue (the method rmerrWithRecovery at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase needs to be unignored mvn clean verify -am -pl jbossts -DfailIfNoTests= false -fn -Djbossts.noJTA -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery

    Description

      This is a follow-up from JBEAP-6307 where change JBTM-2767 (Allow JTS JCA imported transactions to have clearHeuristic called on their participants) was part of it.

      That seems to bring wrong behavior of cli operation for listing transactions when JTS inflow txn is in use. Currently I do observe that operation [1] lists not only transactions as it should but there are listed participants of transaction as well - what is not expected.

      When inflow transaction is prepared then I can see (the testcase contains only one prepared transaction at the time which consists of two test XAResources)

      [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:probe()
{"outcome" => "success"}
[standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource()
{
    "outcome" => "success",
    "result" => {
        "expose-all-logs" => false,
        "type" => "default",
        "transactions" => {
            "0:ffff7f000001:-f30b80c:58480e0a:2c" => undefined,
            "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined,
            "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined
        }
    }
}

      My test causes that one participant ends in heuristic state thus recovery is processed only for the second one. After recovery is processed the listing changes to

      [standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:probe()
{"outcome" => "success"}
[standalone@localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource()
{
    "outcome" => "success",
    "result" => {
        "expose-all-logs" => false,
        "type" => "default",
        "transactions" => {
            "0:ffff7f000001:-f30b80c:58480e0a:26" => undefined,
            "0:ffff7f000001:-f30b80c:58480e0a:2f" => undefined
        }
    }
}

      I'm adding the content of tx-object-store at both phases and the server.log as well.

      Attachments

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-7735 Cli operation for listing transactions returns not only transactions but participants too - for JTS inflow txn

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified
          is related to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-6307 JTS: EIS can't recover transaction when heuristic outcome happens

          • Minor - To be worked after urgent, high, and medium priorities are resolved. This term is chosen when the severity of the issue is low, or the complexity or effort to correct it may be higher, relatively speaking. For low priority issues, known workarounds exist or are not needed due to the trivial effort needed to address the issue.
          • Verified

          Activity

            People

              rhn-engineering-mmusgrov Michael Musgrove
              ochaloup@redhat.com Ondrej Chaloupka (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: