commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Pool, Factory and Config
Date Sat, 16 Oct 2010 05:18:38 GMT
yes, understood and agreed.
BTW I still find redundant that the same field, used with the same
semantic, is present in Config,Pool and Factory, my proposal was about
keeping the Config only - immutable fields can be declared there - and
remove config parameters from Factory/Pool, that will require a Config
or use the default one.
Otherwise any suggestion is much more than welcome, it would be a
shame IMHO not improving the design.
Thanks for discussing about this topic, have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sat, Oct 16, 2010 at 2:25 AM, sebb <sebbaz@gmail.com> wrote:
> 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
>
>

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


Mime
View raw message