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" <ma...@apache.org> 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. >> >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
