Java RMI and synchronized methods

Question

I\'m studying the book \"Distributed Systems\" (by Tanenbaum & Van Steen) and they say something that seems to conflict to what seems to be instead thought by many on Java R

Answer 1

You are correct. The text is wrong. RMI stubs are thread-safe and can be invoked simultaneously by multiple threads within a single client JVM. I'm not aware of any statement or text by Wollrath et all that says anything different, and I've been following this topic since 1997.

Specifically:

What I thought is that using a synchronized method on a Remote Object implementation (so the real implementation running at the server) concurrent execution of that method is prevented even when the calls to that method are from different clients machines (calling the method via a Proxy... aka a Stub).

You are correct.

In the book it's instead said that concurrent execution of synchronized methods is not prevented when using RMI.

The book is not only wrong, it is stating an impossibility. How exactly could RMI prevent synchronization from working?

Logically, blocking in a remote object is simple. Suppose that client A calls a synchronized method of a remote object.

Then blocking occurs at the server, by the normal operation of Java.

To make access to remote objects look always exactly the same as to local objects, it would be necessary to block A in the client-side stub that implements the object's interface and to which A has direct access.

Rubbish. The fact that the remote method implementation is synchronized does everything that is necessary.

Likewise, another client on a different machine would need to be blocked locally as well before its request can be sent to the server.

Again this is rubbish.

The consequence is that we need to synchronize different clients at different machines.

Rubbish again.

An alternative approach would be to allow blocking only at the server.

'Allow'? What does this mean? A synchronized method is synchronized. You can't disallow it.

In principle, this works fine, but problems arise when a client crashes while its invocation is being handled by the server.

Again rubbish. No such problems arise. The server recovers from this situation either via a read timeout or an write exception or even successful completion of the remote method. In all three cases, the method exits, the synchronization lock is released, and life continues.

As we discussed in Chap. 8, we may require relatively sophisticated protocols to handle this situation, and which that may significantly affect the overall performance of remote method invocations.

Nonsense.

Therefore, the designers of Java RMI have chosen to restrict blocking on remote objects only to the proxies (Wollrath et al., 1996).

I am not aware what else this could refer to other than the excerpt you quoted, and I've read that paper many times. If the authors want to rely on this paper they should have provided a quotation and a proper citation to chapter and verse.

In any case the designers of RMI made no such choice. There was no such choice to make. synchronized is synchronized whatever the RMI designers may or may not have wished, and similarly notify() and wait() are final. They weren't free to make any choice. The quotation you provided isn't a 'choice': it is merely a statement about the semantics of Java.

Am I interpreting the text in the wrong way or is in fact stated that synchronized methods are "not so synchronized" when using RMI?

I think you're reading it correctly, and it's completely and utterly wrong, and not only wrong but obviously wrong. How could it possibly be right? Java RMI doesn't, and indeed cannot, alter or remove or extend the semantics of synchronized in any way.