db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-694) Statement exceptions cause all the connection's result sets to be closed with the client driver
Date Mon, 07 Aug 2006 15:26:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-694?page=comments#action_12426256 ] 
            
V.Narayanan commented on DERBY-694:
-----------------------------------

Doing a getSqlCode() on NetSqlCa in the above case was returning a -1. This value is less
than ExceptionSeverity.STATEMENT_SEVERITY(20000) hence it was passing in my previous patch.


I did not however have a way of ever deciding on this as the right method to check for exception
severity. (I would have needed to generate a ABNUOWRM with severity > STATEMENT_SEVERITY)

My only lifeline in this case was through the following 

<cutting and pasting from the comments above>

c.1) I inferred that the getSqlCode() contains the
           severity information from the code for
           SqlExceptionFactory40 where in the getSQLException
           method we check for errCode >=
           ExceptionSeverity.SESSION_SEVERITY.

   c.2) This method is called from
           SqlException.getSQLException() which in turn passes
           to this as parameter return value of getErrorCode().

    c.3) getErrorCode() inturn obtains the error code from
            sqlca_.getSqlCode() when sqlca_ is not null. 

To test the above inference I needed a way of generating an ABNUOWRM with severity greater
than STATEMENT_SEVERITY becase in this case getSqlCode() cannot be -1. But I wasn't able to
generate this case. I have already mentioned this in the above comments.

NetSqlCa.getSqlState() on the other hand does not return me a default value like -1 but returns
22012 from which the severity is derived. So I can be sure that getSqlState does return me
a valid value from which I can call the ExceptionUtil methods to derive severity . 

I did'nt feel safe sticking to the getSqlCode way which is based on an inference and a test
that passes because a default value of getSqlCode is lesser than severity value. Hence I decided
to stick to the getSqlState method. 

If there is someone who can guide me into generating a test case that can generate a ABNUOWRM
with severity > STATEMENT_SEVERITY I most humbly request for guidance from them.

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

        

Mime
View raw message