commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject [dbcp][pool] Robust pooling
Date Fri, 06 May 2011 16:55:13 GMT
Despite lots of user requests over the years, DBCP has always backed
off the challenge of providing really robust connection pooling -
i.e., seamlessly handling server or network failures.  The reason
for this is that from the vantage point of DBCP, doing more than
just validating connections and destroying / attempting to replace
broken ones ends up getting very complicated and ultimately hopeless
given the information available to DBCP itself.

There are three things that have changed that could lead to big
improvements in DBCP robustnesss:

0) Memory is now plentiful enough that the elegant but crippling
decision in the original design of GenericObjectPool to not hold
onto references to objects checked out from the pool can safely be
reversed.  DBCP 2 should hold references to and listen for events
from checked out connections.
1) JDBC 4 API provides better communication with connections
2) Coordination services are emerging

It is really 2) that takes us out of the "hopeless" realm.  Systems
like Zookeeper [1], Doozer [2] and other cloud management /
distributed coordination frameworks make it possible for DBCP to
skirt the responsibility of deciding *what* to do (the hopeless
part) and just decide instead on a protocol and algorithm for
executing failover / rerouting given instructions from a
coordinator.  It should be possible to tell DBCP to "stop using
server A and start using server B" in such a way that applications
using pooled connections are minimally impacted and, depending on
the state of server A and instructions from the coordinator,
transactions in progress are handled optimally.

There are lots of things to consider in making DBCP manageable in
the sense described above.  I am starting this discussion now
because I want to make sure that we build whatever we need to build
into pool 2 to make these features possible in DBCP 2.  Minimally,
we are going to need a GOP that holds references to checked out
instances and the "maintenance thread" concept now embodied in the
evictor needs to be extended to active instances.


[2] **

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message