[ http://issues.apache.org/jira/browse/DERBY-498?page=comments#action_12331617 ]
A B commented on DERBY-498: --------------------------- I applied the patch to my local codeline and ran the repro as well as the new holdCursorJava.java test, and it all works correctly. I also ran the new test cases without the server changes and the test failed as expected: 21c21 < 21, testtable2-one --- > EXPECTED:ResultSet is null 38c38 < EXPECTED:ResultSet is null --- > 11, testtable1-one So that's good. I'm not familiar enough with the XA code to say for sure if there are any concerns in that area, but I did review the changes overall and they look good to me. My one (very minor) comment is that the code path for NON-callable statements changes ever-so-slightly with this patch: in the "addResultSet' method, the value of "newDrdaRs.withHoldCursor" wasn't getting set before (so far as I can tell); now, it's set to the current DRDAStatement's "withHoldCursor" value (which is passed in from DRDAStatement.execute()). I didn't see anything wrong with this when I looked at the code--and in fact this change seems more "correct" to me--but it did make me think twice while I was reviewing it, so I thought I'd mention it.. If this is intentional and okay, then I vote +1 with the hope that someone more familiar with XA can review this patch, as well... > 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 > Attachments: d498.java, derby-498.diff, derby-498.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
