Return-Path: Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 87120 invoked from network); 20 Aug 2003 23:11:38 -0000 Received: from ms-smtp-01.southeast.rr.com (24.93.67.82) by daedalus.apache.org with SMTP; 20 Aug 2003 23:11:38 -0000 Received: from noel770 (cae88-16-024.sc.rr.com [24.88.16.24]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with SMTP id h7KN4hPR021316 for ; Wed, 20 Aug 2003 19:04:44 -0400 (EDT) From: "Noel J. Bergman" To: "Jakarta Commons Developers List" Subject: RE: Commons Pool/DBCP minIdle Implementation Date: Wed, 20 Aug 2003 19:11:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <004401c36752$cf74e6b0$72f8a8c0@WPRWC207> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Richard, I only looked at your patches out of context, so perhaps I missed it, but where is the code to ensure that: + // Check to see if we are below our minimum number of objects + // if so enough to bring us back to our minimum. + int objectDeficit = getNumIdle() - _minIdle; + if ( objectDeficit < 0 ) { + for ( int j = 0; j < Math.abs(objectDeficit); j++ ) { + addObject(); + } // for + } // if doesn't cause the number of objects to exceed the maximum? Unless _whenExhaustedAction is WHEN_EXHAUSTED_GROW, there is no point in allowing numActive + numIdle to exceed maxActive, because bollowObject() won't permit any objects to be borrowed more than maxActive. The default behavior is to block until there are fewer than maxActive objects outstanding. --- Noel