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.
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
