[ http://issues.apache.org/jira/browse/DERBY-498?page=comments#action_12332026 ]
Kathey Marsden commented on DERBY-498: -------------------------------------- Well all that XA trouble sounds like it was due to a not so good tip that I put in this bug (sorry about that). Your fix looks fine except that I wonder about the reflection to get the holdability with xa connections and jdk131 and whether the method will be available. If we don't have one already, I think it would be good to add a procedure call that returns statements, both inside and outside of an xa transaction to xaSimplePositive.sql. You can't specify HOLD_CURSORS_OVER_COMMIT within an xa transaction (it should throw an error), but even statements in procedures with CLOSE_CURSORS_AT_COMMIT should go through the new code path. There are probably existing procedure definitions in functionTests/util/ProcedureTest that could be called from one of the xa sql tests. > 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
