Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <9066468.1153982954776.JavaMail.jira@brutus>
Date: Wed, 26 Jul 2006 23:49:14 -0700 (PDT)
From: "V.Narayanan (JIRA)" <derby-dev@db.apache.org>
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

    [ http://issues.apache.org/jira/browse/DERBY-694?page=comments#action_12423780 ] 
            
V.Narayanan commented on DERBY-694:
-----------------------------------

The following test cases would test the patch in greater detail

1) Generate a case which will cause a ABNUOWRM that will cause the severity to be greater than 
     STATEMENT_SEVERITY. I tried a case that cause a timeout. This is what I did in the test case
     1.a) created connection1 set transaction isolation level as Connection.TRANSACTION_SERIALIZABLE
     1.b) set auto commit to false
     1.c) created a prepared statement to update a table
     1.d) executed the prepared statement
     1.e) created connection2 and a prepared statement from it and did a select from the same  table without    
           commiting the earlier transaction
     1.f) it caused a timeout as expected but did'nt result in a ABNUOWRM
     The test case that currently shows how this bug occurs would work fine if the patch were applied (i.e) the      
     result sets other than the one in which the division by zero occurs would'nt close but then the case when a 
    severity of greater than STATEMENT_SEVERITY occurs needs to be tested to ensure that all the 
    UnitOfWorkListeners are rolled back.

2) We also need a test case that would casue an ABNUOWRM from a Lob object. This would help us test 
     whether the above bug occurs with Lob objects.

I have'nt been able to generate cases 1 and 2. The test suite for the patch would'nt be complete without the above cases. I most humbly request for inputs from anyone who knows how to generate the above cases.

thanx
Narayanan


> 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, DERBY-694_v3.diff, DERBY-694_v3.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