• 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

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

 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 319
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.
 
Derek Canaan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
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 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 ]
 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic