Konfliktbehandlung
Bei der Synchronisierung empfängt der Zielanbieter durch die ProcessChangeBatch-Methode (für verwalteten Code) oder die ProcessChangeBatch-Methode (für nicht verwalteten Code) einen Änderungsbatch vom Quellenanbieter. Anschließend muss der Zielanbieter Konflikte, die aufgrund dieser Liste auftreten, ermitteln und behandeln.
Konflikterkennung
Beim Synchronisieren können zwei Arten von Konflikten auftreten: Parallelitätskonflikte und Einschränkungskonflikte.
Parallelitätskonflikte
Parallelitätskonflikte treten auf, wenn die Version einer Änderung im Zielreplikat nicht im Wissen des Quellreplikats enthalten ist. Diese Konflikte treten auf, wenn Vorgänge wie Aktualisieren/Löschen und Aktualisieren/Aktualisieren dasselbe zu synchronisierende Element betreffen.
In der Regel verwendet der Zielanbieter ein von Sync Framework bereitgestelltes Änderungsanwenderobjekt, um Parallelitätskonflikte zu erkennen. Der Änderungsanwender wird vom NotifyingChangeApplier-Objekt (für verwalteten Code) oder von der ISynchronousNotifyingChangeApplier-Schnittstelle (für nicht verwalteten Code) dargestellt. Um Änderungen mit einem Änderungsanwender zu erkennen, muss der Zielanbieter für jedes Element des vom Quellenanbieter gesendeten Änderungsbatches Versionsinformationen bereitstellen. Hierfür gibt es die folgenden beiden Möglichkeiten:
Der Zielanbieter erstellt eine Liste mit Änderungen, die dem vom Quellenanbieter gesendeten Änderungsbatch entspricht. Für jedes Element im Änderungsbatch des Quellenanbieters fügt der Zielanbieter dieser Liste einen Eintrag mit der Version dieses Elements im Zielreplikat hinzu. Diese Liste wird an den Änderungsanwender übergeben. Der Änderungsanwender überprüft anhand der Liste, ob die Zielversion der einzelnen Elemente im Wissen des Quellreplikats enthalten ist.
Der Zielanbieter stellt dem Änderungsanwender keine Liste der Zielversionen zur Verfügung. Stattdessen implementiert der Zielanbieter die TryGetDestinationVersion-Methode (für verwalteten Code) oder die ISynchronousNotifyingChangeApplierTarget::GetDestinationVersion-Methode (für nicht verwalteten Code). Diese Methode wird für jedes Element im Änderungsbatch des Quellenanbieters einmal aufgerufen.
Um besser zu verstehen, wie der Änderungsanwender zum Erkennen eines Konflikts vorgeht, betrachten Sie das Szenario, in dem ein Zielanbieter einen Änderungsbatch von einem Quellenanbieter empfängt. Um Konflikte zu erkennen, werden für jedes Element im Änderungsbatch die folgenden Schritte ausgeführt:
Der Zielanbieter ermittelt, ob die Version des Elements im Zielreplikat im Wissen des Quellreplikats enthalten ist.
Wenn die Version im Zielreplikat nicht im Wissen des Quellreplikats enthalten ist, liegt ein Konflikt für das Objekt vor.
Einschränkungskonflikte
Einschränkungskonflikte sind Konflikte, bei denen Elementen auferlegte Einschränkungen (z. B. die Beziehung zwischen Ordnern oder der Speicherort identisch benannter Daten innerhalb eines Dateisystems) verletzt werden.
Da das Erkennen eines Einschränkungskonflikts vom Datenspeicher abhängig ist, den ein Replikat verwendet, müssen solche Konflikte vom Anbieter erkannt werden. Beispielsweise muss ein Anbieter, der ein hierarchisches Dateisystem darstellt, speicherspezifische Einschränkungen erkennen können, die persistenten Daten auferlegt werden, z. B. Speicherort, Benennung, Größe usw.
Konfliktauflösung
Konflikte können durch Definieren einer Richtlinie zur Konfliktauflösung, die für alle Konflikte einer Sitzung gilt, oder durch Behandeln eines Ereignisses, das für jeden Konflikt einmal auftritt, gelöst werden.
Festlegen einer Richtlinie zur Konfliktauflösung
Um eine Richtlinie festzulegen, die bei allen Konflikten einer Sitzung angewendet wird, gibt eine Anwendung in der ConflictResolutionPolicy-Eigenschaft (für verwalteten Code) oder in der ISyncSession::Start--Methode (für nicht verwalteten Code) des Zielanbieters eine Richtlinie zur Konfliktlösung an.
Festlegen einer Konfliktauflösungsaktion
Um die Konfliktauflösungsaktion für jeden auftretenden Konflikt dynamisch festzulegen, behandelt die Anwendung das Elementkonfliktereignis mit ItemConflicting (für verwalteten Code) oder ISyncCallback::OnConflict (für nicht verwalteten Code). Das Ereignis wird nur ausgelöst, wenn die Richtlinie zur Konfliktauflösung auf ApplicationDefined (für verwalteten Code) oder CRP_NONE (für nicht verwalteten Code) festgelegt ist.
Verwalteter Code Wenn ItemConflicting ausgelöst wird, empfängt der Ereignishandler ein ItemConflictingEventArgs-Objekt, das die Metadaten und Elementdaten der beiden in Konflikt befindlichen Änderungen enthält. Der Ereignishandler kann die beiden Konflikte untersuchen, Änderungen an den Metadaten oder Elementdaten vornehmen und mit der SetResolutionAction-Methode die Aktion zum Auflösen des Konflikts festlegen. Anschließend verarbeitet Sync Framework den Konflikt und ruft die entsprechenden Methoden des Quellen- oder Zielanbieters zum Übernehmen von Änderungen auf.
Nicht verwalteter Code Wenn ISyncCallback::OnConflict ausgelöst wird, empfängt der Ereignishandler ein IChangeConflict-Objekt, das die Metadaten und Elementdaten der beiden in Konflikt befindlichen Änderungen enthält. Der Ereignishandler kann die beiden Konflikte untersuchen, Änderungen an den Metadaten oder Elementdaten vornehmen und mit der IChangeConflict::SetResolveActionForChange-Methode die Aktion zum Auflösen des Konflikts festlegen. Anschließend verarbeitet Sync Framework den Konflikt und ruft die entsprechenden Methoden des Quellen- oder Zielanbieters zum Übernehmen von Änderungen auf.
Konfliktauflösungen
Sync Framework stellt die folgenden Konfliktauflösungsaktionen bereit und übernimmt den Großteil der Verarbeitung für diese Aktionen. Andere Konfliktauflösungen können durchgeführt werden, indem Sie die widersprüchlichen Änderungen direkt im Elementkonflikt-Ereignishandler bearbeiten.
| Konfliktauflösung | Beschreibung | Als Sitzungsrichtlinie oder Elementaktion verfügbar? |
|---|---|---|
Quelle gewinnt |
Das Quellreplikat gewinnt immer. Hierdurch wird eine schreibgeschützte Synchronisierungslösung ermöglicht, in der das Zielreplikat als nicht vertrauenswürdig gilt. Der Änderungsanwender übergibt die Änderung an die SaveItemChange-Methode (für verwalteten Code) oder die ISynchronousNotifyingChangeApplierTarget::SaveChange-Methode (für nicht verwalteten Code). Die Änderung wird genau wie eine keinen Konflikt verursachende Änderung in das Zielreplikat übernommen. |
Beides |
Ziel gewinnt |
Das Zielreplikat gewinnt immer. Hierdurch wird ermöglicht, dass das Zielreplikat keine Änderungen verarbeitet, die von Remoteclients vorgenommen werden. Der Änderungsanwender übergibt die widersprüchliche Änderung als reine Versionsänderung an die SaveItemChange-Methode (für verwalteten Code) oder die ISynchronousNotifyingChangeApplierTarget::SaveChange-Methode (für nicht verwalteten Code). Im Zielreplikat werden nur Versionsinformationen in die Metadaten übernommen. |
Beides |
Zusammenführen |
Die Informationen beider Elemente werden zusammengeführt. Der Änderungsanwender übergibt die widersprüchliche Änderung als Zusammenführungsänderung an die SaveItemChange-Methode (für verwalteten Code) oder die ISynchronousNotifyingChangeApplierTarget::SaveChange-Methode (für nicht verwalteten Code). Die Daten des Quellelements und des Zielelements werden zusammengeführt, und das Ergebnis wird in das Zielreplikat übernommen. |
Nur Elementaktion |
Protokollieren |
Der Konflikt wird zur späteren Behandlung protokolliert, und die Änderung wird nicht übernommen. Der Änderungsanwender übergibt die widersprüchliche Änderung an die SaveConflict-Methode (für verwalteten Code) oder die ISynchronousNotifyingChangeApplierTarget::SaveConflict-Methode (für nicht verwalteten Code). |
Nur Elementaktion |
Zurückstellen |
Der Konflikt wird ignoriert, und die Änderung wird nicht übernommen. Der Änderungsanwender übergibt die widersprüchliche Änderung nicht an den Zielanbieter. |
Nur Elementaktion |
Gespeicherte Konflikte
Beim Protokollieren eines Konflikts wird statt der SaveItemChange-Methode (für verwalteten Code) bzw. der SaveChange-Methode (für nicht verwalteten Code) die SaveConflict-Methode (für verwalteten Code) bzw. die SaveConflict-Methode (für nicht verwalteten Code) aufgerufen. In diesem Fall muss der Anbieter das Konfliktwissen, die widersprüchliche Änderung und die Konfliktdaten speichern. Anschließend kann eine Anwendung diese Konflikte aus dem Konfliktprotokoll auflisten und später auflösen. Beachten Sie, dass diese Art der Konfliktauflösung immer eine lokale Änderung ist. Daher muss die die Konflikte auflösende Anwendung die Lösung als lokale Änderung übernehmen, die Taktanzahl aktualisieren und dem lokalen Wissen das Konfliktwissen hinzufügen.
Außerdem muss eine Anwendung, die gespeicherte Konflikte löst, veraltete Konflikte behandeln. Insbesondere beim Protokollieren eines neuen Konflikts durch einen Anbieter muss dieser anhand des Anwendungswissens überprüft werden, um sicherzustellen, dass der zu protokollierende Konflikt vor allen bereits protokollierten Konflikten für dieses Element Vorrang hat. Außerdem müssen veraltete Konflikte im Protokoll bereinigt werden. Eine Anwendung kann veraltete Konflikte nicht nur im Anbieter, sondern auch asynchron bereinigen. In diesem Fall muss die Anwendung vor dem Lösen eines Konflikts überprüfen, ob der Konflikt nicht veraltet ist.
Weniger Konflikte mithilfe von Änderungseinheiten
Die Anzahl an Konflikten kann reduziert werden, indem Sie Änderungen an Unterelementen mithilfe von Änderungseinheiten darstellen. Beim Verwenden von Änderungseinheiten werden Versionen nicht für das Element als Ganzes nachverfolgt, sondern für Änderungseinheiten. Daher führen Änderungen, die an verschiedenen Änderungseinheiten innerhalb desselben Elements vorgenommen werden, nicht zu einem Konflikt. Weitere Informationen finden Sie unter Synchronisieren von Änderungseinheiten.
Siehe auch
Verweis
ISyncKnowledge-Schnittstelle
ISyncProvider-Schnittstelle
IKnowledgeSyncProvider-Schnittstelle
IKnowledgeSyncProvider::ProcessChangeBatch
ISynchronousNotifyingChangeApplierTarget-Schnittstelle
IAsynchronousNotifyingChangeApplierTarget-Schnittstelle
ISyncCallback::OnConflict
CONFLICT_RESOLUTION_POLICY-Enumeration
SYNC_RESOLVE_ACTION-Enumeration
SyncKnowledge
KnowledgeSyncProvider
INotifyingChangeApplierTarget
ItemConflicting
ConflictResolutionPolicy
ConflictResolutionAction
Konzepte
Synchronisierungsanbieter
Anwenden von Änderungen
Synchronisierungswissen