• 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

lock / read / update / delete

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All
I'm thinking about what operations in what order and locking state should be allowable.
read : OK, even OK if locked by someone else!
lock, read, unlock : OK
modify : Exception
lock, modify, unlock : OK
Im quite sure that the above behavior is OK, but what about the delete operation? If delete is only allowed on a locked record then what record should be unlocked after the removal?
I think best is to delete a record without a lock operation. But what should happen if I try to delete a record that is locked by someone else?
Thanks for any help!
 
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
you forget that deletion of a record here means marking it as deleted, not physical removal. So, it's really easy to (lock, remove, unlock-deleted).
You should never delete an unlocked record because delete is a destractive operation and you will end up with incorrect or corrupt data if you proceed without locks. While reading without locks is ok in most cases (although it creates problems of dirty and phantom reads), but the destructive operations (such as update, delete, insert) must be safe. Just general thoughts.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is one of the design decisions to be taken during implementation. On one hand, you know the FBN application is only going to modify records in a well-behaved lock-read-modify-write-unlock sequence, and you could require other applications to do likewise. In that case, all you have to do is write decent implementations of lock() and unlock().
On the other hand, you could argue that a database library for re-use should enforce lock discipline; if a client modifying a record (write, delete) does not have the appropriate lock, you could either do the locking for it behind the scenes or throw an exception of some kind.
And there's the issue of what to do with adds in the presence of a database lock...
- Peter
 
Eru Stone
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Guys!
Gennady, you're right, since delete does only mark the record as deleted, it makes some senes to unlock that record afterwards.
Peter, I think adding to a locked database should not be allowed. A good solution would be to wait until the database lock goes away and the add the record. Of course we would have to make sure that during adding the record no database lock can be established...
reply
    Bookmark Topic Watch Topic
  • New Topic