NX: lockCookie generation

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.

Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD

Terry Martinson

Ranch Hand

Posts: 293

posted 12 years ago

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

SCJP, SCJD, SCWCD, SCBCD

Xie Ruchang

Ranch Hand

Posts: 160

posted 12 years ago

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

Best Regards

Xie Ruchang

Ranch Hand

Posts: 160

posted 12 years ago

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

Ranch Hand

Posts: 160

posted 12 years ago

Hi, I know problem.

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

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

Ranch Hand

Posts: 2937

posted 12 years ago

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

Wanderer
Sheriff

Posts: 18671

posted 12 years ago

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).

"I'm not back." - Bill Harding, Twister

Xie Ruchang

Ranch Hand

Posts: 160

posted 12 years ago

Yes, keep it simple and stupid (KISS)

Akhshay Ray

Greenhorn

Posts: 11

posted 12 years ago

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

Ranch Hand

Posts: 160

posted 12 years ago

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

Wanderer
Sheriff

Posts: 18671

posted 12 years ago

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

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 ]

"I'm not back." - Bill Harding, Twister

Jason Mowat

Ranch Hand

Posts: 79

posted 12 years ago

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.

Cheers, Jason

Jacques Bosch

Ranch Hand

Posts: 319

posted 12 years ago

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.

Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD

Jason Mowat

Ranch Hand

Posts: 79

posted 12 years ago

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

Ranch Hand

Posts: 319

posted 12 years ago

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.

Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD

Philippe Maquet

Bartender

Posts: 1872

posted 12 years ago

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

Ranch Hand

Posts: 160

posted 12 years ago

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

Bartender

Posts: 1872

posted 12 years ago

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

Ranch Hand

Posts: 319

posted 12 years ago

Hey Phil. It's time to go sleep now

Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD

Philippe Maquet

Bartender

Posts: 1872

posted 12 years ago

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