Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4DCA8445.1080804@apache.org>
Date: Wed, 11 May 2011 13:42:45 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: svn commit: r1101516 - in
 /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl:
 GenericObjectPool.java PooledObject.java PooledObjectState.java
References: <20110510154823.30ED22388980@eris.apache.org>
 <4DC9F3C6.6050404@gmail.com> <4DCA03DF.3030509@gmail.com>
 <4DCA658A.4060005@apache.org>
In-Reply-To: <4DCA658A.4060005@apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 11/05/2011 11:31, Mark Thomas wrote:
> On 11/05/2011 04:34, Phil Steitz wrote:
>> On 5/10/11 7:26 PM, Phil Steitz wrote:
>>> On 5/10/11 8:48 AM, markt@apache.org wrote:
>>>> Author: markt
>>>> Date: Tue May 10 15:48:22 2011
>>>> New Revision: 1101516
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1101516&view=rev
>>>> Log:
>>>> Move to using LinkedBlockingDeque for the queue of idle objects.
>>> Definitely simpler, cleaner code, but seems there will be no easy
>>> way to enable fairness and some badly "unfair" stuff can happen when
>>> clients get instances under maintenance.  In theory, an unlucky
>>> client could wait forever.  Do we have any data on how "unfair"
>>> LinkedBlockingDeque can be?  ArrayBlockingQueue is an alternative
>>> that does support fairness; but then I guess we lose LIFO/FIFO
>>> control and probably performance.  Any ideas how we could get
>>> fairness, or at least some control over fairness to work?  Another
>>> thing to think about is whether clients are better off waiting for
>>> the state change on instances under maintenance than getting back in
>>> line for the next available instance. (I now see the fairness TODO
>>> in TestGOP :)
>>
>> After looking quickly at the Harmony code for LinkedBlockingDeque,
>> we may be able to solve both the 1.6 problem and fairness by
>> bringing that source in and just making the ReentrantLock that it
>> uses configurable to be either fair or not (as ArrayBlockingQueue
>> does).  Might be naive, but might work.
> 
> I like it. A lot. Great idea.

Better still, it is faster than whatever Oracle wrote for Java 6 :)
With this in place, DBCP is slightly faster than jdbc-pool for
jdbc-pools checkout thread tests. This is only two microbenchmarks
(there are lots of other tests where jdbc-pool is faster but I haven't
optimized DBCP for those yet) but it is a promising sign.

I just need to tidy up the code before I check it in.

Mark


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