JavaPartyA distributed companion to Java
Current release 1.9.5
Bernhard Haumacher, Thomas Moschny and Michael Philippsen
Since JavaParty 1.07a
When a remote method is called, the actual thread sends the method arguments and blocks until the method result is available. After reception of the result, it continues. On the server side, a thread unrelated to the original one receives the method invocation, executes the requested method and returns the result over the network. From a bird's eye view, the control flow moves during the remote call from one virtual machine to another and returns to the original machine when the method returns. Such control flow that spawns multiple nodes is called a "distributed thread". Since Java threads are bound to their virtual machine they are created in, a remote method execution is mapped to two different Java threads: the client thread that initiated the call, and the server thread that executes the remote method on the remote node. These two threads are both representatives for the same distributed thread of control. Each segment of the distributed thread is mapped to a particular local Java thread for execution.
As long as remote method invocations are not nested, the application is unlikely to observe that a single control flow is mapped to different Java threads. If remote invocations are nested, and each segment of the distributed thread is executed in its own thread, the following situation as shown in figure 1 can occur:
Figure 1. A distributed thread re-entering its original node.
Figure 1 describes a distributed thread that first calls a method
At this point in time, the described distributed thread consists of
three segments. The first segment lies on
This situation may cause an unexpected dead-lock, if the
application entered a synchronization in segment 1 and tried to
re-enter the synchronization in segment 3. As one expects form regular
non-distributed Java, one thread should be able to enter the same
synchronization several times. But here the distributed thread is
implemented by two different Java threads. The first Java thread
KaRMI provides a solution for the problem described above by tracking the flow of a distributed thread across the borders of a single virtual machine and assigning an unique representative thread to a distributed thread per node. The unique representative is responsible for executing all segments of the distributed thread falling on its node. The above situation is shown again shown in figure 2 using the unique representative approach.
Figure 2. Unique representative for a distributed thread.
In figure 2 thread
This unique representative approach provides full synchronization reentrance for a transparent distributed environment. RMI and most other RPC middle-ware systems that rely on remote execution do not care about distributed threads. Using these systems, you will actually experience a dead-lock in the situation described above.
KaRMI in combination with JavaParty can do even more by providing completely Transparent Threads in a distributed environment. Please read more about Remote Monitor Access (RMA), and JavaParty Synchronization in the following sections.
For comments and bug reports please use the JavaParty users mailing list.
Page design & maintenance: Bernhard Haumacher.
Last update: Fri Mar 30 18:46:00 GMT+01:00 2007
Java is a trademark of Sun Microsystems.