commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [pool] Pool config vs. factory hierarchies.
Date Fri, 29 Oct 2010 15:52:09 GMT
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Friday, October 29, 2010 21:41
> To: Commons Developers List
> Subject: Re: [pool] Pool config vs. factory hierarchies.
> 
> Another possibility:
> 
> If Config instances are immutable, then there is no need to synch.
> access to their contents.
> However, if the field which stores the Config instance is not final,
> then all accesses to that need to be synch. - or the field could be
> volatile.
> 
> Once the code has obtained the config pointer safely, it can access
> the final Config fields without synch. This would eliminate the need
> for the locks, provided that the config instance was fetched at most
> once per operation.
> 
> Changing a config value would then require creating a new Config
> instance, by taking the existing Config and applying any necessary
> changes to produce the new Config (or of course, creating a new Config
> from scratch).
> 
> StackObjectPoolConfig config1 = ...;
> 
> StackObjectPoolConfig config2 = new StackObjectPoolConfig.Builder(config1)
>        .setInitIdleCapacity(initIdle)
>        .setMaxSleeping(maxSleep)
>        .createConfig();
> 
> where the Builder now takes an existing config as a parameter.

That all looks quite nice. I'm all for it.

Gary

> 
> ==
> 
> BTW, maybe the new Builder() call could be replaced by
> 
> StackObjectPoolConfig.createBuilder()......createConfig()
> 
> This would be a bit more flexible, and perhaps more consistent?
> 
> On 29 October 2010 16:18, Simone Tripodi <simone.tripodi@gmail.com> wrote:
> > Hi James,
> > IMHO the Read/Write lock stuff is a very cool idea, it rocks!!!
> > Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://www.99soft.org/
> >
> >
> >
> > On Fri, Oct 29, 2010 at 5:09 PM, James Carman
> > <james@carmanconsulting.com> wrote:
> >> On Fri, Oct 29, 2010 at 10:58 AM, Gary Gregory
> >> <GGregory@seagullsoftware.com> wrote:
> >>>
> >>> I thought we said that pools settings should be configurable. The current
> Config root class has setters.
> >>>
> >>> Are we saying that, yes, pools are configurable post-creation but not
> through config objects? Should config objects be cloned when passed in a
> constructor then?
> >>>
> >>
> >> My opinion is that the config objects should be immutable.  Then, you
> >> don't have to worry about synchronization issues.  You'd just have the
> >> reconfigure(Config) method (which is called by the constructor).  The
> >> reconfigure method would take care of making sure it locks down
> >> (synchronizes) everything while he does all the reconfiguring of the
> >> pool.
> >>
> >> I would probably suggest a read/write lock.  Folks who want to borrow
> >> an object from the pool or return and object to the pool would be
> >> obtaining the "read" lock.  When you are in the middle of
> >> reconfiguring the pool, you'd obtain the "write" lock.
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message