Why we test the connection
Jerry Brenner, February 28, 2004 - 2:34 pm UTC
We're using an open source connection pool implementation and we're relying on that implementation to return us a valid connection. The connection pool will test the connection before returning it to us. If it is bad, then it will toss that connection and try another one. If there is some major problem, like the database is down, then an exception will be thrown and reported out to the user.
Here's a situation that testing the connection solves:
Connection pool has N connections.
Something bad happens to the network or the database and the problem is fixed.
A user connects to our application. We get an invalid connection back from the connection pool because of the problem mentioned above. At this point, the only way to clean the connection pool is to restart the application. If the connection pool does the testing, then it discovers that the connection is bad (and all others are bad). It throws away the bad connections and gets a new valid connection to return.
February 28, 2004 - 2:41 pm UTC
the application can take care of "something bad happens to connection" just as easily by
a) asking for it
b) trying to use it
c) upon failure getting another
I've seen systems where much of their resources were spent "testing these connections" needlessly.
but, sigh, if you persist, just begin ?:=1; end; or even just execute "begin null; end;" and check the return code from the execute.