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.



Reply via email to