Two Laptop Bag
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes locks, timeouts and Unreferenced (again) 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 "locks, timeouts and Unreferenced (again)" Watch "locks, timeouts and Unreferenced (again)" New topic

locks, timeouts and Unreferenced (again)

Geir Morten Hagen
Ranch Hand

Joined: Apr 05, 2002
Posts: 34
I just read through the requirements again, after implementing a cleanup thread that would remove locks after a certain amount of time, and then I see that there is no timeouts defined for the lock method.. Oooops, I did it again! *put on a blonde whig and dance around*
That brings me to the subject of this post. The requirement says that all public methods in the Data class has to be provided in the remote interface. If no timeouts are defined, this will mean that the client can call lock() and never unlock it again, leaving the record locked for the rest of the server lifetime. This also applies to client crashes, etc.
I've read the topics on handling stale clients using the Unreferenced interface, but the api docs says that unreferenced() is called when there are no more clients that reference the object.
How can the remote object implementation get notified when a client does not reference it anymore? And even if this works, it does not solve the problem with clients calling lock and not followed by an unlock.
Am I supposed to write an application with this serious flaw just to adhere to the requirements? Or should I go with a more "secure" implementation, and document my reasons for doing it?
Adam Caldwell

Joined: Mar 27, 2002
Posts: 17
Speaking as someone who got all of the points on the server portion (although I didn't use RMI), I did not handle the case where unlock was never called.
In my design document, I acknowledge the fact and said that if this were for the "real world" something would have to be done to fix the problem.
Since this assignment isn't the real world, you can safely dismiss the flaw in your code.
Mark Spritzler

Joined: Feb 05, 2001
Posts: 17276

In order to use the Unreference interface, your design would need to match those with the Connection Object, in which each client gets a Remote Connection Object reference. This way there is only one client attached to that object. So if that client crashes, then it is the last object to have a reference to that object. Here is where the Unreference interface comes into play. By default, the interface has a "Timeout" set to 15 minutes. That means that if the client crashes, 15 minutes later it will run the unreferenced interfaces method, where you can then call unlock on any records it has locked.
If you do not use the Connection Object, then you can make up some sort of timeout class for you. I think there is a Timer class that you can use. There are many posts on that solution here that you can search for.
I used the Connection Object model, and my implementation to use the Unreferenced took me ten minutes to write, if that.

Perfect World Programming, LLC - iOS Apps
How to Ask Questions the Smart Way FAQ
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Geir,
I was going to use a lock timer, but have decided to go with Unreferenced instead. Here's the (untested) timer code that I was working with:

Here is the code for LockTimerCallback:

I had my LockMangaer implement LockTimerCallback and register itself as the LockTimer client (ie new LockTimer(this)).
Feel free to use this code if you wish, but remember that I have not run any tests on it.
Hope this helps
Michael Morris

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Geir Morten Hagen
Ranch Hand

Joined: Apr 05, 2002
Posts: 34
Thanks alot for all help. You guys are great
The start of this subject was not entirely correct. The comment about no timeouts is not in instructions.html, but in the javadoc comment in the provided code I got from Sun.
Guess it counts as a requirement.
[ April 11, 2002: Message edited by: Geir Morten Hagen ]
Geir Morten Hagen
Ranch Hand

Joined: Apr 05, 2002
Posts: 34
Adam, thanks for the input.
But do you think I will pass if I implement timeouts and document my reasons for doing it? It's against my principles to knowingly write flawed code
Peter den Haan
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Geir Morten Hagen:
But do you think I will pass if I implement timeouts and document my reasons for doing it?
You will. In my experience, the most unlikely design decisions are approved provided that, in your documentation, you show that that choice has been consciously made and explain the reasons why.
Certainly neither the decision in favour of a timeout, nor the decision against, is "unlikely". You'll pass just fine with either provided that you show that you have carefully thought about the issue.
BTW, I did implement cleanup because it was a good idea that was ridiculously easy to do -- 5 lines of code
- Peter
[ April 11, 2002: Message edited by: Peter den Haan ]
Geir Morten Hagen
Ranch Hand

Joined: Apr 05, 2002
Posts: 34
I just got to thank you as well, Peter. You've all been a tremendeous help
I agree. Here's the link:
subject: locks, timeouts and Unreferenced (again)
It's not a secret anymore!