commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] Pool, Factory and Config
Date Sat, 16 Oct 2010 00:25:48 GMT
On 15 October 2010 17:01, Simone Tripodi <simone.tripodi@gmail.com> wrote:
> Hi all guys,
> there are Generic(Keyed)ObjectPool(Factory) that (in pairs, Pool and
> related factory) share the same kind of information, replicated in the
> related Config class.
>
> I wonder if we can improve that design and remove that information
> redundancy: I propose to keep the Config classes only, put them not as
> inner class, in order to remove the circular dependency between
> factory/pool and remove also the not so comfortable (at least for me)
> n-arguments constructors.
> So, the GenericObjectPool, instead of having all these constructors,
> could work only with:
>
> public GenericObjectPool(PoolableObjectFactory<T> factory) {
>    this(factory, new Config());
> }
>
> public GenericObjectPool(PoolableObjectFactory<T> factory, Config config) {
>    this.factory = factory;
>    this.config = config;
> }
>
> both factory and config can be final; if users need to reconfigure the
> pool at runtime, invoke the setter and modify the interested value
>
> pool.getConfig().setWhenExhaustedAction(WhenExhaustedAction.GROW);
>
> I'd extend later the same approach also to other Pools... WDYT?

The advantage of using ctor parameters is that they can be saved in a
final field.
The config approach is OK for parameters that need to remain mutable,
but can impose additional synch. requirements for settings that must
not be changed during the life of the pool.

For example, I suspect LIFO should be immutable, and should therefore be final.

> Many thanks in advance,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message