Associate Unique Identifiers with Requests
Once you decide to implement retry logic, you need to worry about partial failures. For example, consider the following scenario:
The client makes a remote method call.
The server receives the call, handles it, and returns the appropriate answer.
The network hiccups.
The client gets a
RemoteExceptionand tries again.
Sometimes this is harmless. For example, clients frequently fetch information from a server to display to a user. As long as the request doesn’t change any state on the server, it’s OK to simply make the request twice. If, however, the request changes state on the server (for example, depositing money to an account), it’s usually important that the request not be processed twice. That is, the client needs to make the request a second time, and the server needs to return the correct answer. But the server shouldn’t actually perform the requested action twice.
In complicated cases, the client application might need to use a
distributed transaction manager to actually make sure that a set of
related calls to the server will succeed or fail
atomically.[17] But
in many cases, it simply suffices to associate a unique identifier to
the method call. For example, the following code uses the
VMID
class (from the java.rmi.dgc package) to define a
RequestIdentifier
class:
public final class RequestIdentifier implements Serializable { public static synchronized RequestIdentifier getRequestIdentifier( ) { return new RequestIdentifier( ); } ...