I am developing a distributed Java application in which I need to assign unique IDs for objects which are distributed across multiple JVMs.
Currently, I have thought of using java.util.UUID to generate UUIDs using its Random Generator (Type 4). However, I would like to know if it is guaranteed that the generated UUIDs will be unique across multiple JVMs.
It doesn't say, but I wouldn't think so. Google for 'globally unique identifier'. We implemented one a long time ago that had a central registry for handing out high bits, then each VM was able to allocate the low bits.
Is there anyway that I can generate unique IDs without having a central control over it? I have heard of systems which uses MAC Address of network interface, but that would require JNI, isn't it? Is there any "Pure Java" way to do such a thing? [ May 10, 2008: Message edited by: Yohan Liyanage ]
You could manually configure each instance with (for example) a 4 bit unique key which would allow 16 servers. 4 bits isn't much to give up if you use 64 bit GUIDs. Another way could be to use a sequence generator from a DB, but again has the central connection.
make sure the high key is guaranteed to be larger than you'll ever need, make the key a long rather than an int, and avoid Strings.
I've had an implementation of this that I've brought with me ever since. It's very fast (like my test harness took most of the time when I tried to measure it) and you can easily generate 100's of thousands of GUIDs per second per node.
Co-Author of <a href="http://www.amazon.com/exec/obidos/ASIN/1932394532/ref=ase_dolliedish/103-1355009-6089459" target="_blank" rel="nofollow">WebWork in Action</a> from Manning.
I haven't read the full article, only browsed the code, but I am wary of the hashCode part. I recently had an issue where I had to fix a hashCode used as a unique value. In my case the code was guaranteed to fail, but since hash cocdes are not unique I am dubious of their value in GUIDs
Randomly generated UUIDs like those generated by the java.util.UUID class have 122 random bits. There are 128 bits altogether with 4 bits being used for the version ('Randomly generated UUID'), and 2 bits for the variant ('Leach-Salz'). With random UUIDs, the chance of two having the same value can be calculated using probability theory (Birthday paradox).
To help non-mathematicians understand what those numbers mean, here's a comparison: One's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.00000000006 (6 x 10-11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs.
The odds of a properly generated duplicate UUID being used in error in any practical circumstance is so low that any other work to improve software reliability would clearly be a much higher priority.