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