You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2002/11/15 16:16:57 UTC

DO NOT REPLY [Bug 14592] - DBCP must be robust against e.g. database shutdowns

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14592>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14592

DBCP must be robust against e.g. database shutdowns





------- Additional Comments From rwaldhof@us.britannica.com  2002-11-15 15:16 -------
Can you clarify what exactly you have in mind?  There are a couple of ways to 
get something like this today, and some ways we could enhance that support:

* If you provide a validation query and set testOnBorrow to true, DBCP will 
only return connections that pass validation, evicting those that don't.  This 
should prevent any database shutdown issues, at the cost of a small query each 
time you obtain a connection.

* If you provide a validation query, configure an evictor, and set 
testWhileIdle to true, DBCP will periodically poll the idle connections and 
evict those that fail validation.  This will allow dbcp to "recover" from 
database shutdown, but not immediately--some returned connections will be 
invalid until the pool has had a chance to validate all of them.

* The cvs HEAD of commons-pool now supports an "invalidateObject" method, 
which "evicts" an "active" object.  Exposing this in the DBCP interfaces would 
allow calling code throw away a connection on failure and retry.

* Commons-pool has long supported a clear() method.  Exposing this in the DBCP 
interfaces would make it possible to send a signal to the pool (when the 
database is bounced) that all of its connections are invalid.

* If there was a way in validate that we could reliably tell that the database 
was bounced, we could "automatically" clear the connections in that 
circumstance.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>