For the details of this bug report, see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1879
As the report points out, GenericConnectionPool does not do anything about
"stale" connections (i.e. those that the database has timed out, or what
will happen to all of them if the database is rebooted). The proposal is
to add a call to
connection.getConnection().isClosed()
in an attempt to assess the current state of the connection. I don't
think this is the correct approach, because it depends on the JDBC driver
doing something active to test for this (as opposed to just checking to
see if the application has called close() on it). Doing this would also
contradict the "JDBC 2.1 Core API" spec, section 11.1:
The Connection.isClosed() method is only guaranteed to
return true after Connection.close() has been called.
Connection.isClosed() cannot be called, in general, to
determine if a database connection is valid or invalid.
A typical client can determine that a connection is
invalid by catching the exception that is thrown when an
operation is attempted.
Therefore, it seems to me that allowing the configuration of an optional
"do nothing" SQL command that GenericConnectionPool can use to test the
validity of the connection would be a better approach. Does that make
sense to folks?
Craig
