jQuery in Action, 3rd edition
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Topic:  NX:  Unique Client or Transaction ID Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Topic:  NX:  Unique Client or Transaction ID" Watch "Topic:  NX:  Unique Client or Transaction ID" New topic

Topic: NX: Unique Client or Transaction ID

Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Topic: NX: Unique Client or Transaction ID
Topic: Lock question!

Now to be honest, if you don't expect the need of a unique client identifier
(for automatic unlock of locks owned by crashed clients for instance, or even
deadlock detection, areas where cookies cannot help you), it's probably better
to generate unique cookies. But even in that case, I still think that
Random.nextLong() gives enough "uniqueness" for the purpose.

Hi Phil, and everyone.
Phil, may I be bold enough to contradict your assertion above? I do not wish
to argumentative, of course, as I, like others, ar very grateful that you,
along with others, answer are questions and present your design and
implementation ideas.
I think, however, that the ID used for locking, must be unique.
I realize that this topic probably has been hashed out in the past, and
perhaps done so numerous times. But, the implications of not having a unique
ID could, depending on one's implementation, cause data corruption.
For those exposing Data to the client, wherein Data has a delete(recNo) method,
I'd recommend going for an absolutely unique ID for locking. After all, what
security when the client can willy-nilly delete the whole database.
If the delete(recNo) method is not exposed to the client via Data, I'd still
recommend a unique ID for locking becuase that is stated in the requirements,
while it is stated elsewhere in the requirements that security considerations
are not as important (though I base this on my memory only).
To maximize one's point score on the exam, which is the only issue I am
addressing, I recommend that the ID for locking absolutely and positively be
Javini Javono
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Javini,
What purpose does the lock cookie serve? The only purpose I have been able to come up with is that the lock cookie prevents a client from unlocking a record without knowing the lock cookie that was generated when it was locked.
If there are other purposes for the lock cookie then I may have to rethink my ideas, but as it stands the only reason I can see for a lock cookie is the reason given above.
If you accept my assumption about the purpose of the lock cookie, then security is the only real consideration when it comes to generating the lock cookie. For example:
1) Client A locks recNo = 5 and receives a lockCookie = 47
2) No other client can lock recNo = 5 because recNo = 5 is already locked.
3) It's the case that recNo = 5 will remain locked until someone unlocks recNo = 5.
4) Who can unlock recNo = 5?
5) Any client can unlock recNo = 5 as long as he passes in the correct lockCookie.
6) Client A has a tremendous advantage over any other client because client A knows that the lockCookie = 47.
7) All other clients have to guess the lockCookie, so they are at a substantial disadvantage, they basically have a one in 2 to the 64th power chance of guessing the lockCookie.
8) Let's imagine that some time after the events of item 1 occur, client B locks recNo = 10 and receives the lockCookie = 47.
9) So both client A and client B have the same lockCookie = 47. Client A knows that it is the correct lockCookie to unlock recNo = 5, but has no reason to suspect that it is also the correct lockCookie to unlock record recNo = 10. Client B knows that it is the correct lockCookie to unlock recNo = 10, but has no reason to expect that it is also the correct lockCookie to unlock recNo = 5. In other words, even though the lockCookie is duplicated in this case there is absolutely no way for an individual client to know that and for this reason the lockCookie is quite secure.
10) If all the lockCookies are generated with Random.nextLong() then it is highly unlikely that this situation of duplicate lockCookies in use at the same time would ever occur. To quote from the API for the Random class:

All 2 to the 64th power possible long values are produced with (approximately) equal probability.

But even if duplicate lockCookies are generated, there's still no problem since there's no way a client can know that's the case. The lockCookie is still secure even in the presense of non-unique lock cookies.

Regards, George
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1066
Since I had never used Random.nextLong(), I was curious to find out more about it, so wrote this foll. program :

It took 90 seconds to generate the 50,000 cookies and there were no duplicates at all. So I think, Phil is right. The number 2 to the power of 64 is indeed very big for the human mind to imagine.
As George suggested, I think it is HIGHLY UNLIKELY that another client would try to unlock the same record, locked by some other client. It is also HIGHLY UNLIKELY that Random.nextLong() would generate the same magic cookie at this time. So Random.nextLong() method of generating cookies is a good idea for this assignment.
Mogens Nidding
Ranch Hand

Joined: Mar 08, 2004
Posts: 77
Just a twisted bit of fun here: To get an idea about just how huge Long.MAX_VALUE is, consider the fact that the Date class, which represents a point in time as the number of milliseconds since Jan 1, 1970, using a long variable, can happily keep counting milliseconds for almost 300 million years :-)
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi George,
Thanks much for your detailed explanation given above.
Javini Javono
I agree. Here's the link: http://aspose.com/file-tools
subject: Topic: NX: Unique Client or Transaction ID
jQuery in Action, 3rd edition