Return-Path: 
 <dev-return-126768-apmail-commons-dev-archive=commons.apache.org@commons.apache.org>
X-Original-To: apmail-commons-dev-archive@www.apache.org
Delivered-To: apmail-commons-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 85EAB6CD0
	for <apmail-commons-dev-archive@www.apache.org>;
 Thu,  9 Jun 2011 13:41:51 +0000 (UTC)
Received: (qmail 54519 invoked by uid 500); 9 Jun 2011 13:41:51 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 54430 invoked by uid 500); 9 Jun 2011 13:41:51 -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: "Commons Developers List" <dev@commons.apache.org>
Delivered-To: mailing list dev@commons.apache.org
Received: (qmail 54420 invoked by uid 99); 9 Jun 2011 13:41:51 -0000
Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jun 2011 13:41:51 +0000
Received: from localhost (HELO s2laptop.local) (127.0.0.1)
  (smtp-auth username markt, mechanism plain)
  by minotaur.apache.org (qpsmtpd/0.29) with ESMTP;
 Thu, 09 Jun 2011 13:41:50 +0000
Message-ID: <4DF0CD9C.5010702@apache.org>
Date: Thu, 09 Jun 2011 14:41:48 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; 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: [pool] equal instances
References: <4DF0406C.8010009@gmail.com>	<4DF0821A.3060507@apache.org>
 <BANLkTinafpheHDEC0CCQz8-mfmAp=C8YEg@mail.gmail.com>
In-Reply-To: <BANLkTinafpheHDEC0CCQz8-mfmAp=C8YEg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On 09/06/2011 10:01, Julien Aym� wrote:
> 2011/6/9 Mark Thomas <markt@apache.org>:
>> On 09/06/2011 04:39, Phil Steitz wrote:
>>> Code in trunk now does not work when distinct pooled instances are
>>> equal - i.e., if a factory produces instances A and B and
>>> A.equals(B), this causes problems.   I think this situation should
>>> be allowed - i.e. it is an unacceptable restriction to put on object
>>> factories that distinct the poolable objects they produce be
>>> distinguishable under equals.  This would be a new requirement for
>>> [pool] and I don't think we should require it.  What do others think?
>>
>> As I start to answer this, I can see a very long response developing. I
>> will do my best to keep it short. That may mean I gloss over some aspects.
>>
>> The requirement that objects obtained from the factories meet
>> A.equals(B) == false greatly simplifies the implementation of a number
>> of requirements. Let me explain by using a single requirement although
>> there are a number of other requirements that have very similar
>> consequences.
>>
>> The Requirement:
>> It shall not be possible to return an object to the pool more than once.
>>
>> The pool maintains a list of idle objects. The simplest implementation
>> of the above requirement is to test if any returned object already
>> exists in the pool. This doesn't catch all scenarios but it is a start.
>>
>> If we know that for objects obtained from the factories A.equals(B) ==
>> false then we can use a HashSet to store idle instances and it is very
>> easy to determine if the object being returned exists in the set of idle
>> objects. This makes determining if the object is being returned twice
>> relatively inexpensive. It also makes a reasonable multi-threaded
>> implementation possible.
> 
> </snip>
> 
> And what about using an IdentityHashSet (or IdentityHashMap) to store
> idle objects.
> This would meet the Requirement without having to enforce A.equals(B) == false.

That would be one of the aspects I glossed over. They aren't always
maps/sets and they need to support concurrent access by multiple threads.

A wrapper for pooled objects that uses System.identityHashCode(Object)
may be a possible solution that isn't too complex. It would add a
requirement for the pool to unwrap/wrap objects on borrow/return. I can
look at this if folks think the new restriction on factories is
unacceptable.

Mark

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