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 RMI and synchronized methods.

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).

I've seen that a lot of people have the same opinion, look here for example: Java RMI and Thread Synchronization questions

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

Here's the relevant excerpt from the book (you can read the bold sentence only, but you can read the context if you prefer to):

Logically, blocking in a remote object is simple. Suppose that client A calls a synchronized method of a remote object. 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. Likewise, another client on a different machine would need to be blocked locally as well before its request can be sent to the server. The consequence is that we need to synchronize different clients at different machines. As we discussed in Chap. 6, distributed synchronization can be fairly complex.

An alternative approach would be to allow blocking only at the server. In principle, this works fine, but problems arise when a client crashes while its invocation is being handled by the server. 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.

Therefore, the designers of Java RMI have chosen to restrict blocking on remote objects only to the proxies (Wollrath et al., 1996). This means that threads in the same process will be prevented from concurrently accessing the same remote object, but threads in different processes will not. Obviously, these synchronization semantics are tricky: at the syntactic level (ie, when reading source code) we may see a nice, clean design. Only when the distributed application is actually executed, unanticipated behavior may be observed that should have been dealt with at design time. [...]

I think that the paper "A Distributed Object Model for the Java System" (available here) is referenced in the text by the note Wollrath et all, 1996 between parenthesis. However the only relevant paragraph I've found on that paper is this one:

Due to the differing failure modes of local and remote objects, distributed wait and notification requires a more sophisticated protocol between the entities involved (so that, for example, a client crash does not cause a remote object to be locked forever), and as such, cannot be easily fitted into the local threading model in Java. Hence, a client can use notify and wait methods on a remote reference, but that client must be aware that such actions will not involve the actual remote object, only the local proxy (stub) for the remote object.

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

Solution 1

What your first reference is saying is that within a single VM instance, invocations on an RMI Stub (client to an RMI server) will be internally synchronized. That is, the stub (or proxy, as the text seems to call it) itself will prevent multiple threads from concurrently invoking a method on the remote server. It clarifies, however, that two VMs each with stubs for a remote server will not be blocked from concurrently invoking the remote server (which is obvious, because they cannot share a lock, and RMI itself does not prevent concurrency at the server). If this is undesirable, the RMI server will have to implement a locking mechanism to prevent multiple concurrent invocations.

The second reference does not in anyway contradict the first. The second merely clarifies that if you try to synchronize on a stub, it will only be locked locally, and will not impact the concurrency of the remote server.

Combining the two texts, we can read that synchronizing on a stub will prevent the multiple threads in the same VM from concurrently accessing the remote, but will not prevent threads in distinct VMs from concurrent access.

Solution 2

You should also be aware that Java multi-threading has changed significantly since 1996. The notify() and wait() methods that were part of the original language design got a lot of flack from concurrency experts and in Java 5 (2004, says wiki) high level concurrency objects like the ReentrantLock were introduced which are now the preferred way of doing things.

So the criticisms you mention are probably correct, but outdated.

Solution 3

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.

Solution 4

As far as I know each call to an RMI server will create a new thread (witnessed by my log files from 2000) on server side. If you do synchronizing at server side you should be safe. I faced some ancient warnings from literature as you posted. As an practicioner I prefered to run the software for a month or so and decided it was stable enough for for production. I'm Sorry if this isn't not satisfying.

View more solutions

Comments

[user207421]

Not quite. There is connection pooling, so successive calls from the same JVM may use the same connection and therefor the same thread at the server.

[user207421]

Very good analysis and explanation. However it must be noted that the claim in the cited text that RMI stubs synchronize against concurrent local calls internally is quite incorrect.

[mwhidden]

Actually, I think it is my analysis, and not the claim in the cited text that was incorrect. On carefully re-reading the cited text, it seems that authors intended to convey something like "in the case of synchronization on a remote object, the blocking is restricted to the proxies." In which case my original analysis of the text was in error, because there is no claim made about internal synchronization.

[user207421]

None of those changes had any impact on RMI or the matters raised in this question.

[user207421]

The authors' claim is incorrect, and it can be easily shown by experiment. In fact the quoted text is more or less complete nonsense, and unimplementable nonsense as well. See my answer.

[Bilal Siddiqui]

those are pretty glaring errors.. how did the text even get past review?!