Présentation de la connaissance de synchronisation
Cette rubrique fournit une vue abstraite de la façon dont les algorithmes de synchronisation Sync Framework utilisent la connaissance pour activer l'énumération des modifications et la détection de conflit. La connaissance représente les métadonnées qui décrivent toutes les modifications appliquées à un réplica, directement ou par synchronisation. L'énumération des modifications est le processus d'identification des éléments qui ont été modifiés sur le réplica source et dont le réplica de destination n'a pas connaissance. La détection de conflit représente le processus d'identification des opérations qui ont été effectuées par un réplica sans transférer la connaissance de la modification à l'autre réplica, par exemple lorsque deux réplicas apportent des mises à jour locales au même élément.
Notes
En général, les fournisseurs de synchronisation et les applications n'utilisent pas directement la connaissance. Ils appellent plutôt les méthodes Sync Framework qui appellent de leur part des opérations de connaissance.
Opérations de connaissance
Le tableau suivant répertorie et décrit les opérations de connaissance de la synchronisation.
Opérateur |
Description |
|---|---|
Contains |
Détermine si un objet de connaissance spécifié contient une version spécifiée d'un élément. (La version représente une clé de réplica et un nombre de cycles.) En d'autres termes, déterminez si le réplica qui possède cette connaissance a appliqué cette modification. L'ID d'élément et la version sont des entrées requises pour cette opération. Cette opération est utilisée dans l'énumération des modifications et la détection de conflit. |
Union |
À partir de deux objets de connaissance, créez un objet de connaissance qui contient exactement le même ensemble de modifications que celui qui est contenu par au moins l'un des objets de connaissance d'origine. Cette opération est utilisée pendant l'application des modifications. |
Project |
En utilisant un objet de connaissance spécifié et un ID d'élément, un ID d'unité de modification ou une plage d'ID d'élément, génère un nouvel objet de connaissance qui contient les mêmes modifications que l'original pour l'ID spécifié ou la plage d'ID, et rien pour le reste des éléments. Cette opération est utilisée lorsque la connaissance doit être restreinte à un élément particulier, une unité de modification ou une plage d'éléments, par exemple pendant une synchronisation interrompue, un traitement par lot et certaines formes avancées de synchronisation filtrée. |
Exclude |
En utilisant un objet de connaissance spécifié et un ID d'élément ou un ID d'unité de modification, génère un nouvel objet de connaissance qui ne contient rien pour l'ID spécifié, mais contient les mêmes modifications que l'original pour le reste des éléments. Cette opération est le contraire de l'opération de projection : une opération d'exclusion projette la connaissance partout, sauf sur l'élément spécifié. Cette opération est en général utilisée lors des échecs dans l'application des modifications. |
Énumération des modifications
L'énumération des modifications est implémentée par le développeur du fournisseur de source. En utilisant les opérations de connaissance spécifiées, l'énumération des modifications se déroule comme suit :
Le fournisseur de destination envoie la connaissance actuelle du réplica de destination au fournisseur de source.
Le fournisseur de source parcourt tous les éléments dans le réplica source et effectue les étapes suivantes pour chaque élément :
Détermine si la connaissance de destination contient la version d'élément stockée dans le réplica source.
Dans le cas contraire, inclut l'élément dans le lot de modifications à envoyer au fournisseur de destination.
Notes
L'énumération des modifications peut également être gérée en utilisant une requête directe sur le magasin d'éléments ou la combinaison d'une requête et de cet algorithme, s'il est pris en charge par le magasin d'éléments.
Envoi des modifications
Les modifications énumérées doivent être envoyées du fournisseur de source au fournisseur de destination. Pour cela, elles sont réparties en lots et, pour chaque lot, les informations suivantes sont envoyées :
Métadonnées qui décrivent les modifications elles-mêmes. Le fournisseur ajoute les métadonnées au lot pour chaque modification contenue dans le lot.
Connaissance courante, qui est en général la connaissance actuelle du réplica source, à utiliser dans la détection de conflit. La connaissance courante répond à la question : que saviez-vous lorsque vous avez apporté ces modifications ? Le fournisseur ajoute la connaissance courante au lot pour chaque groupe de modifications ajouté au lot.
Connaissance acquise. Il s'agit de la connaissance actuelle du réplica source projetée sur le sous-ensemble des éléments envoyés dans ce lot, ainsi que les conflits enregistrés. La connaissance acquise répond à la question : que vais-je apprendre en appliquant ce lot de modifications ? Sync Framework calcule la connaissance acquise pour le fournisseur.
Notes
Le traitement par lot et l'énumération des modifications peuvent être traités en parallèle, car le traitement par lot ne doit pas attendre la fin de l'énumération des modifications.
Ordre
Selon l'ordre dans lequel les modifications sont envoyées, la projection de la connaissance sur les éléments dans le lot peut prendre plus ou moins de temps. Par exemple, la connaissance prend en charge les plages d'ID d'élément. Par conséquent, si les modifications sont envoyées dans l'ordre des ID d'élément auxquels elles s'appliquent, la projection de la connaissance sera très efficace.
Quel que soit l'ordre, l'opération de projection peut toujours projeter la connaissance sur le lot envoyé.
Erreurs
Lorsque le fournisseur de source ne peut pas envoyer un élément énuméré, l'élément doit être exclu de la connaissance acquise envoyée. Pour ce faire, il convient d'utiliser l'opérateur d'exclusion.
Détection de conflit
La détection de conflit est gérée par les composants Sync Framework, tels que NotifyingChangeApplier (pour le code managé) ou ISynchronousNotifyingChangeApplier (pour le code non managé).
Une fois que le fournisseur de destination a reçu un lot de modifications qui contient les connaissances acquise et associée pour le lot, les déterminations suivantes doivent être effectuées pour chaque modification dans le lot :
Est-ce que cette modification est en conflit avec la version actuelle de l'élément stocké dans le réplica de destination ?
Est-ce que cette modification est obsolète (remplacée par la version actuelle de l'élément stocké dans le réplica de destination) ?
La réponse à ces questions est simple :
Une modification est en conflit avec la version actuelle lorsque la version de l'élément stocké dans le réplica de destination n'est pas contenue dans la connaissance du réplica source.
Une modification est obsolète lorsque sa version est contenue dans la connaissance du réplica de destination.
Notes
En règle générale, les modifications obsolètes ne sont pas envoyées. Toutefois, des conditions de concurrence peuvent entraîner l'envoi de ces modifications. Par conséquent, Sync Framework doit les détecter et les gérer.
Application des modifications
Une fois les modifications reçues et les conflits détectés, les modifications peuvent être appliquées au réplica de destination. À ce stade, le fournisseur de destination effectue les étapes suivantes :
Ajuste la connaissance acquise du lot de modifications pour les événements qui se sont produits localement :
Si un sous-ensemble de modifications uniquement a été appliqué en raison d'interruptions ou d'annulations, définit une erreur récupérable pour chaque modification qui n'a pas été appliquée. Sync Framework utilise l'opérateur de projection pour restreindre la connaissance acquise à cet ensemble uniquement.
Si l'application de certaines modifications a échoué en raison de problèmes de gestion des droits numériques (DRM), tels que des objets verrouillés, le fournisseur de destination définit une erreur récupérable pour chaque modification qui n'a pas été appliquée. Sync Framework utilise l'opérateur d'exclusion pour supprimer les modifications qui ont échoué de la connaissance acquise.
Si des conflits ont été détectés mais non résolus, Sync Framework utilise également l'opérateur d'exclusion pour les supprimer.
Remplace la connaissance du réplica de destination par la connaissance de destination mise à jour calculée par Sync Framework.