[
https://issues.apache.org/jira/browse/POOL-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved POOL-108.
------------------------------
Resolution: Fixed
Pacth (pool-93-markt-v2.patch) from POOL-93, which was applied in r602773,
should also fix this issue.
> GenericObjectPool does per-resource work (e.g. validate) in a synchronized
> context
> ----------------------------------------------------------------------------------
>
> Key: POOL-108
> URL: https://issues.apache.org/jira/browse/POOL-108
> Project: Commons Pool
> Issue Type: Improvement
> Affects Versions: 1.3
> Reporter: Matthew Moore
> Fix For: 1.4
>
> Attachments: GOP.patch
>
>
> While using the pool library with DBCP, and load testing with simulated
> failures, we noticed that a single bad connection can cause multiple threads
> to block when the test on borrow flag is true. (Using "select 1" as a test
> query.)
> Looking at the code, GenericObjectPool performs activation, passivation, and
> validate on both borrow and return, inside of synchronized methods. This can
> be a real problem, since any of these operations could conceivably block, in
> which case all threads trying to obtain or release a resource will also block
> for the duration. Some of these concerns are indirectly covered by POOL-93
> in 2.0. Looking at revision 594226 I can see this has not yet been addressed.
> Narrowing the synchronization scope via synchronized blocks, rather than
> synchronizing the entire method, would deal with this easily enough. If I
> get the time I'll work up a patch. This should be addressed - in the context
> of DBCP it turns test on return / borrow into counter-intuitively dangerous
> options.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
