Re: Detecting 'socket errors' - closing the Connection object - Mailing list pgsql-jdbc

> > > Retrieves whether this Connection object has been closed. A connection
is
> > > closed if the method close  has been called on it or if certain fatal
> > > errors have occurred.

Precisely.  This makes PERFECT sense to me.  It's those fatal errors that
should allow us to detect something has gone wrong and therefore should not
be retried.  If the JDBC Connection gets an I/O exception, it could easily
close itself.  I suspect I could add that code to the Postgresql JDBC
library myself quite easily.  The unfortunate situation, though, is that
other JDBC libraries may or may not do it, so therefore it's an unreliable
bit of code, and Dmitry's hack comes back into play as perhaps the only
reliable solution with the current state of affairs among JDBC
implementations.  I know for sure that Oracle does not close itself.

> No, it's just saying you can't rely on detecting errors via isClosed().
You
> might see a spontaneous close after an error, but it's not *guaranteed* --
> only close() is guaranteed to cause isClosed() to return true.

True, but it's easy for the Connection to call close() when it gets a fatal
error, so I don't think the second paragraph really means you can't close
it.  The Connection object is surely allowed to call any and all of its
methods as necessary.

> The next paragraph, which you trimmed, clarifies that:
>
>   This method generally cannot be called to determine whether a
>   connection to a database is valid or invalid. A typical client can
determine
>   that a connection is invalid by catching any exceptions that might be
thrown
>   when an operation is attempted.

We certainly can tell that.  I think this is simply saying, though, what
Dmitry was implying earlier, and that's simply the fact that a "valid"
Connection object can fail at any time, since a database can crash, a
network can drop, whatever.  Just because you are holding a Connection
object, doesn't mean the underlying connection is valid.  However, once the
underlying connection IS FOUND to be invalid, it would be quite nice to mark
it as such so that we can take the appropriate action.

The last line says I can tell by catching the exception that might be
thrown.  Well, let me tell you, I catch the exception just fine.  I just
cannot tell if that means the underlying connection is fatally down or not.
I don't know whether the Connection object I'm holding can ever be used
again or not.  This is obvious to anybody because I can catch SQLExceptions
and reuse the Connection object just fine, but at other times the
SQLException thrown means the Connection object is fatally broken and must
be discarded for a new one.  And there's no method in the SQLException to
let me know which type it was, and the Connection object itself (which does
know!) won't tell us!

ACK!  I think the Dmitry hack is my best option right now, though I will
probably do it only after receiving an SQLException rather than just because
a perfectly good Connection object is being returned to the pool (after all,
in our code, success occurs hundreds of thousands of times before an
exception is thrown).

David