On 6/9/11 9:05 AM, Mark Thomas wrote: > On 09/06/2011 15:48, Gary Gregory wrote: >> Hi All: >> >> I would like to understand the requirements better: >> >> - Is this for pool1 and/or pool2? It seems like a big change for pool1 that >> should be in a 1.6 (not 1.5.x) > pool2. No plans for this change in pool1. > >> - Do we have real user stories for this new req? Or is this a theoretical >> nicety? > The most obvious one is preventing the same object being returned to the > pool more than once. POOL-103. > > Keeping track of all the objects in the pool opens up a range of > possibilities for improved monitoring/management features. We could, for > example, move the abandoned object tracking from DBCP to pool.
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. 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. Phil [1] http://en.wikipedia.org/wiki/Identity_of_indiscernibles > 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
