Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1499402.1194890647042.JavaMail.jira@brutus>
Date: Mon, 12 Nov 2007 10:04:07 -0800 (PST)
From: "Matthew Moore (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Created: (POOL-108) GenericObjectPool does per-resource work
 (e.g. validate) in a synchronized context
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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


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.