Verwalten von Tombstones

Artikel
09/18/2009

Tombstones stellen Elemente dar, die aus einem Replikat gelöscht wurden. Hauptsächlich verhindern Tombstones die Wiedereinführung von gelöschten Elementen in einem Replikat. Um potenzielle Leistungs- oder Speicherprobleme zu vermeiden, müssen Tombstones in regelmäßigen Abständen bereinigt werden. Bei dieser Bereinigung sollte sorgfältig vorgegangen werden, um die Wiedereinführung gelöschter Elemente zu vermeiden.

Darstellen von Tombstones

Ein Replikat kann gelöschte Elemente mit einer beliebigen Methode nachverfolgen. Für diese Aufgabe wird empfohlen, ein Tombstonebit oder ein Tombstoneprotokoll für das Replikat zu verwenden.

Tombstonebit

Ein Replikat definiert, dass die Metadaten eines Elements einen booleschen Wert enthalten, der angibt, ob das Element aus dem Elementspeicher gelöscht wurde. Beim Löschen eines Elements wird dieser Wert im Metadateneintrag des Elements auf TRUE festgelegt. Die Verwendung eines Tombstonebits ist für Speicher effizient, in denen viele gelöschte Elemente nachverfolgt werden müssen, da je Element nur ein zusätzliches Bit erforderlich ist. Diese Methode eignet sich weniger zum Auflisten oder Bereinigen von Tombstones, da der gesamte Metadatenspeicher durchsucht werden muss.

Tombstoneprotokoll

Ein Replikat verwaltet ein separates Protokoll, in dem Elemente aufgeführt werden, die aus dem Elementspeicher gelöscht wurden. Beim Löschen eines Elements wird dem Tombstoneprotokoll ein Eintrag hinzugefügt. Die Verwendung eines Tombstoneprotokolls ist für Speicher ineffizient, in denen viele gelöschte Elemente nachverfolgt werden müssen, da das Protokoll für jedes gelöschte Element eine ID enthalten muss. Diese Methode eignet sich zum Auflisten oder Bereinigen von Tombstones, da die Liste nur gelöschte Elemente enthält.

Tombstonebereinigung

Jedem Replikat einer Synchronisierungscommunity ist nur der eigene Status bekannt, nicht jedoch der Status anderer Replikate. Daher kann unmöglich ermittelt werden, ob ein Tombstone in der gesamten Community repliziert wurde. Aus diesem Grund kann für ein bestimmtes Replikat ausschließlich lokal entschieden werden, wann und wie Tombstones bereinigt werden. Beispielsweise könnten Tombstones abhängig vom lokalen Zeitstempel oder von Speicherplatzanforderungen bereinigt werden. Ein Replikat könnte über die Richtlinie verfügen, dass Tombstones höchstens 10 % des Datasets belegen dürfen.

Nach der Bereinigung eines Tombstones ist der Löschvorgang dem Replikat nicht bekannt. Das Replikat muss jedoch weiterhin verhindern, dass das Element im eigenen Speicher oder einem anderen Replikat wiedereingeführt wird. Um dieses Problem zu vermeiden, werden die Erstellungsversionen der einzelnen Elemente und das vergessene Wissen des Replikats im Metadatenspeicher des Replikats gespeichert. Wenn ein Replikat einen Tombstone bereinigt, muss es die Tombstoneversion in seinem vergessenen Wissen aufzeichnen.

Aufzeichnen von bereinigten Tombstones mithilfe von verwaltetem Code

Um aufzuzeichnen, dass die Metadaten für ein gelöschtes Element vom Metadatenspeicher des Replikats entfernt wurden, müssen Sie ForgetTo auf dem ForgottenKnowledge-Objekt des Replikats aufrufen. Für diese Methode ist die Version des gelöschten Elements erforderlich.

Aufzeichnen von bereinigten Tombstones mithilfe von nicht verwaltetem Code

Um aufzuzeichnen, dass die Metadaten für ein gelöschtes Element vom Metadatenspeicher des Replikats entfernt wurden, müssen Sie IForgottenKnowledge::ForgetToVersion auf dem IForgottenKnowledge-Objekt des Replikats aufrufen. Für diese Methode ist die Version des gelöschten Elements erforderlich.

Bereitstellen von vergessenem Wissen für Sync Framework

Wenn ein Replikat bereinigte Tombstones mithilfe von vergessenem Wissen nachverfolgt, muss der mit ihm verknüpfte Anbieter das vergessene Wissen für die Sync Framework-Methoden bereitstellen, die dieses Wissen erfordern, beispielsweise ChangeBatch (für verwalteten Code) oder IProviderSyncServices::CreateChangeBatch (für nicht verwalteten Code). Der Anbieter muss außerdem während der Synchronisierung auch das vergessene Wissen zusammen mit dem aktualisierten Wissen speichern, beispielsweise in der StoreKnowledgeForScope-Methode (für verwalteten Code) oder in der ISynchronousNotifyingChangeApplierTarget::SaveKnowledge-Methode (für nicht verwalteten Code).

