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! 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
