Derby
  1. Derby
  2. DERBY-8

Connection object gets created with un-supported holdability on getting Connection object from XAConnection "inside" the global transaction

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.0.2.0
    • Fix Version/s: 10.1.1.0, 10.2.1.6
    • Component/s: JDBC
    • Labels:
      None

      Description

      Reporting for Mamta Satoor, filed on Derby-dev list.

      I think there is a bug in Derby when the user code tries to get the
      Connection object from XAConnection "inside" the global transaction.
      In this case, the Connection object gets created with un-supported
      holdability. Look at the following piece of code and it's output to
      see what exactly happens
      EmbeddedXADataSource dscsx = new EmbeddedXADataSource();
      dscsx.setDatabaseName("wombat");
      XAConnection xac = dscsx.getXAConnection("fred", "wilma");
      XAResource xr = xac.getXAResource();
      xid = getXid(27, (byte) 21, (byte) 01);
      xr.start(xid, XAResource.TMNOFLAGS);
      conn1 = xac.getConnection();
      System.out.println("This is a bug. Connection's holdability should
      have been CLOSE_CURSORS_AT_COMMIT since it is in the global
      transaction");
      System.out.println("CONNECTION(in xa transaction) HOLDABILITY " +
      (conn1.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT));
      System.out.println("Autocommit on Connection inside global
      transaction has been set correctly to " + conn1.getAutoCommit());
      xr.end(xid, XAResource.TMSUCCESS);
      The output for the above piece of code is
      This is a bug. Connection's holdability should have been
      CLOSE_CURSORS_AT_COMMIT since it is in the global transaction
      CONNECTION(in xa transaction) HOLDABILITY true
      Autocommit on Connection inside global transaction has been set
      correctly to false

        Issue Links

          Activity

          Hide
          Shreyas Kaushik added a comment -

          My comments on this issue:

          Both the XAResource and the Connection handle got by calling a getConnection() method on a XAConnection are child entities of the XAConnection. So the XAResource and the Connection are in parallel if a hierarchy is imagined with a XAConnection as the head.
          So the Connection handle got by calling a getConnection method on the XAResource is not bound to have the same holdability for cursors as that of the Transaction. It should have its own holdability state.

          Moreover in a managed sscenario the XAConnection interface is not directly used, we just get a java.sql.Connection handle by calling the getConnection method on the DataSource. It is the DataSource configuration that determines what all happens behind the scene to return a Connection handle.

          So in my opinion Derby is behaving properly.

          Show
          Shreyas Kaushik added a comment - My comments on this issue: Both the XAResource and the Connection handle got by calling a getConnection() method on a XAConnection are child entities of the XAConnection. So the XAResource and the Connection are in parallel if a hierarchy is imagined with a XAConnection as the head. So the Connection handle got by calling a getConnection method on the XAResource is not bound to have the same holdability for cursors as that of the Transaction. It should have its own holdability state. Moreover in a managed sscenario the XAConnection interface is not directly used, we just get a java.sql.Connection handle by calling the getConnection method on the DataSource. It is the DataSource configuration that determines what all happens behind the scene to return a Connection handle. So in my opinion Derby is behaving properly.
          Hide
          Mamta A. Satoor added a comment -

          Should we then reconsider what happens to the holdability of the connection handle(got by calling a getConnection() method on a XAConnection OUTSIDE the global transaction) when it becomes part of a global transaction?

          Following example code shows that Derby currently (silently) switches the the holdability of the connection handle from HOLD_CURSORS_OVER_COMMIT to CLOSE_CURSORS_AT_COMMIT when it becomes part of the global transaction.

          EmbeddedXADataSource dscsx = new EmbeddedXADataSource();
          dscsx.setDatabaseName("wombat");
          XAConnection xac = dscsx.getXAConnection("fred", "wilma");
          XAResource xr = xac.getXAResource();
          Xid xid = getXid(27, (byte) 21, (byte) 01);
          Connection conn1 = xac.getConnection();
          System.out.println("By default, autocommit is " + conn1.getAutoCommit() + " for a connection");
          System.out.println("Default holdability for a connection is HOLD_CURSORS_OVER_COMMIT");
          System.out.println("CONNECTION(not in xa transaction yet) HOLDABILITY " + (conn1.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT));
          xr.start(xid, XAResource.TMNOFLAGS);
          System.out.println("Notice that autocommit now is " + conn1.getAutoCommit() + " for connection because it is part of the global transaction");
          System.out.println("Notice that connection's holdability at this point is CLOSE_CURSORS_AT_COMMIT because it is part of the global transaction");
          System.out.println("CONNECTION(in xa transaction) HOLDABILITY " + (conn1.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT));

          Output of this code snippet when run under Derby is as follows.
          START XA HOLDABILITY TEST
          By default, autocommit is true for a connection
          Default holdability for a connection is HOLD_CURSORS_OVER_COMMIT
          CONNECTION(not in xa transaction yet) HOLDABILITY true
          Notice that autocommit now is false for connection because it is part of the global transaction
          Notice that connection's holdability at this point is CLOSE_CURSORS_AT_COMMIT because it is part of the global transaction
          CONNECTION(in xa transaction) HOLDABILITY false

          thanks,
          Mamta

          Show
          Mamta A. Satoor added a comment - Should we then reconsider what happens to the holdability of the connection handle(got by calling a getConnection() method on a XAConnection OUTSIDE the global transaction) when it becomes part of a global transaction? Following example code shows that Derby currently (silently) switches the the holdability of the connection handle from HOLD_CURSORS_OVER_COMMIT to CLOSE_CURSORS_AT_COMMIT when it becomes part of the global transaction. EmbeddedXADataSource dscsx = new EmbeddedXADataSource(); dscsx.setDatabaseName("wombat"); XAConnection xac = dscsx.getXAConnection("fred", "wilma"); XAResource xr = xac.getXAResource(); Xid xid = getXid(27, (byte) 21, (byte) 01); Connection conn1 = xac.getConnection(); System.out.println("By default, autocommit is " + conn1.getAutoCommit() + " for a connection"); System.out.println("Default holdability for a connection is HOLD_CURSORS_OVER_COMMIT"); System.out.println("CONNECTION(not in xa transaction yet) HOLDABILITY " + (conn1.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT)); xr.start(xid, XAResource.TMNOFLAGS); System.out.println("Notice that autocommit now is " + conn1.getAutoCommit() + " for connection because it is part of the global transaction"); System.out.println("Notice that connection's holdability at this point is CLOSE_CURSORS_AT_COMMIT because it is part of the global transaction"); System.out.println("CONNECTION(in xa transaction) HOLDABILITY " + (conn1.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT)); Output of this code snippet when run under Derby is as follows. START XA HOLDABILITY TEST By default, autocommit is true for a connection Default holdability for a connection is HOLD_CURSORS_OVER_COMMIT CONNECTION(not in xa transaction yet) HOLDABILITY true Notice that autocommit now is false for connection because it is part of the global transaction Notice that connection's holdability at this point is CLOSE_CURSORS_AT_COMMIT because it is part of the global transaction CONNECTION(in xa transaction) HOLDABILITY false thanks, Mamta
          Hide
          Daniel John Debrunner added a comment -

          I think the point is being missed that Derby does not support holdability when in a global transaction, thus holdability should always be CLOSE_CURSORS_AT_COMMIT when in a global transaction, regardless of the state set by the connection in local mode. So I believe the bug summary is correct, and there is a bug.

          Show
          Daniel John Debrunner added a comment - I think the point is being missed that Derby does not support holdability when in a global transaction, thus holdability should always be CLOSE_CURSORS_AT_COMMIT when in a global transaction, regardless of the state set by the connection in local mode. So I believe the bug summary is correct, and there is a bug.
          Hide
          Mamta A. Satoor added a comment -

          I have a patch to fix Derby-8 (Connection object gets created with un-supported holdability on getting Connection object from XAConnection "inside" the global transaction) and Derby-366 (In jdk13, when a connection transitions from global transaction to local transaction, its default holdability of HOLD_CURSORS_OVER_COMMIT is not restored.) The patch is attached to both Derby-8 and Derby-366.

          The fix for both these bugs was centered around fixing the holdability handling in BrokeredConnection.java This was because BrokeredConnection.java had no code for restoring the holdability of real connection object and no code for saving the current holdability state of real connection object. I put fix for both these issues in BrokeredConnection.java so that both jdk13 and jdk14+ environments will be handled correctly. Had to use reflection for this holdability work
          because Connection.setHoldability and Connection.getHoldability methods are not available through JDK13 apis.

          svn stat
          M java\engine\org\apache\derby\iapi\jdbc\BrokeredConnection.java
          M java\engine\org\apache\derby\iapi\jdbc\BrokeredConnection30.java
          M java\testing\org\apache\derbyTesting\functionTests\tests\store\xaOffline1.sql
          M java\testing\org\apache\derbyTesting\functionTests\tests\store\xab2354.sql
          M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaAnotherTest.sql
          M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaSimplePositive.sql
          M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaSimpleNegative.sql
          M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\checkDataSource30.java
          M java\testing\org\apache\derbyTesting\functionTests\master\xaOffline1.out
          M java\testing\org\apache\derbyTesting\functionTests\master\xaSimplePositive.out
          M java\testing\org\apache\derbyTesting\functionTests\master\xab2354.out
          M java\testing\org\apache\derbyTesting\functionTests\master\xaSimpleNegative.out
          M java\testing\org\apache\derbyTesting\functionTests\master\xaAnotherTest.out
          M java\testing\org\apache\derbyTesting\functionTests\master\checkDataSource30.out

          Kathey, may be you can try this fix with Network Server and see if it resolves any related issues you had there?

          I have run the test suite and this fix has not caused any failures. Have changed some of the existing XA tests so that they can rely on correct holdability status inside and outside global transaction.

          If no comments from anyone, can a commiter please commit this patch?

          Show
          Mamta A. Satoor added a comment - I have a patch to fix Derby-8 (Connection object gets created with un-supported holdability on getting Connection object from XAConnection "inside" the global transaction) and Derby-366 (In jdk13, when a connection transitions from global transaction to local transaction, its default holdability of HOLD_CURSORS_OVER_COMMIT is not restored.) The patch is attached to both Derby-8 and Derby-366. The fix for both these bugs was centered around fixing the holdability handling in BrokeredConnection.java This was because BrokeredConnection.java had no code for restoring the holdability of real connection object and no code for saving the current holdability state of real connection object. I put fix for both these issues in BrokeredConnection.java so that both jdk13 and jdk14+ environments will be handled correctly. Had to use reflection for this holdability work because Connection.setHoldability and Connection.getHoldability methods are not available through JDK13 apis. svn stat M java\engine\org\apache\derby\iapi\jdbc\BrokeredConnection.java M java\engine\org\apache\derby\iapi\jdbc\BrokeredConnection30.java M java\testing\org\apache\derbyTesting\functionTests\tests\store\xaOffline1.sql M java\testing\org\apache\derbyTesting\functionTests\tests\store\xab2354.sql M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaAnotherTest.sql M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaSimplePositive.sql M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\xaSimpleNegative.sql M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\checkDataSource30.java M java\testing\org\apache\derbyTesting\functionTests\master\xaOffline1.out M java\testing\org\apache\derbyTesting\functionTests\master\xaSimplePositive.out M java\testing\org\apache\derbyTesting\functionTests\master\xab2354.out M java\testing\org\apache\derbyTesting\functionTests\master\xaSimpleNegative.out M java\testing\org\apache\derbyTesting\functionTests\master\xaAnotherTest.out M java\testing\org\apache\derbyTesting\functionTests\master\checkDataSource30.out Kathey, may be you can try this fix with Network Server and see if it resolves any related issues you had there? I have run the test suite and this fix has not caused any failures. Have changed some of the existing XA tests so that they can rely on correct holdability status inside and outside global transaction. If no comments from anyone, can a commiter please commit this patch?
          Hide
          Kathey Marsden added a comment -

          Checked this in.
          Transmitting file data ...............
          Committed revision 191755.

          Show
          Kathey Marsden added a comment - Checked this in. Transmitting file data ............... Committed revision 191755.
          Hide
          Kathey Marsden added a comment -

          This issue was fixed with Mamta's fix for DERBY-8 and DERBY366. I think this one is actually a dup of DERBY-8

          Show
          Kathey Marsden added a comment - This issue was fixed with Mamta's fix for DERBY-8 and DERBY366. I think this one is actually a dup of DERBY-8
          Hide
          Mamta A. Satoor added a comment -

          The fix has been committed by Kathey

          Show
          Mamta A. Satoor added a comment - The fix has been committed by Kathey
          Hide
          Mamta A. Satoor added a comment -

          Need to put correct fix-in version

          Show
          Mamta A. Satoor added a comment - Need to put correct fix-in version

            People

            • Assignee:
              Mamta A. Satoor
              Reporter:
              Tulika Agrawal
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development