Thursday
Nov082007
ID generator
Thursday, November 8, 2007 at 9:41PM
Hi,
I would like feed back on a ID generator I just made. What positive and negative effects do you see with this. It's programmed in Java, but could just as easily be programmed in any other typical language. It's thread safe and does not use any synchronization. When testing it on my laptop, I was able to generate 10 million IDs within about 15 seconds, so it should be more than fast enough.
Take a look at the attachment.. (had to rename it from IdGen.java to IdGen.txt to attach it)
IdGen.java
I would like feed back on a ID generator I just made. What positive and negative effects do you see with this. It's programmed in Java, but could just as easily be programmed in any other typical language. It's thread safe and does not use any synchronization. When testing it on my laptop, I was able to generate 10 million IDs within about 15 seconds, so it should be more than fast enough.
Take a look at the attachment.. (had to rename it from IdGen.java to IdGen.txt to attach it)
IdGen.java
Reader Comments (4)
Just curious about how you intend on using it? Whenever I try to base anything on random starting points the counter argument is that you can't guarantee it will be unique. Randomness makes people uncomfortable. They like guaranteed unique and nice predictable monotonically increasing numbers. That's my experience anyway.
I would consider using it on systems using sharded (or clustered) databases where database generated auto increment numbers are no good, and as an alternative to UUID v4 (that's also randomly generated).
In a environment where there at most will be generated a hand full of IDs pr millisecond, I would consider this safe enough, and in addition save space compared to UUID's and also have the time when the ID (and therefor the associated object/row) was created available within the ID (saving space).
Hey Christian,
IMO you got it right. This solution gives you the benefits of (partially) incremental behavior (for search based on time) while avoiding the overhead and performance penalty of synchronization. The chances of collision are practically zero, but you could easily modify the algorithm to include parts of the mac address if you want to be extra cautious.
Just curious about how you intend on using it? Whenever I try to base anything on random starting points the counter argument is that you can't guarantee it will be unique. Randomness makes people uncomfortable. They like guaranteed unique and nice predictable monotonically increasing numbers. That's my experience anyway