This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Hi everyone, In my assignment, the DBAccess interface states:
Suppose: 1. We specify that all clients must adhere to contract of lock -> update/delete ->unlock 2. We check in the lock(recNo) method if the recNo is within range and is not deleted (because lock() throws RecordNotFoundException) Q: Why then do we have to check for RecordNotFoundException again in update or delete. The thread that has locked a particular record generates a unique cookie and thus, is the only thread with the unique cookie to update and unlock that record. All other threads cannot update or delete this record because they don't have the unique cookie. If this is so, the states of the record cannot be changed. So why do we need to check for RecordNotFoundException again in update or delete? Am i missing something? rgds, derek
Not really. DBAccess is a seriously overrated interface. But suppose some other client,from somewhere else, does something wrong with the way it does the locking, and manages to kill a record that you have just locked before you perform an action on it. It should never happen, but it's a safety net to catch a problem should there be one.
Jacques<br />*******<br />MCP, SCJP, SCJD, SCWCD
Joined: Nov 05, 2003
Hi J, The funny thing is when it comes to unlock(recNo), it does not require us to check for RecordNotFoundException. The API suddenly stops being "excessive". If we are to provide a safety net against rogue clients as you mentioned, shouldn't we also check for RecordNotFoundException in unlock() to be consistent? Comments, anyone? derek
Originally posted by Derek Canaan: The funny thing is when it comes to unlock(recNo), it does not require us to check for RecordNotFoundException.
My version of Bodgitt & Scarper declared unlock(recNo) as throwing RecordNotFoundException.
If we are to provide a safety net against rogue clients as you mentioned, shouldn't we also check for RecordNotFoundException in unlock() to be consistent?
It would be nice to "fix" the Sun-provided interface to be more consistent, but that really isn't an option for us given the assignment instructions. I wouldn't change the signature of any of the methods in the Sun-provided interface. Hope this helps, George [ February 06, 2004: Message edited by: George Marinkovich ]
Note on Jacques post: doesn't update() and delete() perform checking smth like isLocked(this, record) to be sure that record is modified by lock owner only? If so, there is no chance that record will be deleted by other client while we are holding lock.
subject: B&S: Why lock and update/delete throw RecordNotFoundException?