commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] equal instances
Date Fri, 10 Jun 2011 21:14:55 GMT
On 6/10/11 10:46 AM, 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;
> - 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 :)

Sweet!
> I'll leave this a little while before I do any coding to give folks a
> chance to comment.

I will play with this a little this evening too.

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


Mime
View raw message