Synchronisierungswissen
In diesem Thema wird abstrakt erläutert, wie Sync Framework-Synchronisierungsalgorithmen Wissen verwenden, um Änderungsenumeration und Konflikterkennung zu ermöglichen. Als Wissen werden die Metadaten bezeichnet, mit denen alle an einem Replikat vorgenommenen Änderungen beschrieben werden, entweder direkt oder durch Synchronisierung. Die Änderungsenumeration ist der Prozess, bei dem die Elemente ermittelt werden, die im Quellreplikat geändert wurden und dem Zielreplikat nicht bekannt sind. Die Konflikterkennung ist der Prozess, bei dem ermittelt wird, welche Vorgänge von einem Replikat durchgeführt wurden, ohne das Wissen über die Änderung an das andere Replikat zu übertragen, z. B. wenn zwei Replikate lokale Aktualisierungen des gleichen Elements vornehmen.
Hinweis
Im Allgemeinen wird Wissen von Synchronisierungsanbietern und -anwendungen nicht direkt verwendet. Stattdessen werden Sync Framework-Methoden aufgerufen, die wiederum Wissensvorgänge aufrufen.
Wissensvorgänge
In der folgenden Tabelle werden die Wissensvorgänge bei der Synchronisierung aufgelistet und erläutert.
| Operator | Beschreibung |
|---|---|
Contains |
Bestimmt, ob ein angegebenes Wissensobjekt die angegebene Version eines Elements enthält. (Die Version ist ein Replikatschlüssel und eine Taktanzahl.) In anderen Worten wird bestimmt, ob das Replikat, das dieses Wissen besitzt, diese Änderung übernommen hat. Die Element-ID und die Version sind erforderliche Eingaben für diesen Vorgang. Dieser Vorgang wird bei der Änderungsenumeration und Konflikterkennung verwendet. |
Union |
Erstellt aus zwei Wissenobjekten ein neues Wissenobjekt, das genau den gleichen Satz an Änderungen enthält wie mindestens eines der beiden ursprünglichen Wissenobjekte. Dieser Vorgang wird während der Übernahme von Änderungen verwendet. |
Project |
Generiert mit einem angegebenen Wissenobjekt und einer Element-ID, Änderungseinheit-ID oder einem Bereich von Element-IDs ein neues Wissenobjekt, das für die angegebene ID bzw. den Bereich von IDs die gleichen Änderungen wie das Original und für den Rest der Elemente nichts enthält. Dieser Vorgang wird verwendet, wenn Wissen auf bestimmte Elemente, Änderungseinheiten oder Bereiche von Elementen beschränkt sein muss, z. B. bei einer unterbrochenen Synchronisierung, Batchverarbeitung und bei einigen erweiterten Formen gefilterter Synchronisierung. |
Exclude |
Generiert mit einem angegebenen Wissenobjekt und einer Element-ID oder Änderungseinheit-ID ein neues Wissenobjekt, das für die angegebene ID nichts und für den Rest der Elemente die gleichen Änderungen wie das Original enthält. Dieser Vorgang ist das Gegenteil des Projektionsvorgangs: Bei einem Ausschlussvorgang wird das Wissen auf alles bis auf das angegebene Element projiziert. Dieser Vorgang wird normalerweise bei Fehlern während der Übernahme von Änderungen verwendet. |
Änderungsenumeration
Die Änderungsenumeration wird durch den Entwickler des Quellenanbieters implementiert. Unter Verwendung der angegebenen Wissensvorgänge läuft die Enumeration wie folgt ab:
Der Zielanbieter sendet das aktuelle Wissen des Zielreplikats an den Quellenanbieter.
Der Quellenanbieter durchläuft alle Elemente im Quellreplikat und führt für jedes Element die folgenden Schritte durch:
Ermittelt, ob das Zielwissen die im Quellreplikat gespeicherte Elementversion enthält.
Ist dies nicht der Fall, wird das Element in den Änderungsbatch einbezogen, der an den Zielanbieter gesendet wird.
Hinweis
Die Änderungsenumeration kann auch mit einer direkten Abfrage des Elementspeichers oder einer Kombination aus einer Abfrage und diesem Algorithmus behandelt werden, wenn dies vom Elementspeicher unterstützt wird.
Senden von Änderungen
Aufgelistete Änderungen müssen vom Quellenanbieter an den Zielanbieter gesendet werden. Hierzu werden Änderungen in Batches aufgeteilt, und für jeden Batch werden die folgenden Informationen gesendet:
Metadaten zur Beschreibung der eigentlichen Änderungen. Der Anbieter fügt dem Batch für jede Änderung im Batch Metadaten hinzu.
Das bei der Konflikterkennung zu verwendende Anwendungswissen, das in der Regel dem aktuellen Wissen des Quellreplikats entspricht. Das Anwendungswissen enthält Informationen über den Wissensstand zum Zeitpunkt der Änderungen. Der Anbieter fügt für jede Gruppe von Änderungen, die dem Batch hinzugefügt wird, Anwendungswissen zum Batch hinzu.
Das erlangte Wissen. Hierbei handelt es sich um das aktuelle Wissen des Quellreplikats, projiziert auf die Teilmenge der Elemente, die in diesem Batch gesendet werden, sowie die protokollierten Konflikte. Das erlangte Wissen enthält Informationen über das Wissen, das bei Übernahme dieser Änderungen hinzugefügt wird. Sync Framework berechnet das erlangte Wissen im Auftrag des Anbieters.
Hinweis
Batchverarbeitung und Änderungsenumeration können parallel verarbeitet werden, da für die Batchverarbeitung nicht auf den Abschluss der Änderungsenumeration gewartet werden muss.
Reihenfolge
Je nach der Reihenfolge, in der die Änderungen gesendet werden, variiert die benötigte Zeit für das Projizieren des Wissens auf die Elemente im Batch. Beispielsweise werden vom Wissen Element-ID-Bereiche unterstützt. Wenn daher Änderungen in der Reihenfolge der Element-IDs gesendet werden, auf die sie sich beziehen, ist die Wissensprojektion sehr effizient.
Unabhängig von der Reihenfolge kann mit dem Projektionsvorgang stets Wissen auf den zu sendenden Batch projiziert werden.
Fehler
Wenn der Quellenanbieter ein aufgelistetes Element nicht senden kann, muss das Element aus dem erlangten Wissen, das gesendet wird, ausgeschlossen werden. Dies wird mithilfe des Exclude-Operators erreicht.
Konflikterkennung
Die Konflikterkennung wird durch Sync Framework-Komponenten behandelt, wie z. B. NotifyingChangeApplier (für verwalteten Code) bzw. ISynchronousNotifyingChangeApplier (für nicht verwalteten Code).
Nachdem ein Änderungsbatch vom Zielanbieter empfangen wurde, der das erlangte Wissen und Anwendungswissen für den Batch enthält, muss für jede Änderung im Batch Folgendes ermittelt werden:
Steht diese Änderung in Konflikt mit der aktuellen Version des im Zielreplikat gespeicherten Elements?
Ist diese Änderung veraltet (ersetzt durch die aktuelle Version des im Zielreplikat gespeicherten Elements)?
Diese Fragen werden direkt beantwortet:
Eine Änderung steht in Konflikt mit der aktuellen Version, wenn die Version des im Zielreplikat gespeicherten Elements nicht im Wissen des Quellreplikats enthalten ist.
Eine Änderung ist veraltet, wenn die Version im Wissen des Zielreplikats enthalten ist.
Hinweis
Unter normalen Umständen werden veraltete Änderungen nicht gesendet. Racebedingungen können jedoch dazu führen, dass solche Änderungen gesendet werden. Daher müssen diese von Sync Framework erkannt und behandelt werden.
Übernehmen von Änderungen
Nachdem die Änderungen empfangen und Konflikte erkannt wurden, können die Änderungen vom Zielreplikat übernommen werden. An diesem Punkt führt der Zielanbieter die folgenden Schritte aus:
Das erlangte Wissen des Änderungsbatches wird hinsichtlich lokaler Vorgänge angepasst:
Wenn aufgrund von Unterbrechungen oder Abbrüchen nur eine Teilmenge der Änderungen übernommen wurde, wird für jede nicht übernommene Änderung ein behebbarer Fehler festgelegt. Sync Framework verwendet den Project-Operator, um erlangtes Wissen ausschließlich auf diesen Satz zu beschränken.
Wenn die Übernahme einiger Änderungen aufgrund von Problemen mit der Verwaltung digitaler Rechte (Digital Rights Management, DRM) fehlgeschlagen ist, z. B. aufgrund gesperrter Objekte, legt der Zielanbieter einen behebbaren Fehler für jede nicht übernommene Änderung fest. Sync Framework verwendet den Exclude-Operator, um die fehlgeschlagenen Änderungen aus dem erlangten Wissen zu entfernen.
Wenn Konflikte erkannt und nicht gelöst wurden, werden diese ebenfalls mit dem Exclude-Operator von Sync Framework entfernt.
Das Wissen des Zielreplikats wird durch das von Sync Framework berechnete aktualisierte Zielwissen ersetzt.
Siehe auch
Konzepte
Auflisten von Änderungen
Konfliktbehandlung
Anwenden von Änderungen