[
https://issues.apache.org/jira/browse/DBCP-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490930
]
Marcos Sanz commented on DBCP-212:
----------------------------------
Regarding concurrency control of GenericObjectPool, I have submitted a patch
(see issue POOL-93) that improves the borrow/return times of the pool. DBCP-212
is somehow hereby alleviated, but it isn't still fixed.
It was not worth tweaking GenericObjectPool.borrowObject() any further because
at the moment the next bottleneck of the test program is DBCP's method
PoolableConnectionFactory.makeObject() (which is called from within
borrowObject()): When the pool reaches a certain size and needs to be
increased, all threads get stack at the factory entrance. Is there any
compelling reason for that method to be synchronized?
> 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
> Fix For: 1.3
>
> Attachments: DBCPtester.java, DBCPtester.java, output.txt
>
>
> 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]
