Previous | Table of Contents | Next |
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
Name | org.omg.ft.MembershipStyle | ||||
Value | FT::MEMB_APP_CTRL | ||||
FT::MEMB_INF_CTRL |
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
Name | org.omg.ft.ConsistencyStyle | ||||
Value | FT::CONS_APP_CTRL | ||||
FT::CONS_INF_CTRL |
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
Name | org.omg.ft.FaultMonitoringStyle | ||||
Value | FT::PULL FT::PUSH FT::NOT_MONITORED |
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
Name | org.omg.ft.FaultMonitoringGranularityStyle | ||||
Value | FT::MEMB FT::LOC FT::LOC_AND_TYPE |
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.