Given that I opened this chapter by talking about the need for multithreaded servers, and given that we’ve spent 30 pages or so on the basic thread manipulation operations in Java, you might think that the RMI specification goes heavy on the details of the threading model. You’d be wrong.
Here’s all of what the RMI specification says about threading:
3.2 Thread Usage in Remote Method Invocations
A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocations on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is threadsafe.
In practice, threading in RMI is fairly simple. On the client side, RMI adds no threading complications. Remote method invocations on the client side consist, more or less, of code that behaves exactly like our socket code. That is, a request is marshalled and sent through a socket. The thread sending the request then tries to read a response back from the server, over the socket. This means that the calling thread (on the client) blocks until the server sends a response.
This model of remote method invocation is nice because it corresponds to what happens with local method invocation. That is, we have:
A new frame is put on the stack, corresponding to the new method ...