You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Jörg Schaible <Jo...@Elsag-Solutions.com> on 2004/04/20 10:48:05 UTC
[id] UUID Version 4
Hi,
just to assure, that my assumptions regarding the usage of the UUID version 4 IdentitifierGenerator are correct.
In my scenario I use the UUID to give some objects a unique id. These objects can be created very fast and some are serialized in the application realizing persistance. The generator itself is created at application startup. The application does not share this persistent storage with other instances, so my single requirement is to have unique ids independent of the application's session. IMHO UUID version 4 is enough for this purpose as long I do not set the system's clock.
Can anyone configm this ?
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [id] UUID Version 4
Posted by Phil Steitz <ph...@steitz.com>.
Jörg,
Sorry for the latency. I have been on the road. See below.
>
> 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?
The SessionIdGenerator should be OK for your use case, if I understand it
correctly, unless application runs start at exactly the same system time
(by resetting the system clock). Have a look at the code here:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/id/src/java/org/apache/commons/id/random/SessionIdGenerator.java?view=markup
to see exactly what it does, but basically the ids generated by this
generator are made up of 6 random characters, followed by 3 characters
based on system time, plus 1+ count characters to ensure that they plus
the 3 time characters are unique (in case ids are generated faster than
clock resolution). The random characters are generated using a Random
which is a (non-static) instance variable, initialized using the default
(system time) seed.
Therefore, if two application runs start at precisely the same system
clock time and each uses a singleton SessionIdGenerator to generate ids,
generated ids could in theory collide; but if you don't mess with the
system clock between subsequent runs, uniqueness should be preserved
across runs.
Another factor to consider here is whether or not / how much you care if
the generated ids can be spoofed. Neither SessionIdGenerator nor the
version 4 UUID are particularly secure from this standpoint (i.e.,
preventing a hacker from generating a valid identifier based on observed
identifier values). The SecureRandom version of the version 4 UUID is
better; but neither are as good as e.g., what tomcat does
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java?view=markup
A "secure" package of secure random or signed identifier generators would
make a good addition to [id]. As always, contributions are welcome :-)
Phil
>
> Regards,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [id] UUID Version 4
Posted by Jörg Schaible <jo...@gmx.de>.
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
Re: [id] UUID Version 4
Posted by Phil Steitz <ph...@steitz.com>.
Jörg Schaible wrote:
> Hi,
>
> just to assure, that my assumptions regarding the usage of the UUID
> version 4 IdentitifierGenerator are correct.
>
> In my scenario I use the UUID to give some objects a unique id. These
> objects can be created very fast and some are serialized in the
> application realizing persistance. The generator itself is created at
> application startup. The application does not share this persistent
> storage with other instances, so my single requirement is to have
> unique ids independent of the application's session. IMHO UUID version
> 4 is enough for this purpose as long I do not set the system's clock.
>
> Can anyone configm this ?
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.
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).
Phil
>
> Regards, Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For
> additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org