Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.220.52 as permitted sender)
Message-ID: <54D541F1.3040601@gmail.com>
Date: Fri, 06 Feb 2015 15:36:33 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [Pool2] Alternative identity hashmap pool implementations
References: 
 <CAOGo0VYN_L5qWcXhP2SRgbHvk1kRARAg8GDD+BiAyOfKc=kuKA@mail.gmail.com>
	<54D51CCE.40306@gmail.com>
 <CAOGo0VafjWF5ZSjVMRidZPK2PqtbyoaVAk+ai-PAvDmb2BOQQg@mail.gmail.com>
In-Reply-To: 
 <CAOGo0VafjWF5ZSjVMRidZPK2PqtbyoaVAk+ai-PAvDmb2BOQQg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 2/6/15 1:28 PM, sebb wrote:
> On 6 February 2015 at 19:58, Phil Steitz <phil.steitz@gmail.com> wrote:
>> On 2/6/15 11:56 AM, sebb wrote:
>>> There seem to be a few use-cases for pools that always treat different
>>> instances as different entries, rather than using the current equals()
>>> check.
>> Yes
>>> Would it make sense to implement alternative versions that accept an
>>> object and wrap it in a class that implements equals() using == and
>>> System.identityHashcode?
>> Yes, we should definitely support this use case.
>>> The IdentityWrapper class was suggested here:
>>>
>>> https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637
>>>
>>> I think it could be done by subclassing the existing implementations
>>> to provide the wrapping/unwrapping support.
>>>
>>> There would be an overhead because the wrappers would need to be
>>> created every time an object was passed in. The wrappers are very
>>> small.
>> Once I get the DBCP release I am working on out, I plan to explore
>> all three alternatives in my comment on POOL-284.  The performance
>> regression testing tool that Thomas found and referenced on that
>> ticket looks very interesting and could help assessing the cost of
>> wrapping / unwrapping or changing the current impl to use
>> sync-protected IdentityHashMap.
> Changing to IdentityHashMap implies dropping support for
> equals()-equivalent pool entries.
> Are there no use-cases for such behaviour?

Good point.  We would probably want to make this configurable.

Phil
>
>> If we can get a solution that "just
>> works" at demonstrably very low cost, I will advocate for that.  If
>> not, then probably what you are describing above, made available
>> like other custom pools via PoolUtils, makes sense.
>>
>> Phil
>>> S.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> .
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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