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
