Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 52591 invoked from network); 17 Jul 2006 19:45:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Jul 2006 19:45:25 -0000 Received: (qmail 82375 invoked by uid 500); 17 Jul 2006 19:45:22 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 82351 invoked by uid 500); 17 Jul 2006 19:45:22 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 82336 invoked by uid 99); 17 Jul 2006 19:45:22 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 12:45:22 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 12:45:21 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id B4701714293 for ; Mon, 17 Jul 2006 19:43:14 +0000 (GMT) Message-ID: <20744410.1153165394736.JavaMail.jira@brutus> Date: Mon, 17 Jul 2006 12:43:14 -0700 (PDT) From: "Rick Hillegas (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-694) Statement exceptions cause all the connection's result sets to be closed with the client driver In-Reply-To: <828757287.1131539539963.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ 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