I know it has been beaten to death, but ...

[Eva Van Shtock]

I couldn't find a post solving the uniqueness issues in generating two identical cookies for two clients.

Cannot you just use random() and before giving it to the client, check a Set to see if it is there?

I plan to do this in my assignment (changing from a sequential cookie scheme).

Does anyone see a potential problem in this?

Eva

[Eva Van Shtock]

Hey, how about this:
for a unique cookie, we return the file pointer (offset) pointing to the record we want to lock.

Eva

[Robert McDonald]

Hey Eva,

I saw an interesting posting which suggested using System.nanoTime() to generate a unique number. I guess you could go for some complex algortihm to try to generate a truly unique random number but i feel it probably just complicates things too much - better to keep it simple.

Robert

[Roy Mallard]

Why not just generate a serial number i.e.

private long id = 0;

synchronized long getNextID() {
return id++;
}

[Oricio Ocle]

Hello Eva,
you can't ensure cookie uniqueness since cookie domain is finite.
For long cookies after 2^64 + 1 cookies returned, is sure at least two of them are the same.
What you can do is trying to minimize cookie repetition, or better cookie repetition per record

Regards

[Anton Golovin]

Start with min for a datatype and add one until you get max for a data type/ With that many values, requests literally cannot overlap - it would take a request to hang around for days if not months if not years. But this implies that your locking is good.