Re: Detecting 'socket errors' - closing the Connection object

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Dmitry Tkach <dmitry(at)openratings(dot)com>
Cc: David Wall <d(dot)wall(at)computer(dot)org>, pgsql-jdbc-list <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Detecting 'socket errors' - closing the Connection object
Date: 2003-07-22 14:25:37
Message-ID: 20030722142537.GG11354@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On Tue, Jul 22, 2003 at 10:18:28AM -0400, Dmitry Tkach wrote:
> >
> >
> >Unfortunately the isClosed() javadoc is fairly explicit in saying you can't
> >use it for this:
> >
> > 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.
> >
> Hmmm.... To me this phrase sounds like exactly what he was asking for...
> Perhaps, it would then make sense to make isClosed() return false if the
> socket goes south...
> I think that situation very well qualifies as a 'certain fatal error'
> after all...
>
> >This method is guaranteed to return true only when it is
> > called after the method Connection.close has been called.
> >
> >
> This is weird.... direct contradiction with the previous sentense isn't
> it? :-)

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.

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.

-O

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dmitry Tkach 2003-07-22 14:27:17 Re: the IN clause saga
Previous Message Felipe Schnack 2003-07-22 14:20:11 Re: patch: tiny patch to correct stringbuffer size estimate