Why don't you just implement equals() and hashCode() as noted here [1] ? This will allow the use of Pool2 and guarantee that different instances are treated as different, regardless of mutabiity.
No need to generate unique ids for each instance. Pool2 needs an equals() method that returns true for objects that really are equal. Also equals() and hashCode() must be stable for a given object, and objects which are the same under equals() must have the same hashCode(). These are standard requirements for using a HashMap (which is what Pool2 uses currently). [1] https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 On 8 February 2015 at 12:12, James Carman <ja...@carmanconsulting.com> wrote: > You aren't guaranteed for them not to collide. So, yes, it could happen. > > On Saturday, February 7, 2015, Michael Osipov <1983-01...@gmx.net> wrote: > >> Am 2015-02-06 um 17:14 schrieb James Carman: >> >>> Try UUID.randomUUID().toString() rather than RandomStringUtils if you >>> really want unique keys. >>> >> >> Aren't both pseudo random? >> >> I won't have more than 30 sessions in parallel. Do you think that a >> collision might happen? >> >> Michael >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
