db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Date Mon, 17 Sep 2007 20:51:52 GMT

Kathey Marsden wrote:
> Lance J. Andersen wrote:
>> Kathey Marsden wrote:
>>> There was a discussion started in DERBY-401 on this but I thought I 
>>> would submit it as a separate thread.  The JDBC 4.0 spec says in 
>>> section 8.5.1..
>>> "A NonTransient SQLException must extend the class
>>> SQLNonTransientException. A NonTransient SQLException would be thrown
>>> in instances where a retry of the same operation would fail unless 
>>> the cause of the
>>> SQLException is corrected. After a NonTransient SQLException occurs, 
>>> the
>>> application can assume that the connection is still valid. For 
>>> SQLState class values
>>> that indicate non-transient errors but which are not specified in 
>>> the following table,
>>> an implementation may throw an instance of the class 
>>> SQLNonTransientException."
>>> TABLE 8-1 specifies which NonTransientSQLException subclass must be 
>>> thrown
>>> for a a given SQLState class value:
>>> TABLE 8-1 NonTransientSQLExeceptions Subclasses
>>> SQL State Class SQLNonTransientException Subclass
>>> .....
>>> 08 SQLNonTransientConnectionException
>>> .....
>>> Derby has quite a few exceptions which are SESSION_SEVERITY or 
>>> greater which are not SQLState Class '08'.  These exception cause 
>>> loss of connection by the application.  There is a list at the 
>>> bottom of this mail.  I thought all of these should be 
>>> SQLNonTransientConnectionExceptions, 
>> SQLNonTransientConnectionException aligns with SQL State class value 
>> 08 from 23.1, table 32 of the sql2003 spec.
> Thank you Lance for looking at this.
> The DRDA Spec section 8.1 defines SQLState mappings to 58XXX which 
> don't fall into table 32 and would seem to conflict with the 08006 
> exceptions.  Any thoughts on what to do with these?
perhaps it is worth going back to DRDA and asking them where/how they 
came up with that class value?

As far as what to do, unless you decide to map the DRDA states to the 
appropriate SQL Class value,  i would return a SQLException.  Also, we 
probably should not be  returning this via SQLException.getSQLState() 
unless we can figure out how/where DRDA is getting the sql class value? 
> Kathey

View raw message