Topic: NX: Unique Client or Transaction ID Hi, From: Topic: Lock question! http://www.coderanch.com/t/185337/java-developer-SCJD/certification/Lock 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. Regards, Phil.
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 unique. Thanks, Javini Javono
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.
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.
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 :-)
Joined: Dec 03, 2003
Hi George, Thanks much for your detailed explanation given above. Thanks, Javini Javono
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Topic: NX: Unique Client or Transaction ID