In typical Windchill installations, most LDAP requests that modify LDAP data will be directed at a particular WindchillDS. In such a configuration, replication conflicts should not occur, or be very unlikely to occur. However, it may be useful to understand more about replication conflicts so you can recognize conflicts if they do occur.

A replication conflict can occur in a replication configuration if changes are made at about the same time on two or more servers and the changes are not compatible, or involve the same entry or set of entries. These are examples of possibly conflicting changes:

There are two types of replication conflicts: modify conflicts and naming conflicts. Modify conflicts occur when conflicting LDAP modify requests are made to two different servers at about the same time. Naming conflicts are those in which at least one of the conflicting changes is an LDAP request other than an LDAP modify request. The first conflict in the list above is a modify conflict and the other two are naming conflicts.

A replication conflict is detected as conflicting changes are replicated and applied on the local server. When a replication conflict is detected, WindchillDS attempts to automatically resolve the conflict in a logical way. Modify conflicts are relatively simple to resolve, and the resolution is performed in an intuitive way. In general, modify conflicts will be resolved based on the order in time in which the change occurred. For this to work properly, of course, system clock settings must be accurate.

If, for example, an attribute is deleted from an entry on one server, and immediately thereafter a value is added to the same attribute on another server, the final result will be the same as if the first change and then the second happened on the same server and in that order. In this example, the final result will be that the attribute will have only the value added on the second server. If the timing of the two changes is reversed, the final result will be that the attribute is deleted from the entry.

Naming conflicts, however, can be much more complex and are more difficult to resolve. In all cases, WindchillDS will resolve the naming conflict. However, in some cases, the likelihood of an incorrect resolution may be high and after resolving the conflict it saves the losing entry(ies) involved in the conflict. This allows later recovery by an administrator, if appropriate.

As one simple example, suppose two entries with different content, but the same DN are added at about the same time to two different servers. When the conflict is detected, the entry added first will be retained, and the entry added second will be saved and given a name based on the entry’s UUID. The DN of such an entry might look like this: