[dbcp] PoolableConnectionFactory validation and synchronized methods

[Brad Johnson <5f...@sneakemail.com>]

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/commons-dev@jakarta.apache.org/msg27029.html



--------------------------------------
Protect yourself from spam, 
use http://sneakemail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [dbcp] PoolableConnectionFactory validation and synchronized methods

[Dirk Verbeeck <di...@pandora.be>]

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/commons-dev@jakarta.apache.org/msg27029.html



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org