commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
Date Wed, 14 Dec 2011 18:29:55 GMT
On 14/12/2011 12:10, sebb wrote:
> This is a parallel thread to the one about PoolFactory implementations.
> I'm trying to establish the mutability needs of the
> [Keyed]ObjectPool implementations, i.e.
> Generic[Keyed]ObjectPool
> I've looked at DBCP 1.4, which uses POOL 1.x.
> SharedPoolDataSource.registerPool() creates an instance of
> GenericKeyedObjectPool which it configures via the setters; however
> the instance is then stored in a KeyedObjectPool, and setters/getters
> are not used elsewwhere.
> SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance
> of GenericKeyedObjectPool which is then only used via the
> KeyedObjectPool interface.
> So: as far as I can tell from DBCP, there is no need to provide
> mutable ObjectPool implementations; so long as the pool can be
> configured intially, that is sufficient.
> Are there any other existing use cases that I am missing here?

I do see periodic requests to be able to change the (DBCP) pool
properties dynamically and it was my intention to support this use case
via JMX for POOL2.

JNDI assumes resources are essentially beans i.e. have zero argument
constructors and getters/setters. If this is not the case then some
extra plumbing is required. The further G[K]OP gets from a JavaBean the
more plumbing required. Currently the only extra plumbing required is to
work-around the zero-argument constructor. Removing the setters would
mean more plumbing would be required for someone to create a custom JNDI
resource for a pool of objects of type X.

DBCP already has the plumbing to handle the removal of the setters but
it would require some code changes.

It was always my intention to provide the ability to change the pool
properties on the fly. I would rather spend a little time fixing the
remaining threading issues than drop that requirement. I certainly don't
want to try coding DBCP to support dynamic changes when the underlying
pool does not.

Given that there is a requirement from DBCP users for dynamic changes to
the pool, I believe POOL2 needs to support mutable pool implementations.


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

View raw message