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!
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.
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
posted 18 years ago
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...
Bring me the box labeled "thinking cap" ... and then read this tiny ad: