commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [id] UUID Version 4
Date Mon, 26 Apr 2004 18:17:11 GMT
Hi Phil,

Phil Steitz wrote:
> The Version 4 UUID is based on random bytes so does not depend on the
> system clock.  The current [id] implementation uses a static SecureRandom
> to source the random bytes. The implementation tries to get a SecureRandom
> instance using SecureRandom.getInstance("SHA1PRNG", "SUN") and falls back
> to use a Random if this is not available.  Assuming a SecureRandom is
> used, initialization (which happens on first use once the class is loaded)
> will fully randomize PRNG state, so there is no need to worry
> (realistically) about collisions across application sessions, regardless
> of what may be going on with the system clock.  If the
> SecureRandom.getInstance fails and an ordinary Random is used, the default
> initialization using the system clock will apply, so collisions could in
> theory occur if the app is restarted with the same system clock time.

Thanks for your detailed explanation.

> You could also use o.a.c.id.random.SessionIdGenerator if all you need is
> uniqueness (i.e. you don't need the UUID format).

Yes, all I really want is uniqueness, but again SessionIdGenerator implies
for me, that uniqueness is only guaranteed during a session, i.e.
restarting the application may produce id collisions?

Regards,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message