Gestion d'objets tombstone

Article
09/18/2009

Les objets tombstone représentent des éléments supprimés d'un réplica. À l'origine, les objets tombstone permettent d'empêcher de réintroduire des éléments supprimés dans un réplica. Pour éviter d'éventuels problèmes au niveau des performances ou du stockage, les objets tombstone doivent régulièrement être nettoyés. Ce nettoyage doit être géré avec soin pour éviter de réintroduire des éléments supprimés.

Représentation d'objets tombstone

Un réplica peut utiliser toute méthode pour effectuer le suivi des éléments supprimés. Pour effectuer cette tâche, nous recommandons qu'un réplica utilise un bit tombstone ou un journal tombstone.

Bit tombstone

Un réplica définit que les métadonnées pour un élément contiennent une valeur booléenne qui indique si l'élément a été supprimé du magasin d'éléments. Lorsqu'un élément est supprimé, cette valeur est True dans l'entrée de métadonnées pour cet élément. L'utilisation d'un bit tombstone est efficace pour le stockage si de nombreux éléments supprimés doivent faire l'objet d'un suivi, car seul un bit supplémentaire est requis par élément. Cette méthode est moins efficace pour énumérer ou nettoyer des objets tombstone, car les recherches doivent porter sur l'intégralité de la banque des métadonnées.

Journal tombstone

Un réplica gère un journal séparé qui répertorie les éléments supprimés du magasin d'éléments. Lorsqu'un élément est supprimé, une entrée est ajoutée au journal tombstone. L'utilisation d'un journal tombstone est inefficace pour le stockage si de nombreux éléments supprimés doivent faire l'objet d'un suivi, car le journal doit contenir un ID pour chaque élément supprimé. Cette méthode est efficace pour énumérer ou nettoyer des objets tombstone, car la liste contient uniquement des éléments supprimés.

Nettoyage des objets tombstone

Chaque réplica dans une communauté de synchronisation contient une connaissance sur son propre état uniquement et non sur l'état de tout autre réplica. Par conséquent, il est impossible de déterminer le moment où un objet tombstone a été répliqué dans la communauté. Par conséquent, pour tout réplica particulier, l'identification du moment et du mode de nettoyage des objets tombstone est une décision complètement locale. Par exemple, les objets tombstone peuvent être nettoyés selon l'horodateur local ou l'espace requis. Un réplica peut avoir une stratégie qui stipule que les objets tombstone ne peuvent pas occuper plus de 10 pour cent du jeu de données.

Lorsqu'un objet tombstone est nettoyé, un réplica ignore la suppression, mais doit encore empêcher l'élément d'être réintroduit dans son propre magasin ou sur un autre réplica. Pour éviter ce problème, la version de création de chaque élément et la connaissance oubliée du réplica sont conservées dans la banque des métadonnées pour le réplica. Lorsqu'un réplica nettoie un objet tombstone, il doit enregistrer la version de l'objet tombstone dans sa connaissance oubliée.

Enregistrement des objets tombstone nettoyés à l'aide de code managé

Pour enregistrer que les métadonnées d'un élément supprimé ont été retirées de la banque des métadonnées d'un réplica, appelez ForgetTo sur l'objet ForgottenKnowledge du réplica. Cette méthode requiert la version de l'élément supprimé.

Enregistrement des objets tombstone nettoyés à l'aide de code non managé

Pour enregistrer que les métadonnées d'un élément supprimé ont été retirées de la banque des métadonnées d'un réplica, appelez IForgottenKnowledge::ForgetToVersion sur l'objet IForgottenKnowledge du réplica. Cette méthode requiert la version de l'élément supprimé.

Transmission de la connaissance oubliée à Sync Framework

