Derby
  1. Derby
  2. DERBY-346

running jdbcapi/xaSimplePostive.sql under the DerbyNetClient framework gives error "Cannot set holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for a global transaction."

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 10.1.1.0
    • Fix Version/s: 10.2.1.6
    • Component/s: Network Client
    • Labels:
      None

      Description

      Running jdbcapi/xaSimplePositive.sql with network client causes an error in the last case:

      Cannot set holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for a global transaction.

      The trace on the client is:
      ij(XA)> select * from APP.global_xactTable where gxid is not null order by gxid;
      ERROR XJ05C: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ05C, SQLERRMC: XJ05C.S
      org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ05C, SQLERRMC: XJ05C.S
      at org.apache.derby.client.am.Statement.completeSqlca(Statement.java:1354)
      at org.apache.derby.client.am.Statement.completeOpenQuery(Statement.java:1025)
      at org.apache.derby.client.net.NetStatementReply.parseOpenQueryFailure(NetStatementReply.java:503)
      at org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply(NetStatementReply.java:226)
      at org.apache.derby.client.net.NetStatementReply.readOpenQuery(NetStatementReply.java:56)
      at org.apache.derby.client.net.StatementReply.readOpenQuery(StatementReply.java:49)
      at org.apache.derby.client.net.NetStatement.readOpenQuery_(NetStatement.java:151)
      at org.apache.derby.client.am.Statement.readOpenQuery(Statement.java:1021)
      at org.apache.derby.client.am.Statement.flowExecute(Statement.java:1556)
      at org.apache.derby.client.am.Statement.executeX(Statement.java:631)
      at org.apache.derby.client.am.Statement.execute(Statement.java:622)
      at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299)
      at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433)
      at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:312)
      at org.apache.derby.impl.tools.ij.Main.go(Main.java:203)
      at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169)
      at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
      at org.apache.derby.tools.ij.main(ij.java:60)

      On the server, the trace is:

      Cannot set holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for a global transaction.
      SQL Exception: Cannot set holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for a global transaction.
      at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:79)
      at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:96)
      at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:160)
      at org.apache.derby.jdbc.EmbedXAConnection.checkHoldCursors(EmbedXAConnection.java:712)
      at org.apache.derby.jdbc.XAStatementControl.checkHoldCursors(XAStatementControl.java:193)
      at org.apache.derby.iapi.jdbc.BrokeredPreparedStatement.execute(BrokeredPreparedStatement.java:426)
      at org.apache.derby.impl.drda.DRDAStatement.execute(DRDAStatement.java:548)
      at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:3533)
      at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:871)
      at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:226)
      handle SQLException here

      I have been trying to get the jdbcapi/xaSimplePostive.sql test running with network client. The changes for DERBY -246 and DERBY-339 allow all but the last case in xaSimplePositve to pass. Unfortunately I have not yet been able to strip down the test to get a smaller reproducable case.

        Issue Links

          Activity

          Kathey Marsden created issue -
          Hide
          Kathey Marsden added a comment -

          This patch changes Network Server to pass the holdability to the prepare method of BrokeredConnection30 when running under JDK14.
          It also adds the jdbcapi/xaSimplePositive.sql test to the derbynetclientmats test suite. The netxapositive test has been removed as it was a subset of
          xaSimplePositive.

          Note:It seems that under JDK13 the default holdability for BrokeredConnections in global transactions is consistently, CLOSE_CURSORS_AT_COMMIT, but for JDK141, the default holdability is sometimes set to HOLD_CURSORS_OVER_COMMIT.

          Ran jdbcapi/xaSimplePositive.sql test under JDK131 and JDK142 as well as derbyentclientmats.

          Show
          Kathey Marsden added a comment - This patch changes Network Server to pass the holdability to the prepare method of BrokeredConnection30 when running under JDK14. It also adds the jdbcapi/xaSimplePositive.sql test to the derbynetclientmats test suite. The netxapositive test has been removed as it was a subset of xaSimplePositive. Note:It seems that under JDK13 the default holdability for BrokeredConnections in global transactions is consistently, CLOSE_CURSORS_AT_COMMIT, but for JDK141, the default holdability is sometimes set to HOLD_CURSORS_OVER_COMMIT. Ran jdbcapi/xaSimplePositive.sql test under JDK131 and JDK142 as well as derbyentclientmats.
          Kathey Marsden made changes -
          Field Original Value New Value
          Attachment derby346.diff [ 12310666 ]
          Hide
          Kathey Marsden added a comment -

          Mamta posted this summary of holdability behaviour for use in debugging this issue. Client should match the embedded behaviour.

          Just to summarize, the holdability table will look the same for EmbedConnection as well as BrokeredConnection.

          Global Transaction Local Transaction
          JDK13 CLOSE_CURSORS_AT_COMMIT conn holdability (Default HOLD_CURSORS_OVER_COMMIT)
          JDK14+ CLOSE_CURSORS_AT_COMMIT conn holdability (Default HOLD_CURSORS_OVER_COMMIT)

          A Connection object will have it's holdability set to default which is HOLD_CURSORS_OVER_COMMIT. When the connection joins a global transaction, the holdability will get switched internally to CLOSE_CURSORS_AT_COMMIT. When the connection leaves the global transaction and becomes part of local transaction, the holdability is restored to what it was before entering the global transaction. It works this way in both jdk13 and jdk14+. One thing to keep in mind is that PreparedStatement get the holdability from where they are prepared and not where they are executed,

          for instance,
          Start Local Transaction
          Connection holdability (default - HOLD_CURSORS_OVER_COMMIT)
          PreparedStatement (holdability will be HOLD_CURSORS_OVER_COMMIT)
          ResultSet from PreparedStatement will have holdability as HOLD_CURSORS_OVER_COMMIT
          Start Global Transaction
          Connection holdability switches to CLOSE_CURSORS_AT_COMMIT
          Another ResultSet from PreparedStatement will attempt to have the preparedStatement's holdability and that will cause exception because Global transactions do not support holdable cursors.
          Exit Global Transaction and become part of Local Transaction
          Connection holdability back to HOLD_CURSORS_OVER_COMMIT

          I have come across one bug with jdk13 though, where the holdability is not getting restored back to HOLD_CURSORS_OVER_COMMIT when the connection becomes part of local transaction after leaving global transaction. I will enter a JIRA entry for it and start working on it.

          Show
          Kathey Marsden added a comment - Mamta posted this summary of holdability behaviour for use in debugging this issue. Client should match the embedded behaviour. Just to summarize, the holdability table will look the same for EmbedConnection as well as BrokeredConnection. Global Transaction Local Transaction JDK13 CLOSE_CURSORS_AT_COMMIT conn holdability (Default HOLD_CURSORS_OVER_COMMIT) JDK14+ CLOSE_CURSORS_AT_COMMIT conn holdability (Default HOLD_CURSORS_OVER_COMMIT) A Connection object will have it's holdability set to default which is HOLD_CURSORS_OVER_COMMIT. When the connection joins a global transaction, the holdability will get switched internally to CLOSE_CURSORS_AT_COMMIT. When the connection leaves the global transaction and becomes part of local transaction, the holdability is restored to what it was before entering the global transaction. It works this way in both jdk13 and jdk14+. One thing to keep in mind is that PreparedStatement get the holdability from where they are prepared and not where they are executed, for instance, Start Local Transaction Connection holdability (default - HOLD_CURSORS_OVER_COMMIT) PreparedStatement (holdability will be HOLD_CURSORS_OVER_COMMIT) ResultSet from PreparedStatement will have holdability as HOLD_CURSORS_OVER_COMMIT Start Global Transaction Connection holdability switches to CLOSE_CURSORS_AT_COMMIT Another ResultSet from PreparedStatement will attempt to have the preparedStatement's holdability and that will cause exception because Global transactions do not support holdable cursors. Exit Global Transaction and become part of Local Transaction Connection holdability back to HOLD_CURSORS_OVER_COMMIT I have come across one bug with jdk13 though, where the holdability is not getting restored back to HOLD_CURSORS_OVER_COMMIT when the connection becomes part of local transaction after leaving global transaction. I will enter a JIRA entry for it and start working on it.
          Hide
          Kathey Marsden added a comment -

          This issue was fixed by Mamta's fixes for embedded holdability for DERBY-8 and DERBY-366.

          The following checkin adds the xaSimplePositive.sql test to the client suite and removes netxaPositve, which was a subset of xaSimplePositive.

          Transmitting file data ...
          Committed revision 192968.

          Show
          Kathey Marsden added a comment - This issue was fixed by Mamta's fixes for embedded holdability for DERBY-8 and DERBY-366 . The following checkin adds the xaSimplePositive.sql test to the client suite and removes netxaPositve, which was a subset of xaSimplePositive. Transmitting file data ... Committed revision 192968.
          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
          Kathey Marsden made changes -
          Link This issue duplicates DERBY-8 [ DERBY-8 ]
          Hide
          Kathey Marsden added a comment -

          Fixed with fix for DERBY-8, DERBY-366

          Show
          Kathey Marsden added a comment - Fixed with fix for DERBY-8 , DERBY-366
          Kathey Marsden made changes -
          Fix Version/s 10.2.0.0 [ 11187 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Duplicate [ 3 ]
          Kathey Marsden made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12321246 ] Default workflow, editable Closed status [ 12800525 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development