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

It is not that trivial for JDBC to be able to detect and handle all the
cases when the connection can be considered "closed" as opposed
legitimate error conditions...
Besides, if isClosed () returned true in such situations, it would be
lying :-)

You can use other means to figure out if the connection is still valid
when it is returned to the pool, instead of relying on isClosed ().
I do something like this in my connection pool:

try
{
c.createStatement ().execute ("select 1;");
idlingConnections.add (c);
}
catch (Exception e)
{
log ("OOPS: the connection seems dead: ", e);
try
{
c.close (); //Just in case...
}
catch (Exception e)
{
}

numOpenConnections--;
}

I hope it helps...

Dima.

David Wall wrote:

>I have a connection pool that opens several connections and passes them out
>to individual threads as needed. Normally this works just fine. However,
>if the postgresql database is restarted, or if the database is on another
>network segment, hiccups on the network will cause socket errors on the
>underlying JDBC connection.
>
>When a connection is returned to the pool, I'm calling the 'isClosed()'
>method to see if the underlying connection has been closed, but apparently
>when there is a socket error, the JDBC connection is not automatically being
>closed, despite the fact that such an error will always be unrecoverable.
>
>I've also seen the same problem occur on the Oracle JDBC drivers (oracle sql
>exception errors 17002 and 17008).
>
>Is there a reason why the JDBC implementations don't close the Connection
>object when they get an I/O error on the socket? Or am I doing something
>else wrong in trying to detect that the connection has failed and must be
>closed and reopened before being used again?
>
>Thanks,
>David
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
>