> -----Original Message----- > From: sebb [mailto:seb...@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.trip...@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 > > <ja...@carmanconsulting.com> wrote: > >> On Fri, Oct 29, 2010 at 10:58 AM, Gary Gregory > >> <ggreg...@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-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
