David Wall wrote:
>> 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.
>
>
But why do you only care about socket errors? What is so special about them?
What if you execute a query, and it crashes the backend? You'll get a
SQLException from the backend (not a socket error), but the connection
will still be invalid.
>>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?
>
>
I am sure some application code would get *very* surprised if
connections started to get closed "automagically" under it :-)
You don't want to preceed every statement executing a query with (if
(!connection.isClosed ()) check, do you?
>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.
>
>
>
It *is* very different... With this piece of code, the only overhead is,
pretty much, just the cost of sending about 15 bytes over the wire...
that's pretty negligeable...
You are still saving on the expensive stuff like establishing a new TCP
connection, creating file descriptors, multiple network round trips for
authentication, constructing, and starting a new backend process,
setting up memory structures etc, etc, etc...
Dima
