db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-346) running jdbcapi/xaSimplePostive.sql under the DerbyNetClient framework gives error "Cannot set holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for a global transaction."
Date Tue, 14 Jun 2005 23:06:48 GMT
    [ http://issues.apache.org/jira/browse/DERBY-346?page=comments#action_12313654 ] 

Kathey Marsden commented on DERBY-346:

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
                        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.

> running jdbcapi/xaSimplePostive.sql under the DerbyNetClient framework gives   error
"Cannot set holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for a global transaction."
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>          Key: DERBY-346
>          URL: http://issues.apache.org/jira/browse/DERBY-346
>      Project: Derby
>         Type: Bug
>   Components: Network Client
>     Versions:
>     Reporter: Kathey Marsden
>     Assignee: Kathey Marsden

> Running jdbcapi/xaSimplePositive.sql with network client  causes  an error  in the last
> 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;
> org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ05C,
> 	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
> 	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.  

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message