commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [Pool2] Alternative identity hashmap pool implementations
Date Fri, 06 Feb 2015 22:36:33 GMT
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


Mime
View raw message