Détection et résolution des conflits d'accès concurrentiel
Les conflits d'accès concurrentiel se produisent lorsque le même élément ou la même unité de modification est modifié sur deux réplicas différents qui sont ensuite synchronisés. Sync Framework fournit un objet d'applicateur de modifications qui simplifie la détection et la résolution des conflits d'accès concurrentiel.
Mode de détection et de résolution des conflits d'accès concurrentiel par l'applicateur de modifications
Un conflit d'accès concurrentiel se produit lorsque la version d'une modification du réplica de destination ne figure pas dans la connaissance du réplica source.
Sync Framework fournit un objet d'applicateur de modifications que le fournisseur de destination peut utiliser pour détecter des conflits d'accès concurrentiel. L'applicateur de modifications détecte les conflits d'accès concurrentiel en effectuant les étapes suivantes pour chaque élément contenu dans le lot de modifications envoyé par le fournisseur de source :
Il détermine si la version de l'élément du réplica de destination figure dans la connaissance du réplica source.
Si la version de l'élément du réplica de destination ne figure pas dans la connaissance du réplica source, la modification est en conflit.
Après avoir détecté un conflit d'accès concurrentiel, l'applicateur de modifications le résout conformément à la stratégie de résolution des conflits définie pour la session ou à l'action de résolution de conflit définie par l'application pour le conflit spécifié.
Détection des conflits d'accès concurrentiel à l'aide d'un applicateur de modifications
Pour utiliser un applicateur de modifications pour détecter des modifications, le fournisseur de destination crée d'abord l'objet d'applicateur de modifications.
Code managé Crée un objet NotifyingChangeApplier.
Code non managé Crée un objet ISynchronousNotifyingChangeApplier en passant IID_ISynchronousNotifyingChangeApplier à la méthode IProviderSyncServices::CreateChangeApplier.
Le fournisseur de destination doit ensuite fournir les informations de version pour chaque élément contenu dans le lot de modifications envoyé par le fournisseur de source. Les deux façons de procéder sont les suivantes :
Le fournisseur de destination génère une liste de versions qui correspond au lot des modifications envoyées par le fournisseur de source. L'applicateur de modifications utilise cette liste pour déterminer si la version de destination d'un élément figure dans la connaissance du réplica source.
Code managé Pour créer cette liste, créez un objet de type System.Collections.Generic.IEnumerable<Microsoft.Synchronization.ItemChange>. Pour chaque élément contenu dans le lot de modifications du fournisseur de source, ajoutez un élément à cette liste qui contient la version de l'élément sur le réplica de destination. Passez cette liste à l'applicateur de modifications comme paramètre destinationVersions de la surcharge de méthode appropriée, telle que ApplyChanges(ConflictResolutionPolicy, ChangeBatch, IChangeDataRetriever, IEnumerable<(Of <<'(ItemChange>)>>), SyncKnowledge, ForgottenKnowledge, INotifyingChangeApplierTarget, SyncSessionContext, SyncCallbacks).
Code non managé Pour créer cette liste, créez un objet IDestinationChangeVersionsBuilder en appelant IProviderSyncServices::CreateDestinationChangeVersionsBuilder. Pour chaque élément contenu dans le lot de modifications du fournisseur de source, ajoutez un élément à cette liste qui contient la version de l'élément sur le réplica de destination, en appelant IDestinationChangeVersionsBuilder::AddItemMetadata. Obtenez un énumérateur pour la liste en appelant IDestinationChangeVersionsBuilder::GetChangeEnumerator et passez l'énumérateur à l'applicateur de modifications comme paramètre pDestinationVersions de la méthode ApplyChanges.
Sinon, le fournisseur de destination ne passe pas de liste de versions de destination à l'applicateur de modifications. À la place, le fournisseur de destination implémente la méthode TryGetDestinationVersion (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget::GetDestinationVersion (pour le code non managé). L'applicateur de modifications appelle cette méthode une fois pour chaque élément contenu dans le lot de modifications du fournisseur de source. Dans cette méthode, le fournisseur de destination recherche la version de l'élément du réplica de destination et la retourne à l'applicateur de modifications afin que celui-ci puisse déterminer si la modification est ou non un conflit.
Enfin, le fournisseur de destination appelle la méthode ApplyChanges (pour le code managé) ou ISynchronousNotifyingChangeApplier::ApplyChanges (pour le code non managé) de l'applicateur de modifications.
Utilisation d'un applicateur de modifications pour résoudre les conflits d'accès concurrentiel
L'applicateur de modifications aide le fournisseur de destination à résoudre les conflits en distribuant les appels à l'objet cible de l'applicateur de modifications spécifié par le fournisseur. Lorsqu'une stratégie de résolution de conflit est spécifiée, l'applicateur de modifications l'utilise pour déterminer l'action de résolution de conflit appropriée qu'il doit prendre pour résoudre chaque conflit qui se produit. Lorsque la résolution de conflit personnalisée est spécifiée, l'applicateur de modifications signale le conflit à l'application de synchronisation, laquelle à son tour spécifie l'action de résolution de conflit à prendre. Dans tous les cas, l'applicateur de modifications appelle la méthode cible appropriée de l'applicateur de modifications, puis l'objet cible de l'applicateur de modifications effectue l'action, par exemple, enregistrer la modification dans le réplica ou enregistrer le conflit pour le traiter ultérieurement.
L'application de synchronisation spécifie généralement une stratégie de résolution de conflit avant le démarrage de la synchronisation.
Code managé L'application spécifie la stratégie en définissant une valeur pour la propriété ConflictResolutionPolicy du fournisseur de destination.
Code non managé L'application spécifie la stratégie dans le paramètre resolutionPolicy de la méthode ISyncSession::Start. Le fournisseur de destination reçoit cette stratégie comme paramètre resolutionPolicy de la méthode IKnowledgeSyncProvider::ProcessChangeBatch.
Le fournisseur de destination passe la stratégie de résolution de conflit à l'applicateur de modifications afin que celui-ci puisse distribuer correctement les méthodes à sa cible. La cible de l'applicateur de modifications est représentée par l'objet INotifyingChangeApplierTarget (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget (pour le code non managé).
Sync Framework définit les stratégies de résolution des conflits d'accès concurrentiel suivantes.
Stratégie de résolution de conflit |
Description |
|---|---|
SourceWins (pour le code managé), CRP_SOURCE_PROVIDER_WINS (pour le code non managé) |
La modification effectuée sur le réplica source gagne toujours. Ce type prend en charge une solution de synchronisation en lecture seule dans laquelle le réplica de destination ne doit pas être approuvé. Sync Framework spécifie une action de résolution de conflit SourceWins (pour le code managé) ou SRA_ACCEPT_SOURCE_PROVIDER (pour le code non managé). |
DestinationWins (pour le code managé), CRP_DESTINATION_PROVIDER_WINS (pour le code non managé) |
La modification effectuée sur le réplica de destination gagne toujours. Ce type prend en charge les cas où le réplica de destination n'utilise pas les modifications apportées par les clients distants. Sync Framework spécifie une action de résolution de conflit DestinationWins (pour le code managé) ou SRA_ACCEPT_DESTINATION_PROVIDER (pour le code non managé). |
ApplicationDefined (pour le code managé), CRP_NONE (pour le code non managé) |
L'applicateur de modifications signale à l'application de synchronisation chaque conflit lorsqu'il se produit, en utilisant l'événement ItemConflicting (pour le code managé) ou la méthode ISyncCallback::OnConflict (pour le code non managé). L'application examine les éléments en conflit et spécifie l'action de résolution de conflit en appelant SetResolutionAction (pour le code managé), ou IChangeConflict::SetResolveActionForChange ou IChangeConflict::SetResolveActionForChangeUnit (pour le code non managé). |
Spécification de résolutions de conflits personnalisées
Pour spécifier dynamiquement l'action de résolution de conflit pour chaque conflit d'accès concurrentiel qui se produit, une application effectue les actions suivantes avant de démarrer la synchronisation.
Code managé
Elle inscrit un gestionnaire d'événements pour l'événement ItemConflicting du fournisseur de destination.
Elle définit la propriété ConflictResolutionPolicy du fournisseur de destination à la valeur ApplicationDefined.
Code non managé
Elle implémente la méthode ISyncCallback::OnConflict et inscrit l'objet ISyncCallback en appelant ISyncSession::RegisterCallback.
Elle passe CRP_NONE comme paramètre resolutionPolicy de ISyncSession::Start.
Pendant la synchronisation, l'applicateur de modifications déclenche l'événement ItemConflicting (pour le code managé) ou la méthode ISyncCallback::OnConflict (pour le code non managé) chaque fois qu'il détecte un conflit d'accès concurrentiel. L'application peut ensuite examiner les deux modifications en conflit, modifier des métadonnées ou des données d'élément et définir l'action de résolution du conflit à l'aide de la méthode SetResolutionAction (pour le code managé), ou de la méthode IChangeConflict::SetResolveActionForChange ou IChangeConflict::SetResolveActionForChangeUnit (pour le code non managé). L'applicateur de modifications traite ensuite le conflit et distribue l'appel approprié à l'objet cible de l'applicateur de modifications.
Notes
La même action de résolution de conflit doit être spécifiée pour toutes les unités de modification en conflit dans un élément ou des résultats inattendus peuvent se produire. Lorsque ce type de résolution de conflit est requis, spécifiez que le conflit doit être résolu en fusionnant et gérez la résolution dans le fournisseur de destination.
Actions de résolution de conflit d'accès concurrentiel utilisées par le code managé
Sync Framework fournit l'ensemble suivant d'actions de résolution de conflit d'accès concurrentiel pour lesquelles l'applicateur de modifications gère la plupart du traitement.
Action de résolution de conflit |
Description |
|---|---|
La modification effectuée sur le réplica source gagne toujours. L'applicateur de modifications passe la modification à la méthode SaveItemChange ou SaveChangeWithChangeUnits et spécifie une action d'enregistrement UpdateVersionAndData. La modification est appliquée au réplica de destination exactement comme n'importe quelle modification non conflictuelle. |
|
La modification effectuée sur le réplica de destination gagne toujours. L'applicateur de modifications passe une modification de version uniquement à la méthode SaveItemChange ou SaveChangeWithChangeUnits et spécifie une action d'enregistrement UpdateVersionOnly. Seules les informations sur la version de l'élément sont mises à jour dans les métadonnées sur le réplica de destination. Aucune modification des données d'élément n'est apportée. |
|
Permet de fusionner les données de l'élément source dans l'élément de destination. L'applicateur de modifications passe les données de modification du réplica source à la méthode SaveItemChange ou SaveChangeWithChangeUnits et spécifie une action d'enregistrement UpdateVersionAndMergeData. Le fournisseur de destination combine les données d'élément source et les données d'élément de destination, et applique le résultat au réplica de destination. |
|
Permet de consigner le conflit et de ne pas appliquer la modification. L'applicateur de modifications passe les données en conflit à la méthode SaveConflict, ce qui enregistre le conflit dans un journal des conflits. Pour plus d'informations sur la journalisation des conflits, consultez Journalisation et gestion des conflits. |
|
Permet d'ignorer le conflit et de ne pas appliquer la modification. L'applicateur de modifications ne passe pas les données en conflit au fournisseur de destination. |
|
Le dernier enregistreur gagne |
La dernière modification effectuée gagne. L'application récupère l'heure à laquelle la modification a été apportée sur le réplica source et l'heure à laquelle la modification a été apportée sur le réplica de destination, en appelant GetItemChangeTime ou GetChangeUnitChangeTime sur les deux modifications. L'application compare les deux heures et détermine l'action de résolution de conflit qui applique la dernière modification effectuée. Par exemple, si la modification de destination est la plus récente, l'application spécifie une action de résolution de conflit DestinationWins. |
Actions de résolution de conflit d'accès concurrentiel utilisées par le code non managé
Sync Framework fournit l'ensemble suivant d'actions de résolution de conflit d'accès concurrentiel pour lesquelles l'applicateur de modifications gère la plupart du traitement.
Action de résolution de conflit |
Description |
|---|---|
SRA_ACCEPT_SOURCE_PROVIDER |
La modification effectuée sur le réplica source gagne toujours. L'applicateur de modifications passe la modification à la méthode ISynchronousNotifyingChangeApplierTarget::SaveChange ou ISynchronousNotifyingChangeApplierTarget::SaveChangeWithChangeUnits et spécifie une action d'enregistrement SSA_UPDATE_VERSION_AND_DATA. La modification est appliquée au réplica de destination exactement comme n'importe quelle modification non conflictuelle. |
SRA_ACCEPT_DESTINATION_PROVIDER |
La modification effectuée sur le réplica de destination gagne toujours. L'applicateur de modifications passe une modification de version uniquement à la méthode SaveChange ou SaveChangeWithChangeUnits et spécifie une action d'enregistrement SSA_UPDATE_VERSION_ONLY. Seules les informations sur la version de l'élément sont mises à jour dans les métadonnées sur le réplica de destination. Aucune modification des données d'élément n'est apportée. |
SRA_MERGE |
Permet de fusionner les données de l'élément source dans l'élément de destination. L'applicateur de modifications passe les données de modification du réplica source à la méthode SaveChange ou SaveChangeWithChangeUnits et spécifie une action d'enregistrement de SSA_UPDATE_VERSION_AND_MERGE_DATA. Le fournisseur de destination combine les données d'élément source et les données d'élément de destination, et applique le résultat au réplica de destination. |
SRA_TRANSFER_AND_DEFER |
Permet de consigner le conflit et de ne pas appliquer la modification. L'applicateur de modifications passe les données en conflit à la méthode ISynchronousNotifyingChangeApplierTarget::SaveConflict, ce qui enregistre le conflit dans un journal des conflits. Pour plus d'informations sur la journalisation des conflits, consultez Journalisation et gestion des conflits. |
SRA_DEFER |
Permet d'ignorer le conflit et de ne pas appliquer la modification. L'applicateur de modifications ne passe pas les données en conflit au fournisseur de destination. |
Le dernier enregistreur gagne |
La dernière modification effectuée gagne. L'application récupère l'heure à laquelle la modification a été apportée sur le réplica source et l'heure à laquelle la modification a été apportée sur le réplica de destination, en appelant ISupportLastWriteTime::GetItemChangeTime ou ISupportLastWriteTime::GetChangeUnitChangeTime sur les deux modifications. L'application compare les deux heures et détermine l'action de résolution de conflit qui applique la dernière modification effectuée. Par exemple, si la modification de destination est la plus récente, l'application spécifie une action de résolution de conflit SRA_ACCEPT_DESTINATION_PROVIDER. |
Voir aussi
Référence
Autres ressources
Détection et résolution des conflits de contraintes
Interface ISynchronousNotifyingChangeApplier
Interface ISynchronousNotifyingChangeApplierTarget