NX: lockCookie generation

[Jacques Bosch]

Is there a problem with using System.currentTimeMillis() to generate my unique lockCookie values. Unless somebody messes arround with the server's system time while it's running.

[Terry Martinson]

Jacques - I don't know about your idea, but I use Random.nextLong()
I think it was suggested in a posting a while back.
TJ

[Xie Ruchang]

Hi,
If you use Random, there is a possibility that you get the same value again. I suggest you use

long uniqueCookie = new Date().getTime()

Best Regards

[Xie Ruchang]

Hi Jacques,
Sorry, I didn't read carefully enough, my solution is the same as yours. The assumption and of course the reality is that it must be no one mess around with the system time, otherwise, it is just too bad.
Regards

[Xie Ruchang]

Hi,
I know problem.

  
long a = System.currentTimeMillis();
long b = System.currentTimeMillis();
long c = System.currentTimeMillis();
System.out.println(a);
System.out.println(b);
System.out.println(c);

I got a, b and c to be equal!!! My machine is too fast Are you stressed-testing your program. I try my method

  
long a = new Date().getTime();
long b = new Date().getTime();
long c = new Date().getTime();
System.out.println(a);
System.out.println(b);
System.out.println(c);

and it is the same even though there are some time taken for the Date objects instantiation. I am now working on a delay mechanism and will get back shortly.
Regards

[John Smith]

FC: and it is the same even though there are some time taken for the Date objects instantiation. I am now working on a delay mechanism and will get back shortly.
Are you planning to artificially delay the app with the purpose of acquiring a unique cookie based on the system time? Sounds like a sabotage to me. Why not look into something more natural (like the identity of the object in the virtual machine using hashCode())?

[Jim Yingst]

The assumption and of course the reality is that it must be no one mess around with the system time
It's not just that. Even without anyone deliberately altering system time, it's too easy for near-simultaneous requests to get the same time, as you've seen. On most systems, System.currentTimeMillis() rounds results to 10 milliseconds. You may service multiple requests in that time.
If you use Random, there is a possibility that you get the same value again. I suggest you use
If you construct a new Random() for each request, yes - because the constructor uses the current time as a seed. However you can create a statically-held Random, and keep reusing it, calling nextLong() as Terry suggests. This will not repeat even with near-simultaneous requests (except perhaps by sheer chance).

[Xie Ruchang]

Yes, keep it simple and stupid (KISS)

  private long generateCookieValue() {
    long current = System.currentTimeMillis();
    long unique = System.currentTimeMillis();
    while (current == unique) {
      unique = System.currentTimeMillis();
    }
    return unique;
  }

[Akhshay Ray]

You can also use java.rmi.server.UID() - this generates a UID that is unique over time with respect to the host it was generated on.

[Xie Ruchang]

Hi,
UID is an object which encapsulates System.currentTimeMillis together with some other information to make it unique. We need a long not an object.
Regards

[Jim Yingst]

[Frankie]: Yes, keep it simple and stupid (KISS)
Because using nextLong() is so complex?

private static Random rand = new Random();
public static long newCookie() {
    return rand.nextLong();
}

Also has the advantage of not sending the server into a busy loop for 10 ms of doing nothing for no reason.
[ January 13, 2004: Message edited by: Jim Yingst ]

[Jason Mowat]

Why not keep a static long in your concrete database class, seed it with a 1 on initialization (startup), and increment it by 1 on every lock attempt. As long as the increment is synchronized, you will get a unique value for the duration of the lifetime of the database.
Since the cookie is never saved anywhere, I see no point in creating unique values between database runs. This is extremely simple, following the previous KISS advice. FWIW.

public long lock(int recNo)
    throws RecordNotFoundException {
    
    verifyRecordExists(recNo);
    synchronized (recordLocks) {
        /* Get lock on record and save to recordLocks collection */
        /* Thread handling code omitted :-) */
        //  Save the lock
        recordLocks.put(new Integer(recNo), new Long(lockCookie));    
        // Increment cookie for other clients
        return lockCookie++;
    }
}

Cheers,
Jason

[Jacques Bosch]

Thanx Frankie, Jim, everybody, for your comments.
I think I'll go for the self incremented, or the random option in stead of system time.
See ya.

[Jason Mowat]

Jasques,
I would reconsider the random path. Even though it is incredibly slim, you could get a duplicate random number between 2 different calls. Why introduce that potential bug? If you are going to choose anything, choose the self incrementing or the system time down to the millisecond.
Hehe, even the millisecond option could potentially fail if you have really fast computers and simultaneous locks (I think matter would collapse on itself first ). Still, it "could" happen.
Synchronizing in a block and controlling your increments from in there is, IMO, the safest, easiest bug-free implementation that you can go with.
Cheers,
Jason

[Jacques Bosch]

Hi Jason.

Synchronizing in a block and controlling your increments from in there is, IMO, the safest, easiest bug-free implementation that you can go with.

Yup. That's what I did. Thanx.

[Philippe Maquet]

Hi Jason and Jacques,
I just discovered this thread through a link from this one. So, sorry for entering here so late.
I'd generate a once constructed Random object to generate cookies, as Jim suggests above.
Lock cookies don't need to be unique, just difficult to guess. So it's far better to generate cookies with a risk of generating a duplicate cookie (number_of_cookies_in_use / (2 ^ 64) == a very little risk BTW ), than cookies easy to guess (generated in any sequence, based on system time or not).
Regards,
Phil.

[Xie Ruchang]

Hi Philippe,
In the scenario given in the assignment, the accomodation or contractor or whatever is not a big list, to have two client to book for the same record ID is very high. If your cookie generation algorithm has a possibility whatever formula you use which gives the same cookie for two booking to the same resource, your synchronization and locking mechanism will collapse. Uniqueness is of utmost importance here.
Using a sequential or time-based cookie generation scheme gives the advantage of time-out and deadlock detection, not for a random number without other means of capturing the time. Secrecy is not an issue in the cookie as in this assignment as there is no need to implement security.
IMHO and not to be argumentative.
Best Regards

[Philippe Maquet]

Hi Frankie,

In the scenario given in the assignment, the accomodation or contractor or whatever is not a big list, to have two client to book for the same record ID is very high. If your cookie generation algorithm has a possibility whatever formula you use which gives the same cookie for two booking to the same resource, your synchronization and locking mechanism will collapse. Uniqueness is of utmost importance here.

Mmh... You are right *if and only if* you use the generated cookies to uniquely identify clients (for deadlock detection purposes whatever the cause). But as it's by far not the easiest way to identify clients for such a purpose (a client == a collection of cookies instead of a simple reference), I don't believe in the need of uniqueness for lock cookies, for most designs anyway.
But it's just my opinion of course.
Best,
Phil.

[Jacques Bosch]

Hey Phil. It's time to go sleep now

[Philippe Maquet]

Hi Jacques,
I'd like to! But I've still at least 2 hours work tonight for a class preparation.
Best regards,
Phil.

[Jacques Bosch]

Good morning. I hope it went really well.