eDirectory is described as a loosely consistent environment, which means that there is no guarantee that all replicas hold the same data at any one moment in time. In other words, partition replicas are not updated instantaneously, and a change made to one replica must be synchronized with other replicas.
The synchronization interval is established by the network administrator and can be as short as one second or as long as five minutes.
For a developer who is new to the eDirectory environment, this can present many new challenges. A program that works well in the test environment can suddenly become unreliable when installed on a real network. A program that seems to work on a small network might not work at all on a large, busy network. Taking time now to consider some of the implications of working in a loosely consistent environment can save many hours of grief later. The following topics detail some things you need to consider:
Because the eDirectory database must synchronize replicas, not all replicas hold the latest changes at any given time. This concept is referred to as loose consistency, which simply means that the partition replicas are not updated instantaneously. In other words, as long as the database is being updated, the Directory is not guaranteed to be completely synchronized at any moment in time. However, during periods in which the database is not updated, it will synchronize completely.
Loose consistency has the advantage of allowing eDirectory servers to be connected to the network with different types of media. For example, a company might connect parts of its network by using a satellite link. Data travelling over a satellite link experiences transmission delays, so any update to the database on one side of the satellite link is delayed in reaching the database on the other side of the satellite link. However, these transmission delays do not interfere with the normal operation of the network because the database is loosely consistent. The new information arrives over the satellite link and is propagated through the network at the next synchronization interval.
Another advantage to loose consistency becomes apparent when communication problems cause a number of the servers on a network to become unavailable. Any changes made to eDirectory during the time that the servers were out of operation are not lost. When the problem is resolved, the replicas on the affected servers receive updates.
eDirectory guarantees a loosely consistent Directory, meaning that changes made to one replica may take time to synchronize with all other replicas. It is possible that a user or other object may access one of these other replicas before these replicas receive the updated information. For example, a program might create an object in the eDirectory tree and then collect the data it needs to modify the object’s attributes. The operations used to gather the data might change the context variable that points to the specific replica where the object was created.
Now that the program has the data it needs, the program will call NWDSModifyObject, which then walks the tree to find the partition holding the object. If the replica it contacts has not yet received the information it needs to create the object, the operation will return a NO_SUCH_ENTRY (-601) error.
There are several ways to avoid or correct the problem of disappearing objects. The simplest solution is to wait until after the next synchronization interval. If you don’t want to wait, you could call NWDSSyncPartition, which signals the synchronization engine to update the specified partition without waiting for the next synchronization time. This function has four input parameters: the context handle, the name of the server where the partition resides, the name of the partition root, and the number of seconds to wait before beginning the update.
Before calling NWDSSyncPartition, you should call NWDSGetPartitionRoot to get the name of the partition root. It requires a context handle and the name of the object in the partition, and it returns the name of the partition root. The following code segment shows how to make these calls:
ccode = NWDSGetPartitionRoot (context, objectName, partitionRoot);
ccode = NWDSSyncPartition (context, serverName, partitionRoot, 0);
if (ccode)
printf("Error, sync partition failed. %d\n", ccode);
Another solution would be caching the contents of the context variable called DCK_LAST_CONNECTION immediately after creating the object. This variable contains the name of the server where you created the object.
You might also create a separate context handle for operations that deal with other objects. This would ensure that the context handle for the object that was just added would not be changed.
There is one other possible solution to this problem, which might work well in some situations. The partition root object, as a member of the Partition class, has a Replica attribute, which is a multivalued attribute that contains a list of servers that store a replica of the partition. After reading the Replica attribute of the partition Root object, you could attempt to read the object you are looking for on each of the servers that contain a replica of that partition until you find the object. Note that this solution does not scale well. On large networks with many replicas of a single partition, this process could take more time than it would save.