commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] Reusing Config
Date Mon, 25 Oct 2010 16:43:01 GMT
On 10/25/10 12:36 PM, James Carman wrote:
> On Mon, Oct 25, 2010 at 12:25 PM, Phil Steitz<>  wrote:
>> I notice now what I missed on initial review of Simo's patch - the pool
>> accessors now manage the config properties via persisted Config members.  I
>> am OK with this, but it now means that the Config classes have to be
>> mutable.  What needs to be threadsafe, however, is the pool itself. Given
>> that you can't rely on Config locks to ensure correctness for the pool (i.e.
>> the pool-exposed mutators are still going to have to lock the pool itself),
>> making Config accessors synchronized is just adding extra synch.
> I haven't had a chance to review the proposed code changes yet, but
> why not just use a reconfigure(Config) method on the pool objects
> which is called by the constructor and by the outside world (including
> JMX stuff)?  There are two options with this approach:
> 1.  Make a copy of the Config object so that outside changes (if
> Config is left mutable) don't make an impact.
> 2.  Don't refer directly to the Config object at all inside the pool's
> implementation.  You'd have to copy the config information somewhere
> else obviously.

I like 2. better. That is how it worked before (pool properties were 
held in individual fields).  I missed that part of the change.  Not 
all properties are mutable and we want to be able to set / get 
individual properties at runtime. That would be awkward under option 1.


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message