23.3.2 Fault Tolerance Properties

   Each object group has an associated set of properties that are set as defaults for the fault tolerance domain, that are set for the type of the object, that are set when the object group is created, or that are set subsequently while the application executes. The names and values of the specified properties are given below. Vendor implementations may define additional properties and may extend the property values.

   23.3.2.1 ReplicationStyle

   Name

   org.omg.ft.ReplicationStyle Value

   FT::STATELESS FT::COLD_PASSIVE FT::WARM_PASSIVE FT::ACTIVE FT::ACTIVE_WITH_VOTING

   For the STATELESS Replication Style, the behavior of the object group is unaffected by its history of invocations. A typical example is a server that provides read-only access to a database.

   23-32 Common Object Request Broker Architecture (CORBA), v3.0.3 March 2004

   For the COLD_PASSIVE or WARM_PASSIVE Replication Styles, only a single member, the primary member, executes the methods that have been invoked on the object group. The object group contains additional backup members for recovery after a fault.

   For the COLD_PASSIVE Replication Style, the state of the primary is extracted from a log and loaded into a backup member when needed for recovery.

   For the WARM_PASSIVE Replication Style, the state of the primary member is loaded into one or more backup members periodically during normal operation.

   For the ACTIVE Replication Style, all of the members of the object group independently execute the methods invoked on the object, so that if a fault prevents one member from operating correctly, the other members will produce the required replies without the delay required for recovery. Duplicate requests and duplicate replies, generated by multiple members of the object group, are detected and suppressed. The ACTIVE Replication Style typically requires the use of a multicast group communication system that provides reliable totally-ordered message delivery and group membership services in a model of virtual synchrony (see the Glossary on page 23-96).

   For a source object group that has the ACTIVE_WITH_VOTING Replication Style, the requests (replies) from the members of the source object group are voted, and are delivered to the members of the destination object group only if a majority of the requests (replies) are identical (match exactly). A vote on a specific request or reply must be performed using the same voting membership at each host where that vote is performed. This Replication Style requires protection against commission faults both in the objects and in the network infrastructure. The ACTIVE_WITH_VOTING Replication Style is not supported in the current specification, but is an anticipated extension. It should be understood that voting itself is computationally inexpensive but that the communication required to support voting properly is substantially more expensive than that required to tolerate only crash faults.

   23.3.2.2 MembershipStyle

   If the value of the MembershipStyle is MEMB_APP_CTRL, the application may create an object itself and then invoke the add_member() operation of the ObjectGroupManager interface to cause the Replication Manager to add the object to the object group. Alternatively, the application may invoke the create_member() operation of the ObjectGroupManager interface to cause the Replication Manager to create the member and add it to the object group. The application is responsible for enforcing the InitialNumberReplicas and MinimumNumberReplicas properties. The Replication Manager initiates monitoring of the members for faults, according to the FaultMonitoringStyle, and registers with the Fault Notifier to receive notifications of faults. Likewise, the application may register for fault notifications for the members of the object group.

   At most one member of an object group can exist at a given location. Therefore, if the application attempts to create or add a second member to an object group at the given location, a MemberAlreadyPresent exception is raised.

   If the value of the MembershipStyle is MEMB_INF_CTRL, the Replication Manager invokes the individual factories, for the appropriate locations, to create the members of the object group, both initially to satisfy the InitialNumberReplicas property, and after the loss of a member because of a fault to satisfy the MinimumNumberReplicas property. The Replication Manager initiates monitoring of the members for faults, according to the FaultMonitoringStyle, and registers with the Fault Notifier to receive notifications of faults.

   23.3.2.3 ConsistencyStyle

   If the value of the ConsistencyStyle is CONS_APP_CTRL, the application is responsible for checkpointing, logging, activation and recovery, and for maintaining whatever kind of consistency is appropriate for the application.

   If the value of the ConsistencyStyle is CONS_INF_CTRL, the Fault Tolerance Infrastructure is responsible for checkpointing, logging, activation and recovery, and for maintaining Strong Replica Consistency, Strong Membership Consistency, and Uniqueness of the Primary for the COLD_PASSIVE and WARM_PASSIVE Replication Styles. The CONS_INF_CTRL Consistency Style requires the object to inherit the Checkpointable interface.

   For the COLD_PASSIVE and WARM_PASSIVE Replication Styles, Strong Replica Consistency requires that, at the end of each state transfer, each of the members of an object group has, or has access to, the same state and the same requests the primary replica had, or had not, processed when it created that state. It requires that requests and replies are not lost in the event of a fault and that duplicate requests and duplicate replies, generated during recovery, are suppressed.

   For the ACTIVE and ACTIVE_WITH_VOTING Replication Styles, Strong Replica Consistency requires that, at the end of each method invocation on the object group, the members of the object group have the same state, and that no requests or replies are lost or duplicated.

   For the ACTIVE, COLD_PASSIVE, and WARM_PASSIVE Replication Styles, the behavior of each member of an object group must be deterministic and each member must start in the same state. If the same sequence of requests are then applied, in the same order, to each member of the group, Strong Replica Consistency will be maintained. Strong Replica Consistency simplifies the application programming, but requires strong mechanisms within the Fault Tolerance Infrastructure to do so. In particular, the ACTIVE and ACTIVE_WITH_VOTING Replication Styles, and perhaps also the WARM_PASSIVE Replication Style, typically employ a multicast group communication protocol that provides reliable totally-ordered delivery of messages and group membership services to maintain Strong Replica Consistency.

   Strong Membership Consistency requires that, for each method invocation on an object group, the Fault Tolerance Infrastructures on all hosts have the same view of the membership of the object group. For the COLD_PASSIVE and WARM_PASSIVE Replication Styles, Uniqueness of the Primary requires that there is exactly one primary member of the object group at each logical point in time.

   23.3.2.4 FaultMonitoringStyle

   For the PULL FaultMonitoringStyle, the Fault Monitor interrogates the monitored object periodically to determine whether it is alive. The PULL FaultMonitoringStyle requires that the object inherits the PullMonitorable interface.

   For the PUSH FaultMonitoringStyle, the monitored object periodically reports to the fault monitor to indicate that it is alive. The PUSH FaultMonitoringStyle is not supported in the current specification, but is an anticipated extension.

   23.3.2.5 FaultMonitoringGranularity

   For the MEMB FaultMonitoringGranularity, each individual member of this object group is monitored. This is the default.

   For the LOC FaultMonitoringGranularity and for a member of this object group at a particular location, if no other object at that location is already being monitored, then the member of this object group at that location is monitored. This member acts as a “fault monitoring representative? for the members of the other objects groups at that location. If another object at that location is already being monitored, then that object acts as the “fault monitoring representative? for the member of this object group at that location. If the “fault monitoring representative? at a particular location ceases to exist due to a fault, then the Replication Manager regards all objects at that location to have failed and performs recovery for all objects at that location. If the “fault monitoring representative? ceases to exist because the member was removed from the group but had not actually failed, then the Replication Manager selects another object at that location as the “fault monitoring representative.?

   For the LOC_AND_TYPE FaultMonitoringGranularity and for a member of this object group at a particular location, if no other object of the same type at that location is already being monitored, then the member of this object group at that location is monitored. This member acts as a “fault monitoring representative? for the members of the other object groups of the same type at that location. If another object of the same type at that location is already being monitored, then that object acts as the “fault monitoring representative? for the member of this object group at that location. If the “fault monitoring representative? at a particular location for a particular type ceases to exist due to a fault, then the Replication Manager regards all objects at that location of that type to have failed and performs recovery for all objects of that type at that location. If the “fault monitoring representative? ceases to exist because the member was removed from the group but had not actually failed, then the Replication Manager selects another object at that location of that type as the “fault monitoring representative.?

   23.3.2.6 Factories

   A factory is an object, the purpose of which is to create other objects. FactoryInfos is a sequence of FactoryInfo, where FactoryInfo contains the reference to the factory, the location at which the factory is to create a member of the object group and criteria that the factory is to use to create the member.

   23.3.2.7 InitialNumberReplicas

   The number of replicas of an object to be created initially.

   23.3.2.8 MinimumNumberReplicas

   The smallest number of replicas of an object needed to maintain the desired fault tolerance.