aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Orphan LOCKS/Lost Clients Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Orphan LOCKS/Lost Clients" Watch "Orphan LOCKS/Lost Clients" New topic
Author

Orphan LOCKS/Lost Clients

GD Deepz
Ranch Hand

Joined: Sep 29, 2004
Posts: 55
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
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
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
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
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.


SCJP 1.4, SCJD
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
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
Ranch Hand

Joined: Aug 10, 2004
Posts: 175
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.


MCP (C# application dev 70-316) 860<br />SCJP 1.4 100% SCJD (URLyBird) 378<br />MAD 100% nuts
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
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
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
How do you handle orphan locks using sockets?


SCJP 1.4<br />SCJD 1.4
Josh Allen
Ranch Hand

Joined: Jan 15, 2005
Posts: 37
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
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
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:


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
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11509
    
  95

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


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
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.
 
 
subject: Orphan LOCKS/Lost Clients