Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Message-ID: <4093B5FC.2000503@steitz.com>
Date: Sat, 01 May 2004 07:36:44 -0700
From: Phil Steitz <phil@steitz.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [id] UUID Version 4
References: <F0D7281DAB048B438E8F5EC4ECEFBDDC176075@esmail.elsag.de>
 <408CA2CD.50402@steitz.com> <c6jjn7$ac8$2@sea.gmane.org>
In-Reply-To: <c6jjn7$ac8$2@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

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