Point taken. MessageDigest would be better, and the more bits you have
available (128 vs 32) is the critical factor in determining uniqueness.
I did find an Internet draft for guidelines on the generation of UUIDs.
http://www.microsoft.com/dtv/draft-leach-uuids-guids-01.txt
The UUID schema suggested is also 128-bit for sufficient uniqueness. The
problem I see with 128-bit numbers involves their representation in the
database. This large of a value, may have to be represented with a String
type to achieve the proper precision.
The original mechanism that I suggested in the EJB involved three integers
that can be guaranteed to be unique. Perhaps there is an efficient and
reliable way to combine these three integers to represent a *sufficiently*
unique number. Perhaps there isn't. Maybe, going to a 64-bit long value
would be more appropriate.
If all else fails, we can get rid of the timestamp parameter, and simply
keep a sequence number. This sequence number will be incremented on each
call to getUID() and persisted in the ejbActivate and ejbPassivate methods.
I was hoping to avoid this persistence step. Some containers that I have
used, call these methods after every transaction!
Since this is an EJB group, I don't want to get too far off-topic by
focusing on the algorithm. I believe that every implementation that uses
some kind of crunching algorithm (non-sequential) will have to handle the
possibility of a duplicate key being generated.
jim
----- Original Message -----
From: Mats Lofkvist <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 29, 1999 9:59 AM
Subject: Re: UUID Implementation (correction of my earlier post)
> Mats,
>
> I don't think your previous post made it through...
>
> jim
>
> Hmm, if not then I get another try (if somebody removes posts with
> errors I hope I have better luck with this one :-)
>
> The suggested algorithm was:
>
> 1. Split a timestamp (long) into two int's.
> 2. Increment a sequence counter (int).
> 3. Use the java.util.zip.CRC32 class to generate a CRC value for
> these 3 integer values.
> 4. Return this value.
>
> The returned crc32 is 32 bit number as far as I know.
> This is way to small since the risk of having generated two identical
> id's reach 50% after only 2^16 id's (due to the birthday paradox).
>
> Even if the crc32 returns a full long, the risk of duplicates may be
> to big to ignore if you are creating large numbers of id's.
>
> My suggestion is to replace the crc32 with a hash from
> java.security.MessageDigest. Those are 128 bits or more.
>
> _
> Mats Lofkvist
> [EMAIL PROTECTED]
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
