Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

client based approach

 
luis veron
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not that I am against here, I just happen read a post regarding this logic;
"putting all my lock, read, update, write, unlock mechanism in my client code."
Can somebody try to explained this line and what are the advantages/disadvantages of doing this...
Your reply will be much appriciated...
Thank you very much
 
Sam Wong
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The main advantage of such an approach is to avoid passing client id as a parameter to track lock ownership on the database. By ensuring that lock/read/write/unlock work as an atomic operation, client id becomes irrelevant. It can work if done properly and handling all exceptions.
 
Rahul Rathore
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I understand it, this approach simply requires the Database to know that Record Number 5 is locked. The database need not keep track of who owns the lock on Record Number 5. The logic of lock() becomes simple- it succeeds if the same record is not already locked- otherwise the requesting thread goes into wait().
For the above approach to succeed the following is necessary:-
1. The client is always well-behaved, calling lock() before doing any write operation in the data, and then finally calling unlock(). The client should ensure that it does not hold the lock for too long.
2. The data does not exercise any unilateral control over locks- eg. it should not itself unlock() a record for any reason (like expiry of a time-out period). Otherwise the data may unlock and give the lock to another client. Subsequently the previous lock-holder may execute, although the lock belongs to another client.
I personally feel that this client-based approach is not very practical or robust. The client cannot always be expected to behave, because network-conditions are unpredictable. The clients may crash, hang, or network may be slow. One bad client should not hold others to ransom. Records may thus remain redundantly locked, preventing other clients from getting a lock. I think it is much more robust to put lock control in the database, and to modify all write operations to check the id of the lock holder for the target record.
I would be glad to hear comments to the contrary.
 
luis veron
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
guys...yuor the man..
atleast it gives me some idea of what to do...I was pondering to apply it in my FBN...I'm not really that clear yet but your reply is much appriciated..
Thanks
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic