Orphan LOCKS/Lost Clients

[GD Deepz]

What do you all think of a Timer Thread as an inner class in the Data class that checks locked records every 5 mins. If any of the locked records have been locked for more than, say 20 secs, the record is unlocked by calling the unlock().

We can use this idea if a client loses communication with the server for example it gets a RemoteException. Although my client never calls the lock/unlock methods directly and I put the lock/unlock in a try/catch/finally, I could sill have an orphan lock.

As such, there is no need for WeakHashMap or java.server.rmi.Unreferencd

[peter wooster]

Originally posted by GD Deepz:
What do you all think of a Timer Thread as an inner class in the Data class that checks locked records every 5 mins. If any of the locked records have been locked for more than, say 20 secs, the record is unlocked by calling the unlock().

We can use this idea if a client loses communication with the server for example it gets a RemoteException. Although my client never calls the lock/unlock methods directly and I put the lock/unlock in a try/catch/finally, I could sill have an orphan lock.

As such, there is no need for WeakHashMap or java.server.rmi.Unreferencd

A problem with that solution is communicating the fact that you have unlocked a record back to the client. If the client eventually tries to unlock the record they will get a SecurityException if they haven't been informed. The Unreferenced solution is the easiest and probaly the best for those using RMI.

[Frans Janssen]

I am doing something very similar. I schedule a new TimerTask for every locked record, that will automatically unlock the record if it is not unlocked by the client within an reasonable amount of time. I still have to decide what "a reasonable amount of time is", but I'll probably take something around 60 seconds.

The Unreferenced solution cannot solve clients that fail to unlock for reasons other than a lost connection.

As an extra, the timer solution also provides a way out of deadlock situations, although I must confess it is not a very elegant one

For the assignment though I am assuming that it will be good enough.

Frans.

[Frans Janssen]

Originally posted by peter wooster:
[QB]

A problem with that solution is communicating the fact that you have unlocked a record back to the client. If the client eventually tries to unlock the record they will get a SecurityException if they haven't been informed.[QB]

Very true indeed. But on the other hand, a client that manages to lock a record for an extensive time and thus "steals" this record from other clients, deserves no mercy!

Of course I will document this behavior in my choices.txt.

Frans.

[Inuka Vincit]

Originally posted by Frans Janssen:
I am doing something very similar. I schedule a new TimerTask for every locked record, that will automatically unlock the record if it is not unlocked by the client within an reasonable amount of time. I still have to decide what "a reasonable amount of time is", but I'll probably take something around 60 seconds.

The Unreferenced solution cannot solve clients that fail to unlock for reasons other than a lost connection.

As an extra, the timer solution also provides a way out of deadlock situations, although I must confess it is not a very elegant one

For the assignment though I am assuming that it will be good enough.

Frans.

I am going with what peter said as well. The Unreferenced is the best sollution, as well as the simplest. The thing is frans there should not be any case other than lost connections to cause orphan locks( crash, power faliure etc should also cause lost connection). IMHO with the timer sollution unless you attempt to notify the client of a timeout your going to leave the client hanging.

[Frans Janssen]

Originally posted by Inuka Vincit:

I am going with what peter said as well. The Unreferenced is the best sollution, as well as the simplest. The thing is frans there should not be any case other than lost connections to cause orphan locks( crash, power faliure etc should also cause lost connection). IMHO with the timer sollution unless you attempt to notify the client of a timeout your going to leave the client hanging.

One of the assumptions I am making for my project is that although I am creating my own very nice and safe clients, I cannot exclude the possibility that someone else will write his own client that connects to my server. Since I cannot control that client's behavior, I have to make my server robust against unforeseen client behavior.

I know this goes probably beyond the scope of the assignment. In the end the main reason to choose for the TimerTask is that I do not have to come up with a separate solution to deadlocks. (But then again, if your assuming your clients are the only ones, you can just design your clients such that they will never cause deadlock.*)

So either choice will probably be correct, I am just giving my 2 cents.

Frans.

* The assignment seems to suggest that the assessor will run some automated tests against our Data classes. I wonder if a deadlock scenario will be part of these tests and if so, if mentioning in the choices.txt that the clients will never deadlock will be sufficient to prevent deductions of points.

[Daniel Simpson]

How do you handle orphan locks using sockets?

[Josh Allen]

Originally posted by Frans Janssen:


In the end the main reason to choose for the TimerTask is that I do not have to come up with a separate solution to deadlocks. (But then again, if your assuming your clients are the only ones, you can just design your clients such that they will never cause deadlock.*)

I think you could eliminate any possible deadlock by only allowing clients to hold a lock on one record at a time. Otherwise two different clients could obviously aquire multiple locks in different sequences and reach deadlock.

[peter wooster]

Originally posted by Josh Allen:

I think you could eliminate any possible deadlock by only allowing clients to hold a lock on one record at a time. Otherwise two different clients could obviously aquire multiple locks in different sequences and reach deadlock.

A timer doesn't solve the deadlock issue, if the marker tries her deadlock test she will see a deadlock and not necessarilly know that it will be cleared by the timer.

There are three solutions to the deadlock issue, all require an exception to be thrown if a potential or actual deadlock occurs:

1) the simplest = allow only one lock per client, the server keeps a Map of clients and locked records.

2) average difficulty = allow resources to be locked in a specific order, eg. ascending, the server keeps a Map of clients and Lists or resources. Both locked resources and resource being waited for must be kept.

3) difficult = allow resources to be locked in any order, but check whether a lock attempt is about to deadlock. The rule is:

if we have any existing locks and the new resource is locked {
   for each resource we own {
       for each client waiting on the resource {
           do they own or are waiting for the resource we want
           if so throw the exception
       }      
   }
} 

To do this you need a Map of clients and Lists of resources and a Map of resources and List of clients.

So far, I'm going with solution 1, its easy to test and sufficient for this assignment.

[Andrew Monkhouse]

Hi Daniel,

Originally posted by Daniel Simpson:
How do you handle orphan locks using sockets?

When the client disconnects you should get a java.net.SocketException (the cause will be "Connection reset"). You can catch that and clear any orphaned locks at that point.

Regards, Andrew

[Daniel Simpson]

Originally posted by Andrew Monkhouse:
Hi Daniel,



When the client disconnects you should get a java.net.SocketException (the cause will be "Connection reset"). You can catch that and clear any orphaned locks at that point.

Regards, Andrew

Thanks for replying, Andrew. If you haven't heard the news, I had an overnight conversion to RMI. After doing my entire networking in a matter of hours with RMI, I wanted to go hug somebody. So now my networking is all done, although this locking issue is bugging me. I'm struggling on it and here's what I've been talking about.