I agree, isClosed() won't work. An option for a testing a connection with a
do-nothing SQL statement is needed. This is pretty standard for most
connection pools that I have seen.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 01, 2001 5:41 PM
> To: [EMAIL PROTECTED]
> Subject: Bugzilla #1879 (Connection Pool handling of Stale
> Connections)
>
>
> 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
>
>
