This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
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

Using Unreferenced interface to delete lock for crashed client

 
David Winters Junior
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,

I am trying to figure out how i can use the Unreferenced interface to release a lock a client has if the client should crash unexpectedly.

I have implemented the locking in a seperate Lock managaer class and the locking is implemented on the server side in a pattern similar to lock(recno)-> dooperation(recno)->unlock(). Although the chance of the lock remaining even if the client crashes is small it still is possible.

Now i have decided to implement the Unreferenced interface on the Remote server object- each client will have its own unique instance of the remote object (this is how we identify the client that owns the lock).

Now the method unreferenced() will be called by the server on each client stub which is stale or which may have crashed however i would like to implement in here some logic which would release the client lock from a hashtable which stores the client which holds the lock on a record should the client crash.
However i am not sure how i can do this? how can i uniquely identify the client to allow me to release its lock from the hashtable inside the unreferenced() method.

Perhaps others have used this interface in a different way to achieve the same objective here...

I have read a number of other posts on this issue and there is no definitive answer on the issue.


Any help would be appreciated
david
 
Roman Yankin
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David I believe your approach is overcomplicated. The thing you are trying to implement definitely goes beyond what's actually required. If you are afraid of some unreleased locks, why don't you make use of the ReentrantLock just the way it is done in PriorityBlockingQueue or any other implementation of AbstractQueue? E.g. say your ReentrantLock field is called lock then implementation of you update method may look like:



Thus you can be sure your lock will always be released, just make sure there is no code between the call of lock.lock(); and try block
 
David Winters Junior
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roman,

Agreed since the locking is on the server side if the client crashes then it does not matter the record will be booked or updated as needed anyway and the lock will be released either way here, it is not necessary to do this but more importantly it is very risky since another client may be modifying the same record and releasing the lock would lead to data integrity issues here.

Thanks,
David
 
Roman Yankin
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by David Winters Junior:
Roman,

Agreed since the locking is on the server side if the client crashes then it does not matter the record will be booked or updated as needed anyway and the lock will be released either way here, it is not necessary to do this but more importantly it is very risky since another client may be modifying the same record and releasing the lock would lead to data integrity issues here.

Thanks,
David


No, it would not lead to any data integrity. Your server method will be started and completed as normal, because server is running locally and would not even "know" you are calling this method remotely through RMI.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic