Handling Conflicts
To ensure that changes made to items in the synchronization community are correctly propagated, the destination provider must detect and handle conflicts that occur between items sent from the source provider and items in the destination replica. Sync Framework provides change applier objects that perform most of the work required to detect and handle conflicts.
Sync Framework supports two categories of conflicts that can occur during synchronization: concurrency conflicts and constraint conflicts. Concurrency conflicts occur when the same item or change unit is changed on two different replicas that are later synchronized. Constraint conflicts are conflicts that violate constraints that are put on items or change units, such as the relationship of folders or the location of identically named data within a file system.
Sync Framework provides two ways for a synchronization application to specify how conflicts are handled: by setting a conflict resolution policy that applies to all conflicts that occur during a session, or by registering to receive notification of each conflict as it is detected so that each conflict can be examined and resolved individually.
Conflict Handling Flow of Execution
Conflicts are detected and handled during the change application phase of synchronization. Typically, this occurs in the ProcessChangeBatch(ConflictResolutionPolicy, ChangeBatch, Object, SyncCallbacks, SyncSessionStatistics) (for managed code) or ProcessChangeBatch (for unmanaged code) method of the destination provider.
When the destination provider uses a Sync Framework change applier, the following steps are performed for each item in the change batch.
The change applier verifies whether any updates to the item in the destination replica cause the item to be in a concurrency conflict with the source change. For example, when the item has been changed locally in both the source and destination replicas, an update-update conflict is detected.
When the application has specified a conflict resolution policy for concurrency conflicts, the change applier assigns a conflict resolution action based on the policy. Otherwise, the change applier notifies the application of the conflict and the application specifies the conflict resolution action.
The change applier dispatches a call to the destination provider to apply the change, based on the conflict resolution action. For example, delete the item from the destination replica and replace it with the item from the source provider.
When the change is applied by the destination provider to the destination replica, the destination provider detects constraint conflicts. For example, the source change is identified by id1 and is named "FavoriteBooks", but the destination replica contains an item identified by id2 that is also named "FavoriteBooks". The destination replica sees the items as the same because the two items have the same name, but Sync Framework sees the items as different because the two items have different item IDs. The destination provider reports a constraint conflict to the change applier.
When the application has specified a collision conflict resolution policy, and the constraint conflict is because of a collision, the change applier assigns a conflict resolution action based on the policy. Otherwise, the change applier notifies the application of the conflict and the application specifies the conflict resolution action.
The change applier dispatches a call to the destination provider to apply the change, based on the conflict resolution action.
For more information on handling concurrency conflicts, see Detecting and Resolving Concurrency Conflicts.
For more information on handling constraint conflicts, see Detecting and Resolving Constraint Conflicts.
Reducing Conflicts by Using Change Units
The number of conflicts can be reduced by using change units to represent subitem changes. When change units are used, versions are tracked for change units instead of for the item as a whole. Therefore, changes that are made to different change units within the same item will not result in a conflict. For more information, see Synchronizing Change Units.
Saving Conflicts in a Log
It can be useful to save conflicts in a log so that they can be processed separately from the synchronization session, such as when the user will review the conflicts and decide how to resolve them. Also, when constraint conflicts are resolved by merging the data for the two items in conflict, the change applier might, in some cases, use the conflict log to store temporary conflicts during a synchronization session.
For more information about creating and using a conflict log, see Logging and Managing Conflicts.
See Also
Reference
ISynchronousNotifyingChangeApplier Interface
ISynchronousNotifyingChangeApplierTarget Interface