Hi Gary, yes, more people involved on defining these details is better, I agree. I'm thinking about creating a wiki page to resume all the requirements, what do you think? Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory <ggreg...@seagullsoftware.com> wrote: > On Dec 1, 2010, at 2:01, "Simone Tripodi" <simone.trip...@gmail.com> wrote: > >> Hi Gary :) >> thanks for the feedback, IMHO once the Configuration for >> Generic(Keyed)ObjectPool(Factory) will be fixed, we could start >> thinking about a new release of the new pool. This evening/tonight (in >> my local time) I'll start re-arranging stuff, of course suggestions >> will be more than appreciated. >> >> About duplication: I agree with you, but after re-reading all the >> mails we wrote about it, I recently become convinced that >> Configuration for GKOB/GOB have different semantic even if some >> configuration property have same name/type, what's your opinion about >> it? Many thanks in advance! >> > Yes, semantics are different iirc and I'd confusing is that some props have > the same name but mean different things for each pool type. > > I am not sure if it worth changing these method names (new method and > deprecated old method) or just writing better javadocs. I would go with an > experts opinion there. > > Gary >> Have a nice day, >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory >> <ggreg...@seagullsoftware.com> wrote: >>> Yes, I thought we were on a roll there! Lots of good discussions and >>> then... quiet. That's OK though. We all get busy. Time to come back and >>> reflect. >>> >>> I am still looking for these goals: >>> - Generics released ASAP. I would be OK for a earlier release just to get >>> this out. >>> - Better names for properties and methods >>> - Refactor to remove duplication >>> >>> Gary >>> >>>> -----Original Message----- >>>> From: Simone Tripodi [mailto:simone.trip...@gmail.com] >>>> Sent: Tuesday, November 30, 2010 09:33 >>>> To: Commons Developers List >>>> Subject: Re: [pool] Pool config vs. factory hierarchies. >>>> >>>> Hi all guys, >>>> sorry for resurrecting a zombie message, but I've been busy at work >>>> and haven't had the chance to contribute at all. >>>> I could re-start committing code according to the requirements >>>> described by Phil, If it works for you, so other tasks like >>>> JMX/autoconfigure can be unlocked, please let me know. >>>> Have a nice day, >>>> Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert <smsi...@gmail.com> wrote: >>>>> >>>>>>> >>>>>>> >>>>>>> You restore the pool fields that used to hold the configuration setting >>>>>>> properties and leave the getters and setters (for the mutable ones) in >>>>>>> place. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>> so something like this? >>>>>> >>>>>> public class GOP extends .... { >>>>>> >>>>>> /** >>>>>> * ref to immutable config reference, immutable config values are >>>>>> either >>>>>> referred directly here >>>>>> * or are copied to a final instance field >>>>>> */ >>>>>> private GOPConfig config >>>>> >>>>> No. There is no config member. It is used only to encapsulate the >>>> parameters of the ctors. The GOP class stores the config data in >>>> individual >>>> fields, accessed by getters and setters. The setters at least are >>>> synchronized using the pool monitor. Look at the old code. What I am >>>> proposing is that we limit the use and lifetime of the config objects to >>>> the >>>> ctors and/or factories. >>>>> >>>>> Phil >>>>>> >>>>>> >>>>>> //mutable configuration values are mutated/accessed from pool instance >>>>>> private volatile int mut1; //probably better to use read/write locks >>>>>> private volatile int mut2; >>>>>> >>>>>> public GOP (GOPConfig config) { >>>>>> this.config = config; >>>>>> reconfigure(config); >>>>>> } >>>>>> >>>>>> /** >>>>>> * using this model, this method isn't really required (at least not >>>>>> public) >>>>>> * but would be a convenience for "batch"/atomic changes to >>>>>> configuration >>>>>> values - >>>>>> * this is possible if we switch from volatile to a r/w locking >>>>>> mechanism >>>>>> */ >>>>>> public void reconfigure (GOPConfig config) { >>>>>> mut1 = config.getMut1; >>>>>> mut2 = config.getMut2; >>>>>> } >>>>>> >>>>>> public void setMut1 (int m) { >>>>>> mut1 = m; >>>>>> } >>>>>> >>>>>> public int getMut1 () { >>>>>> return mut1; >>>>>> } >>>>>> >>>>>> .... >>>>>> } >>>>>> >>>>>> I wonder, with this model....what is the reason for having an immutable >>>>>> configuration instance if we're going to copy the values locally for (at >>>>>> least) mutability purposes? I believe the attraction of the immutable >>>>>> configuration instance was for concurrency issues...but with this model, >>>>>> we >>>>>> would need to use pool-local syncronization (locking) anyway. >>>>>> >>>>>> I wrote a quick mock-up implementation like this, using a >>>>>> ReentrantReadWriteLock, and the amount of concurrency work in each >>>>>> pool/factory started to pile up. We already identified that inheritance >>>>>> of >>>>>> the Pool/Factory classes might not be the best approach (I agree with >>>>>> this >>>>>> as well...which would cause POOL-177 to no longer be implemented)...so >>>>>> this >>>>>> means duplication of synchronization code as well. >>>>>> >>>>>> I think I'm falling back to my initial thought on this in that the config >>>>>> classes should, IMO, either be mutable (where appropriate) and made >>>>>> thread >>>>>> safe (internally synchronized) to reduce the amount of concurrency work >>>>>> needed in each class that aggregates the instance...or immutable and any >>>>>> changes to the config instance needs to be done by going back to the >>>> Builder >>>>>> (something like new Builder(configInstance).change().create());) and then >>>>>> the config reference in each pool/factory could be made volatile. >>>>>> >>>>>> I know this is confusing in email....I would be glad to create a quick >>>> patch >>>>>> or UML for this to clear things up if this would help. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> S >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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
