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
