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