commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
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 <> 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.


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


> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message