commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [pool] equal instances
Date Fri, 10 Jun 2011 21:33:19 GMT
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?


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

View raw message