I think you have to use time in milliseconds + network card number (mac address) + a random number to genererate a uuid as microsoft .net framework. Iy guarantees uniqueness in a cluster
Serdar ------------------------------------------------------------- Thanks, Tatu! I'm going ahead with it. Now if something goes wrong I'll say: "But Tatu said..." (just kidding). I've replaced Random in the code above with SecureRandom, for that extra dose of randomness (my biggest worry was that Random self-seeds with System.currentTimeMillis(), and there is some infinitesimal chance that two servers could start up in the same clock tick). Any thoughts? On Thu, Jun 24, 2010 at 8:31 PM, Tatu Saloranta <tsalora...@gmail.com<mailto:tsalora...@gmail.com>> wrote: On Wed, Jun 23, 2010 at 12:18 AM, David Boxenhorn <da...@lookin2.com<mailto:da...@lookin2.com>> wrote: > Tatu, I did read your comments - and I appreciate them very much! > > I want someone to argue with me (using good arguments) since what I'm doing > *does* seem weird to me - because no one else is doing it. > > What I mean by readable is that the sort order of my UUIDs are obvious to > humans. > > What I mean by "weird code" is mostly that it doesn't come with enough > authority that I would trust it as a black-box more than my own code. For > example, what happens when I want to port it to different kinds of machines? Ok! It all makes sense -- honestly I just wanted to try to explain why certain consensus builds, not to argue against your way of doing things. I don't think you are missing anything obvious, my suggestions are really secondary arguments. I think you have good reasons and code looked solid. And yes, implementing time-based UUIDs leads to quite a few complications, if one tries to address all oddities. This is probably why JDK UUID is so limiting, I assume JDK authors did not want to deal with such aspects. And that is why I think that fundamentally random-based variant is good for the main goal of achieving uniqueness. > But another thing weird about it is the complexity (and I think low speed) > of the algorithms I need in my *own* code to use it. Just look at it > http://wiki.apache.org/cassandra/FAQ#working_with_timeuuid_in_java ! Yes, that is definitely overly complicated (IMO). Perhaps Cassandra could add convenience methods for mundane things like converting between java.util.UUID and byte[]. Or authors of nice extension/convenience libraries like Hector (and others mentioned -- apologies for not listing I just worry I misspell their names :) ) -+ Tatu +- - Bu e-posta mesaji kisiye özel olup, gizli bilgiler içeriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, e-posta mesajini kullaniciya hemen geri gönderiniz ve mesaj kutunuzdan siliniz. Bu e-posta mesaji, hiç bir sekilde, herhangi bir amaç için çogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Yollayici, bu e-posta mesajinin - virüs koruma sistemleri ile kontrol ediliyor olsa bile - virüs içermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hiçbir sorumlulugu kabul etmez. - The information contained in this message is confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy. You should not copy, disclose or distribute this information for any purpose. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, we cannot warrant that virus or other forms of data corruption may not be present and we do not take any responsibility in any occurrence.