OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
Unfortunately, with a remote procedure call, there is no way to guarantee either exactly
once or at-least-once call semantics. Instead, RPC provides at-most-once and
idempotent semantics. When a call completes and returns to the client, then at-most-
once semantics is equivalent to exactly-once semantics, and idempotent semantics is
equivalent to at-least-once. When a call fails to return to the client—either because of a
server or communications failure—the semantics make the following guarantees:
at-most-once
The call was invoked on the server either 0 or 1 times. If the call was
invoked, it may or may not have completed execution.
idempotent
The call was invoked on the server 0 or more times. If the call was
invoked, it may or may not have completed execution for any
invocation.
In reality, idempotent semantics provides no guarantee for calls that fail to return to the
client. In fact, DCE provides no guarantee about how idempotent semantics are actually
implemented. It is perfectly correct to implement idempotency by using at-most-once
semantics, and depending on protocol and implementation, this may be the case.
Idempotent semantics is therefore really a hint from the application that a call is a
candidate to be retried if the implementation uses a retry strategy.
These characteristics lead to two kinds of policy guidelines for call semantics. The first
has to do with the behavior required of idempotent operations. An operation is a good
candidate for idempotent semantics if it either changes no state on the server (such as, a
read operation), or if the server state will be the same even if the same call is invoked
more than once (such as, a call that writes the same record) with the same [in] data. Note
that in either of these cases, the result returned by a call may not be the same on each
retry, since some other thread or process may have modified server state. A server that
allows simultaneous reads and writes provides a good example. However, the runtime
does guarantee commutativity of operations on the same association: an idempotent call
will not be retried if a later call on the same association has been invoked.
The second policy issue has to do with how applications respond to call failures. The
issues are the same for idempotent and at-most-once calls. In neither case can the client
know whether the server manager operation was invoked, and, if it was invoked, whether
it was completed. This leads to three possible failure states:
1. The manager operation was not invoked.
2. The manager operation was invoked but did not complete.
3. The manager operation was invoked and completed, but failed to return to the
client.
The burden of determining which state applies, and implementing recovery actions rests
almost entirely with the application. The RPC mechanism provides limited support for
cleanup in the case of applications that use context handles to maintain state between
calls. Application provided context rundown routines will be called on behalf of the
application if a communications failure is detected. Beyond this rather elementary
mechanism, DCE RPC does not provide any internal support for transaction processing,
roll-back, or other recovery mechanisms. For applications where error recovery and
maintainance of consistent state is essential, these must be implemented by the
application programmer. The topic is beyond the realm of this policy guide.
6− 2 Tandem Computers Incorporated 124246