Michael Ludwig wrote:
André Warnier schrieb am 15.05.2010 um 22:47:14 (+0200):

A tip : to get a really unique identifier, I often use
"yyyymmddhhmmssrrrrr", where rrrrr is the rand() result,
and the prefix is the date/time. Unless you process more
than 99,999 requests per second, it will always be unique.

I'm probably missing something trivial, but how do you
enforce uniqueness over rrrrr for 99,999 consecutive calls
to rand?

The perldoc doesn't promise any uniqueness, only randomness,
which isn't uniqueness.

You are right, I should not have said "always". It is still not guaranteed, and does not "enforce" uniqueness. But yyyymmddhhmmssrrrrr means that you would need a duplicate within the same second, which is quite a bit less likely than over a much longer period of time. I have never done the math to calculate exactly how likely it was that I would get 2 identical identifiers for any given number of requests/second. Nor what adding one rand() digit would do to this probability. Let's say this : I have a dozen websites where the above is being used. None of them even approaches 99,999 requests/second, and none of them necessarily generates a unique-id at each request. But the setup is such that, should a duplicate identifier be generated, the application stops with an error. I did it so because I was curious, and because my sites are not Google.
Over a period of about 5 years, it has never happened.
Probabilities being what they are, it does not mean that it cannot be happening at this very second. But then also, the Sun may have turned into a supernova 6 minutes ago.

One alternative is to use some strictly incremental counter, shared between multiple processes running on potentially multiple systems or CPUs. This requires a common place to store the counter, which survives a system restart, and it requires some lock-read-increment-unlock mechanism. I don't know any really fast and efficient way of doing this. I am interested however if anyone knows one.

Reply via email to