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 12:51:38 GMT
On 16 October 2010 13:10, Simone Tripodi <simone.tripodi@gmail.com> wrote:
> Thanks for the feedbacks Seb!!!
> what about if I start implementing a proposal and then we
> progressively refine the design?

Fine by me.

But it might be better to look at how the Tomcat JDBC pool
implementation might be of use before polishing the current code much
further.

> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sat, Oct 16, 2010 at 1:46 PM, sebb <sebbaz@gmail.com> wrote:
>> On 16 October 2010 06:18, Simone Tripodi <simone.tripodi@gmail.com> wrote:
>>> 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.
>>
>> I'd be happy with using config for all parameters.
>>
>> If one did not want to have multiple config constructors for them,
>> then immutable fields could be extracted from the config by the
>> Factory (etc.) constructors.
>> The Factory class would then use its local final copy of the immutable
>> field, and subsequent changes to the config would be ignored.
>>
>> This would be fairly easy to implement, but the different treatment of
>> some config parameters would need to be documented.
>>
>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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