Derby
  1. Derby
  2. DERBY-246

XA end() fails with Connection is closed error

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.1.1.0
    • Fix Version/s: 10.1.1.0
    • Component/s: Network Client
    • Labels:
      None
    • Environment:
      I am using the 10.1.0 alpha build.

      Description

      I am testing ClientXADataSource.
      It fails when end() is called - here is the output fromn my test program.

      Running test org.simplejta.xatests.common.Test1
      autocommit = false
      No of rows Affected 1
      autocommit = true
      No of rows Affected 1
      org.apache.derby.client.am.XaException: XAER_RMFAIL : Connection is Closed.
      at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown Source)
      at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown Source)
      at org.apache.derby.client.net.NetXAResource.connectionClosedFailure(Unknown Source)
      at org.apache.derby.client.net.NetXAResource.end(Unknown Source)
      at org.simplejta.xatests.common.Test1.doTest(Test1.java:52)
      at org.simplejta.tests.DerbyClientTests.main(DerbyClientTests.java:66)
      Caused by: org.apache.derby.client.am.SqlException: Connection is Closed.
      ... 4 more
      Test org.simplejta.xatests.common.Test1 failed

      The test program is:

      /*

      • Test case for multiple logical connections between start() and end().
        */
        package org.simplejta.xatests.common;

      import java.sql.Connection;
      import java.sql.SQLException;
      import java.sql.Statement;

      import javax.sql.XAConnection;
      import javax.sql.XADataSource;
      import javax.transaction.xa.XAResource;
      import javax.transaction.xa.Xid;

      public class Test1 extends TestCase {

      public void doTest(XADataSource ds) throws Exception

      { // Get a XA connection to the underlying data source XAConnection pc1 = ds.getXAConnection(); // Get the XA Resource XAResource xar1 = pc1.getXAResource(); // Create an Xid Xid xid1 = Utils.createXid(1); // Start the XA transaction xar1.start(xid1, XAResource.TMNOFLAGS); // Get a Logical Connection Connection conn1 = pc1.getConnection(); System.out.println("autocommit = " + conn1.getAutoCommit()); // Do something with conn1 doSomeWork1(conn1, 50); // Close the logical connection conn1.close(); // Get another logical connection conn1 = pc1.getConnection(); System.out.println("autocommit = " + conn1.getAutoCommit()); // Do something with conn1 doSomeWork1(conn1, 51); // Close the logical connection conn1.close(); // END the branche xar1.end(xid1, XAResource.TMSUCCESS); // Prepare the RMs int prp1 = xar1.prepare(xid1); // Commit transaction xar1.commit(xid1, false); // Close physical connection pc1.close(); }

      private void doSomeWork1(Connection conn, int deptno) throws SQLException

      { Statement stmt = conn.createStatement(); int cnt = stmt .executeUpdate("INSERT INTO dept VALUES (" + deptno + ", 'BSD', 'LONDON')"); System.out.println("No of rows Affected " + cnt); stmt.close(); stmt = null; }

      }

      This test works fine with EmbeddedXADataSource. It also works fine with Oracle.

      Also, note that this error seems similar to the error I am getting with DB2 using the DB2 type 4 driver.

      Running test org.simplejta.xatests.common.Test1
      autocommit = false
      No of rows Affected 1
      autocommit = false
      No of rows Affected 1
      com.ibm.db2.jcc.b.de: XAER_RMFAIL : Connection is Closed. : Exception from native code during XA
      at com.ibm.db2.jcc.uw.UWXAResource.a(UWXAResource.java:695)
      at com.ibm.db2.jcc.uw.UWXAResource.a(UWXAResource.java:709)
      at com.ibm.db2.jcc.uw.UWXAResource.end(UWXAResource.java:227)
      at org.simplejta.xatests.common.Test1.doTest(Test1.java:52)
      at org.simplejta.tests.DB2Tests.main(DB2Tests.java:65)
      Caused by: com.ibm.db2.jcc.b.SqlException: Connection is Closed.
      at com.ibm.db2.jcc.uw.UWXAResource.a(UWXAResource.java:705)
      ... 3 more
      Test org.simplejta.xatests.common.Test1 failed

      Curiously, the error appears to corrupt the database. Subsequent attempts to start the database gives an error.

      org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ040, SQLERRMC: tca[..snip..]XJ040.C..[snip]..STB0:XSTB0.M..[snip]..led to start database 'tca', see the next exception for details...[snip]..An exception was thrown during transaction abort...[snip]..(server log:c:\derby\databases\derby.log)
      at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source)
      at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown Source)
      at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown Source)
      at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown Source)
      at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown Source)
      at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown Source)
      at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown Source)
      at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown Source)
      at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
      at org.apache.derby.client.net.NetConnection.initialize(Unknown Source)
      at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
      at org.apache.derby.client.net.NetXAConnection.<init>(Unknown Source)
      at org.apache.derby.client.ClientPooledConnection.<init>(Unknown Source)
      at org.apache.derby.client.ClientXAConnection.<init>(Unknown Source)
      at org.apache.derby.jdbc.ClientXADataSource.getXAConnection(Unknown Source)
      at org.apache.derby.jdbc.ClientXADataSource.getXAConnection(Unknown Source)

      1. derby246.diff
        28 kB
        Kathey Marsden
      2. DERBY-246_irc_6_3_2005
        4 kB
        Kathey Marsden

        Issue Links

          Activity

          Hide
          Julius Stroffek added a comment -

          From the XA Transaction Specification from the OpenGroup:

          It is an error, [XAER_PROTO], for a transaction manager to call xa_close () within a
          thread of control that is associated with a transaction branch (that is, the transaction
          manager must call xa_end() before calling xa_close ()).

          Show
          Julius Stroffek added a comment - From the XA Transaction Specification from the OpenGroup: — It is an error, [XAER_PROTO] , for a transaction manager to call xa_close () within a thread of control that is associated with a transaction branch (that is, the transaction manager must call xa_end() before calling xa_close ()).
          Hide
          David Van Couvering added a comment -

          I tried applying this patch to a fresh tree and got an error:

          bash-2.05$ patch -p0 < derby246.diff
          (Stripping trailing CRs from patch.)
          patching file java/drda/org/apache/derby/impl/drda/XADatabase.java
          patch: **** malformed patch at line 30: Index: java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/netxaPositive.sql

          I looked at the line but can't figure out what's up.

          Show
          David Van Couvering added a comment - I tried applying this patch to a fresh tree and got an error: bash-2.05$ patch -p0 < derby246.diff (Stripping trailing CRs from patch.) patching file java/drda/org/apache/derby/impl/drda/XADatabase.java patch: **** malformed patch at line 30: Index: java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/netxaPositive.sql I looked at the line but can't figure out what's up.
          Hide
          Kathey Marsden added a comment -

          Additional cleanup of the xaState is required and
          has been filed as DERBY-339

          Show
          Kathey Marsden added a comment - Additional cleanup of the xaState is required and has been filed as DERBY-339
          Hide
          Kathey Marsden added a comment -

          The fix for this issue was checked in.

          r179867 | kmarsden | 2005-06-03 12:35:33 -0700 (Fri, 03 Jun 2005) | 17 lines

          XA end() fails with Connection is closed error

          For the client there were multiple problems associated with the tracking
          of XA_STATE in the client. The approach for this patch is to remove as
          much of the client state as possible.

          This patch removes all the client XA state except for
          XA_GLOBAL - In an active global transaction
          XA_LOCAL - No active global transaction.

          For Network Server there was a bug that the connection was not being
          reset properly when a connection
          reset request came from the client. Changed it so that if an ACCRDB
          is sent and a connection has already been established it will reset.

          Additional work in this area will bechecked in with DERBY-339

          Show
          Kathey Marsden added a comment - The fix for this issue was checked in. r179867 | kmarsden | 2005-06-03 12:35:33 -0700 (Fri, 03 Jun 2005) | 17 lines XA end() fails with Connection is closed error For the client there were multiple problems associated with the tracking of XA_STATE in the client. The approach for this patch is to remove as much of the client state as possible. This patch removes all the client XA state except for XA_GLOBAL - In an active global transaction XA_LOCAL - No active global transaction. For Network Server there was a bug that the connection was not being reset properly when a connection reset request came from the client. Changed it so that if an ACCRDB is sent and a connection has already been established it will reset. Additional work in this area will bechecked in with DERBY-339
          Hide
          Kathey Marsden added a comment -

          Philip reviewed my change for DERBY-246 and commented that an instance of if (!open_ && !availableForReuse_)
          could be changed to
          if (isPhysicallyClosed())

          • Talked about how in the client the public api calls such as close() and next() have tracing but the corresponding internal calls closeX() and nextX() don't.
            Internal code should call closeX() instead of close().
          • Talked about general approach of fix for DERBY-246, to rip out as much of the XA state in the client as possible.
          Show
          Kathey Marsden added a comment - Philip reviewed my change for DERBY-246 and commented that an instance of if (!open_ && !availableForReuse_) could be changed to if (isPhysicallyClosed()) Talked about how in the client the public api calls such as close() and next() have tracing but the corresponding internal calls closeX() and nextX() don't. Internal code should call closeX() instead of close(). Talked about general approach of fix for DERBY-246 , to rip out as much of the XA state in the client as possible.
          Hide
          Kathey Marsden added a comment -

          Attached is a patch for DERBY-246.

          For the client there were multiple problems associated with the tracking
          of XA_STATE in the client. The approach for this patch is to remove as
          much of the client state as possible.

          This patch removes all the client XA state except for
          XA_GLOBAL - In an active global transaction
          XA_LOCAL - No active global transaction.

          For Network Server there was a bug that the connection was not being
          reset properly when a connection
          reset request came from the client. Changed it so that if an ACCRDB
          is sent and a connection has already been established it will reset.

          There is still a fair amount of cleanup to do for xa in the client. Including
          changing the values above to a single boolean value.
          That will come in follow up patches. I will also file bugs for some
          other client XA issues I am looking at.

          I will commit this probably at noon today, but would appreciate review before or
          after checkin.

          Show
          Kathey Marsden added a comment - Attached is a patch for DERBY-246 . For the client there were multiple problems associated with the tracking of XA_STATE in the client. The approach for this patch is to remove as much of the client state as possible. This patch removes all the client XA state except for XA_GLOBAL - In an active global transaction XA_LOCAL - No active global transaction. For Network Server there was a bug that the connection was not being reset properly when a connection reset request came from the client. Changed it so that if an ACCRDB is sent and a connection has already been established it will reset. There is still a fair amount of cleanup to do for xa in the client. Including changing the values above to a single boolean value. That will come in follow up patches. I will also file bugs for some other client XA issues I am looking at. I will commit this probably at noon today, but would appreciate review before or after checkin.
          Hide
          Kathey Marsden added a comment -

          The workaround for this issue leave logical connections that participate in a global transaction openned until the transaction completes.

          Show
          Kathey Marsden added a comment - The workaround for this issue leave logical connections that participate in a global transaction openned until the transaction completes.
          Hide
          Kathey Marsden added a comment -

          There are basically three issues with Derby-246

          Issue 1 - xa_end will throw an exception if the logical connection is closed. If the logical connection is not yet closed when xa_end is called, the transaction ends properly.

          AException.errorcode: XAER_RMFAIL
          XAER_RMFAIL : Connection is Closed.
          org.apache.derby.client.am.XaException: XAER_RMFAIL : Connection is Closed.
          at org.apache.derby.client.net.NetXAResource.throwXAException(NetXAResource.java:736)
          at org.apache.derby.client.net.NetXAResource.throwXAException(NetXAResource.java:631)
          at org.apache.derby.client.net.NetXAResource.connectionClosedFailure(NetXAResource.java:926)
          at org.apache.derby.client.net.NetXAResource.end(NetXAResource.java:252)

          Issue 2 - A Lock timeout occurs when trying to reconnect with the same user after the connection is closed error, because the automatic schema creation is not complete. You can reconnect with user "APP" because that schema exists.

          ERROR 40XL1: A lock could not be obtained within the time requested

          at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301)

          at org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java:414)

          at org.apache.derby.impl.services.locks.SinglePool.lockAnObject(SinglePool.java:174)

          at org.apache.derby.impl.services.locks.SinglePool.lockObject(SinglePool.java:226)

          at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForRead(RowLocking3.java:187)

          at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:518)

          at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:636)

          at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:332)

          at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:574)

          at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:119)

          at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:380)

          at org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java:1696)

          at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:7124)

          at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java:1386)

          at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java:1296)

          at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initDefaultSchemaDescriptor(GenericLanguageConnectionContext.java:350)

          at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(GenericLanguageConnectionContext.java:332)

          at org.apache.derby.impl.db.BasicDatabase.setupConnection(BasicDatabase.java:272)

          at org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(TransactionResourceImpl.java:188)

          at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:242)

          at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:72)

          at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:73)

          at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:183)

          at org.apache.derby.impl.drda.Database.makeConnection(Database.java:248)

          at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1132)

          at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1110)

          at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:2648)

          at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:973)

          at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:816)

          at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:226)

          Issue 3 - A lock timeout hoses the connection. But I seem to recall that this was determined to not be a bug at one point. Need to double check on that.

          Show
          Kathey Marsden added a comment - There are basically three issues with Derby-246 Issue 1 - xa_end will throw an exception if the logical connection is closed. If the logical connection is not yet closed when xa_end is called, the transaction ends properly. AException.errorcode: XAER_RMFAIL XAER_RMFAIL : Connection is Closed. org.apache.derby.client.am.XaException: XAER_RMFAIL : Connection is Closed. at org.apache.derby.client.net.NetXAResource.throwXAException(NetXAResource.java:736) at org.apache.derby.client.net.NetXAResource.throwXAException(NetXAResource.java:631) at org.apache.derby.client.net.NetXAResource.connectionClosedFailure(NetXAResource.java:926) at org.apache.derby.client.net.NetXAResource.end(NetXAResource.java:252) Issue 2 - A Lock timeout occurs when trying to reconnect with the same user after the connection is closed error, because the automatic schema creation is not complete. You can reconnect with user "APP" because that schema exists. ERROR 40XL1: A lock could not be obtained within the time requested at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java:414) at org.apache.derby.impl.services.locks.SinglePool.lockAnObject(SinglePool.java:174) at org.apache.derby.impl.services.locks.SinglePool.lockObject(SinglePool.java:226) at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForRead(RowLocking3.java:187) at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:518) at org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:636) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:332) at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:574) at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:119) at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:380) at org.apache.derby.impl.store.access.btree.BTreeScan.next(BTreeScan.java:1696) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:7124) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java:1386) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java:1296) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initDefaultSchemaDescriptor(GenericLanguageConnectionContext.java:350) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(GenericLanguageConnectionContext.java:332) at org.apache.derby.impl.db.BasicDatabase.setupConnection(BasicDatabase.java:272) at org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(TransactionResourceImpl.java:188) at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:242) at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:72) at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:73) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:183) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:248) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1132) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1110) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:2648) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:973) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:816) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:226) Issue 3 - A lock timeout hoses the connection. But I seem to recall that this was determined to not be a bug at one point. Need to double check on that.
          Hide
          Myrna van Lunteren added a comment -

          removing some non-printable characters spewed out by networkserver - JIRA cannot properly generate XML with them in a CDATA field...(JRA-5660 was logged). replaced the troublesome characters with '..[snip]..'

          Show
          Myrna van Lunteren added a comment - removing some non-printable characters spewed out by networkserver - JIRA cannot properly generate XML with them in a CDATA field...(JRA-5660 was logged). replaced the troublesome characters with '.. [snip] ..'

            People

            • Assignee:
              Kathey Marsden
              Reporter:
              Dibyendu Majumdar
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development