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 Sat, 11 Jun 2011 17:18:24 GMT
On 6/11/11 2:54 AM, Mark Thomas wrote:
> On 11/06/2011 08:44, Phil Steitz wrote:
>> I have looked at this some more and I think we have two choices,
>> depending on how much we want to be able to do in terms of
>> monitoring and instance management.  The simplest solution is to
>> enable only holding references to instances checked out to clients,
>> but no tracking of last active times, etc. by the pool itself
>> (leaving this to the pooled objects themselves, as
>> AbandonedObjectPool does now).  That could be done with less
>> ambitious _allObjects and PoolableObject classes.  Actually,
>> _allObjects would go away, replaced by a List of _circulatingObjects
>> (like AbandonedObjectPool trace) and PoolableObject would really
>> only maintain state for idle instances or instances undergoing
>> lifecycle transitions.
> The problem with a List and objects where A.equals(B) is that we'll have
> to iterate through the list testing objects for equality when an object
> is returned in order to remove the right object. That will be slow. (If
> we want to prevent the same object being returned multiple times).

>> If we want to be able to track things like last active time (as the
>> trunk code now enables), we need to be able to identify returning
>> objects uniquely.  That means either we impose the factory
>> discernibility requirement or use system identity hashcodes.
>> I would like to keep the monitoring / management options open, so my
>> vote is for the second option.  I wonder, though, if it makes sense
>> to keep the base implementation simple (and a little faster) and
>> restrictive and provide the equals-tolerant functionality in a
>> subclass or via a config option.
> I too think that the second option is the way to go using system
> identity hashcodes. I'm not sure that the first option will be faster
> since iterating through the List of circulating objects is likely to be
> slower than generating a system identity hashcode and doing a lookup in
> a Map. If testing pool2/dbcp2 shows that the system identity hashcode
> makes it significantly slower than Tomcat's jdbc-pool then we can look
> at this again.

What I meant in the second comment was to basically leave the code
as is with the restriction that instances must be equals-discernible
by default and provide either a subclass or a config option that
would trigger the more complicated code to check identity hashes.

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

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

View raw message