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:58:01 GMT
On 6/11/11 4:31 AM, Mark Thomas wrote:
> On 11/06/2011 12:26, Honton, Charles wrote:
>> Please look at java.util.IdentityHashMap again.  I think it does
>> everything you're looking for except concurrent access.  Given other
>> requirements, I'm not sure a ConcurrentHashMap will buy much performance
>> anyway.
> I suggest you take a look in the archives. Synchronisation has a major
> negative impact on performance. IdentityHashMap is completely the wrong
> solution for this use case.
> Mark
>> chas
>> On 6/11/11 5: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.

Speaking of that, you will notice that [performance] is now set up
to handle both dbcp2 and tomcat jdbc-pool and a mock driver.  I
would strongly encourage testing with variable load profiles as
[performance] can generate rather than the primitive
threads-in-a-loop setup in the jdbc-pool unit tests.  To really test
the pool performance, you need the pool to grow and shrink.  That
will not happen with constant load. 

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

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

View raw message