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

CMR recovery wrongly handles commit and rollback

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 5.5.33.Final, 5.9.0.Final
    • 5.8.1.Final
    • JTA
    • None
    • Hide 
      git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git
export JBOSS_HOME=<<path to WFLY13>>

# unignore tests of jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/test/JPACMRCrashRecoveryTestCase.java marked with JBEAP-6326

DS_PROPS="-Dds0.db=oracle -Dds0.jdbc.driver.url=http://www.qa.jboss.com/jdbc-drivers-products/EAP/7.1.0/oracle12c/jdbc4/ojdbc8.jar -Dds0.jdbc.xa-class=oracle.jdbc.xa.client.OracleXADataSource -Dds0.jdbc.url=jdbc:oracle:thin:@dev151.mw.lab.eng.bos.redhat.com:1521:qaora12 -Dds0.db.name=qaora12 -Dds0.user=crashrec -Dds0.pass=crashrec -Dds0.jdbc.driver.jar=dsdriver-oracle.jar"
mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Dtest=JPACMRCrashRecoveryTestCase#commitHaltAfterCMR -Djbossts.noJTS -Dno.cleanup.at.teardown=true $DS_PROPS
      Show
      git clone http: //git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=<<path to WFLY13>> # unignore tests of jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/test/JPACMRCrashRecoveryTestCase.java marked with JBEAP-6326 DS_PROPS= "-Dds0.db=oracle -Dds0.jdbc.driver.url=http: //www.qa.jboss.com/jdbc-drivers-products/EAP/7.1.0/oracle12c/jdbc4/ojdbc8.jar -Dds0.jdbc.xa-class=oracle.jdbc.xa.client.OracleXADataSource -Dds0.jdbc.url=jdbc:oracle:thin:@dev151.mw.lab.eng.bos.redhat.com:1521:qaora12 -Dds0.db.name=qaora12 -Dds0.user=crashrec -Dds0.pass=crashrec -Dds0.jdbc.driver.jar=dsdriver-oracle.jar" mvn clean verify -am -pl jbossts -DfailIfNoTests= false -Dtest=JPACMRCrashRecoveryTestCase#commitHaltAfterCMR -Djbossts.noJTS -Dno.cleanup.at.teardown= true $DS_PROPS

    Description

      The recovery of CMR works wrongly.

      For scenario I currently investigate there is issue the second resource beging committed and rolled-back too.

      1. cmr resource prepare (no real action on the local transction)
      2. xa resource prepare (prepared in real as XA)
      3. cmr resource commit (commiting the local transaction)
      4. JVM crash
      5. expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue.

      This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed.

      This is regression against EAP 7.0.0. The same scenario works in 7.0.0 smoothly.

      Attachments

        Issue Links

          causes

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-15059 (7.1.z) Transaction manager CMR wrongly handles commit of periodic recovery

          • 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.
          • Closed
          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. JBTM-3061 CMR recovery wrongly handles commit and rollback

          • 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.
          • Closed
          relates to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-6326 Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Verified

          Bug - A problem that impairs or prevents the functions of the product. JBTM-2734 EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed

          Activity

            People

              ochaloup@redhat.com Ondrej Chaloupka (Inactive)
              ochaloup@redhat.com Ondrej Chaloupka (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: