| Previous | Table of Contents | Next |
IOGRs are IORs. However, the semantics of several of the operations inherited from CORBA::Object must be adjusted to account
for the group contents of an IOGR.
23.2.3.1 get_interface
Unchanged. The assembly procedure for an object group guarantees that the interfaces supported by the object group are supported
by all members of the object group.
23.2.3.2 is_a
Unchanged.
23.2.3.3 is_nil
Essentially unchanged. True if no profiles are present or if is_nil is true for all of the profiles.
23.2.3.4 non_existent
Essentially unchanged. True if the object group does not exist. Note that the object group might exist even if non_existent()
is true for all of the profiles of the object group reference or even if there are no IOP profiles in the object group reference.
(This occurs when an object group with the application-controlled Membership Style is created with no members so that the
members can be added individually by the application.) A server ORB can obtain an authoritative determination of non-existence
of the object group from the Replication Manager, using the same mechanisms as are used to obtain the most recent object group
reference. The ORB must use those mechanisms to generate a LOCATION_FORWARD reply when the client’s request contains an obsolete
object_group_ref_version field in the FT_GROUP_VERSION service context.
23.2.3.5 is_equivalent
There are three cases to consider for checking equivalence:
1. Two non-object group references. The semantics of the operation are unchanged in this case.
2. An object group reference and a non-object group reference. These references are not equivalent.
3. Two object group references. Section 23.2.2.1, “TAG_FT_GROUP Component,? on page 23-14 introduces a strong identity for an object group in its ft_domain_id and object_group_id fields. Two object group references are equivalent if they have the same ft_domain_id and the same object_group_id fields. Note that the object_group_ref_version field in the TAG_FT_GROUP component is ignored.
The analysis of these cases collapses the semantics to the following:
• Non-Fault-Tolerant CORBA implementations are essentially unchanged. These implementations might not recognize certain object group references as representing the same object group. However, that is allowed under the present semantics.
• Fault Tolerant CORBA implementations compare the values of the corresponding ft_domain_id and object_group_id fields in the TAG_FT_GROUP components to determine the equivalence of two object group references. Otherwise, the semantics for is_equivalent are unchanged.
23.2.3.6 hash
Follows the semantics for is_equivalent(). An interoperable object group reference contains an object group identifier that
is unique and immutable over the lifetime of the object group. For such a reference, the value of hash() shall be derived
from the object group identifier. For references that are not interoperable object group references, the value of hash() continues
to be derived as at present.
23.2.3.7 create_request
Unchanged.
23.2.3.8 get_policy
Unchanged.
23.2.3.9 get_domain_managers
Unchanged.
23.2.3.10 set_policy_overrides
Unchanged.