[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    RE: [pool] Pool config vs. factory hierarchies.
From:       Gary Gregory <GGregory () seagullsoftware ! com>
Date:       2010-11-30 22:02:57
Message-ID: 02AA127CD8DCDE48BC7D2DFB6C87083A07DE7A71 () nwt-s-mbx2 ! rocketsoftware ! com
[Download RAW message or body]

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.tripodi@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.steitz@gmail.com> wrote:
> >
> >
> >
> >
> > On Nov 3, 2010, at 5:03 PM, Steven Siebert <smsiebe@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-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


[prev in list] [next in list] [prev in thread] [next in thread]