8 Synchronisation in Verteilten Datenbanksystemen
8.3 Optimistische Synchronisation
Optimistische Synchronisationsverfahren gehen von der Annahme aus, daß Konflikte zwischen Transaktionen seltene Ereignisse darstellen und somit das präventive Sperren der Objekte unnötigen Aufwand verursacht [KR81]. Daher greifen diese Verfahren zunächst nicht in den Ablauf einer Transaktion ein, sondern erlauben ein nahezu beliebig paralleles Arbeiten auf der Datenbank. Erst bei Transaktionsende wird überprüft, ob Konflikte mit anderen Transaktionen aufgetreten sind. Gemäß dieser Vorgehensweise unterteilt man die Ausführung einer Transaktion in drei Phasen:
- In der Lesephase wird die eigentliche Transaktionsverarbeitung vorgenommen, d.h., es werden Objekte der Datenbank gelesen und modifiziert. Jede Transaktion führt dabei ihre Änderungen auf Kopien in einem ihr zugeordneten Transaktions-Puffer durch, der für keine andere Transaktion zugänglich ist.
- Bei EOT wird eine Validierungsphase gestartet, in der geprüft wird, ob die beendigungswillige Transaktion mit einer parallel zu ihr laufenden Transaktion in Konflikt geraten ist. Im Gegensatz zu Sperrverfahren, bei denen Blockierungen das primäre Mittel zur Behandlung von Synchronisationskonflikten sind, werden hier Konflikte stets durch Zurücksetzen einer oder mehrerer beteiligter Transaktionen aufgelöst. Es ist so zwar mit mehr Rücksetzungen als bei Sperrverfahren zu rechnen, dafür können aber bei optimistischen Verfahren keine Deadlocks entstehen. Dies ist vor allem für Verteilte DBS ein potentieller Vorteil.
- Die Schreibphase wird nur von Änderungstransaktionen ausgeführt, die die Validierungsphase erfolgreich beenden konnten. In dieser Phase wird zuerst die Wiederholbarkeit der Transaktion sichergestellt (Logging), bevor alle Änderungen durch Einbringen in die Datenbank für andere Transaktionen sichtbar gemacht werden.
Abb. 8-3 veranschaulicht die Verwendung von privaten Transaktions-Puffern sowie dem DB-Puffer (Systempuffer), der für alle Transaktionen zugänglich ist. Für Lesezugriffe ist zunächst zu überprüfen, ob das entsprechende Objekt (aufgrund einer vorherigen Änderung) im privaten Transaktions-Puffer vorliegt. Ist dies nicht der Fall, erfolgt der Zugriff zum DB-Puffer; liegt die betreffende Seite auch dort nicht vor, ist sie vom Externspeicher einzulesen. In der Schreibphase werden die Änderungen vom Transaktions-Puffer in den DB-Puffer gebracht, womit sie allen Transaktionen zugänglich werden.
Abb. 8-3: Pufferorganisation bei optimistischer Synchronisation
- 8.3.1 - Validierungsansätze
-
- 8.3.2 - Zentrale Validierung
-
- 8.3.3 - Verteilte Validierung
-