Previous | Table of Contents | Next |
The failover semantics for Fault Tolerant CORBA extend the failover semantics for the
CORBA core, and are summarized in Table 23-1 on page 23-22. Note that the Fault
Tolerant CORBA failover semantics permit reinvocation of requests even when a prior invocation yielded COMPLETED_MAYBE, whereas
the CORBA failover semantics permit reinvocation only if all prior attempts yielded COMPLETED_NO. The permissible failover
behaviors are determined by whether the IOR contains the TAG_FT_GROUP
component (defined in Section 23.2.2.1, “TAG_FT_GROUP
Component,? on page 23-14) and whether the client ORB includes an
FT_REQUEST
service context (defined in Section 23.2.8.1, “FT_REQUEST Service Context,? on
page 23-24) in its request, as well as by the completion status returned and by the
exception raised.
The temporal scope of the replacement reference provided by LOCATION_FORWARD_PERM is ORB lifetime or the next LOCATION_FORWARD_PERM.
It is safe, and appropriate, for an ORB to replace any reference that contains the same fault tolerance domain identifier,
the same object group identifier, and a smaller value of the version of the object group reference.
If a client tries to establish a connection to an endpoint that cannot handle the request, the client ORB might receive a
reply containing a LOCATION_FORWARD_PERM response, which provides the most recent object
group reference for the group (as described in Section 23.2.7, “Most Recent Object
Group Reference,? on page 23-22), or it might receive a
SYSTEM_EXCEPTION.
Each time a client ORB attempts to establish a connection, it must not abandon the attempt and raise an exception to the client
application until it has tried to invoke the server using all of the alternative IIOP addresses in the IOR, and has failed
to establish a connection within the request_duration_policy_value (defined in
Section 23.2.8.2, “Request Duration Policy,? on page 23-26). It must then return a
SYSTEM_EXCEPTION to the client application. Alternative addresses include all of the host/port pairs in all of the TAG_INTERNET_IOP
profiles within the interoperable object group reference, and all of the TAG_ALTERNATE_IIOP_ADDRESS components.
Each time a client ORB attempts to invoke a method, it must not abandon the invocation and raise an exception to the client
application until it has tried to invoke the server using all of the alternative IIOP addresses in the interoperable object
group reference, or has received a “non-failover? condition, or the request duration has expired.
No order is prescribed for the use of the addresses present in an interoperable object group reference (including the TAG_ALTERNATE_IIOP_ADDRESS).
If a failover condition arises, an ORB may retry with the same address, or may immediately retry with other addresses - this
is a quality of implementation issue.
This behavior specifies the minimum failover semantics that an ORB must implement. An ORB may also retry in other conditions
not stated above, but this is not mandated. Under all failover conditions, at most once semantics must be guaranteed.
Table 23-1 Permitted Failover Conditions without and with Transparent Reinvocation
Completion Status |
CORBA Exception |
||||
Without Transparent Reinvocation | COMPLETED_NO | COMM_FAILURE TRANSIENT NO_RESPONSE OBJ_ADAPTER | |||
With Transparent Reinvocation | COMPLETED_NO COMPLETED_MAYBE | COMM_FAILURE TRANSIENT NO_RESPONSE OBJ_ADAPTER |