[ http://issues.apache.org/jira/browse/DERBY-498?page=comments#action_12331935 ]
Deepa Remesh commented on DERBY-498: ------------------------------------ To solve this problem, initially I was using a different approach, where I was changing the holdability in PKGNAMCSN for each resultset returned by network server. With this approach, jdbcapi/xaSimplePositive.sql and jdbcapi/xaStateTran.sql were failing in derbynetclientmats. Also, I had to change a lot on the client side and still things were not working fully. So I reworked my patch to update OPNQRYRM reply message with the holdability for each resultset. With this approach, I did not have to change anything on client side. And my new testcase and all tests in derbyall passed. The failures with my first approach made me think if there could be any other effect on XA. Also, I was going through some mails in derby-dev which talk about XA and holdability. So I requested someone who has worked in this area to look at this patch. http://mail-archives.apache.org/mod_mbox/db-derby-dev/200506.mbox/[EMAIL PROTECTED] http://issues.apache.org/jira/browse/DERBY-346 > 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
