The following illustration depicts the naming conflict scenario.
Processing steps
- The Client sends an update (Add, Delete, or Modify DN) request to server A.
- The Client sends an update (Add, Delete, or Modify DN) request conflicting with the first request to server A.
- Replication propagates the updates.
- Conflict resolution takes place.
The following table shows the result of a modification conflict depending on the type of updates that occur. The code does not compare change sequence numbers (CSNs) but applies operations in the order they were received. This might lead to inconsistent replays.
For all of the naming conflict scenarios, assume the following:
- Update 1 was applied at PingDirectory server 1.
- Update 2 was applied at PingDirectory server 2.
- Update 1 occurred shortly before Update 2 so that PingDirectory server 2 received Update 1 after Update 2 was applied.
Update 1 | Update 2 | Automatic Resolution? | Result of Conflict Resolution at PingDirectory server 2 When Update 1 is received |
---|---|---|---|
|
|
Yes |
|
|
|
Yes |
New entry is located based on the entryUUID and |
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
Entry B is renamed and Entry A is deleted. |
|
|
Yes |
|
|
|
No |
The entry targeted in the |
|
|
Yes |
The entry is moved under the new DN of the parent. |
|
|
No |
A and B will be conflict entries. |
|
|
Yes |
The entry is added under the new DN of the parent. |
|
|
No |
The added entry is marked as a conflict entry. |
|
|
Yes |
The entryUUID of the incoming Add operation applied to the existing entry. |
|
|
No |
The existing entry is marked as a conflicting entry and the incoming
|