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 Wed, 01 Dec 2010 13:39:23 GMT
On Dec 1, 2010, at 2:01, "Simone Tripodi" <simone.tripodi@gmail.com> wrote:

> Hi Gary :)
> thanks for the feedback, IMHO once the Configuration for
> Generic(Keyed)ObjectPool(Factory) will be fixed, we could start
> thinking about a new release of the new pool. This evening/tonight (in
> my local time) I'll start re-arranging stuff, of course suggestions
> will be more than appreciated.
> 
> About duplication: I agree with you, but after re-reading all the
> mails we wrote about it, I recently become convinced that
> Configuration for GKOB/GOB have different semantic even if some
> configuration property have same name/type, what's your opinion about
> it? Many thanks in advance!
> 
Yes, semantics are different iirc and I'd confusing is that some props have the same name
but mean different things for each pool type. 

I am not sure if it worth changing these method names (new method and deprecated old method)
or just writing better javadocs. I would go with an experts opinion there. 

Gary
> Have a nice day,
> Simo
> 
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
> 
> 
> 
> On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory
> <GGregory@seagullsoftware.com> wrote:
>> 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
>> 
>> 
> 
> ---------------------------------------------------------------------
> 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