23.2.6 Extensions to CORBA Failover Semantics

   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