Also about clientid and unclock

Gerald Kou

Greenhorn

Posts: 14

posted 13 years ago

I saw some posts about "clientid"'s role.They said that using of clientid can prevent the case as below: A.lock(27) .. B.unlock(27) A.unlock(27) But I doubted it beacase the sequence of execution is lock-reade-modify-unlock.So if Thread A locked one record suceessfully,then Thread B can't locked the same record.Thread B should blocked in lock() method untill Thread A finish unlock() and notifyAll(). Am I wrong? Please tell me why to use clientid?

John Smith

Ranch Hand

Posts: 2937

posted 13 years ago

So if Thread A locked one record suceessfully,then Thread B can't locked the same record.Thread B should blocked in lock() method untill Thread A finish unlock() and notifyAll(). Am I wrong? Please tell me why to use clientid? The problem is not with locking, but with the unlocking. There is an explicit requirement in your instructions (or the javadoc for unlock()) that only the client who locked a particular record can unlock it. The only way to accomplish it is to track the clients. [ June 26, 2003: Message edited by: Eugene Kononov ]

Jim Yingst

Wanderer
Sheriff

Posts: 18671

posted 13 years ago

Well, that depends on your assignment. Many of the current assignments use "cookies" instead. When you lock a record, the method returns a unique long value - and if you want to unlock the record later, you have to provide the correct cookie for that record. Which is a rather irritating API to use, but we're explicitly required to use it. (Well, many of us are - requirements vary in subtle ways.) So, if your assignment uses cookies, the requirement is not that "only the client that unlocked the record can unlock it" but rather "Cookie must be the cookie returned when the record was locked; otherwise throws SecurityException." Which means that once you've implemented this odd scheme, there's not really any need for clientID any more. So - maybe you have a use for it, maybe you don't. Read your assignment carefully and analyze.