Journalisation et gestion des conflits
Pendant la synchronisation, une application de synchronisation peut indiquer qu'un conflit doit être enregistré dans un journal des conflits, au lieu d'être résolu immédiatement. En utilisant un journal des conflits, les conflits peuvent être résolus séparément de la synchronisation afin que celle-ci puisse être effectuée aussi efficacement que possible.
Résolution d'un conflit par la journalisation
Pour indiquer qu'un conflit d'accès concurrentiel doit être enregistré, l'application définit une action de résolution de conflit SaveConflict (pour le code managé) ou SRA_TRANSFER_AND_DEFER (pour le code non managé). Pour indiquer qu'un conflit de contraintes doit être enregistré, l'application définit une action de résolution de conflit SaveConflict (pour le code managé) ou SCRA_TRANSFER_AND_DEFER (pour le code non managé).
Journalisation d'un conflit
Pour enregistrer un conflit d'accès concurrentiel, l'applicateur de modifications appelle SaveConflict (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget::SaveConflict (pour le code non managé). Dans cette méthode, le fournisseur enregistre les métadonnées de la modification en conflit, les données de la modification en conflit et la connaissance de conflit spécifiée.
Pour enregistrer un conflit de contraintes, l'applicateur de modifications appelle SaveConstraintConflict (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget2::SaveConstraintConflict (pour le code non managé). Dans cette méthode, le fournisseur enregistre les métadonnées de la modification en conflit, les données de la modification en conflit, l'ID de l'élément en conflit dans le réplica de destination, la raison du conflit et la connaissance de conflit spécifiée.
Avant qu'un conflit ne soit stocké dans le journal des conflits, le fournisseur doit garantir que le conflit n'est pas remplacé par une autre modification qui est déjà dans le journal des conflits. Pour ce faire, vous pouvez créer une connaissance du journal à l'aide de la méthode Combine (pour le code managé) ou ISyncKnowledge::Union (pour le code non managé) pour combiner la connaissance de conflit de tous les conflits dans le journal. Si le nouveau conflit est contenu dans la connaissance du journal, il est obsolète et ne doit pas être ajouté au journal. Cette connaissance du journal peut être créée sur demande ou être stockée avec le journal des conflits. Si la connaissance du journal est stockée, elle doit être mise à jour lorsqu'un conflit est ajouté, en utilisant Combine (pour le code managé) ou Union (pour le code non managé). De la même façon, lorsqu'un conflit est supprimé, la connaissance du journal doit être mise à jour à l'aide de Complement (pour le code managé) ou ISyncKnowledge2::Complement (pour le code non managé).
Suppression de conflits obsolètes
Pour empêcher le journal des conflits de devenir trop volumineux, les conflits obsolètes doivent être supprimés du journal des conflits.
La détection et la suppression des conflits obsolètes sont effectuées plus aisément à l'aide du composant applicateur de modifications de Sync Framework. Pour connecter un journal des conflits à l'applicateur de modifications, le fournisseur ou journal des conflits implémente les interfaces IConflictLogAccess et IConflictLogWriter (pour le code managé) ou les interfaces IConflictLogAccess et IConflictLogWriter (pour le code non managé). Le journal des conflits est passé à l'applicateur de modifications à l'aide de la méthode
ApplyChanges (pour le code managé) ou ISynchronousNotifyingChangeApplier2::ApplyChanges (pour le code non managé). Lorsqu'un journal des conflits est passé à l'applicateur de modifications, l'applicateur de modifications détecte et supprime les conflits obsolètes qui sont dans le journal à la fin de chaque lot de modifications.
Pour un journal des conflits qui ne se connecte pas à un applicateur de modifications, le journal des conflits doit gérer les conflits obsolètes lui-même. Un conflit peut devenir obsolète lorsqu'un conflit est ajouté au journal des conflits qui remplace un conflit qui est dans le journal. Une façon de détecter cette situation consiste à tester la version de modification de chaque conflit dans le journal par rapport à la connaissance du nouveau conflit. Lorsque la version de modification d'un conflit est contenue dans la connaissance du nouveau conflit, le conflit existant est obsolète et doit être supprimé du journal. Un conflit peut également devenir obsolète lorsqu'une modification est appliquée au réplica qui remplace un conflit qui est dans le journal. Une façon de détecter cette situation consiste à tester la version de modification de chaque conflit dans le journal par rapport à la connaissance du réplica après l'application de chaque lot de modifications. La détection et la résolution de conflits obsolètes peuvent être effectuées dans le cadre de la session de synchronisation ou à un autre moment.
Résolution de conflits dans le journal
Les conflits dans le journal des conflits peuvent être résolus dans le cadre de la session de synchronisation ou à un autre moment. Toutefois, les conflits dans le journal des conflits ne doivent pas être résolus pendant l'application des modifications, ou des résultats inattendus peuvent se produire.
Lorsqu'un conflit dans un journal est appliqué au réplica, il doit être traité comme une modification locale. Pour résoudre un conflit dans le journal des conflits, l'application ou le fournisseur effectue les étapes suivantes :
incrémente le nombre de cycles du réplica ;
met à jour la version de modification de l'élément ou de l'unité de modification pour refléter que la modification est apportée par le réplica local avec le nombre de cycles mis à jour ;
combine la connaissance du réplica avec la connaissance du conflit à l'aide de Combine (pour le code managé) ou Union (pour le code non managé) et enregistre la connaissance combinée en tant que nouvelle connaissance du réplica ;
applique les données modifiées au réplica ;
supprime le conflit du journal des conflits.
Journal des conflits en mémoire
Un journal des conflits est requis lorsqu'un fournisseur signale des conflits de contraintes. Pour aider un fournisseur qui signale des conflits de contraintes pour un réplica qui ne contient pas de journal des conflits, Sync Framework fournit une implémentation des interfaces de journal des conflits qui fonctionne en mémoire et est utilisée pour stocker des conflits temporaires qui peuvent survenir suite à la gestion des conflits de contraintes. L'implémentation est la classe MemoryConflictLog (pour le code managé) ou l'interface IMemoryConflictLog, qui peut être obtenue en appelant IProviderSyncServices2::CreateMemoryConflictLog (pour le code non managé).
L'implémentation du journal des conflits en mémoire peut également être utilisée avec un journal des conflits persistant. Le journal des conflits en mémoire peut être utilisé pour améliorer les performances en l'utilisant pour fournir un cache en mémoire du journal des conflits complet et gérer des conflits temporaires. Lorsqu'un journal des conflits persistant est chaîné au journal des conflits en mémoire, les conflits peuvent être enregistrés dans le journal des conflits persistant à la fin de la synchronisation en appelant [M:Microsoft.Synchronization.MemoryConflictLog.Persist()] (pour le code managé) ou IMemoryConflictLog::Persist (pour le code non managé).