The Deadlock Problem with RMI
What would happen if you locked a synchronized section on an object c, made a remote call,
passing c to the server, and then the server made a synchronized remote callback on c? The
server's callback would run in the client's RMI thread. It would try to get the lock, fail (because
the main thread owns that lock), and go to sleep, waiting for the main thread to release it.
Unfortunately, the main thread is waiting for frob() to return. Deadlock (Figure 13-3).
Figure 13-3. Deadlock by Remote Callback
What can you do about it? Nothing. In the best of situations you can simply ensure that a locking
hierarchy is maintained, recognizing that remote callbacks run in different threads. This has the
potential of becoming quite complex in more elaborate applications where hundreds of different
programs on different machines may all hold references to different remote objects scattered
across the network. In the very best of situations, you write your code so that this never comes up.
Another minor note: You can synchronize on the local object stub for the remote object. This will
lock the lock on the stub, not the actual object. This is probably not what you want to do.
Running synchronized remote methods on remote objects could get quite complicated. Don't do
that.
Remote Garbage Collection
A reasonable question at this point is: How does RMI handle garbage collection? Clearly, an
object that is not referenced locally could still have remote references to it which our local process
wouldn't know about. RMI has a clever, optimistic distributed garbage collector (DGC). Basically,
each RMI process has a DGC client that periodically sends messages to other processes telling
them that it has references to objects there (this is called lease renewal).
The DGC does its level best, collecting all objects to which it can't find references. Should a
reference to one of these objects later turn up in some client process that didn't renew the lease,
too bad. The object is gone, and any remote method invocations on it will throw
RemoteException, and it will be up to the programmer to deal with the problem. Presumably
Search WWH :
