Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1192449398.1246647947167.JavaMail.jira@brutus>
Date: Fri, 3 Jul 2009 12:05:47 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-4219) Wrong SQLState when client has lost
 connection to server
In-Reply-To: <207143685.1242045945780.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-4219:
--------------------------------------

    Issue & fix info: [Release Note Needed]

Yes, I think we'll need a release note if we fix it.

> Wrong SQLState when client has lost connection to server
> --------------------------------------------------------
>
>                 Key: DERBY-4219
>                 URL: https://issues.apache.org/jira/browse/DERBY-4219
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.5.1.1
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
>
> If a client loses the connection to the server, it may end up throwing
> an exception with SQLState 58009, which is only supposed to be thrown
> if there is a protocol error caused by a programming error. If the
> connection is lost, an exception with SQLState 08006 should be thrown
> instead. One way to detect this situation might be to check if the
> underlying cause is a SocketException, but I haven't checked if that
> would work as a general solution.
> More information copied from comment posted on DERBY-401:
> I'm wondering if SQLSTATE 58009 is the correct one to use in this
> situation. Class 58 is reserved for implementation-defined conditions
> according to the SQL standard (ISO/IEC 9075-2:2003 - Chapter 23), so
> there's no mention of what it's supposed to mean there. However,
> section 8.2 of DRDA V4, vol 1 (SQLSTATE Codes Referenced by DRDA) says
> this about 58009:
> > 58009
> >
> > Execution failed due to a distribution protocol error that caused
> > deallocation of the conversation.
> >
> > This SQLSTATE reports a DRDA protocol error that causes termination
> > of processing for a specific command or SQL statement. When an
> > application requester returns this SQLSTATE, the application
> > requester must also deallocate the conversation on which the
> > application server reported the protocol error.
> >
> > Each of these errors is a programming error.
> >
> > The current connection failed because the server does not support
> > the requested function. A new connection is required to allow the
> > successful execution of further SQL statements.
> Note that this SQLSTATE is supposed to be used only if there is a
> programming error leading to protocol errors or if the server does not
> support the requested function. The error in Kathey's example doesn't
> match any of those error conditions.
> Also, I found this comment in SQLState.java which explains the
> rationale for choosing this particular SQLSTATE:
> // 58009 means connection is terminated. This can be caused by any number
> // of reasons, so this SQL State has a lot of instances.
> //
> // NOTE: if the disconnection is not caused by DRDA-level error, you should
> // use SQL State 08006. The way I determined this is if the error occurs
> // in the 'client.net' package, use 58009. If it occurs in the 'client.am'
> // or any other client package, use 08006. It's really not at all clear
> // from the specs when you should use one SQL state or the other, but that's
> // the approach I chose (David Van Couvering).
> So it seems to me we should have a more intelligent logic for choosing
> when to throw 58009 and when to throw 08006. As it is now, it decides
> based on which package the error was detected in. I think we need to
> change this so that 58009 is thrown if the client receives invalid
> data from the server, and 08006 if the connection is lost. If we
> change it this way, Kathey's example will throw
> SQLNonTransientConnectionException (and match SQL+DRDA).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.