UUID stands for universally unique identifier, so you should be okay as far as collisions go. Given that the length of a UUID and its alphabet is fixed, there are indeed a finite number of them (2^122), but collisions are extremely unlikely.
If you do not NEED an identifier on your sessions and are only doing so in order to force uniqueness, then just get rid of it and use java's built in equals and hashCode implementation which treats every object as unique regardless of the content of its fields. Or keep the id and don't override equals and hashCode. On Sunday, February 8, 2015, Michael Osipov <[email protected]> wrote: > Am 2015-02-08 um 13:12 schrieb James Carman: > >> You aren't guaranteed for them not to collide. So, yes, it could happen. >> > > But UUID is neither but the probability is exteremely low. Is that what > you tried to say? > > On Saturday, February 7, 2015, Michael Osipov <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
