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 Tracking and Locking

 
Akshay Sharma
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
I had finished my assignment by implementing locking in a very crude manner using wait and notify.
But when I regsitered at this site I came to know that its is imperative to check for clients which fail abnormally otherwise a deadlock occurs if a client dies abnormally and some other client is in a wait state.
Agreed and tested.
Now finally I read a lot about the LockManager and locking. But I am extremely sorry that I am not able to figure out how this will actually work.Can anybody explain me in detail how this needs to be implemented.I am actually a bit confused with all this.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well in the LockManager class you will ahve a lock and unlock method that takes the reference of the Remote Object for the client, and the record number. It stores this in a Collection. The LockManager will then ahve all the locks by all clients, and when you call unlock on a record with the Remote reference, it can check in the Collection to see if the client actually has the lock then pass the call to the Data class.
The Data class or LockManager can still have all the blocking, if you want.
Hope that is detailed enough for you. If not there are many threads on LockManager in this forum. Just do a search on LockManager, and you will have days of reading returned.
Mark
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

But when I regsitered at this site I came to know that its is imperative to check for clients which fail abnormally otherwise a deadlock occurs if a client dies abnormally and some other client is in a wait state.

There's some debate on this, and Mark(I think) and I agree that it's not called for: just make sure that normal usage can't lead to deadlock. Some other posters, however, seem to disagree, though I can't find see anything in the requirements supporting this.
M
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't find see anything in the requirements supporting this.
The closest I see is:
This document deliberately leaves some issues unspecified, and some problems unraised

The requirements say nothing about this issue specifically, but there is some justification for addressing unraised issues if we deem them important. But I'll agree with Max that you shouldn't feel you need to worry about disconnected clients. And if you do handle them, make sure your solution works correctly, and is as simple as possible for what it does do. A simple solution that doesn't handle disconnects is definitely preferable to a complex solution that doesn't really work. A complex solution that does work is risky too - make sure the function of each part is easy to understand.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, there are unraised problems. However, I think the requirements are clear here. There's no request for this functionality, which mean that you're not responsible for it, but it's a nice-to-have, if you're feeling energetic.
Similarly, there's no requirement that you buy me a beer if you find yourself in Columbus, Ohio. However, it's a nice-to-have..assuming it's good beer
M
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic