The issue of high concurrency is very important to us as well. What I would like to see is the narrowing of the synchronization in borrowObject to include only grabbing a idle object or to making a new object and placing it the pool. Activation of the object should NOT be sychronized. This is because activation should not have anything to do with the maintenance of the datastructures tracking the pool of objects themselves. The one exception to this is testing an object that is being retrieved from the pool for use (testOnBorrow): the failure case of this test would need to be synchronized to handle removing the object from the pool.
In addition, the actual/physical connection to the database needs to occur lazily and inside activateObject. Currently this occurs in makeObject. I am speaking of the org.apache.commons.dbcp.datasources.KeyedCPDSConnectionFactory and org.apache.commons.pool.impl.GenericKeyedObjectPool. The synchronization of the makeObject and that fact that it creates that actual physical database connection causes serious degradation any time a new connection needs to be created: no other call can execute borrowObject while a database connection is being created which takes a long time. I have done a couple prototypes to work around this but have not spent enough time to get it fully functioning. Part of my problem is that I am not familiar with nor understand the need for the WeakHashMap in KeyedCPDSConnectionFactory and that the object PooledConnectionAndInfo uses final members. Anyway: +1 for removing the bottle neck on borrowObject when new objects need to be created. ToddC -----Original Message----- From: Brad Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 12:08 PM To: [EMAIL PROTECTED] Subject: [dbcp] PoolableConnectionFactory validation and synchronized methods Hello Dirk, Well, we are trying to get as much concurrency out of our application as we can (uPortal running on Tomcat). Seems that allowing concurrent connections to the database should help performance, and might allow your code to perform well enough that it exposes a bottleneck in the database. Then the problem is really with the database. So, I really don't see any drawback of removing synchronized from the code on these methods. Am I missing something here? thanks, Brad Johnson Texas Tech University --------------------------------- From: Dirk Verbeeck Subject: Re: JDBC AbandonedObjectPool and PoolableConnectionFactory Date: Sun, 28 Sep 2003 11:24:40 -0700 You can remove the synchronization of the validateObject method in PoolableConnectionFactory but be carefull. If the query is slow because the database is overloaded then allowing more validationQueries will increase the problem. For the next release I'm thinking about monitoring SQLExceptions thrown by the connection and invalidating the connection before it is returned to the pool. This will cover "broken" connections. Combined with a "testOnBorrowOldConnection" it can replace the current "testOnBorrow". Dirk ------------------- http://www.mail-archive.com/[EMAIL PROTECTED]/msg27029.html -------------------------------------- Protect yourself from spam, use http://sneakemail.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
