9.1 Examples

This section contains the following examples:

9.1.1 Deleting an Object

  1. Add the Primary obituary OBT_DEAD.

    The Back Link attribute contains a list of servers that have an interest in this object and need to be notified of changes to this entry. For every DN listed in the Back Link attribute and all servers listed in the entry's partition replica attribute, eDirectory adds a Back Link obituary. The creation time of the Primary obituary, OBT_DEAD, is stored in the Secondary obituary.

    The Used By attribute contains a list of partitions that have an interest in this object and need to be notified of changes to this entry. For every DN listed in the Used By attribute, eDirectory adds a Used By obituary. The creation time of the Primary obituary, OBT_DEAD, is stored in the Secondary obituary.

  2. Remove all attributes but the obituaries.

    The Outbound Replication Process then synchronizes this change to all other servers in the replica ring.

    On the next inbound synchronization of this partition, the Obituary Process is started, which does the following:

    • Computes a time vector which is a minimum transitive vector, referred to as the purge vector. Later versions of eDirectory compute a second minimum vector, called the obituary vector, which does not consider replicas which are subordinate references.

    • Each Obituary in this partition is now examined.

      If the obituary is a Primary obituary, there are no Secondary obituaries, and the attribute's modification time (MTS) on the obituary is older than the Purge Vector, then all servers have seen the change and this obituary will be removed.

      If the obituary is a Back Link obituary and this server is the master, then this server is responsible for processing this obituary.

      IMPORTANT:Perform the required operation for this state if it has not been done. Most often, this is done by notifying an external reference.

      If the obituary is a Used By obituary and this server is the server where the delete occurred (determined by comparing the replica number in the obituary's MTS to our replica number), this server is responsible for processing this obituary.

    • If this server is responsible for processing a particular Secondary obituary type (Back Link or Used By), all Secondary obituaries of that type on an entry are in the same state, the required operation for that state has been completed on all obituaries (for example, servers have been notified), and the obituary's MTSs for that obituary type are older than the Obituary Vector, then all Secondary obituaries of that type can be advanced to the next state.

9.1.2 Moving an Object

Move acts much like Delete, but with the following changes:

  • Before the Primary obituary is placed on the move source, a partial entry is created in the destination container and a Tracking obituary (OBT_INHIBIT_MOVE) is placed on that partial entry. This Tracking obituary is placed to prevent the entry from being moved or taking part in a partition operation before the full entry is transferred from the source.

  • On the source entry, the Primary obituary is OBT_MOVED.

  • After the Primary obituary (OBT_MOVED) is moved to the Notified state (meaning that all replicas of the source know the entry is being moved) and all external references have been notified, the Tracking obituary (OBT_INHIBIT_MOVE) is removed from the destination entry.