• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to remove locks if client has failed to do so?

 
Paula Decker
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

My implementation allows the client to lock a record before updating it. If the client fails to unlock the record, how can the server clean this up? I was thinking of creating a lock timeout. The question is...how long to make the timeout? Does anyone have any thoughts on this topic?

Thanks.

Paula
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paula Decker:
Hello,

My implementation allows the client to lock a record before updating it. If the client fails to unlock the record, how can the server clean this up? I was thinking of creating a lock timeout. The question is...how long to make the timeout? Does anyone have any thoughts on this topic?

Thanks.

Paula


I set my client up so that the user has no means of delaying the unlocking of a record. The booking sequence is {lock, read, check, update, unlock} and requires no user input within that sequence. Beyond that you have the problem of client programs that crash between the lock and the unlock, you can either simply ignore this situation, or use a network based timer to disconnect clients that crash and unlock any locked records. If you are using RMI, you can use the Unreferenced interface for this. For more details do a search on "unreferenced" in this forum.
 
Paula Decker
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Peter. I read the threads regarding the Unreferenced interface. I don't think this will solve the case where the client forgot to call the unlock() method...(and the remote object has a static reference in the client code).

I can modify my code to expose a book(recNum) method to the client.

I thought we were supposed to expose lock/unlock to the client. I read the 'Local Adapter Issue' thread. Are you exposing all the methods in the DBAccess interface to the client?

Thanks.

Paula
 
Leo Tien
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paula:

I call lock/read/update/unlock sequence in my logic layer. In it, I use try..catch..finally to solve your problem.



This is same as use it in database connection, you should do con.close() in finally block.

Do you think?
 
Paula Decker
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the post! Your code is a good standard for clients to follow when using this project's required interface.

Are you supplying a business logic layer in your server which has the book() method?

Will the lock()/unlock() methods be called by the client? At first I thought they would be, but now with additional methods being exposed to the client (i.e. book()), I'm not sure.

Peter, do you expose the lock()/updateRecord()/unlock() methods to the user? If so, then how do you handle the case where if, for any reason, the unlock() method was not called?

Thank you and sorry for so many questions.

-Paula

 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paula Decker:
Thanks for the post! Your code is a good standard for clients to follow when using this project's required interface.

Are you supplying a business logic layer in your server which has the book() method?

Will the lock()/unlock() methods be called by the client? At first I thought they would be, but now with additional methods being exposed to the client (i.e. book()), I'm not sure.

Peter, do you expose the lock()/updateRecord()/unlock() methods to the user? If so, then how do you handle the case where if, for any reason, the unlock() method was not called?

Thank you and sorry for so many questions.

-Paula



I expose lock and unlock to the client and use code that is very similar to the code posted by Leo. Here's pseudocode for what I do in the book method in the client:



You don't need to worry about the crashed client case, just document that you feel this problem is outside the scope of the project. Getting it to work with RMI and Unreferenced is tricky, but fun if you're into those kind of problems.

In my booking client the user has no means to interrupt that sequence short of powering off their machine, I do have a test client that allows all the operations and lets me leave records locked. But its not part of the code that I will submit, its only to help get full coverage of the server.
 
Paula Decker
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, Peter. I thought you were putting the book() method on the server. Thanks for your clear example. I was thinking that client and user in your earlier email were the same. Sorry for my confusion. I'm back on track now.

-Paula
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paula Decker:
Thank you, Peter. I thought you were putting the book() method on the server. Thanks for your clear example. I was thinking that client and user in your earlier email were the same. Sorry for my confusion. I'm back on track now.

-Paula


You're welcome, there are people who have passed with servers that provide a book method. They call it a "thin client". I don't believe that actually matches the requirements.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I don't believe that actually matches the requirements.

The requriements in fact did not mention anything on where the locking is taking place. Basically, thick/thin clients do not encounter any problems, however, for thick clients in networked environment, how should client A know client B acquired a lock on record X? Thus, there should be a centralized location to hold the lock. In such sense, the server is a good place for it.

Nick
 
Josh Allen
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you DID want to have the client do this you could add a timestamp to the locking scheme. You would then check whether the lock was still valid or if it has expired when another thread tries to aquire the lock.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic