Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: lockCookie generation

 
Jacques Bosch
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, keep it simple and stupid (KISS)
 
Akhshay Ray
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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 ]
 
Jason Mowat
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Phil. It's time to go sleep now
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good morning. I hope it went really well.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic