commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <>
Subject Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
Date Wed, 29 Mar 2006 04:51:32 GMT
On 3/28/06, Craig McClanahan <> wrote:
> On 3/28/06, Peter Steijn <> wrote:
> >
> > >
> > > I haven't dug into Dbcp code but I think the GenericObjectPool is deep
> > > within Dbcp as an internal data structure and I'd be surprised if it
> > > let you specify a specific pool implementation.
> >
> >
> > Does anyone else think that this should be different?
> >
> > Suggestion: The next version of DBCP should allow you to specify your own
> > implementation in a configuration file.  I know that I was looking around
> > for this feature when I first was exploring DBCP and POOL.
> It's been a couple of years since I looked in detail, but IIRC the only
> place that DBCP locks down the choice of the pool implementation is when you
> select a specific *implementation* of DataSource (such as
> org.apache.commons.dbcp.BasicDataSource).  If you assemble your own from
> scratch, you're free to do whatever you want as you build up the stack.
> Adding plugability inside something like BasicDataSource strikes me as an
> excellent way to hand a developer a loaded gun, aimed at their foot.  The
> code in a given implementation is going to naturally make assumptions about
> the underlying pool implementation being used (such as what configuration
> parameters it accepts) -- if you want a different DBCP implementation, it's
> really easy to assemble your own.

Also, my read of some of Dbcp code weeks ago is that if you use a pool
with a running idle object (connection) evictor you run the risk of
deadlock because of the order of how locks are acquired.

synchronization of getting a new connection normally:
DbcpConnection -> ObjectPool -> DbcpConnection.makeObject (implements
the same object instance on each side of the object pool instance.

The idle eviction thread synchronization:
ObjectPool -> DbcpConnection.activateObject (implements PoolableObjectFactory)

Until this is worked out it's not safe to let client code configure
their own ObjectPool. Most likely this problem won't turn up in
testing under light load but will fall apart in production.

Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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

View raw message