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

NX: Locking and Dead Clients

 
joe black
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm trying to redo my locking so that it takes care of dead clients. I know I need to use a client object and am thinking of modeling my locking after the example shown in Alain Trottier's book. However, my assignment requires that a cookie be used in the locking and I'm not sure how this fits in. Could the client object be the cookie itself?
 
Don Resnik
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe,
I have been using Alian's book as well. I tried using his dead client code, but I could never get it to work. The reality is, if your row is not locked until you hit the reserve button, the lock-modify-unlock calls are probably made one after another, and the chances of a dead client occuring is very remote. If you lock the row when you just select it, that is different and a dead client may be possible. I know of one project that did not have dead client code, and did not even address it in his submission, and got a great score. The lack of dead client code did not seem to hurt in that circumstance. I am not including dead client code, but I am explaining why in my submitted docs. I know there are a lot of threads on this, and including the code will make the project more complete, but I don't think it will hurt you too much if you don't (as long as the lock happens on the reserve button)
Don
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Joe & Don,
You should be aware that the LockManager in Alain Trottier's code requires a unique instance of a class to identify the client, however he only ever instantiates a single instance of DatabaseRMIImpl. I raised this issue with Alain, and he agreed that this would cause a problem, and noted that he felt it would be better to have a unique reference being passed from the client to the server (similar to the cookie concept).
This being the case, you cannot use his code directly (although you could adapt it to use cookies). Likewise his dead client handling will not work since he does not have anything unique with which to identify clients.
To convert the code to use cookies, you would have to change his LockManager. At present his lock() method has a parameter passed in to identify the client - this becomes redundant. Within the lock() method, he creates a WeakReference based on the client - instead you would create an object to hold your cookie. Then you store it in a map in a similar manner to what Alain does.
I have deliberately left that description pretty vague so as to leave you some work to do (and I haven't described unlocking at all) - but hopefully that will give you some ideas.
You might also be interested in reading my review of Alain's book, as I mention some of the other areas I had concerns with - you can then see if you can spot the problems yourselves
Regards, Andrew
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My suggestion is to forget dead clients altogether. It's not part of your requirements, and it will only make the grader's work a little more complicated. You might do it correctly, at which point you will not be rewarded. OTOH, you might do it incorrectly, at which point you will be penalized.
All best,
M
 
joe black
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys.
I decided I'm not going to worry about dead clients.
 
Don Resnik
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew,
I just read your review of Alian's book. While I have found it very helpful in general, there are some things I emailed him about that confused me, a lot of which dealt with the fact he is basing the book on old project requirements. I am not using his locking code, I am using a random number generated to be the 'lock cookie', and I ensure the number is unique before it is given to a client.
I am a little concerned about your comment that the server does not meet the requirements of the locking code. Was this only in relation to the included locking code Alian wrote? I have not had a problem with the locking with my server, but maybe I have not tested it enough. Can you please elaborate?
Also, could you explain you comment about the thread safe code in the book not being thread safe?
Thank you,
Don Resnik
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Don,
I did suggest you try and spot these issues yourself - you will learn more that way
OK, starting with the "thread safe" code:
Alain's code synchronizes on the methods of PrintObject. Which means that you will be synchronizing on the instance of PrintObject. However each ObjectTwo's run() method instantiates its own instance of PrintObject.
From my email to Alain
There are two simple changes you can make to your progam to verify that
there is a problem:
* Change the time that the threads wait before starting up so that
they attempt to start simultaneously:

* Add some code in the synchronized method so that it does some
work that takes some time to complete. That way if the
synchronization is not working, you will be able to see it.
Here's my favourite way of doing this:

Calling any of the trigonomic functions is a sure way of
taking up time (and chewing up CPU ), and it does not release
whatever mutexs it holds.

Try running the provided code and look at the output. Then add my changes in and look at the output again - you should see that the threads are not behaving in a synchronized manner: the output of one thread is appearing in the middle of the output from another thread.
As for the "comment that the server does not meet the requirements of the locking code" - I don't remember exactly what the problem was that lead me to that comment. But some possibilities:
  • The code is using the instance of DatabaseRMIImpl to identify who owns the lock, however there is only ever one instance of DatabaseRMIImpl, so the instruction that only the client that locked the record could unlock it could not be met.
  • Locking was delegated to the LockManager (nothing wrong with that per se) but only called from the network code - not from the Data code where it would have needed to be implemented according to the instructions Alain was working with.
  • Individual records could be locked after the entire database was locked
  • Locking the entire database could return while there were still individual records locked (so the user could think they were in single user mode while other clients were still working).


  • Regards, Andrew
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic