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.
==
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
