On 6 February 2015 at 22:36, Phil Steitz <phil.ste...@gmail.com> wrote: > On 2/6/15 1:28 PM, sebb wrote: >> On 6 February 2015 at 19:58, Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> . >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
