Partager via


Gestion des conflits

Pour garantir la propagation correcte des modifications apportées aux éléments de la communauté de synchronisation, le fournisseur de destination doit détecter et gérer les conflits qui se produisent entre les éléments envoyés à partir du fournisseur de source et les éléments du réplica de destination. Sync Framework fournit des applicateurs de modifications qui effectuent la majeure partie du travail requis pour détecter et gérer des conflits.

Sync Framework prend en charge deux catégories de conflits qui peuvent se produire au cours de la synchronisation : les conflits d'accès concurrentiel et les conflits de contraintes. Les conflits d'accès concurrentiel se produisent lorsque le même élément ou la même unité de modification est modifiée sur deux réplicas différents qui sont ensuite synchronisés. Les conflits de contraintes sont des conflits qui ne respectent pas les contraintes mises sur les éléments ou unités de modification, par exemple la relation de dossiers ou l'emplacement de données portant le même nom dans un système de fichiers.

Sync Framework offre à une application de synchronisation deux moyens de spécifier comment les conflits sont gérés : définition d'une stratégie de résolution des conflits qui s'applique à tous les conflits intervenant au cours d'une session ou inscription pour recevoir une notification de chaque conflit détecté afin d'en permettre l'examen et la résolution de façon individuelle.

Flux d'exécution de la gestion des conflits

Les conflits sont détectés et gérés pendant la phase d'application des modifications de la synchronisation. Celle-ci intervient généralement dans la méthode ProcessChangeBatch (pour le code managé) ou ProcessChangeBatch (pour le code non managé) du fournisseur de destination.

Lorsque le fournisseur de destination utilise un applicateur de modifications Sync Framework, les étapes suivantes sont effectuées pour chaque élément du lot de modifications.

  1. L'applicateur de modifications vérifie si des mises à jour de l'élément sur le réplica de destination provoquent un conflit d'accès concurrentiel entre l'élément et la modification de la source. Par exemple, lorsque l'élément a été modifié localement sur les réplicas source et de destination, un conflit de mises à jour est détecté.

  2. Lorsque l'application a spécifié une stratégie de résolution des conflits pour les conflits d'accès concurrentiel, l'applicateur de modifications attribue une action de résolution de conflit conforme à la stratégie. Sinon, l'applicateur de modifications envoie une notification de conflit à l'application, qui spécifie l'action de résolution de conflit.

  3. L'applicateur de modifications distribue un appel au fournisseur de destination pour appliquer la modification, selon l'action de résolution de conflit. Par exemple, supprimer l'élément du réplica de destination et le remplacer par l'élément du fournisseur de source.

  4. Lorsque la modification est appliquée au réplica de destination par le fournisseur de destination, celui-ci détecte des conflits de contraintes. Par exemple, la modification de la source est identifiée par id1 et est nommée « FavoriteBooks », mais le réplica de destination contient un élément identifié par id2 qui est également nommé « FavoriteBooks ». Le réplica de destination considère que les deux éléments n'en font qu'un, puisqu'ils portent le même nom, mais Sync Framework les voit comme des éléments distincts, car leur ID n'est pas le même. Le fournisseur de destination signale un conflit de contraintes à l'applicateur de modifications.

  5. Lorsque l'application a spécifié une stratégie de résolution des conflits de collision, et que le conflit de contraintes est dû à une collision, l'applicateur de modifications attribue une action de résolution de conflit conforme à la stratégie. Sinon, l'applicateur de modifications envoie une notification de conflit à l'application, qui spécifie l'action de résolution de conflit.

  6. L'applicateur de modifications distribue un appel au fournisseur de destination pour appliquer la modification, selon l'action de résolution de conflit.

Pour plus d'informations sur la gestion des conflits d'accès concurrentiel, consultez Détection et résolution des conflits d'accès concurrentiel.

Pour plus d'informations sur la gestion des conflits de contraintes, consultez Détection et résolution des conflits de contraintes.

Réduction des conflits à l'aide d'unités de modification

Le nombre de conflits peut être réduit en utilisant des unités de modification pour représenter les modifications de sous-éléments. Lorsque les unités de modification sont utilisées, les versions font l'objet d'un suivi pour ces unités de modification et non pour l'intégralité de l'élément. Par conséquent, les modifications apportées aux différentes unités de modification dans le même élément ne provoquent pas de conflit. Pour plus d'informations, consultez Synchronisation des unités de modification.

Enregistrement des conflits dans un journal

Il peut être utile d'enregistrer des conflits dans un journal pour en permettre le traitement indépendamment de la session de synchronisation, de façon, par exemple, à ce qu'un utilisateur puisse passer les conflits en revue et décider de la manière de les résoudre. De même, lorsque des conflits de contraintes sont résolus en fusionnant les données des deux éléments en conflit, l'applicateur de modifications peut, dans certains cas, utiliser le journal des conflits pour stocker des conflits temporaires au cours d'une session de synchronisation.

Pour plus d'informations sur la création et l'utilisation d'un journal des conflits, consultez Journalisation et gestion des conflits.

Voir aussi

Référence

NotifyingChangeApplier

INotifyingChangeApplierTarget

Autres ressources

Implémentation d'un fournisseur personnalisé standard

Application des modifications

Interface ISynchronousNotifyingChangeApplier

Interface ISynchronousNotifyingChangeApplierTarget