commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Pool config vs. factory hierarchies.
Date Tue, 30 Nov 2010 14:32:31 GMT
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


Mime
View raw message