Hi Seb! :) Of course, thanks for the suggestion! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
On Sat, Oct 16, 2010 at 2:51 PM, sebb <seb...@gmail.com> wrote: > On 16 October 2010 13:10, Simone Tripodi <simone.trip...@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 <seb...@gmail.com> wrote: >>> On 16 October 2010 06:18, Simone Tripodi <simone.trip...@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 <seb...@gmail.com> wrote: >>>>> On 15 October 2010 17:01, Simone Tripodi <simone.trip...@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-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
