| Previous | Table of Contents | Next |
In order to efficiently manage state that include large numbers of object references, services need to support a notion of
object reference identity. Such services include not just bridges, but relationship services and other layered facilities.
Two identity-related operations are provided. One maps object references into disjoint groups of potentially equivalent references,
and the other supports more expensive pairwise equivalence testing. Together, these operations support efficient maintenance
and search of tables keyed by object references.
4.3.6.1 Hashing Object Identifiers
hash
unsigned long hash( in unsigned long maximum );
Object references are associated with ORB-internal identifiers that may indirectly be accessed by applications using the hash
operation. The value of this identifier does not change during the lifetime of the object reference, and so neither will any
hash function of that identifier.
The value of this operation is not guaranteed to be unique; that is, another object reference may return the same hash value.
However, if two object references hash differently, applications can determine that the two object references are not identical.
The maximum parameter to the hash operation specifies an upper bound on the hash value returned by the ORB. The lower bound
of that value is zero. Since a typical use of this feature is to construct and access a collision chained hash table of object
references, the more randomly distributed the values are within that range, and the cheaper those values are to compute, the
better.
For bridge construction, note that proxy objects are themselves objects, so there could be many proxy objects representing
a given “real? object. Those proxies would not necessarily hash to the same value.
4.3.6.2 Equivalence Testing
is_equivalent
boolean is_equivalent( in Object other_object );
The is_equivalent operation is used to determine if two object references are equivalent, so far as the ORB can easily determine.
It returns TRUE if the target object reference is known to be equivalent to the other object reference passed as its parameter,
and FALSE otherwise.
If two object references are identical, they are equivalent. Two different object references that in fact refer to the same
object are also equivalent.
ORBs are allowed, but not required, to attempt determination of whether two distinct object references refer to the same object.
In general, the existence of reference translation and encapsulation, in the absence of an omniscient topology service, can
make such determination impractically expensive. This means that a FALSE return from is_equivalent should be viewed as only
indicating that the object references are distinct, and not necessarily an indication that the references indicate distinct
objects. Setting of local policies on the object reference is not taken into consideration for the purposes of determining
object reference equivalence.
A typical application use of this operation is to match object references in a hash table. Bridges could use it to shorten
the lengths of chains of proxy object references. Externalization services could use it to “flatten? graphs that represent
cyclical relationships between objects. Some might do this as they construct the table, others during idle time.