commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [pool] equal instances
Date Fri, 10 Jun 2011 21:38:37 GMT
On 10/06/2011 22:33, Gary Gregory wrote:
> On Jun 10, 2011, at 13:47, Mark Thomas <markt@apache.org> wrote:
> 
>> On 09/06/2011 17:47, Phil Steitz wrote:
>>> I guess I "want it both ways" here.  We already have a use case for
>>> tracking instances - abandoned connection tracking in DBCP and
>>> *lots* of requests and practical uses for holding references to
>>> instances in circulation (mostly from dbcp, but I recall some from
>>> people managing socket pools or message queue pools).
>>>
>>> I know I flip/flopped on this - initially thinking it was a
>>> reasonable expectation for factories to produce equals-discernible
>>> instances.  But I am afraid it will be the source of hard to find
>>> bugs and I can see the argument on the other side - i.e., a pool
>>> should be perfectly happy managing indiscernible objects.  I never
>>> agreed with Leibniz [1] - he he.
>>>
>>> As you pointed out, Mark, 1.x gets around this problem by wrapping /
>>> unwrapping but that strategy makes identity-checking awkward.  I
>>> will think about this some more, but a hybrid strategy where
>>> _allObjects becomes a HashBag (steal from [collections]) used for
>>> quick checking and we add _allInstances  to hold wrapped instances.
>>> Could be nonsense, but something along these lines might work.
>>
>> I've done some testing and under heavy load (10 threads concurrently
>> creating 1000000 objects each) on a 8 core machine I saw zero
>> duplicates. With this in mind I think I can do the following for pool 2:
>> - have calls to PoolableObjectFactory#makeObject() check
>> System#idenityHashcode() and if a duplicate is detected discard that
>> object and ask the factory for a new one;
> 
> With a retry limit to avoid infinite loops.

Indeed.

> Is this a feature that should be in a subclass or a toggle? Or do we
> want it baked it?

I think it is going to have to be baked in. We have requirements that
mean we need to track all the objects and we need a scalable solution
for doing that. However we slice it, that is going to come down to
hashes and we need to prevent collisions.

Mark

> Gary
> 
>> - use some simple wrapper based on identityHashcode around objects in
>> the idle object pool and the all objects map
>> - when an object is returned, use identityHashcode to map it back to the
>> right object in the all object pool
>>
>> The requirement this places on PoolableObjectFactories is that they must
>> produce objects with identityHashcodes that only rarely have collisions.
>> Since this is under JVM control and my test case shows this is rare, I'm
>> happy with this.
>>
>>> The important thing at this point is to agree on what invariants we
>>> expect [pool] and user factories to maintain.  Since I have already
>>> changed my mind once on this, and I understand the practical
>>> arguments in favor of staying with the setup now in trunk (equal
>>> instances not allowed), I would like to hear what others have to say
>>> on this.
>>
>> I think we can have it both ways this time :)
>>
>> I'll leave this a little while before I do any coding to give folks a
>> chance to comment.
>>
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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