[ http://issues.apache.org/jira/browse/DERBY-694?page=comments#action_12423395 ] Rick Hillegas commented on DERBY-694: -------------------------------------
Hi Narayanan. Thanks for these improvements. I have a couple comments: 1) It seems to me that the code would be simpler if StatementCallbackInterface and ResultSetCallbackInterface extended UnitOfWorkListener. If you make that change, then it suggests that getConnectionCallbackInterface() might move up to UnitOfWorkListener. What stands in the way there is that the Lobs implement UnitOfWorkListener but don't have a getConnectionCallbackInterface() method. But this makes me wonder whether this bug could surface when you call methods on Lobs? 2) I'm a little puzzled about the uwl field in NetConnectionReply and how it is set by the two new parseAbnormalEndUow() overloads before they forward to the old overload. This breaks the general pattern of the methods in this class, which seem to pass variables through method arguments rather than through state variables. It makes me uneasy. > Statement exceptions cause all the connection's result sets to be closed with > the client driver > ----------------------------------------------------------------------------------------------- > > Key: DERBY-694 > URL: http://issues.apache.org/jira/browse/DERBY-694 > Project: Derby > Issue Type: Bug > Components: Network Client > Affects Versions: 10.1.1.1 > Reporter: Oyvind Bakksjo > Assigned To: V.Narayanan > Priority: Minor > Attachments: DERBY-694.html, DERBY-694_upload_v1.diff, > DERBY-694_upload_v1.stat, DERBY-694_v2.diff, DERBY-694_v2.stat, > StatementRollbackTest.java > > > Scenario: > Autocommit off. Have two prepared statements, calling executeQuery() on both, > giving me two result sets. Can fetch data from both with next(). If one > statement gets an exception (say, caused by a division by zero), not only > this statement's result set is closed, but also the other open resultset. > This happens with the client driver, whereas in embedded mode, the other > result set is unaffected by the exception in the first result set (as it > should be). -- 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
