• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What is client crashing impact on LockManager?

 
YungSheng Chang
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My lock design pretty much follows Max Habibi's pattern. With a static LockManager object, the lock record is maintained logically in HashMap.
Now I am trying to find out the impact for client crash, and add remedy for it in my LockManger.
The way I try to simulate the scenario is as the following:
1. Start the server(of course)
2. client 1 is connected
3. client 2 is connected
The idea is to force one client abort the console mode. To make the simulation more smoothly, I add "sleep" after some critical action in Data wrapper class:

public String[] read(long recNo){
1.//lock record i
2.long cookie = lock(recNo);
3.System.out.println("lock record " + recNo);
4.//sleep for 5 seconds
5.Thread.currentThread().sleep(5000);
6.unlock(recNo, cookie);
}

I forced client 1 abort the console mode after it acquires the lock and sleeping(on line 5). At the mean time, client 2 still connects to the server.
I was hoping that once client 1 acquires the lock, and exits, the corrosponding thread will not finish its unlock job. However, it does not work this way. The thread still executes line 6, and client 2 still can read it.
I put this on another check point, even in a while loop continously accessing the server by many clients. But no deadlock caused by client crash, and it works just fine.
Am I wrong on my simulation? What client crashing scenario should be handled? please suggest, thanks!!
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by YungSheng Chang:
My lock design pretty much follows Max Habibi's pattern. With a static LockManager object, the lock record is maintained logically in HashMap.
Now I am trying to find out the impact for client crash, and add remedy for it in my LockManger.


There are a lot of ways to handle this, but I suggest that you stick with your requirements and ignore it
M
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi YungSheng,
Originally posted by YungSheng Chang:
Now I am trying to find out the impact for client crash, and add remedy for it in my LockManger.

I think Max is correct, handling client crashes is beyond the scope of the assignment.
To get your scenario to work as you expect, I would suggest making the following changes:
0) Add before line 1 "System.out.println(Thread.currentThread() + " started");
1) Replace line 3 with "System.out.println(Thread.currentThread() + ": lock record " + recNo);"
2) In line 5 sleep for 5 minutes instead.
3) Add line 7 as follows: "System.out.println(Thread.currentThread() + ": unlock record " + recNo);"
If you test the scenario the same way as before you should see the following output:
Thread1 started
Thread1: lock record recNo
Thread 2 started
I imagine this is what you would expect to see. If you see something else I would be concerned that your locking is not working as you want it to. If you do see this output, that is, it works the way you expect it to, I would move on to something else. You could document in your design choices document that if a client crashes while holding a lock on a record, then that record will remain locked until the server is restarted.
 
YungSheng Chang
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max and George:
Yap I understand that most suggestion goes to ignore client crash. I guess will put it into the document too, but I still want to see what really happens in that scenario. The learning process makes things fun, isn't it?
I extended the lock time to 10 minutes and exits the locking client at beginning. However, it looks the thread in server side never dies even though the network client loses connection.
This means in my experiment, the server side thread always unlocks record even though the network client already aborts. I am looking into my design to see if I could find anything now....
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi YungSheng,
You are right - the method on the server will continue to run even after the server knows that the client has disconnected. This is a good thing - otherwise you would have a very hard time trying to work out how far through your transaction was when it died.
Here is some code to demonstrate this. I have implemented Unreferenced so that you can see exactly when the server gets notified that the client died. This can all be copied and pasted into one file (ClientDied.java) - I don't like forcing people to create and compile multiple small class files just to test something like this.

Note that there are two remote objects in that file, so you will have to run rmic against both of them:

The first time you run java ClientDied the server will start up, and will remain running:

You should then run java ClientDied in another window, which will start the client section of code, run for a few seconds and then exit:

Simultaneously you should start seeing messages in the server window:

As you can see in my running of the code above, Unreferenced was called at 08:38:59, but the method that was being run (doSomething()) continued to run for a further 19 seconds.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic