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