[
https://issues.apache.org/jira/browse/DBCP-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487994
]
Phil Steitz commented on DBCP-212:
----------------------------------
Thanks. By adding the System.out, I can reproduce the symptoms. You are
correct that it is the pool's returnObject method that is triggering closing of
the excess idle physical connections. The default maxIdle for the pool is 8.
I think that what is causing the threads to "stack up", however, is not
contention for locks on the pool, but contention on the relatively slow and
synchronized System.out.println(). When I replace
System.out.println(connectionPool.getMaxActive()) with just
connectionPool.getMaxActive(), the idle connection count to does not grow. On
the other hand, replacing it with System.out.println("hello") leads to the idle
object build up.
> 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]
