On Jun 10, 2011, at 13:47, Mark Thomas <ma...@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. Is this a feature that should be in a subclass or a toggle? Or do we want it baked it? 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-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