Si un réplica effectue le suivi d'objets tombstone nettoyés en utilisant une connaissance oubliée, son fournisseur associé doit transmettre la connaissance oubliée aux méthodes Sync Framework qui la requièrent, telles que ChangeBatch (pour le code managé) ou IProviderSyncServices::CreateChangeBatch (pour le code non managé). Le fournisseur doit également enregistrer la connaissance oubliée avec la connaissance mise à jour au cours de la synchronisation, par exemple dans sa méthode StoreKnowledgeForScope (pour le code managé) ou ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (pour le code non managé).

Si un réplica ne nettoie pas les objets tombstone et ne conserve pas la connaissance oubliée, son fournisseur associé doit transmettre null (pour le code managé) ou NULL (pour le code non managé) aux méthodes Sync Framework qui disposent d'un paramètre de connaissance oubliée.

Scénarios relatifs aux objets tombstone

Deux scénarios relatifs aux objets tombstone à prendre en compte sont un réplica obsolète qui demande une synchronisation et un réplica qui envoie une mise à jour à un élément supprimé. Sync Framework détecte ces deux scénarios.

Détection d'un réplica obsolète

Dans ce scénario, le réplica de destination est obsolète par rapport au réplica source. Étant donné que le réplica source a nettoyé ses objets tombstone, il existe des suppressions qu'il ignore. Par conséquent, le fournisseur de source ne peut pas envoyer les modifications qui représentent ces suppressions au fournisseur de destination. Avant que les modifications ne soient appliquées, Sync Framework compare la connaissance oubliée du réplica source à la connaissance actuelle du réplica de destination. Si le réplica de destination ne contient pas la connaissance oubliée, Sync Framework identifie le réplica de destination comme étant obsolète et commence une synchronisation de récupération.

Si une application a inscrit un gestionnaire d'événements, Sync Framework donne la possibilité à l'application de continuer ou d'arrêter l'énumération complète. En code managé, l'événement FullEnumerationNeeded est déclenché. En code non managé, l'application reçoit un rappel ISyncCallback::OnFullEnumerationNeeded.

Si l'application n'a pas inscrit de gestionnaire d'événements, l'énumération complète se produit automatiquement. Une énumération complète permet à Sync Framework de comparer les modifications du fournisseur de source aux éléments du réplica de destination et de déterminer ainsi les éléments qui doivent être supprimés du réplica de destination. Tout élément du réplica de destination qui n'a pas de modification correspondante du fournisseur de source est supprimé du réplica de destination.

Détection d'une mise à jour sur un élément supprimé

Dans ce scénario, le réplica source est obsolète par rapport au réplica de destination. Cela se produit lorsque le réplica source n'a pas été synchronisé depuis la dernière fois que le réplica de destination a nettoyé ses objets tombstone. Un problème peut se produire lorsqu'un élément a été supprimé sur le réplica de destination, que son objet tombstone a été par la suite nettoyé sur le réplica de destination et que ce même élément a été mis à jour sur le réplica source. L'élément apparaît dans le lot de modifications que le fournisseur de source envoie au fournisseur de destination. Le fournisseur de destination doit reconnaître que cet élément n'est pas un nouvel élément ; sinon, l'élément sera réintroduit de façon incorrecte dans le réplica de destination.

Gardez à l'esprit qu'il est inutile de comparer la version actuelle pour un élément du réplica source avec la connaissance actuelle du réplica de destination, car la version actuelle de l'élément qui serait réintroduit n'est pas contenue dans la connaissance actuelle du réplica de destination. La version de création de l'élément du réplica source est plutôt comparée à la connaissance actuelle du réplica de destination pour déterminer si l'élément était précédemment connu du réplica de destination. Dans la mesure où la suppression de l'élément doit être intervenue après la création de l'élément et où la connaissance actuelle du réplica de destination contient la suppression, la connaissance actuelle doit également contenir la création.

Par conséquent, avant d'ajouter un nouvel élément à un réplica de destination, Sync Framework compare la version de création de l'élément à la connaissance actuelle du réplica de destination. Si la connaissance de destination contient la version de création de l'élément, l'élément était précédemment connu, mais a été supprimé et oublié. L'élément est traité comme un conflit de mise à jour/suppression.

Partager via