Hello Dirk, We have build dbcp with the synchronization removed and it removed the bottleneck from dbcp. We've only used our modified dbcp in our testing environment. I wanted to check with the list to see if we were overlooking something when modifying the synchronization. I'll probably post our patch to the list tomorrow. It is a really small change.
Thanks, Brad Johnson -----Original Message----- From: Dirk Verbeeck dirk.verbeeck-at-pandora.be |jakarta-commons| [mailto:[EMAIL PROTECTED] Sent: Saturday, November 22, 2003 7:35 AM To: Johnson, Brad Subject: Re: [dbcp] PoolableConnectionFactory validation and synchronized methods Hello Brad, There is indeed no technical reason why PoolableConnectionFactory should be synchronized but I didn't want to include this change in 1.1. First it should be tested by multiple people / multiple database systems to see how the system reacts in the real world. There is indeed a good chance that the change boosts performance without any negative effects. If you are able and have the time to do some performance tests then please do so, I can assist if needed (make test build,...). Regards Dirk Brad Johnson wrote: > 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 --------------------------------------------------------------------- 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]
