Hallo, in diesem Video geht es um die optimistische Synchronisation. Bei der optimistischen Synchronisation werden Zeitstempel verwendet, um Konflikte zwischen Transaktionen aufzulesen, wenn das Commit durchgeführt werden soll.

Die Grundidee ist eine rückgewärtsorientierte Validierung. Das heißt, es wird am Ende der Transaktion geprüft, ob ein Konflikt zu bereits abgeschlossenen Transaktionen auftritt. Wenn ein Konflikt auftritt, erfolgt ein Rollback. Wenn kein Konflikt auftritt, dann kann das Ergebnis der Transaktion geschrieben werden.

Das heißt, es folgt nach der Verdelierphase eine Schreibphase. Damit sind keine Sperren erforderlich zur Synchronisation der Transaktion. Und die Verarbeitung der Transaktion erfolgt erst nach dem Commit-Zeitpunkt. Allerdings ist es beim Ende der Transaktion noch nicht sicher,

ob die Transaktion auch geschrieben werden kann. Zudem ist nicht ausgeschlossen, dass auch ein kaskadierendes, zurücksetzten Weitereintransaktion erforderlich ist, um wieder einen konsistenten Zustand herzustellen. Optimistische Synchronisationsverfahren werden beispielsweise von Oracle eingesetzt

und einigen NoSQL-Datenbanken. Zum Erkennen von Änderungen werden entweder Zeitstempel genutzt oder eine Versionierung durchgeführt. Eine Implementierung ist das Multi-Version Concurrency Control-Protokoll.

Dabei wird eine Versionierung genutzt. Jedes Datenobjekt erhält also eine Versionsnummer. Bei jeder Schreiboperation erhöht sich die Versionsnummer. Am Ende der Transaktion wird dann geprüft, ob alle Datenobjekte, die gelesen worden sind, noch in der ursprünglichen Version vorliegen.

Ist das nicht der Fall, dann wird die Transaktion abgebrochen und ein Rollback durchgenommen. Nehmen wir als Beispiel die Situation eines Dirty Reads. Dafür liest die Transaktion 1 das Objekt A mit der Version 1 und ändert dies und schreibt dieses Objekt.

Parallel liest die Transaktion 2 auch das Objekt in der Version 1 und schreibt auch, macht aber jetzt schon ein Commit. Bei der anschließenden Validierung wird geprüft, ob Änderungen auf dem Objekt A vorhanden sind. Berücksichtigt werden nur die Änderungsoperationen,

die auch durch ein Commit abgeschlossen sind. Das ist bei der Änderung der ersten Transaktion nicht der Fall. Damit hat sich die Versionsnummer des Objekts nicht geändert seit dem Lesenzugriff der Transaktion 2. Die Validierung kann somit erfolgreich durchgeführt werden und das geänderte Objekt erhält die Versionsnummer 2.

Wenn die Transaktion 1 jetzt ein Commit macht, dann schlägt die Validierung fehl, weil die Versionsnummer jetzt 2 ist und nicht mehr 1. Die Transaktion 1 muss abgebrochen werden. Dadurch wird die Dirty Read-Anomalie vermieden. Wenn stattdessen durch die Transaktion 1 zunächst das Commit durchgeführt wird,

dann kann die Änderung der ersten Transaktion erfolgreich validiert werden und die Änderung in die Version 2 überführt werden. In diesem Fall schlägt dann die zweite Transaktion fehl bei der Validierung und die zweite Transaktion muss abgebrochen werden.

Die optimistische Synchronisation kann mittels Zeitstempelverfahren oder Versionierungen durchgeführt werden. Dabei wird die Transaktion erst zum Commit-Zeitpunkt verarbeitet. Dabei erfolgt eine rückwärtsorientierte Validierung. Das heißt, es wird geprüft, ob Konflikte aufgetreten sind.

Wenn keine Konflikte aufgetreten sind, dann erfolgt eine Schreibphase und die Änderungen werden übernommen. Eine Implementierung ist das Multi-Version Concurrency Control-Protokoll. Dieses wird beispielsweise auch von Oracle oder auch von CouchDB eingesetzt.

Optimistische Synchronisationsverfahren haben den Vorteil, dass keine Sperren und Deadlocks gesetzt werden. Damit sind diese Verfahren auch gut geeignet für lang andauernde Transaktionen, beispielsweise im mobilen und im verteilten Umfeld.