commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [POOL2] [Keyed]ObjectPoolFactory mutability and DBCP/JNDI
Date Wed, 14 Dec 2011 17:01:24 GMT
On 14/12/2011 09:23, sebb wrote:
> I'm trying to establish the mutability needs of the
> [Keyed]ObjectPoolFactory implementations, i.e.
> Generic[Keyed]ObjectPoolFactory
> I've looked at DBCP 1.4, which uses POOL 1.x.

You need to look at DBCP trunk that uses POOL 2. There has been quite a
lot of refactoring.

> DBCP 1.4 currently creates an instance of
> GenericKeyedObjectPoolFactory, which it then uses via the interface
> KeyedObjectPoolFactory.
> [This is in the class BasicDataSource.]
> The additional GKOPF getters, and the protected mutable variables are
> not actually used by DBCP; it only needs to create the instance of
> KeyedObjectPoolFactory.
> There is no indication that DBCP needs to change or even inspect the
> factory settings once it is created.
> The factory setters were added in POOL2; if they were not needed for
> DBCP in POOL 1.X, so are they really needed in POOL 2.x?
> I already removed them as part of making the classes thread-safe; the
> question is, are the setters now needed in POOL 2?
> If so, they can be restored, but synch./volatile will need to be
> added, as I assume the factories must be thread-safe.
> Indeed, are the getters even needed? The Pool 1.x code did provide
> getters, but AFAICT they were not used by DBCP.
> The calling code knows what it used to create the factory, and the
> factory is subsequently used as an instance of the interface - which
> only provides the createPool() method.
> Is there really a need for other code to find out what the original
> factory settings were?
> Can the getters be removed?
> Do the setters have to be restored?

The factory is little more than a wrapper for the G[K]OPConfig and

I think there are three options.
1. Drop getters and setters and keep it as a simple, immutable wrapper.
2. Provide getters and setters and make it thread-safe for folks who
want multiple pools with almost identical configuration.
3. Drop the Factory entirely.

DBCP2 doesn't need these factories.
The factories aren't adding very much value.

On reflection, I am leaning towards dropping these factories entirely.


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

View raw message