Multithreading in multiple VM enviorment

Question

I'm writing a client server application which makes extensive use of rmi.
There are times when I have to synchronize access to certain resources.
The problem is that if, during a remote method invocation, the remote client VM crashes, the lock will not be released.
I came up with the following solution.
Each relevant method invocation will add a "task" into a queue of some sort.
On the server, a dedicated thread which is spawned by its own VM, will look into the queue and execute the "tasks". So if the remote client VM crashes, it won't cause a deadlock. And if the server application crashes, well then, deadlock is the least of my problems.
I'd like to hear your comments or other ideas if you have them.

Answer 1

I'm confused about your model. Are you talking about clients making lock/unlock requests? Or perhaps starting/ending transactions? That's the only way I could figure a client crash would cause the problem you describe.
Here's an idea for dealing with this:
o Define a timeout period for each resource lock. Or - if you prefer - have the client program ask for the period it wants to lock a resource.
o When a request comes in, lock the resource.
o When another request for the same resource comes in, examine "now" vs the time of the last resource request + the timeout period. If the timeout has expired, grant the new request.
(No muss, no fuss, no extra threads/timers/queues/etc.)
If you are NOT talking about client lock/unlock/start transaction/end transaction requests, then client calls are atomic, and a client crash should have no effect on the server.