[ 
https://issues.apache.org/jira/browse/DBCP-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487805
 ] 

Marcos Sanz commented on DBCP-212:
----------------------------------

Indeed, the problem is triggered by the synchronized methods in 
GenericObjectPool, like getNumActive() and getNumIdle(), often called by 
applications. These methods serialize all executing threads to a single code 
point, thus the number of unused objects in the pool increases at some moments 
and eventually reaches the maxIdle value, which triggers the destroyObject(), 
causing physical closes() of database connections.

This is very cumbersome, and nearly a paradox: there are indeed one thousand 
threads in the example concurring for fifteen database connections, yet the 
pool decides the connections are idle.

One solution to this problem can be the application always setting maxIdle := 
maxActive, though this has side effects. I am wondering whether it could be 
possible to make these private fields (_maxActive, _numActive, ...) volatile 
and get rid of the synchronized in the methods. I have to explore this. In the 
meantime, I think this issue belongs to Commons-Pool, rather than to 
Commons-DBCP.

> PoolingDataSource closes physical connections
> ---------------------------------------------
>
>                 Key: DBCP-212
>                 URL: https://issues.apache.org/jira/browse/DBCP-212
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.2.2
>         Environment: Windows XP, Java 1.5.0_06-b05, Sybase ASE 12.5.4, 
> jConnect 6.0.5 EBF 13862, Commons Pool 1.3
>            Reporter: Marcos Sanz
>         Attachments: DBCPtester.java, DBCPtester.java
>
>
> By executing the attached program and monitoring the process id of the 
> physical connections at the database server, it is possible to demonstrate 
> that the connections are being actually physically closed and reopened by the 
> application at a very high rate.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to