Return-Path: 
 <dev-return-105819-apmail-commons-dev-archive=commons.apache.org@commons.apache.org>
Delivered-To: apmail-commons-dev-archive@www.apache.org
Received: (qmail 75498 invoked from network); 2 Dec 2007 21:24:33 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 2 Dec 2007 21:24:33 -0000
Received: (qmail 25155 invoked by uid 500); 2 Dec 2007 21:24:21 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 25076 invoked by uid 500); 2 Dec 2007 21:24:20 -0000
Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@commons.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@commons.apache.org>
List-Post: <mailto:dev@commons.apache.org>
List-Id: <dev.commons.apache.org>
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Delivered-To: mailing list dev@commons.apache.org
Received: (qmail 25061 invoked by uid 99); 2 Dec 2007 21:24:20 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Dec 2007 13:24:20 -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; Sun, 02 Dec 2007 21:24:00 +0000
Received: (qmail invoked by alias); 02 Dec 2007 21:24:02 -0000
Received: from e182076071.adsl.alicedsl.de (EHLO [85.182.76.71])
 [85.182.76.71]
  by mail.gmx.net (mp040) with SMTP; 02 Dec 2007 22:24:02 +0100
X-Authenticated: #383581
X-Provags-ID: V01U2FsdGVkX1/BRw8ReTrB875wNX9JzT2XvFNv5W2XUfyX5zFFYU
	IQEEmWst3mZZh8
Message-ID: <47532273.6080409@gmx.de>
Date: Sun, 02 Dec 2007 22:24:03 +0100
From: kutzi@gmx.de
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Jakarta Commons Developers List <dev@commons.apache.org>
Subject: Re: [POOL] Offer of help for a 1.4 release
References: <47530435.9020601@gmx.de>
 <8a81b4af0712021152p2aa479c4u8a765e9170c86426@mail.gmail.com>
In-Reply-To: <8a81b4af0712021152p2aa479c4u8a765e9170c86426@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Virus-Checked: Checked by ClamAV on apache.org

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<Connection> 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?

Christoph


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org