commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (POOL-108) GenericObjectPool does per-resource work (e.g. validate) in a synchronized context
Date Sun, 09 Dec 2007 23:37:43 GMT

    [ https://issues.apache.org/jira/browse/POOL-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549867
] 

Mark Thomas commented on POOL-108:
----------------------------------

I have attached a proposed patch to POOL-93 that includes the GOP fixes here, ports them to
GKOP and also includes the sync fixes proposed in POOL-93.

> 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.


Mime
View raw message