14.6 Optimistische Synchronisation
14.6.1 Zentrale Validierung
Die zentrale Validierung kann für Shared-Disk praktisch genauso wie in Verteilten DBS realisiert werden (Kap. 8.3.2). Am Ende jeder Transaktion werden ihr Read- und Write-Set an den zentralen Validierungsknoten gesendet, der entscheidet, ob ein Konflikt mit anderen Transaktionen aufgetreten ist. Dabei ist nur eine BOCC-artige Validierung möglich, so daß im Konfliktfall die validierende Transaktion abzubrechen ist. Zur Synchronisation entstehen damit lediglich zwei Nachrichten pro Transaktion. Wie empirische Simulationsstudien gezeigt haben, ist der damit verbundene Kommunikationsaufwand meist deutlich geringer als mit (optimierten) globalen Sperrverfahren [Ra93d]. Der Validierungsaufwand pro Transaktion ist ebenfalls relativ gering, so daß selbst mit einem einzigen Validierungsrechner hohe Transaktionsraten möglich sind.
Um das mehrfache Scheitern derselben Transaktion zu verhindern, kann eine Kombination mit einem zentralen Sperrverfahren vorgenommen werden. Hierzu wird ausgenutzt, daß vor allem kürzere Transaktionen bei der wiederholten Ausführung mit hoher Wahrscheinlichkeit die gleichen Objekte wie bei der ersten Ausführung referenzieren. Die betreffenden Objekte sind im zentralen Rechner natürlich bekannt, da sie im Read-Set bzw. Write-Set der Transaktion vermerkt sind. Für die Neuausführung einer erfolglos validierten Transaktion erfolgt nun die Umstellung auf eine pessimistische Synchronisation. Dazu wird vor dem erneuten Start für jedes von der Transaktion gelesene bzw. geänderte Objekt eine Lese- bzw. Schreibsperre am zentralen Knoten gesetzt, was ohne zusätzliche Kommunikation möglich ist. Diese Sperren verhindern, daß andere Transaktionen die Objekte in unverträglicher Weise bearbeiten. Dazu wird eine erweiterte Validierung notwendig, welche die gesetzten Sperren berücksichtigt und bei unverträglichem Zugriff die validierende (optimistisch synchronisierte) Transaktion abbricht. Somit ist die erfolgreiche Bearbeitung der zweiten Transaktionsausführung garantiert, wenn keine zusätzlichen Objekte referenziert werden[62]. Ferner wird ein Verhungern von Transaktionen, wie ansonsten bei BOCC-artiger Synchronisation möglich (Kap. 8.3), verhindert.
Beispiel 14-6
- Abb. 14-9 zeigt die parallele Verarbeitung mehrerer Transaktionen in zwei Verarbeitungsrechnern sowie die zugehörigen Validierungen am zentralen Validierungsknoten (ZVK). Nach der erfolgreichen Validierung von T1 wird bei der Validierung von T2 ein Konflikt für Objekt x erkannt, so daß T2 erneut an Rechner 2 ausgeführt werden muß (Transaktion T2'). Bei rein optimistischer Synchronisation scheitert jedoch auch die zweite Ausführung T2', da eine Transaktion T3 zwischenzeitlich Objekt x erfolgreich ändern konnte. Bei Kombination mit einem Sperrverfahren dagegen wird am zentralen Rechner nach der erfolglosen Validierung von T2 eine Schreibsperre für x gesetzt. Dies führt dazu, daß die Validierung von T3 scheitert, während die zweite Ausführung T2' erfolgreich zu Ende kommt.
Abb. 14-9: Szenario zur zentralen Validierung
Die Sperren können nicht nur zur erfolglosen Validierung optimistisch synchronisierter Transaktionen führen, sondern auch zu Sperrkonflikten (Blockierungen) mit anderen Transaktionen, deren Validierung gescheitert ist. Deadlocks lassen sich jedoch umgehen, da sämtliche Sperren vor der erneuten Transaktionsausführung angefordert werden, ähnlich einem Preclaiming-Ansatz (Kap. 8.5.1). Die Wiederausführung einer Transaktion kommt auch meist mit geringerem E/A-Aufwand aus, da die benötigten Objekte vielfach noch aufgrund der ersten Ausführung im Hauptspeicher gepuffert sind.
[62] Für während der Wiederholung erstmals referenzierte Objekte ist entweder eine Validierung durchzuführen, oder es wird sicherheitshalber für sie eine Sperre am zentralen Rechner bereits während der Transaktionsausführung eingeholt.