At the moment there are several issues open which highlight weaknesses in the dependency checking mechanism. The dependency mechanism allows a DS to replay changes in parallel and consistently such that an operation is only replayed once any operations that it is dependent upon have completed. For example, an Add operation can only be replayed once the Add of its parent entry has completed. Similarly, a Modify operation can only be replayed once the Add of the entry has been replayed.
Performing the dependency checking in the receiving DS is expensive, inherently race-prone, and wasteful (since all DS instances have to do the same work). It would be preferable if update messages included sufficient information to make the dependency checking more reliable and quicker.
One possibility is for update messages sent by a DS to include the CSNs of operations that they are dependent upon which is readily available in the ds-sync-hist attribute of the originating DS:
- a Modify operation should include the CSN of the Add operation for the target entry
- an Add operation should include the CSN of the Add operation for the parent entry
- a Delete operation should include the CSN of the Add or last Modify operation for the target entry
There's still a number of potential dependencies that are not addressed by this mechanism:
- an Add operation depends on a Delete of the same entry
- a Delete operation depends on the Deletion of its children
I've not included ModifyDN operations because they can be considered as a combination of Add/Delete operations.