Issue Details (XML | Word | Printable)

Key: DERBY-498
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Deepa Remesh
Reporter: A B
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Derby

Result set holdability defined inside stored procedures is ignored by server/client

Created: 09/Aug/05 01:30 AM   Updated: 24/May/06 04:22 AM
Return to search
Component/s: Network Client, Network Server
Affects Version/s: 10.1.2.1, 10.2.1.6
Fix Version/s: 10.1.2.1, 10.2.1.6

Time Tracking:
Not Specified

File Attachments:
  Size
Java Source File Licensed for inclusion in ASF works d498.java 2005-08-09 01:44 AM A B 6 kB
File Licensed for inclusion in ASF works derby-498.diff 2005-10-07 01:19 AM Deepa Remesh 13 kB
File Licensed for inclusion in ASF works derby-498.status 2005-10-07 01:19 AM Deepa Remesh 0.4 kB
File Licensed for inclusion in ASF works xa_proc_test.diff 2005-10-19 08:01 AM Deepa Remesh 5 kB
File Licensed for inclusion in ASF works xa_proc_test.status 2005-10-19 08:01 AM Deepa Remesh 0.3 kB

Resolution Date: 21/Oct/05 08:59 AM


 Description  « Hide
Assume I have a Java stored procedure that returns one or more result sets, and the holdability of those result sets is specified as part of the createStatement() method within the procedure definition (see below for an example).

If I execute this procedure against Derby embedded, the holdability of each result set matches that of the statement-specific holdability that is defined within the stored procedure. However, if I run the procedure against the Network Server using the Derby client, the holdability of _all_ result sets is the same, and it is based on the holdability of the statement that _executed_ the procedure--i.e. the statement-specific holdability that is defined within the procedure is ignored.

Ex: If I create a stored procedure that corresponds to the following method:

public static void p2(ResultSet[] rs1, ResultSet[] rs2,
    ResultSet[] rs3) throws Exception
{
    Connection conn = DriverManager.getConnection(
        "jdbc:default:connection");

    Statement st1 = conn.createStatement(
        ResultSet.TYPE_FORWARD_ONLY,
        ResultSet.CONCUR_READ_ONLY,
        ResultSet.HOLD_CURSORS_OVER_COMMIT);
    rs1[0] = st1.executeQuery("select * from testtable1");

    Statement st2 = conn.createStatement(
        ResultSet.TYPE_FORWARD_ONLY,
        ResultSet.CONCUR_READ_ONLY,
        ResultSet.CLOSE_CURSORS_AT_COMMIT);
    rs2[0] = st2.executeQuery("select * from testtable2");

    Statement st3 = conn.createStatement(
        ResultSet.TYPE_FORWARD_ONLY,
        ResultSet.CONCUR_READ_ONLY,
        ResultSet.HOLD_CURSORS_OVER_COMMIT);
    rs3[0] = st3.executeQuery("select * from testtable3");

    return;

    }
}

Then with Derby embedded, if I have a JDBC Statement that executes a call to this procedure, rs1 and rs3 will behave with HOLD_CURSORS holdability and rs2 will behave with CLOSE_CURSORS holdability--and that will be the case regardless of the holdability on the Statement that executed the call. That seems correct to me.

But if I do the same thing with Network Server, all of the result sets (rs1, rs2, and rs3) will have the same holdability as the JDBC Statement that executed the call. It doesn't matter what the holdabilities used within the procedure definition are: they will all be over-ridden by the holdability of the Statement that made the call.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Repository Revision Date User Message
ASF #326718 Wed Oct 19 21:47:26 UTC 2005 kmarsden DERBY-498 - Result set holdability defined inside stored procedures is ignored by server/client

The attached patch 'DERBY-498.diff' changes network server to use statement holdability set within stored procedures. The patch does the following:

1. For callable statements, the execute method in DRDAStatement gets holdability from the statement that produced the resultset.
2. Added getResultSetHoldability method which takes a resultset and returns holdability.
3. execute method passes this holdability to addResultSet method, which sets DRDAResultSet.withHoldCursor with this value.
4. writeOPNQRYRM method in DRDAConnThread is changed to use the holdability of the current DRDAResultSet for setting SQLCSRHLD.
5. Added tests in lang/holdCursorJava.java. Created a new master file for DerbyNetClient.

Ran derbyall on WinXP Sun jdk1.4.2. No failures. However, in a previous run of derbyall I got failures in few encryption tests. The failures did not seem related to my change. So I ran the encryption suites again and they passed. Then ran derbyall again and all tests passed.

Also attaching an additional patch "xa_proc_test.diff" for xa tests. It does the following:
1. Adds procedure test to jdbcapi/xaSimplePositive.sql.
2. Updates master files.

Contributed by Deepa Remesh dremesh@gmail.com
Files Changed
MODIFY /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/xaSimplePositive.sql
MODIFY /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/xaSimplePositive.out
MODIFY /db/derby/code/trunk/java/drda/org/apache/derby/impl/drda/DRDAStatement.java
MODIFY /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/holdCursorJava.java
MODIFY /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/xaSimplePositive.out
MODIFY /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/holdCursorJava.out
MODIFY /db/derby/code/trunk/java/drda/org/apache/derby/impl/drda/DRDAConnThread.java
ADD /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/holdCursorJava.out

Repository Revision Date User Message
ASF #327002 Thu Oct 20 21:01:01 UTC 2005 kmarsden DERBY-498 - Result set holdability defined inside stored procedures is ignored by server/client
merge from trunk
svn merge -r 326717:326718 https://svn.apache.org/repos/asf/db/derby/code/trunk
Contributed by Deepa Remesh
Note the test lang/holdCursorJava.java does not currently run with derbynetmats or derbynetclientmats. It requires port of DERBY-593 to run.
Files Changed
MODIFY /db/derby/code/branches/10.1/java/drda/org/apache/derby/impl/drda/DRDAStatement.java
MODIFY /db/derby/code/branches/10.1/java/testing/org/apache/derbyTesting/functionTests/tests/lang/holdCursorJava.java
MODIFY /db/derby/code/branches/10.1/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/xaSimplePositive.out
ADD /db/derby/code/branches/10.1/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/holdCursorJava.out (from /db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/holdCursorJava.out)
MODIFY /db/derby/code/branches/10.1/java/testing/org/apache/derbyTesting/functionTests/master/xaSimplePositive.out
MODIFY /db/derby/code/branches/10.1/java/testing/org/apache/derbyTesting/functionTests/master/holdCursorJava.out
MODIFY /db/derby/code/branches/10.1/java/drda/org/apache/derby/impl/drda/DRDAConnThread.java
MODIFY /db/derby/code/branches/10.1/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/xaSimplePositive.sql