• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Topic: NX: Unique Client or Transaction ID

 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Topic: NX: Unique Client or Transaction ID
Hi,
From:
Topic: Lock question!
https://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
 
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi George,
Thanks much for your detailed explanation given above.
Thanks,
Javini Javono
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic