Derby
  1. Derby
  2. DERBY-4731

XA two phase commit with active GLOBAL TEMPORARY TABLE causes An internal error identified by RawStore module

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.1.0, 10.7.1.1
    • Component/s: JDBC
    • Labels:
      None
    • Issue & fix info:
      High Value Fix, Repro attached, Workaround attached
    • Bug behavior facts:
      Crash, Deviation from standard, Seen in production

      Description

      If an XA two phase commit is performed while an GLOBAL TEMPORARY TABLE is active, it will fail with:
      XAER_RMERR
      Exception in thread "main" javax.transaction.xa.XAException: An internal error w
      as identified by RawStore module.
      at org.apache.derby.jdbc.EmbedXAResource.wrapInXAException(EmbedXAResour
      ce.java:820)
      at org.apache.derby.jdbc.EmbedXAResource.commit(EmbedXAResource.java:143
      )
      at ReproXATempTable.tempTableInXA(ReproXATempTable.java:51)
      at ReproXATempTable.main(ReproXATempTable.java:14)
      Caused by: java.sql.SQLTransactionRollbackException: An internal error was ident
      ified by RawStore module.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLE
      xceptionFactory40.java:88)
      at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)

      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException
      (TransactionResourceImpl.java:391)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Tr
      ansactionResourceImpl.java:346)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConne
      ction.java:2269)
      at org.apache.derby.impl.jdbc.EmbedConnection.xa_commit(EmbedConnection.
      java:2924)
      at org.apache.derby.jdbc.XATransactionState.xa_commit(XATransactionState
      .java:339)
      at org.apache.derby.jdbc.EmbedXAResource.commit(EmbedXAResource.java:141
      )
      ... 2 more
      Caused by: java.sql.SQLException: An internal error was identified by RawStore m
      odule.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExc
      eptionFactory.java:45)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransport
      AcrossDRDA(SQLExceptionFactory40.java:119)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLE
      xceptionFactory40.java:70)
      ... 9 more
      Caused by: ERROR 40XT0: An internal error was identified by RawStore module.
      at org.apache.derby.iapi.error.StandardException.newException(StandardEx
      ception.java:276)
      at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java:18
      09)
      at org.apache.derby.impl.store.raw.xact.Xact.addContainer(Xact.java:1357
      )
      at org.apache.derby.impl.store.access.heap.Heap.create(Heap.java:274)
      at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.creat
      eConglomerate(HeapConglomerateFactory.java:195)
      at org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(
      RAMTransaction.java:823)
      at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.clean
      upTempTableOnCommitOrRollback(GenericLanguageConnectionContext.java:1345)
      at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCom
      mit(GenericLanguageConnectionContext.java:1263)
      at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.xaCom
      mit(GenericLanguageConnectionContext.java:1160)
      at org.apache.derby.impl.jdbc.EmbedConnection.xa_commit(EmbedConnection.
      java:2921)
      ... 4 more

      See attached program for reproduction.
      javac -g ReproXATempTable.java utilXid.java
      java ReproXATempTable

      To work around the issue, you can drop the temp table before ending the xa transaction.

      1. derby_4731_3.diff
        9 kB
        Mike Matrigali
      2. backport10_3.diff
        12 kB
        Mike Matrigali
      3. derby_4731_2.diff
        14 kB
        Mike Matrigali
      4. derby_4731.diff
        8 kB
        Mike Matrigali
      5. ReproXATempTableAssert.java
        6 kB
        Kathey Marsden
      6. utilXid.java
        1 kB
        Kathey Marsden
      7. ReproXATempTable.java
        6 kB
        Kathey Marsden

        Issue Links

          Activity

          Hide
          Mike Matrigali added a comment -

          fixed and backported to 10.3, 10.4, 10.5, and 10.6

          Show
          Mike Matrigali added a comment - fixed and backported to 10.3, 10.4, 10.5, and 10.6
          Hide
          Mike Matrigali added a comment -

          old backported fix did not fix issue completely. New fix has so far only made it into trunk.

          Show
          Mike Matrigali added a comment - old backported fix did not fix issue completely. New fix has so far only made it into trunk.
          Hide
          Mike Matrigali added a comment -

          commited 2nd part of fix to trunk.

          svn commit
          Sending java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
          Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/XATest.java
          Transmitting file data ..
          Committed revision 965317.

          Show
          Mike Matrigali added a comment - commited 2nd part of fix to trunk. svn commit Sending java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/XATest.java Transmitting file data .. Committed revision 965317.
          Hide
          Kathey Marsden added a comment -

          I thought I would try this with DB2 and found that after the global transaction commits, the GLOBAL TEMPORARY TABLE was no longer accessible. I think that is a reasonable behavior.

          Note: In order to use global temporary tables in db2 I had to first create a user temporary table space.
          create user temporary tablespace MYTMPSPACE managed by automatic storage

          Show
          Kathey Marsden added a comment - I thought I would try this with DB2 and found that after the global transaction commits, the GLOBAL TEMPORARY TABLE was no longer accessible. I think that is a reasonable behavior. Note: In order to use global temporary tables in db2 I had to first create a user temporary table space. create user temporary tablespace MYTMPSPACE managed by automatic storage
          Hide
          Mike Matrigali added a comment -

          There is a problem with the initial fix, not sure why it only showed an error in the 10.3 backport. The
          issuem is most easily seen by the embedded run of the test case for DERBY-4743 which will pass after
          applying this fix. It does not fix the network server run of that test case.

          The temporary tables are stored in the transaction context, so using a nested transaction creates a new
          context and the work there is not reflected in the parent context.

          This patch delays the work on the XA global temporary tables until after the xa transaction has committed but before control returns to the client executing the commit.

          It passes all tests against trunk except for ttestSetPortPriority, which I believe is failing against trunk for other users.

          Show
          Mike Matrigali added a comment - There is a problem with the initial fix, not sure why it only showed an error in the 10.3 backport. The issuem is most easily seen by the embedded run of the test case for DERBY-4743 which will pass after applying this fix. It does not fix the network server run of that test case. The temporary tables are stored in the transaction context, so using a nested transaction creates a new context and the work there is not reflected in the parent context. This patch delays the work on the XA global temporary tables until after the xa transaction has committed but before control returns to the client executing the commit. It passes all tests against trunk except for ttestSetPortPriority, which I believe is failing against trunk for other users.
          Hide
          Mike Matrigali added a comment -

          10.3 backport is not working. Here is the diff of the backport.

          Show
          Mike Matrigali added a comment - 10.3 backport is not working. Here is the diff of the backport.
          Hide
          Kristian Waagan added a comment -

          This issue has the patch available flag set, but has not been resolved even though commits have been made.
          What's the status of the issue?

          Show
          Kristian Waagan added a comment - This issue has the patch available flag set, but has not been resolved even though commits have been made. What's the status of the issue?
          Hide
          Kathey Marsden added a comment -

          In general my experience has been that RMFAIL on the client means something pretty serious has happened on the server side. Was there anything in the derby.log after running the test?

          Show
          Kathey Marsden added a comment - In general my experience has been that RMFAIL on the client means something pretty serious has happened on the server side. Was there anything in the derby.log after running the test?
          Hide
          Mike Matrigali added a comment -

          I've successfully backported this all the way back to 10.4. When I try the backport to 10.3 I am getting one error in the client/server run of the new test. I don't think this is an issue with the actual change, but some fix that not made it back to the 10.3 line. It is sort of hard to prove as without the fix the test fails with the expected error that the test is exercising. The problem seems similar to DERBY-4310 but that fix is in 10.3. :

          There was 1 error:
          1) testXATempTableD4731_RawStore(org.apache.derbyTesting.functionTests.tests.jdb
          capi.XATest)java.sql.SQLException: Error executing a XAResource.commit(), server
          returned XAER_RMFAIL.
          at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExcepti
          onFactory.java:46)
          at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java
          :362)
          at org.apache.derby.client.am.Statement.close(Statement.java:506)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.doXATempTableD
          4731Work(XATest.java:1166)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.testXATempTabl
          eD4731_RawStore(XATest.java:1096)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
          :79)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
          mpl.java:43)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          Caused by: org.apache.derby.client.am.SqlException: Error executing a XAResource
          .commit(), server returned XAER_RMFAIL.
          at org.apache.derby.client.net.NetXAResource.xaRetValErrorAccumSQL(NetXAReso
          urce.java:954)
          at org.apache.derby.client.net.NetXAConnection.readCommit(NetXAConnection.ja
          va:184)
          at org.apache.derby.client.net.NetConnection.readXACommit_(NetConnection.jav
          a:1827)
          at org.apache.derby.client.am.Connection.readCommit(Connection.java:663)
          at org.apache.derby.client.am.Connection.readAutoCommit(Connection.java:657)
          at org.apache.derby.client.am.Statement.readCloseResultSets(Statement.java:1
          703)
          at org.apache.derby.client.am.Statement.readCloseResultSets(Statement.java:1
          667)
          at org.apache.derby.client.am.Statement.readClose(Statement.java:1606)
          at org.apache.derby.client.am.Statement.flowClose(Statement.java:1589)
          at org.apache.derby.client.am.Statement.closeX(Statement.java:539)
          at org.apache.derby.client.am.Statement.close(Statement.java:501)
          ... 42 more

          Show
          Mike Matrigali added a comment - I've successfully backported this all the way back to 10.4. When I try the backport to 10.3 I am getting one error in the client/server run of the new test. I don't think this is an issue with the actual change, but some fix that not made it back to the 10.3 line. It is sort of hard to prove as without the fix the test fails with the expected error that the test is exercising. The problem seems similar to DERBY-4310 but that fix is in 10.3. : There was 1 error: 1) testXATempTableD4731_RawStore(org.apache.derbyTesting.functionTests.tests.jdb capi.XATest)java.sql.SQLException: Error executing a XAResource.commit(), server returned XAER_RMFAIL. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExcepti onFactory.java:46) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java :362) at org.apache.derby.client.am.Statement.close(Statement.java:506) at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.doXATempTableD 4731Work(XATest.java:1166) at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.testXATempTabl eD4731_RawStore(XATest.java:1096) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: org.apache.derby.client.am.SqlException: Error executing a XAResource .commit(), server returned XAER_RMFAIL. at org.apache.derby.client.net.NetXAResource.xaRetValErrorAccumSQL(NetXAReso urce.java:954) at org.apache.derby.client.net.NetXAConnection.readCommit(NetXAConnection.ja va:184) at org.apache.derby.client.net.NetConnection.readXACommit_(NetConnection.jav a:1827) at org.apache.derby.client.am.Connection.readCommit(Connection.java:663) at org.apache.derby.client.am.Connection.readAutoCommit(Connection.java:657) at org.apache.derby.client.am.Statement.readCloseResultSets(Statement.java:1 703) at org.apache.derby.client.am.Statement.readCloseResultSets(Statement.java:1 667) at org.apache.derby.client.am.Statement.readClose(Statement.java:1606) at org.apache.derby.client.am.Statement.flowClose(Statement.java:1589) at org.apache.derby.client.am.Statement.closeX(Statement.java:539) at org.apache.derby.client.am.Statement.close(Statement.java:501) ... 42 more
          Hide
          Mike Matrigali added a comment -

          Backported fix #962738 from 10.6 codeline to 10.4 codeline.

          m104_ibm16:23>svn commit

          Sending java\engine\org\apache\derby\impl\sql\conn\GenericLanguageConnectionContext.java
          Sending java\engine\org\apache\derby\jdbc\EmbedXAResource.java
          Sending java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\XATest.java
          Transmitting file data ...
          Committed revision 963099.

          Show
          Mike Matrigali added a comment - Backported fix #962738 from 10.6 codeline to 10.4 codeline. m104_ibm16:23>svn commit Sending java\engine\org\apache\derby\impl\sql\conn\GenericLanguageConnectionContext.java Sending java\engine\org\apache\derby\jdbc\EmbedXAResource.java Sending java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\XATest.java Transmitting file data ... Committed revision 963099.
          Hide
          Mike Matrigali added a comment -

          Backported fix #962738 from 10.6 codeline to 10.5 codeline.

          m105_jdk16:17>svn commit
          Sending .
          Sending java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
          Sending java/engine/org/apache/derby/jdbc/EmbedXAResource.java
          Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/XATest.java
          Transmitting file data ...
          Committed revision 962770.

          Show
          Mike Matrigali added a comment - Backported fix #962738 from 10.6 codeline to 10.5 codeline. m105_jdk16:17>svn commit Sending . Sending java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java Sending java/engine/org/apache/derby/jdbc/EmbedXAResource.java Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/XATest.java Transmitting file data ... Committed revision 962770.
          Hide
          Mike Matrigali added a comment -

          backported to 10.6 codeline.

          m106_jdk16:47>svn commit
          Sending java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
          Sending java/engine/org/apache/derby/jdbc/EmbedXAResource.java
          Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/XATest.java
          Transmitting file data ...
          Committed revision 962738.

          Show
          Mike Matrigali added a comment - backported to 10.6 codeline. m106_jdk16:47>svn commit Sending java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java Sending java/engine/org/apache/derby/jdbc/EmbedXAResource.java Sending java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/XATest.java Transmitting file data ... Committed revision 962738.
          Hide
          Mike Matrigali added a comment -

          committed fix to trunk:

          s1_ibm16:17>svn commit

          Sending java\engine\org\apache\derby\impl\sql\conn\GenericLanguageConnectionContext.java
          Sending java\engine\org\apache\derby\jdbc\EmbedXAResource.java
          Sending java\testing\org\apache\derbyTesting\functionTests\tests\jdbcap\XATest.java
          Transmitting file data ...
          Committed revision 961511.

          Show
          Mike Matrigali added a comment - committed fix to trunk: s1_ibm16:17>svn commit Sending java\engine\org\apache\derby\impl\sql\conn\GenericLanguageConnectionContext.java Sending java\engine\org\apache\derby\jdbc\EmbedXAResource.java Sending java\testing\org\apache\derbyTesting\functionTests\tests\jdbcap\XATest.java Transmitting file data ... Committed revision 961511.
          Hide
          Mike Matrigali added a comment -

          derby_4731_2.diff is my proposed fix for this issue. It fixes the raw store error on commit. It does not fix the assert caused by the other test case. I am going to report a new JIRA to track that assert test case. In insane mode that the prepare returns XA_RDONLY which I think is the right return for that case as no "real" updates have happened.

          Show
          Mike Matrigali added a comment - derby_4731_2.diff is my proposed fix for this issue. It fixes the raw store error on commit. It does not fix the assert caused by the other test case. I am going to report a new JIRA to track that assert test case. In insane mode that the prepare returns XA_RDONLY which I think is the right return for that case as no "real" updates have happened.
          Hide
          Mike Matrigali added a comment -

          This patch does the work of temp table cleanup on commit during an XA commit in a nested updatable user transaction. I believe it is ok to do this in a nested transaction
          for XA because it does the right thing in both possible cases:
          1) If the XA transaction commits successfully then the same work has been done.
          Because of where it is done in the code, the committing user can never get access
          to the global temp tables between the time the nested xact commits and the XA
          transaction commits.
          2) If the XA transaction fails to commit somehow, then I think one of two things will happen:
          a) the session will go away, and then it does not matter what happens to the session
          life objects.
          b) the transaction will rollback, and on commit work which deleted the rows is the
          same work that needs to get done on rollback.

          The only locks the nested transaction gets is created new containers, so there should
          be no problem with lock contention of the work with either the parent transaction, or
          any other transactions.

          It fixes the xtestXATempTableD4731_RawStore()
          fixture, but does not fix the xtestXATempTableD4731_Assert.
          It also passes full set of tests.

          I have not debugged the xtestXATempTableD4731_Assert case.

          Show
          Mike Matrigali added a comment - This patch does the work of temp table cleanup on commit during an XA commit in a nested updatable user transaction. I believe it is ok to do this in a nested transaction for XA because it does the right thing in both possible cases: 1) If the XA transaction commits successfully then the same work has been done. Because of where it is done in the code, the committing user can never get access to the global temp tables between the time the nested xact commits and the XA transaction commits. 2) If the XA transaction fails to commit somehow, then I think one of two things will happen: a) the session will go away, and then it does not matter what happens to the session life objects. b) the transaction will rollback, and on commit work which deleted the rows is the same work that needs to get done on rollback. The only locks the nested transaction gets is created new containers, so there should be no problem with lock contention of the work with either the parent transaction, or any other transactions. It fixes the xtestXATempTableD4731_RawStore() fixture, but does not fix the xtestXATempTableD4731_Assert. It also passes full set of tests. I have not debugged the xtestXATempTableD4731_Assert case.
          Hide
          Kathey Marsden added a comment -

          I checked in fixtures for the RawStore error and the the Assert case to XATest. The fixtures are xtestXATempTableD4731_RawStore() and xtestXATempTableD4731_Assert and can be enabled by removing the 'x' in front.

          Show
          Kathey Marsden added a comment - I checked in fixtures for the RawStore error and the the Assert case to XATest. The fixtures are xtestXATempTableD4731_RawStore() and xtestXATempTableD4731_Assert and can be enabled by removing the 'x' in front.
          Hide
          Kathey Marsden added a comment - - edited

          Attaching perhaps another manifestation of the issue which gives an assert on the prepare. The only difference that there the Assert case does not do logged work (creating a table) in the the transaction. This one also requires the utilXid class.

          java ReproXATempTableAssert
          ot 1rows from session.t1 before commit
          Exception in thread "main" org.apache.derby.shared.common.sanity.AssertFailure:
          ASSERT FAILED real connection should have been idle at this point
          at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityMana
          er.java:120)
          at org.apache.derby.jdbc.EmbedXAResource.prepare(EmbedXAResource.java:29
          )
          at ReproXATempTableAssert.tempTableInXA(ReproXATEmpTableAssert.java:54)
          at ReproXATempTableAssert.main(ReproXATEmpTableAssert.java:14)
          --------------
          tack traces for all live threads:
          [snip thread dump]

          I will add the two test cases as Junit fixtures to XATest but not enable them for now.

          Show
          Kathey Marsden added a comment - - edited Attaching perhaps another manifestation of the issue which gives an assert on the prepare. The only difference that there the Assert case does not do logged work (creating a table) in the the transaction. This one also requires the utilXid class. java ReproXATempTableAssert ot 1rows from session.t1 before commit Exception in thread "main" org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED real connection should have been idle at this point at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityMana er.java:120) at org.apache.derby.jdbc.EmbedXAResource.prepare(EmbedXAResource.java:29 ) at ReproXATempTableAssert.tempTableInXA(ReproXATEmpTableAssert.java:54) at ReproXATempTableAssert.main(ReproXATEmpTableAssert.java:14) -------------- tack traces for all live threads: [snip thread dump] I will add the two test cases as Junit fixtures to XATest but not enable them for now.
          Hide
          Mike Matrigali added a comment -

          I verified the bug is reproducible against trunk using the attached test case.

          The stores support of XA enforces certain protocols. After a transaction has been prepared, no further activity on that transaction is expected. The raw store enforces this by checking the state of the transaction for all logged operations. It will throw a protocol error if any logged operation is attempted
          after the transaction has moved into PREPARE state. This is the situation that the test case is
          causing.

          In this case the global temporary table has been declared to not be logged and on commit to delete all the rows in the table. It looks like the code to do this did not take into account XA transactions. To
          provide the expected behavior with no logging, the SQL layer determines at commit time if any
          temp tables will need fix up, and in the case of delete on commit it implements this by creating new
          empty containers and substituting these for the existing containers. This action of creating a container
          after the prepare is caught by store and the error is thrown.

          I am not sure the right fix, but here are some options:

          1) somehow figure out how to move the work to prepare, rather than commit - so that there is no
          work to do at commit time.
          2) move the work to after the commit. I think this will mean coming up with a different transaction
          to do the work on. Need to make sure all the work is done before user gets control back.

          option 2 seems best to me, not sure how tricky it is to come up with the right transaction to use.

          Show
          Mike Matrigali added a comment - I verified the bug is reproducible against trunk using the attached test case. The stores support of XA enforces certain protocols. After a transaction has been prepared, no further activity on that transaction is expected. The raw store enforces this by checking the state of the transaction for all logged operations. It will throw a protocol error if any logged operation is attempted after the transaction has moved into PREPARE state. This is the situation that the test case is causing. In this case the global temporary table has been declared to not be logged and on commit to delete all the rows in the table. It looks like the code to do this did not take into account XA transactions. To provide the expected behavior with no logging, the SQL layer determines at commit time if any temp tables will need fix up, and in the case of delete on commit it implements this by creating new empty containers and substituting these for the existing containers. This action of creating a container after the prepare is caught by store and the error is thrown. I am not sure the right fix, but here are some options: 1) somehow figure out how to move the work to prepare, rather than commit - so that there is no work to do at commit time. 2) move the work to after the commit. I think this will mean coming up with a different transaction to do the work on. Need to make sure all the work is done before user gets control back. option 2 seems best to me, not sure how tricky it is to come up with the right transaction to use.

            People

            • Assignee:
              Mike Matrigali
              Reporter:
              Kathey Marsden
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development