wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: Why lock and update/delete throw RecordNotFoundException? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: Why lock and update/delete throw RecordNotFoundException?" Watch "B&S: Why lock and update/delete throw RecordNotFoundException?" New topic
Author

B&S: Why lock and update/delete throw RecordNotFoundException?

Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
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
Jacques Bosch
Ranch Hand

Joined: Dec 18, 2003
Posts: 319

Am i missing something?

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
Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
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
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi 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 ]

Regards, George
SCJP, SCJD, SCWCD, SCBCD
Gytis Jakutonis
Ranch Hand

Joined: Feb 02, 2004
Posts: 76
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S: Why lock and update/delete throw RecordNotFoundException?