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. 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: [email protected] > For additional commands, e-mail: [email protected] > > . > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
