[ http://issues.apache.org/jira/browse/DERBY-694?page=comments#action_12421705 ] Rick Hillegas commented on DERBY-694: -------------------------------------
Hi, Narayanan. Thanks for tackling this bug and for the explanatory html page. I am far from being an expert on this corner of the code. However, the following issues jump occur to me: 1) I don't see a regression test case for this problem. Please add a test case to derbyall. 2) Shouldn't Connection.completeSpecificRollback( UnitOfWorkListener uwl ) call uwl.completeLocalRollback() just as Connection.completeLocalRollback() does? It may be that the UnitOfWorkListener.completeLocalRollback() in question is a NOP right now, but that could change in the future. 3) I am wondering whether this fixes the whole bug. Should similar logic be added to network ResultSets as well as Statements? What happens if we get a STATEMENT_SEVERITY exception while calling a ResultSet method? > 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, 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
