commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [pool] equal instances
Date Sat, 11 Jun 2011 09:54:56 GMT
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.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message