commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [Pool2] Alternative identity hashmap pool implementations
Date Sun, 08 Feb 2015 15:51:49 GMT
On 6 February 2015 at 22:36, Phil Steitz <phil.steitz@gmail.com> wrote:
> 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.

We seem to be moving towards changing the implementations to support
both the current equals() comparison and a new identity comparison
(whether by wrapper or alternate hashmap implementation).

That would allow Pool2 to be used in the same way as Pool1 (with
suitable config).
I think that would be better than providing the identity comparing
pools as independent PoolUtils methods.

Also it should make it easier to change the identity implementation at
a later date if necessary.
I.e. the initial impl. could use the IdentityWrapper, as that is known
to work and is available now.
If a bettter impl. were developed later it could replace the IdentityWrapper.

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

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


Mime
View raw message