From: | "David Wall" <d(dot)wall(at)computer(dot)org> |
---|---|
To: | "Dmitry Tkach" <dmitry(at)openratings(dot)com> |
Cc: | "pgsql-jdbc-list" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Detecting 'socket errors' - closing the Connection object |
Date: | 2003-07-21 18:41:05 |
Message-ID: | 015101c34fb7$a5343f20$3201a8c0@rasta |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
> 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...
Why is that the case? I mean, if the library gets a socket error, rather
than error from the database, it's an I/O error that probably means a TCP
socket won't really be okay anymore, and it could then close it.
> Besides, if isClosed () returned true in such situations, it would be
> lying :-)
Well, not if it closed it after it got an error. I mean, I don't open the
socket either, but the JDBC library should be able to figure it out, no?
> 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--;
> }
That will work, but doesn't adding an entire call to the backend database on
each use a connection from the pool seem excessive? I mean, if I'm going to
all that trouble, I might as well not pool the connection at all -- the
overhead can't be that much different.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Darin Ohashi | 2003-07-21 18:51:09 | Re: IN clauses via setObject(Collection) [Was: Re: Prepare |
Previous Message | Paul Thomas | 2003-07-21 18:24:43 | Re: IN clauses via setObject(Collection) [Was: Re: Prepare |