Hi Steve,
My personal view is that the instructions seem to indicate that I should be able to own a lock as long as I want. There is no indication of a timeout in the interface definition. There is no indication of a timeout anywhere else in the instructions.
So if you were to implement a timeout, you are introducing something that has not been asked for. Furthermore you will be specifying a time limit that other users may not be expecting, and there is no standard idea of what sort of timeout to put on it - in real life a decision on timeout values would either come about after discussion with the relevant parties (which we cant do) or be configurable (hmmm - we could end up with too many configurable options in our GUI if we are not careful).
So, if we are going to worry about stale sessions (which I don't believe we have to worry about), then I would prefer to do it in one of two ways:
Have some generic way of clearing stale locks within the Data class itself that will work no matter whether we have a Sockets based or an RMI based solution. WeakHashMap fits that description.Have a protocol based solution (clean-up code in SocketException in a sockets based solution, or in Unreferenced.unreferenced() for an RMI based solution.Both have their good and bad points. Sometimes the interface you have been provided by Sun makes one or the other problematic which can be the deciding factor
Regards, Andrew