Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 8228 invoked from network); 4 Dec 2007 14:29:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Dec 2007 14:29:36 -0000 Received: (qmail 57969 invoked by uid 500); 4 Dec 2007 14:29:23 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 57712 invoked by uid 500); 4 Dec 2007 14:29:22 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 57703 invoked by uid 99); 4 Dec 2007 14:29:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Dec 2007 06:29:22 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kutzi@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 04 Dec 2007 14:29:00 +0000 Received: (qmail 9973 invoked by uid 0); 4 Dec 2007 14:29:01 -0000 Received: from 213.238.39.18 by www174.gmx.net with HTTP; Tue, 04 Dec 2007 15:29:01 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Dec 2007 15:29:01 +0100 From: "Christoph Kutzinski" In-Reply-To: <8a81b4af0712021537r578a5b42j39b9d2a86be505d6@mail.gmail.com> Message-ID: <20071204142901.316840@gmx.net> MIME-Version: 1.0 References: <47530435.9020601@gmx.de> <8a81b4af0712021152p2aa479c4u8a765e9170c86426@mail.gmail.com> <47532273.6080409@gmx.de> <8a81b4af0712021537r578a5b42j39b9d2a86be505d6@mail.gmail.com> Subject: Re: [POOL] Offer of help for a 1.4 release To: "Jakarta Commons Developers List" X-Authenticated: #383581 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/uffo6sAfuNYpK1WsX24RtXtYTEKGTv73yK6/kvN VDjaRIVIZ5h2sCkeBHI/r78+E9wcI7K60Qpg== Content-Transfer-Encoding: 7bit X-GMX-UID: TAg+L40uTlI8dDW/cmhroN1OU2poZdnW X-Virus-Checked: Checked by ClamAV on apache.org Hi, > On Dec 2, 2007 2:24 PM, wrote: > > Phil Steitz wrote: > > > > >> - fully synchronized borrowObject() and returnObject() methods. I've > > >> seen this to be a serious bottleneck when the database is under high > > >> load and another connection needs to be created. > > > > > > Agreed. Ideas on how to improve this without creating threadsafety > > > issues would be appreciated. > > > > I have started to implement a solution which has the basic idea to > > return a (Java 5) Future instead of a Connection on > > borrowObject(). > > If we still have a pooled Connection I return an 'ImmediateFuture'. If a > > new connection is needed, I return a FutureTask which creates the new > > connection. The Task is executed by a SingleThreadExecutor with an > > unbounded queue. Thus the blocking on connection creation is moved to > > the caller thread and the pool is open for other threads. > > However I'm still not 100% convinced with this solution. E.g. I would > > like to immediate return a pooled connection to the waiting caller > > thread, if a connection is returned to the pool meanwhile. > > > > Also, I understand that Java 5 is probably no option for commons-pool, > > as it must stay compatible with Java 1.4, right? But maybe you can take > > some of my ideas and implement a similar solution? > > > > Yes, we need to stay 1.4-compatible in pool 1.4. If I understand the > ideas that you are presenting correctly, this is sort of how pool used > to work before the additional synchronization was added in pool 1.3. > If you look back at the 1.2 codebase, the factory methods were mostly > executed by client threads not holding locks on the pool. I think we > should be able to safely revert to that setup by taking a more > surgical approach to deal with the threadsafety issues that the > synchronization was added to address. More to follow on this. I took a look at 1.2's GenericObjectPool now. And no: that's not what I meant. In my solution an (one) extra thread is handling the connection creation. All client threads which want a connection past the current idle connection limit wait for this thread to finish. This way it is still guaranteed that just one connection at a time is created (which is a good thing IMO). I can send you my - still not complete - implementation, which will probably tell you more than I can do with words. greetings Christoph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org