[ http://issues.apache.org/jira/browse/DERBY-498?page=comments#action_12332645 ]
Kathey Marsden commented on DERBY-498: -------------------------------------- Checked this into 10.1 New Revision: 327002 URL: http://svn.apache.org/viewcvs?rev=327002&view=rev > Result set holdability defined inside stored procedures is ignored by > server/client > ----------------------------------------------------------------------------------- > > Key: DERBY-498 > URL: http://issues.apache.org/jira/browse/DERBY-498 > Project: Derby > Type: Bug > Components: Network Client, Network Server > Versions: 10.1.2.0, 10.2.0.0 > Reporter: A B > Assignee: Deepa Remesh > Fix For: 10.2.0.0, 10.1.2.0 > Attachments: d498.java, derby-498.diff, derby-498.status, xa_proc_test.diff, > xa_proc_test.status > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
