PingDirectory

Conflict resolution

This topic covers background information, the conflict resolution process flow, and explanation of conflict resolution.

Replication employs an eventual-consistency model which can introduce a window where conflicting updates targeting the same entry might be applied at two different PingDirectory servers. In general, if the update that arrived later fails, two updates to the same server are in conflict. Conflict resolution, when possible, corrects conflicts introduced by clients automatically. There are some exceptions, however, when manual administrative action is required. For example, adding an entry in one replica and simultaneously deleting the parent of this entry on another replica introduces a conflict that requires manual action. In a carefully implemented deployment, the risk of introducing conflicts that require manual action can be significantly reduced or even eliminated.

The conflict resolution algorithm in PingDirectory server uses a mechanism that orders all updates in the replication topology. The server assigns a unique change number to each update. The change number is attached to each update propagated through replication and allows each server to order updates exactly the same way. See the following diagram for an example.

Conflict resolution process flow

The following diagram depicts adding a single-valued attribute with different values to an entry concurrently at two PingDirectory servers resulting in a conflict as well as the conflict resolution in the standalone environment versus the replicated environment.

An illustration of the Conflict Resolution process flow in a standalone environment and a replicated environment. The standalone environment depicts steps 1 to 4 on the left showing the LDAP communication between the client and the Identity Data Store. The replicated environment depicts steps 1 to 6 on the right showing the LDAP communication between the clients and Identity Data stores A and B as well as the replication between Identity Data Stores A and B. In the center of the illustration, steps 1 to 6 are written.

Processing steps

  1. The client sends a modify request to the Identity Datastore and succeeds.

  2. The client sends another modify request that conflicts with the first.

  3. In the standlaone environment, the request is rejected. In the replicated environment, the request succeeds.

  4. In the replicated environment only: Replication propagates the updates.

  5. In the replicated environment only: Conflict resolution concludes with A ignores the update from B, B sets the attribute value to the value on A.

From the diagram example, you can make the following observations:

  • The second operation fails if a client attempted to add the same attribute to the same entry at the same PingDirectory server.

  • In a replicated environment, the conflict is not immediately seen if these updates are applied concurrently at two different PingDirectory servers.

  • The conflict is handled only after replication propagates the updates.

  • The PingDirectory servers resolve the conflict independently of the other server. On one server, the entry updates to reflect the correct value. On the other server, the value stays the same. As a result, each server independently resolves the conflict the same way based on the ordering of the updates.