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