On 10/06/2011 22:33, Gary Gregory wrote: > 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.
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-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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
