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]
