commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] equal instances
Date Thu, 09 Jun 2011 16:47:40 GMT
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.


> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message