Wenn ein Replikat Tombstones nicht bereinigt und vergessenes Wissen nicht beibehält, muss der mit ihm verknüpfte Anbieter null (für verwalteten Code) oder NULL (für nicht verwalteten Code) an die Sync Framework-Methoden übergeben, die über einen Parameter für vergessenes Wissen verfügen.

Tombstonebezogene Szenarien

Es gibt zwei tombstonebezogene Szenarien, die zu beachten sind: ein veraltetes Replikat, das eine Synchronisierung anfordert, und ein Replikat, das eine Aktualisierung für ein gelöschtes Element sendet. Beide Szenarien werden von Sync Framework erkannt.

Erkennen eines veralteten Replikats

In diesem Szenario ist das Zielreplikat in Bezug auf das Quellreplikat veraltet. Da die Tombstones im Quellreplikat bereinigt wurden, gibt es gelöschte Elemente, die nicht mehr im Quellreplikat bekannt sind. Der Quellenanbieter kann daher keine Änderungen senden, die diese Löschvorgänge für den Zielanbieter darstellen. Vor dem Übernehmen von Änderungen vergleicht Sync Framework das vergessene Wissen des Quellreplikats mit dem aktuellen Wissen des Zielreplikats. Wenn das vergessene Wissen nicht im Wissen des Zielreplikats enthalten ist, identifiziert Sync Framework das Zielreplikat als veraltet und startet eine Wiederherstellungssynchronisierung.

Wenn eine Anwendung über einen registrierten Ereignishandler verfügt, ermöglicht Sync Framework der Anwendung, die vollständige Auflistung fortzusetzen oder diese anzuhalten. In verwaltetem Code wird das FullEnumerationNeeded-Ereignis ausgelöst. In nicht verwaltetem Code empfängt die Anwendung den ISyncCallback::OnFullEnumerationNeeded-Rückruf.

Wenn die Anwendung nicht über einen registrierten Ereignishandler verfügt, wird die vollständige Auflistung automatisch ausgeführt. Bei einer vollständigen Enumeration kann Sync Framework Änderungen vom Quellanbieter mit den Elementen im Zielreplikat vergleichen und so feststellen, welche Elemente vom Zielreplikat gelöscht werden müssen. Alle Elemente im Zielreplikat, die nicht über eine entsprechende Änderung vom Quellenanbieter verfügen, werden vom Zielreplikat gelöscht.

Erkennen einer Aktualisierung eines gelöschten Elements

In diesem Szenario ist das Quellreplikat in Bezug auf das Zielreplikat veraltet. Dies ist der Fall, wenn das Quellreplikat nach der letzten Bereinigung der Tombstones im Zielreplikat nicht synchronisiert wurde. Ein Problem kann auftreten, wenn ein Element im Zielreplikat gelöscht und sein Tombstone anschließend vom Zielreplikat bereinigt wurde, dasselbe Element jedoch auf dem Quellreplikat aktualisiert wurde. Das Element ist im Änderungsbatch vorhanden, den der Quellenanbieter an den Zielanbieter sendet. Der Zielanbieter muss erkennen, dass dieses Element kein neues Element ist, da andernfalls das Element fälschlicherweise wieder in das Zielreplikat eingeführt wird.

Beachten Sie, dass die aktuelle Version eines Elements im Quellreplikat für einen Vergleich mit dem aktuellen Wissen des Zielreplikats nicht hilfreich ist, da die aktuelle Version des Elements, das wiedereingeführt werden würde, im aktuellen Wissen des Zielreplikats nicht enthalten ist. Stattdessen wird die Erstellungsversion des Elements aus dem Quellreplikat mit dem aktuellen Wissen des Zielreplikats verglichen, um festzustellen, ob das Element dem Zielreplikat bereits bekannt war. Da das Löschen des Elements nach dem Erstellen des Elements stattgefunden haben muss, und das aktuelle Wissen des Zielreplikats den Löschvorgang enthält, muss das aktuelle Wissen auch die Erstellung enthalten.

Bevor einem Zielreplikat ein neues Element hinzugefügt wird, vergleicht Sync Framework daher die Erstellungsversion des Elements mit dem aktuellen Wissen des Zielreplikats. Wenn das Zielwissen die Erstellungsversion des Elements enthält, war das Element bereits bekannt, wurde jedoch gelöscht und vergessen. Das Element wird als Aktualisierungs-/Löschkonflikt behandelt.

Share via