3.1 Schedules und Histories

Transkript

1 3 Concurrency Control: Korrektheit Wir betrachten zunächst nur das Seitenmodell (read/write)! 3.1 Schedules und Histories Bislang: Transaktionen = (partiell) geordnete Folgen von (Daten-) Operationen... dem Scheduler (der Concurrency Control-Komponente) werden die Operationen der verschiedenen Transaktionen dynamisch übergeben, das Ende der Transaktionen wird durch Terminierungsoperationen angezeigt: Commit c: erfolgreiches Ende einer Transaktion, alle vorgenommenen Änderungen sollen dauerhaft wirksam werden, Abort a: Abbruch einer Transaktion vor Erreichen des erfolgreichen Endes, alle Änderungen müssen ggf. zurückgenommen werden. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-1

2 Dynamische Sicht auf Transaktionen Im normalen Betriebsablauf ist das Ende vieler (laufender) Transaktionen noch offen, erst im Rückblick ist klar, welche TXs committed und welche schließlich aborted wurden. Der Scheduler muss aber beim jeweiligen Aufruf einer Datenoperation Entscheidungen fällen. Wir unterscheiden fortan: History (vollständiger Schedule): alle Transaktionen sind mit einer Terminierungsoperation abgeschlossen, Schedule (dynamischer Schedule): Präfix einer History, einige (oder gar alle) Transaktionen sind noch ohne Terminierungsoperation aktiv. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-2

3 Scheduling von Transaktionen Transaction Manager (TM) Data Manager (DM) Requests Client 1 Client 2 Client Layer 5 Layer 4 Layer 3 Layer 2 Layer 1 Clients Data Server Database c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-3

4 Formal: Definition 3-1: (Schedule, History) Sei T = {t 1,..., t n } eine (endliche) Menge von Transaktionen, wobei jedes t i T die Form t i = (op i, < i ) hat. Dabei ist op i die Operationenmenge von t i und < i die auf ihnen definierte (partielle) Ordnung, 1 i n. 1. Eine History (vollständiger Schedule) für T ist ein Paar s = (op(s), < s ) mit (a) op(s) n i=1 op i n i=1 {a i, c i }, d.h. s enthält die Operationen der gegebenen Transaktionen sowie Terminationsoperationen c i (commit) oder a i (abort) für jedes t i T. (b) ( i, 1 i n) c i op(s) a i op(s) (c) < s n i=1 < i (d) ( i, 1 i n)( p op i ) p < s a i oder p < s c i (e) jedes Paar von Operationen p, q op(s) aus verschiedenen Transaktionen, das auf dasselbe Datenobjekt zugreift, so dass mindestens eine Schreiboperation darunter ist, ist geordnet in s, also entweder p < s q oder q < s p. 2. Ein Schedule ist ein Präfix einer History. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-4

5 Erläuterungen Eine History enthält alle Operationen aller Transaktionen (1a), beinhaltet genau eine der beiden Terminationsoperationen für jede TX (1b), erhält die Reihenfolgen unter den (geordneten) Schritten einer Transaktion (1c), enthält nach einem Terminierungsschritt keine weiteren Schritte der betroffenen TX (1d), ordnet im Konflikt stehende Operationen (1e). Der zuletzt genannte Konfliktbegriff ist genau derjenige, der nachfolgend in der Serialisierbarkeit verwendet wird. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-5

6 Beispiel Beispiel 3-1: Wir betrachten drei Transaktionen, die durch das folgende Bild dargestellt sind. Die Kanten geben jeweils die Ordnung auf den Schritten an: r (x) 2 w (y) 2 1 r (z) 1 (x) w (x) 1 r (z) 3 w (y) 3 w (z) Eine erste History für diese Transaktionen (alle mit commit) lautet: r 1 (x)r 2 (x)r 1 (z)w 1 (x)w 2 (y)r 3 (z)w 3 (y)c 1 c 2 w 3 (z)c 3 Hierbei sind alle Schritte total geordnet (von links nach rechts). c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-6

7 Eine zweite History, mit einer nur partiellen Ordnung auf den Schritten könnte die folgende sein. Dabei bezeichnen die gestrichelten Linien diejenigen Ordnungsbeziehungen, die durch die Bedingung (1e) in Definition 3-1: eingeführt werden. r (x) 1 w (x) 1 c 1 2 (x) w (y) 2 c 2 (z) 1 w (y) 3 (z) 3 w (z) 3 c 3 Schreibweise: wenn ein Schritt p in einem Schedule vor einem Schritt q liegt schreiben wir: p < q; wenn der Kontext eines Schedules s [einer Transaktion t] genannt werden soll, dann p < s q [p < t q]. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-7

8 Serielle Ausführungsreihenfolgen Definition 3-2: (Serielle History) Eine History ist seriell, wenn für je zwei Transaktionen t i und t j mit i j gilt: alle Operationen von t i liegen vor denen von t j in s (oder umgekehrt). Ein Präfix einer partiellen Ordnung erhält man durch Weglassen am Ende einer Erreichbarkeitskette, genauer: sei s = (op(s), < s ) ein Schedule, dann hat ein Präfix von s die Form s = (op(s ), < s ) mit: 1. op s op s 2. < s < s 3. ( p op s )( q op s ) q < s p q op s Aus einer partiellen Ordnung kann immer (durch Ordnen von ungeordneten Schritten) eine vollständige Ordnung (i.a. mehrere) hergestellt werden. So ist etwa im obigen Beispiel 3-1: die erste History durch topologische Sortierung der zweiten (azyklischen!) History zu erhalten. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-8

9 Umgekehrt können aus einer (endlichen) Menge T = {t 1,..., t n } total geordneter Transaktionen über das sog. Shuffle Product shuffle(t ) die möglichen überlappt parallelen Schedules erzeugt werden. shuffle(t ) ist die Menge aller möglichen Reihenfolgen aus genau den Schritten von Transaktionen in T, die die Schrittfolgen der t i als geordnete Teilfolgen enthält. In shuffle(t ) werden die Transaktionsschritte der Transaktion t i wie zuvor, mit einem zusätzlichen Index i für die Transaktion bezeichnet. Damit ergibt sich als alternative Definition für total geordnete Histories und Schedules im Seitenmodell: Sei T = {t 1,..., t n } eine (endliche) Menge von total geordneten Transaktionen. Eine History (vollständiger Schedule) s für T erhält man aus einer Sequenz s shuffle(t ), indem für jedes t i T eine Terminierungsaktion c i oder a i (unter Beachtung der Regeln 1b und 1d von Definition 3-1:) hinzugefügt wird. Ein Schedule ist, wie zuvor, ein Präfix einer History. Eine History s ist seriell, wenn für eine Permutation ρ von {1,..., n}. s = t ρ(1)... t ρ(n) c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-9

10 Beispiele Beispiel 3-2: Wir betrachten T = {t 1, t 2, t 3 } aus Beispiel 3-1: wieder, die als total geordnete Transaktionen aufgefasst werden. Die History von früher: t 1 = r 1 (x)r 1 (z)w 1 (x) t 2 = r 2 (x)w 2 (y) t 3 = r 3 (z)w 3 (y)w 3 (z) r 1 (x)r 2 (x)r 1 (z)w 1 (x)w 2 (y)r 3 (z)w 3 (y)c 1 c 2 w 3 (z)c 3 hat u.a. folgende Präfixe: r 1 (x)r 2 (x)r 1 (z)w 1 (x)w 2 (y)r 3 (z)w 3 (y), r 1 (x)r 2 (x)r 1 (z)w 1 (x)w 2 (y), r 1 (x)r 2 (x)r 1 (z) c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-10

11 Beispiel 3-3: Für die Menge T = {t 1, t 2, t 3 } von Transaktionen mit t 1 = r 1 (x)w 1 (x)r 1 (y)w 1 (y) t 2 = r 2 (z)w 2 (x)w 2 (z) t 3 = r 3 (x)r 3 (y)w 3 (z) gilt: s 1 = r 1 (x)r 2 (z)r 3 (x)w 2 (x)w 1 (x)r 3 (y)r 1 (y)w 1 (y)w 2 (z)w 3 (z) shuffle(t ), s 2 = s 1 c 1 c 2 a 3 ist eine um Terminierungsschritte erweiterte History aus shuffle(t ), s 3 = r 1 (x)r 2 (z)r 3 (x) ist ein Schedule, s 4 = s 1 c 1 ist ein weiterer Schedule, s 5 = t 1 c 1 t 3 a 3 t 2 c 2 ist seriell. Wir werden weiterhin i.d.r. totale Ordnungen annehmen und nur in besonderen Fällen auf Auswirkungen von partiellen Ordnungen hinweisen. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-11

12 Notationen Im Gegensatz zu vielen (Standard-) Lehrbüchern betrachten wir die dynamische Situation von ablaufenden Transaktionen, die ihre Aktionen nach und nach dem Scheduler übergeben, also keine gegebene Menge von Transaktionen mit ihren jeweiligen Aktionen. Wir lesen die Aktionen schrittweise aus einem Schedule. Sei s ein Schedule, dann bezeichnet trans(s) := {t i s enthält Schritte von t i } die Menge der Transaktionen, die in s (ganz oder teilweise) auftreten; commit(s) := {t i trans(s) c i s} die Menge aller in s erfolgreich abgeschlossener Transaktionen; abort(s) := {t i trans(s) a i s} die Menge aller in s mit Misserfolg abgebrochenen Transaktionen; active(s) := trans(s) (commit(s) abort(s)) die Menge aller in s noch aktiven (Ende noch offen) Transaktionen. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-12

13 Anhand des Beispiels?? Für den Schedule s 2 = r 1 (x)r 2 (z)r 3 (x)w 2 (x)w 1 (x)r 3 (y)r 1 (y)w 1 (y)w 2 (z)w 3 (z)c 1 c 2 a 3 ergeben sich folgende Mengen von Transaktionen: trans(s 2 ) = {t 1, t 2, t 3 } commit(s 2 ) = {t 1, t 2 } abort(s 2 ) = {t 3 } active(s 2 ) = c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-13

14 Für den Schedule s 4 = r 1 (x)r 2 (z)r 3 (x)w 2 (x)w 1 (x)r 3 (y)r 1 (y)w 1 (y)w 2 (z)w 3 (z)c 1 gilt entsprechend: trans(s 4 ) = {t 1, t 2, t 3 } commit(s 4 ) = {t 1 } abort(s 4 ) = active(s 4 ) = {t 2, t 3 } Offensichtlich gilt für jede History s: trans(s) = commit(s) abort(s) active(s) = sowie für beliebige Schedules s: trans(s) = commit(s) abort(s) active(s) c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-14

15 3.2 Korrektheit von Schedules und Histories Ziel: Korrektheitskriterium für (überlappt) parallele Schedules. Sei S die Menge aller Schedules, dann suchen wir eine Funktion σ : S {0, 1}, die für jeden Schedule s S die Korrektheit prüft ( 0 steht für false, 1 für true ). Folglich können wir schreiben: correct(s) = {s S σ(s) = 1}. Offensichtlich sollten für konkrete solche Kriterien die folgenden Eigenschaften gelten: correct(s), es sollte wenigstens einige korrekte Schedules in S geben, s correct(s) muss effizient entscheidbar sein, damit ein Scheduler schnelle Entscheidungen im laufenden Betrieb fällen kann, correct(s) sollte hinreichend groß sein, damit ein Scheduler möglichst viele potentielle Ausführungsfolgen zulassen kann und damit möglichst viel Parallelität erlaubt wird. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-15

16 Vorgehensweise TX-Semantik ist unbekannt wir unterstellen (wie oben) eine syntaktische Semantik, die zu intuitiv richtigen Ergebnissen führt. Da Transaktionen einzeln integritätswahrend sein sollen, ist es sinnvoll anzunehmen, dass serielle Histories korrekt sind. Serielle Ausführung ist jedoch aus Performance-Überlegungen nicht wünschenswert, wir nutzen sie lediglich als Korrektheitsmaß, über eine Äquivalenzrelation auf Schedules und bilden die zugehörigen Äquivalenzklassen: [S] = {[s] s S} [S] bezeichnet die Menge aller Äquivalenzklassen bzgl., alle Schedules in einer solchen Klasse sind äquivalent. Klassen, in denen als Repräsentant ein serieller Schedule gewählt werden kann, heißen serialisierbar. Wir gehen also in zwei Schritten vor (wie in jedem Transaktionsmodell!): 1. Definiere einen Äquivalenzbegriff auf Schedules; 2. definiere Serialisierbarkeit durch Äquivalenz zu einem seriellen Schedule. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-16

17 3.3 Herbrand-Semantik von Schedules Wir folgen der Idee der Definition der Transaktionssemantik in Kapitel 2: Leseoperationen lesen den Wert, der zuletzt geschrieben wurde, Schreiboperationen hängen von allen vorherigen Leseoperationen ab. Dies wird auf Schedules s übertragen: 1. Ein Schritt r i (x) s einer Transaktion t i trans(s) liest den Wert, der beim letzten w j (x) s, j i, das in s vor r i (x) liegt, geschrieben wurde, mit a j / s. 2. Ein Schritt w i (x) s, schreibt einen neuen Wert, der (potentiell) von allen Werten abhängt, die t i aus der Datenbank oder von anderen Transaktionen in active(s) commit(s) vor w i (x) gelesen hat. Anmerkung: der letzte Schreiber vor einer Leseoperation ist immer wohldefiniert, da Schreiboperationen auf demselben Objekt geordnet sein müssen. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-17

18 Probleme Die erste Annahme oben ist (in Gegenwart von Fehlern) nicht-trivial! Betrachte den (Ausschnitt aus einem) Schedule s 1 = w i (x)w j (x)r k (x). Nach der Annahme oben liest r k (x) von w j (x), da (i) kein anderer Schritt zwischen diesen beiden liegt, und (ii) a j / s. Daran ändert sich nichts, wenn wir s 1 modifizieren zu s 2 = w i (x)c i w j (x)r k (x). Wenn nun an s 2 die Operation a j angehängt wird, also s 3 = w i (x)c i w j (x)r k (x)a j, liest r k (x) nun aber von w i (x), das sogar bereits committed ist. Wäre der Abort-Schritt von t j etwas früher im Schedule aufgetaucht, etwa s 4 = w i (x)c i w j (x)a j r k (x), so wäre dies von Anfang klar gewesen! Dies zeigt die Schwierigkeiten beim Umgang mit dynamisch entstehenden Schedules: formal ist s 2 s 3, aber dynamisch kann s 3 aus s 2 entstehen, dabei ändert sich der von r k (x) gelesene Wert! In der Literatur wird daher oft bei der Behandlung von Concurrency Control eine fehlerfreie Ausführungsumgebung angenommen (in der jede Transaktion ein commit erreicht). Wir tun dies nicht, werden jedoch manchmal abgebrochene Transaktionen explizit aus der Betrachtung ausschließen. In einem Schedule können Leseoperationen auftreten, vor denen kein write-schritt liegt, wie bei s = r 1 (x)r 2 (y)w 1 (x)r 2 (x).... c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-18

19 Dazu nehmen wir eine gedachte Initialisierungstransaktion t 0 vor allen anderen Operationen des Schedules an, die alle in einem Schedule angesprochenen Objekte schreibt und dann mit commit beendet wird. Am Beispiel also: s = w 0 (x)w 0 (y)c 0 r 1 (x)r 2 (y)w 1 (x)r 2 (x).... Meist werden wir t 0 nicht explizit aufführen. Da die genaue Semantik der Schritte eines Schedules nicht bekannt ist, verwenden wir wieder uninterpretierte Funktionssymbole für die Berechnung der neu zu schreibenden Werte. In der Logik bezeichnet man diese Vorgehensweise als Definition einer Herbrand-Semantik. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-19

20 Formalisierung Definition 3-3: (Herbrand-Semantik von Schritten) Sei s ein Schedule. Die Herbrand- Semantik H s von Schritten r i (x), w i (x) op(s) wird rekursiv definiert: 1. H s (r i (x)) := H s (w j (x)), wobei w j (x), j i, die letzte write-operation auf x in s vor r i (x) ist und a j op(s). 2. H s (w i (x)) := f ix (H s (r i (y 1 )),..., H s (r i (y m ))), wobei die r i (y j ), 1 j m, alle read-operationen von t i, die in s vor w i (x) liegen, darstellen. Die Funktion f ix ist ein uninterpretiertes m-stelliges Funktionssymbol. Anmerkungen: die Funktion f ix in Teil 2 ist wohldefiniert, da nach unserer Annahme jede TX nur eine Schreiboperation auf jedem Objekt enthalten kann. Die Initialisierungstransaktion t 0 schreibt ohne vorheriges Lesen, d.h. die Schreibschritte werden mit einer 0-stelligen Funktion f 0x (), also einer Konstanten, dem Anfangswert von x, assoziiert. Leseschritte geben den zuletzt von nicht abgebrochenen Transaktionen geschriebenen Wert zurück. Die Forderung, nur von abgeschlossenen Transaktionen zu lesen, wird erst später bei der Fehlerbehandlung erhoben! c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-20

21 Beispiel Beispiel 3-4: Die Schritte des Schedules s = w 0 (x)w 0 (y)c 0 r 1 (x)r 2 (y)w 2 (x)w 1 (y)c 2 c 1 erhalten mit den 0-stelligen Funktionen (Konstanten) f 0x (), f 0y () die Herbrand-Semantik H s : H s (w 0 (x)) = f 0x () H s (w 0 (y)) = f 0y () H s (r 1 (x)) = H s (w 0 (x)) = f 0x () H s (r 2 (y)) = H s (w 0 (y)) = f 0y () H s (w 2 (x)) = f 2x (H s (r 2 (y))) = f 2x (f 0y ()) H s (w 1 (y)) = f 1y (H s (r 1 (x))) = f 1y (f 0x ()) Wir definieren nun das Herbrand-Universum und darauf aufbauend die Herbrand-Semantik von Schedules. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-21

22 Definition 3-4: (Herbrand-Universum) Zu einer Transaktion t bezeichne op(t) die Menge aller Schritte von t. Das Herbrand-Universum HU zu Transaktionen t i, i > 0, ist die kleinste Menge von Symbolen, für die gilt: 1. f 0x () HU für jedes Objekt x D, wobei f 0x ein 0-stelliges Funktionssymbol (eine Konstante) ist; 2. Wenn w i (x) op(t i ) mit {r i (y) ( y D) r i (y) < ti w i (x)} = m und v 1,..., v m HU, dann ist auch f ix (v 1,..., v m ) HU, wobei f ix ein m-stelliges Funktionssymbol ist. Definition 3-5: (Semantik von Schedules) Die Semantik eines Scheduless ist eine Abbildung H[s] : D HU die definiert ist durch H[s](x) := H s (w i (x)), wobei w i (x) zu jedem x D die letzte Schreiboperation in s auf x ist, die zu einer nicht abgebrochenen (aborted) Transaktion gehört. Die Semantik eines Schedules s ist also die Menge der in s (von nicht abgebrochenen TXs) zuletzt geschriebenen Werte von Objekten. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-22

23 Beispiel Beispiel 3-5: Wir betrachten nochmals den Schedule aus dem vorherigen Beispiel: s = w 0 (x)w 0 (y)c 0 r 1 (x)r 2 (y)w 2 (x)w 1 (y)c 2 c 1. Wir erhalten mit den 0-stelligen Funktionen (Konstanten) f 0x (), f 0y () die Herbrand-Semantik H[s] von s: H[s](x) = H s (w 2 (x)) = f 2x (f 0y ()) H[s](y) = H s (w 1 (y)) = f 1y (f 0x ()) Anmerkung: der Vorteil dieser allgemeinen Definition der Herbrand-Semantik liegt darin, dass sie für beliebige konkrete Interpretationen von Transaktionen anwendbar ist. Der Nachteil liegt in der schwierigen Handhabbarkeit. Wir untersuchen zunächst, wie weit wir kommen können. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-23

24 3.4 Final State-Serialisierbarkeit Eine erste Definition von Serialisierbarkeit oder Äquivalenz zu einer seriellen History. Es macht hier keinen Sinn, von (unvollständigen) Schedules zu sprechen, da serielle Ausführungsfolgen per Definition vollständig sind (eine TX läuft vollständig vor einer anderen ab). Definition 3-6: (Final State-Äquivalenz) Seien s und s Schedules. s und s heißen final state-äquivalent, in Zeichen s f s, wenn op(s) = op(s ) und H[s] = H[s ], d.h., s und s enthalten die gleichen Operationen und haben gleiche Herbrand-Semantik. Inituitve Interpretation: zwei Schedules sind äquivalent, wenn sie den gleichen Ausgangszustand in den gleichen Endzustand überführen. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-24

25 Beispiel 3-6: Wir betrachten zwei Schedules s = r 1 (x)r 2 (y)w 1 (y)r 3 (z)w 3 (z)r 2 (x)w 2 (z)w 1 (x) s = r 3 (z)w 3 (z)r 2 (y)r 2 (x)w 2 (z)r 1 (x)w 1 (y)w 1 (x) Beide Schedules beinhalten die gleichen Schritte und zwar nur solche von aktiven TXs; t 0 ist nicht explizit gezeigt. Es gilt: H[s](x) = H s (w 1 (x)) = f 1x (f 0x ()) = H[s ](x) = H s (w 1 (x)) H[s](y) = H s (w 1 (y)) = f 1y (f 0x ()) = H[s ](y) = H s (w 1 (y)) H[s](z) = H s (w 2 (z)) = f 2z (f 0x (), f 0y ()) = H[s ](z) = H s (w 2 (z)) Folglich gilt s f s, die beiden Schedules sind final state-äquivalent. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-25

26 Beispiel 3-7: Wir betrachten zwei Schedules Es ergibt sich s = r 1 (x)r 2 (y)w 1 (y)w 2 (y)c 1 c 2 s = r 1 (x)w 1 (y)r 2 (y)w 2 (y)c 2 c 1 H[s](y) = H s (w 2 (y)) = f 2y (f 0y ()) H[s ](y) = H s (w 2 (y)) = f 2y (H s (r 2 (y))) = f 2y (H s (w 1 (y))) = f 2y (f 1y (H s (r 1 (x)))) = f 2y (f 1y (f 0x ())) Folglich ist s f s. Die Äquivalenz kann nicht nur aufgrund der letzten Schreiboperationen entschieden werden: In s wird nur der Wert von y (durch t 2 ) neu geschrieben, basierend auf dem alten, von t 2 gelesenen, Wert von y. Dagegen beeinflusst das vorherige Schreiben von y durch t 1 in s den von t 2 letztlich geschriebenen Wert von y. In s dagegen war t 1 ohne Effekt. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-26

27 Die Liest-von -Relation Die Beobachtung aus dem letzten Beispiel veranlasst uns, auch an das Ende einer History s noch eine gedachte Transaktion t anzuhängen, die alle in s angesprochenen Objekte liest und dann mit commit beendet wird. Für Schedules s macht t wenig Sinn, formal können wir jedoch auch hier t am Ende anhängen. Beispiel 3-8: Wir betrachten die drei Transaktionen aus Beispiel 3-1: und den dort als Graph dargestellten Schedule nochmals. Ohne die commit-schritte, aber jetzt mit der Initialisierungstransaktion und der abschließenden Lese-Transaktion sieht dieser Schedule so aus: w (x) 0 r (x) 1 w (x) 1 r (x) oo r (x) 2 w (y) 2 w (y) 0 r (z) 1 w (y) 3 r (y) oo w (z) 0 r (z) 3 w (z) 3 r (z) oo c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-27

28 Definition 3-7: (Liest-von-Relation, genutzte Schritte) Sei s eine History. 1. Sei t i trans(s) abort(s) und r i (x) eine read-operation von t i. r i (x) liest x von w j (x), j i in s, wenn w j (x) die letzte write-operation auf x einer nicht abgebrochenen Transaktion t j in s ist mit w j (x) < s r i (x). 2. Die liest-von-relation (reads-from relation) zu s ist definiert durch RF(s) := {(t i, x, t j ) ein r j (x) liest x von einem w i (x)} 3. Ein Schritt p ist direkt genutzt (directly useful) in einem Schritt q, in Zeichen p q, wenn q von p liest oder wenn p ein read-schritt und q ein nachfolgender write-schritt der gleichen Transaktion ist. ( genutzt (useful)) bezeichne die reflexive und transitive Hülle von. 4. ein Schritt p ist lebendig (alive) in s, wenn er in irgendeinem Schritt von t genutzt wird, also wenn ( q t ) p q, andernfalls ist es ein toter (dead) Schritt. 5. Die lebendige liest-von-relation (live-reads-from relation) zu s ist definiert durch LRF(s) := {(t i, x, t j ) ein lebendiges r j (x) liest x von einem w i (x)}. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-28

29 Beispiel 3-9: Wir betrachten die zwei Schedules von vorher (Beispiel 3-6:) noch einmal: Es ergibt sich In beiden Schedules s und s gilt: s = r 1 (x)r 2 (y)w 1 (y)w 2 (y)c 1 c 2 s = r 1 (x)w 1 (y)r 2 (y)w 2 (y)c 2 c 1 RF(s) = {(t 0, x, t 1 ), (t 0, y, t 2 ), (t 0, x, t ), (t 2, y, t )}, RF(s ) = {(t 0, x, t 1 ), (t 1, y, t 2 ), (t 0, x, t ), (t 2, y, t )}. w 0 (x) r 1 (x) w 1 (y), r 2 (y) w 2 (y) r (y). Und damit w 0 (x) w 1 (y), r 2 (y) r (y). In s gilt zusätzlich w 1 (y) r 2 (y) und daher w 1 (y) r (y) und r 1 (x) r (y). Folglich ist LRF(s) = {(t 0, y, t 2 ), (t 0, x, t ), (t 2, y, t )}, LRF(s ) = {(t 0, x, t 1 ), (t 1, y, t 2 ), (t 0, x, t ), (t 2, y, t )}. Mit Hilfe der Relation LRF lässt sich die Final State-Äquivalenz von Schedules überprüfen: c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-29

30 Satz 3-1: Seien s und s Histories ohne abgebrochene (aborted) Transaktionen. Es gilt: s f s LRF(s) = LRF(s ) Beweis. [-Skizze:] Zu einer History s konstruiere einen Schrittgraphen (step graph) D(s) = (V, E): V := op(s) D := {(p, q) p, q V, p q} Aus dem Schrittgrpahen D(s) wird ein reduzierter Schrittgraph D 1 (s) abgeleitet, in dem alle Knoten (und ihre inzidenten Kanten) gelöscht werden, die zu toten Schritten gehören. Dann kann gezeigt werden: 1. LRF(s) = LRF(s ) D 1 (s) = D 1 (s ); 2. s f s D 1 (s) = D 1 (s ). Damit ist der Beweis geführt. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-30

31 Beispiel 3-10: Die Histories s = r 1 (x)r 2 (y)w 1 (y)r 3 (z)w 3 (z)r 2 (x)w 2 (z)w 1 (x)c 1 c 2 c 3 s = r 3 (z)w 3 (z)r 2 (y)r 2 (x)w 2 (z)r 1 (x)w 1 (y)w 1 (x)c 3 c 2 c 1 haben die folgenden LRF-Relationen: LRF(s) = {(t 0, x, t 1 ), (t 0, x, t 2 ), (t 0, y, t 2 ), (t 0, z, t 3 )(t 1, x, t ), (t 1, y, t ), (t 2, z, t )} LRF(s ) = {(t 0, x, t 2 ), (t 0, x, t 1 ), (t 0, y, t 2 ), (t 0, z, t 3 )(t 1, x, t ), (t 1, y, t ), (t 2, z, t )} In beiden Histories sind die Leseschritte r 1 (x), r 2 (y) und r 3 (z) lebendig. Die Schrittgraphen D(s) und D(s ) sind im nachfolgenden Bild dargestellt. Die reduzierten Schrittgraphen erhält man jeweils durch Weglassen der eingekreisten Teile. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-31

32 D(s): w 0 (x) w 0 (y) w 0 (z) r 1 (x) r 2 (y) r 3 (z) r 2 (x) w 1 (y) w 3 (z) w 2 (z) D(s ): w 0 (x) w 0 (y) w 0 (z) r 2 (x) r 2 (y) r 3 (z) r 1 (x) w 1 (y) w 3 (z) w 1 (x) w 1 (x) w 2 (z) r (x) r (y) r (z) r (x) r (y) r (z) Offensichtlich impliziert LRF(s) = LRF(s ), dass D 1 (s) = D 1 (s ) und damit s f s. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-32

33 Beispiel 3-11: Für die Histories aus Beispiel 3-6: ergeben sich die Graphen D(s) und D(s ): s = r 1 (x)r 2 (y)w 1 (y)w 2 (y)c 1 c 2 s = r 1 (x)w 1 (y)r 2 (y)w 2 (y)c 2 c 1 D(s): w 0 (x) w 0 (y) r 1 (x) r 2 (y) w 1 (y) w 2 (y) D(s ): w 0 (x) w 0 (y) r 1 (x) w 1 (y) r 2 (y) w 2 (y) r (x) r (y) r (x) r (y) In s ist nur r 2 (y) lebendig, in s dagegen r 1 (x) und r 2 (y). Daher ist D 1 (s) D 1 (s ) und damit s f s. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-33

34 Anmerkung Der Schrittgraph einer Historie s ist i.a. verschieden von der partiellen Ordnung der Schritte in s. In D(s) werden Kanten für direkt genutzte Schritte konstruiert. Sei etwa in einer History s gegeben: w i (x) r k (x) w j (x) Da im Konflikt stehende Operationen in s geordnet sein müssen, muss gelten w i (x) < s w j (x) oder umgekehrt. Wenn etwa w i (x) < s w j (x) gilt, so gäbe es in D(s) keine Kante von w i (x) nach r k (x), da r k (x) dann von w j (x) lesen würde. Intuitiv bedeutet die Einschränkung auf den reduzierten Schrittgraphen D 1 (s) eines Schedules, dass wir nur aktive Schritte beim Test der Final State-Äquivalenz betrachten, also solche, die den Endzustand beeinflussen (auf einem Pfad nach t im reduzierten Graphen liegen). Der Satz besagt also, dass zwei Schedules s, s FS-äquivalent sind, wenn jeder lebendige read-schritt in s und s vom gleichen anderen Schritt liest. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-34

35 Final State-Serialisierbarkeit Aus den vorangegangenen Überlegungen ersehen wir für die Komplexität des Tests auf FS- Äquivalenz: Korollar 3-2: Final State-Äquivalenz zweier Schedules s und s kann in polyniomialer Zeit in der Länge der beiden Schedules (oder des längeren, wenn op(s) op(s )) entschieden werden. Ein erster Serialisierbarkeitsbegriff kann nun festgehalten werden. Definition 3-8: (Final State-Serialisierbarkeit) Eine History s ist final state-serialisierbar, wenn es eine serielle History s gibt mit op(s) = op(s ) und s f s. Mit FSR bezeichnen wir die Klasse aller final state-serialisierbaren Schedules. Beispiel 3-12: Für den Schedule s = r 1 (x)r 2 (y)w 1 (y)r 3 (z)w 3 (z)r 2 (x)w 2 (z)w 1 (x)c 1 c 2 c 3 von oben gilt: s f t 3 t 2 t 1, also s FSR. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-35

36 3.5 View-Serialisierbarkeit Definition Wir bestrachten nun eine Einschränkung der Final State-Serialisierbarkeit, die durch folgende Überlegungen motiviert ist: Wenn alle Transaktionen in einem gegebenen Schedule s nur lesen, sind Ausgangs- und Endzustand derselbe (t liest nur von t 0 ), somit ist das FSR-Kriterium trivial. Der FSR-Begriff stützt sich auf lebendige Schritte in einem Schedule s. Da wir nicht wissen, was die Semantik einer TX ist, ist es sinnvoll, für äquivalente Schedules zu fordern, dass alle Transaktionen die gleichen Werte lesen, unabhängig von ihrer Lebendigkeit. So ist garantiert, dass alle Transaktionen in beiden Schedules dasselbe tun, die gleiche Sicht auf die zugrundeliegenden Daten haben. Dies ist besonders dann wichtig, wenn Transaktionen aufgrund der gelesenen Daten Aktionen in der realen Welt auslösen, z.b. Bestellungen tätigen, Buchungen vornehmen, etc. Dann sind die gelesenen Daten Teil der realen Welt, unabhängig davon, ob die Datenbasis verändert wurde oder nicht. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-36

37 Formalisierung Definition 3-9: (View-Äquivalenz) Zwei Schedules s und s sind view-äquivalent, in Zeichen s v s, wenn gilt: 1. op(s) = op(s ) 2. H[s] = H[s ] 3. H s (p) = H s (p) für alle read-schritte und alle write-schritte nicht abgebrochener Transaktionen, von denen in beiden Schedules gelesen wird. Die Bedingungen 1 und 2 fordern die FS-Äquivalenz von s und s. Bedingung 3 fordert darüberhinaus, dass jede nicht abgebrochene Datenoperation in beiden Schedules die gleiche Semantik hat. View-Äquivalenz kann wie folgt charakterisiert werden: Satz 3-3: Seien s und s äquivalent: 1. s v s 2. D(s) = D(s ) 3. RF(s) = RF(s ) zwei Schedules. Die folgenden drei Aussagen sind paarweise c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-37

38 Beweis. Wir zeigen die Äquivalenz von 1 und 3. = : =: c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-38

39 Korollar 3-4: View-Äquivalenz zweier Schedules s und s kann in polynomialer Zeit in der Länge der Schedules (Anzahl Elemente in op(s)) geprüft werden. (Folgt aus Korollar 3-2:) Mit diesem Äquivalenzbegriff ergibt sich der nächste Begriff von Serialisierbarkeit: Definition 3-10: (View-Serialisierbarkeit) Eine History s ist view-serialisierbar, wenn es eine serielle History s gibt mit op(s) = op(s ) und s v s. Mit VSR bezeichnen wir die Klasse aller view-serialisierbaren Schedules. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-39

40 Eigenschaften von VSR Aus der Definition 3-9: folgt VSR FSR. Der folgende Satz verschärft dies. Satz 3-5: VSR FSR Beweis. Es genügt, einen Schedule aus FSR VSR anzugeben. Betrachte s = w 1 (x)r 2 (x)w 2 (y)r 1 (y)w 1 (y)w 3 (x)w 3 (y)c 2 c 1 c 3. Man sieht leicht, dass s FSR VSR: Zum einen gilt s f t 2 t 1 t 3. Da t 3 in s blind schreibt (ohne vorher zu lesen), sind die beiden seriellen Histories t 1 t 2 t 3 und t 2 t 1 t 3 potentiell view-äquivalent zu s. Beide haben jedoch eine andere RF-Relation als s. Der Unterschied zwischen FSR und VSR liegt allein im Umgang mit toten Schritten: Satz 3-6: Sei s eine History ohne tote Schritte. Dann gilt: Ohne Beweis. s FSR s VSR c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-40

41 3.5.2 Zu abgebrochenen Transaktionen Frage: Ist VSR eine adäquate Klasse korrekter Schedules? Falls das so ist, dann muss VSR die in der Einführung betrachteten Anomalien (Lost Update, Inconsistent Read, Dirty Read) vermeiden. Lost Update. Ein einfacher ( kanonischer ) Schedule, der ein Lost Update-Phänomen zeigt ist L = r 1 (x)r 2 (x)w 1 (x)w 2 (x)c 1 c 2. Für L gibt es zwei mögliche serielle Ausführungsreihenfolgen, t 1 t 2 und t 2 t 1. Wir betrachten ihre RF-Relationen: RF(L) = {(t 0, x, t 1 ), (t 0, x, t 2 ), (t 2, x, t )} RF(t 1 t 2 ) = {(t 0, x, t 1 ), (t 1, x, t 2 ), (t 2, x, t )} RF(t 2 t 1 ) = {(t 0, x, t 2 ), (t 2, x, t 1 ), (t 1, x, t )} Da alle drei Schedules unterschiedliche RF-Relationen haben, hat L keinen view-äquivalenten seriellen Schedule, also gilt L / VSR. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-41

42 Inconsistent Read. Ein kanonischer Schedule mit einem Inconsistent Read-Phänomen ist I = r 1 (x)r 1 (y)r 2 (z)w 2 (z)r 2 (x)w 2 (x)c 2 r 1 (z)c 1. Für I und die beiden seriellen Ausführungsreihenfolgen t 1 t 2 und t 2 t 1 ergeben sich folgende RF-Relationen: RF(I) = {(t 0, x, t 1 ), (t 0, y, t 1 ), (t 0, z, t 2 ), (t 0, x, t 2 ), (t 2, z, t 1 ), (t 2, x, t ), (t 0, y, t ), (t 2, z, t )} RF(t 1 t 2 ) = {(t 0, x, t 1 ), (t 0, y, t 1 ), (t 0, z, t 1 ), (t 0, x, t 2 ), (t 0, z, t 2 ), (t 2, x, t ), (t 0, y, t ), (t 2, z, t )} RF(t 2 t 1 ) = {(t 2, x, t 1 ), (t 0, y, t 1 ), (t 2, z, t 1 ), (t 0, x, t 2 ), (t 0, z, t 2 ), (t 2, x, t ), (t 0, y, t ), (t 2, z, t )} Wieder sind die RF-Relationen paarweise verschieden, also ist auch I / VSR, wie erwartet. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-42

43 Dirty Read. Ein kanonischer Dirty Read-Schedule ist etwa D = r 1 (x)w 1 (x)r 2 (x)a 1 w 2 (x)c 2. Für diese History D finden wir eine serielle Ausführungsreihenfolge, t 1 t 2 mit gleicher RF- Relation: RF(D) = {(t 0, x, t 1 ), (t 0, x, t 2 ), (t 2, x, t )} RF(t 1 t 2 ) = {(t 0, x, t 1 ), (t 0, x, t 2 ), (t 2, x, t )} Also ist D v t 1 t 2, was unserer intuitiven Absicht widerspricht (schließlich wollen wir Dirty Reads verhindern)! Beachte: die View-Äquivalenz gilt hier nur, weil wir eine History (also einen vollständigen Schedule) betrachten, d.h. weil wir berücksichtigen, dass die Transaktion t 1 abgebrochen wird! Die Tatsache, dass D vom VSR-Kriterium akzeptiert wird, gibt uns einen Hinweis, dass noch etwas fehlt in unserer Theorie. Wir werden erst bei der Recovery wieder darauf zurückkommen. Bis dahin werden wir Transaktion-Aborts i.d.r. von der Betrachtung ausschließen. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-43

44 3.5.3 Komplexität des VSR-Tests Wir hatten bislang nur (positive) Komplexitätsaussagen über die Äquivalenztests (in VSR und FSR) gemacht. Jetzt fragen wir nach dem Test s VSR? (und damit nach s FSR? ). Satz 3-7: Das Problem, zu einem gegebenen Schedule s zu entscheiden, ob s VSR, ist N P-vollständig. Es bleibt also i.w. nichts anderes übrig als alle möglichen seriellen Schedules auszuprobieren und jeweils View-Äquivalenz zu prüfen. Beweis. Der Beweis wird hier nicht geführt. Zu jeder History s wird ein verallgemeinerter DAG, ein sog. Polygraph P (s) assoziiert. Man kann dann zeigen, dass s VSR P (s) azyklisch ist (für eine geeignete Def. von Azyklizität). Es bleibt zu zeigen, dass der Zyklen-Test für Polygraphen N P-vollständig ist (durch Reduktion auf SAT). c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-44

45 Anmerkungen Wegen der hohen Komplexität ist View-Serialisierbarkeit für praktische Scheduling Algorithmen unbrauchbar. Es gibt weitere Gründe, weshalb VSR keine erstrebenswerte Klasse korrekter Schedules für die Praxis darstellt: die Eigenschaft s VSR ist nicht monoton: Projektionen aus Schedules: Sei s ein Schedule und T trans(s). Dann bezeichnet Π T (s) eine Projektion von s auf T, nämlich denjenigen Schedule s, der aus s durch Streichen aller Operationen von Transaktionen nicht aus T entsteht: op(s ) = op(s) t/ T op(t). Beispiel: anhand des Schedules s = w 1 (x)r 2 (x)w 2 (y)r 1 (y)w 1 (y)w 3 (x)w 3 (y)c 1 a 2 ergibt sich mit T = {t 1, t 2 }: Π T (s) = w 1 (x)r 2 (x)w 2 (y)r 1 (y)w 1 (y)c 1 a 2. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-45

46 Monotonie: Eine Eigenschaft E eines Schedules s ist monoton genau dann wenn gilt: Wenn E für s gilt, dann auch für alle Projektionen Π T (s) für T trans(s); E ist also abgeschlossen unter allen Projektionen. Monotonie ist eine erstrebenswerte Eigenschaft: angenommen wir wollen Eigenschaft E für eine History erreichen. Wenn ein Anfangsstück s der History die Eigenschaft E nicht hat, dann macht es keinen Sinn, mit der Bearbeitung fortzufahren, da wir E für die vollständige History nie mehr erreichen können, falls E monoton ist. Jetzt können wir durch ein Gegenbeispiel zeigen, dass die Eigenschaft E(s) = s VSR nicht monoton ist: Betrachte s = w 1 (x)w 2 (x)w 2 (y)c 2 w 1 (y)c 1 w 3 (x)w 3 (y)c 3. Es gilt t v t 1 t 2 t 3 v t 2 t 1 t 3, also s VSR. Jedoch kann leicht verifiziert werden, dass Π {t1 t 2 }(s) = w 1 (x)w 2 (x)w 2 (y)c 2 w 1 (y)c 1 / VSR. Wir haben also eine History s VSR, für die eine Teilmenge T trans(s) existiert mit Π T (s) / VSR, also ist E(s) = s VSR nicht monoton. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-46

47 3.6 Konflikt-Serialisierbarkeit... für die Praxis relevanter Serialisierbarkeitsbegriff, effizient überprüfbar, interessante theoretische Eigenschaften, kann leicht auf andere Transaktionsmodelle übertragen werden Konflikt-Relationen Im Kontext von partiell geordneten Schedules haben wir bereits von Konflikten zwischen Operationen verschiedener Transaktionen gesprochen. Definition 3-11: (Konflikt, Konflikt-Relation) Seien s ein Schedule und t, t Transaktionen daraus, t, t trans(s), mit t t : 1. Zwei Datenoperationen p op(t) und q op(t ) stehen im Konflikt in s, wenn sie dasselbe Datenobjekt betreffen und mindestens eine davon eine Schreiboperation ist, also (p = r(x) q = w(x)) (p = w(x) q = r(x)) (p = w(x) q = w(x)) 2. C(s) := {(p, q) p, q stehen im Konflikt und p < s q} ist die Konflikt-Relation von s. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-47

48 Anmerkungen Die Konfliktrelation eines Schedules berücksichtigt den Terminierungsstatus einer Transaktion nicht, insbesondere wird nicht nach commit und abort unterschieden! Wenn wir beispielsweise den folgenden Schedule betrachten so hat dieser die Konfliktrelation s = w 1 (x)r 2 (x)w 2 (y)r 1 (y)w 1 (y)w 3 (x)w 3 (y)c 1 a 2, C(s) = {(w 1 (x), r 2 (x)), (r 2 (x), w 3 (x)), (w 1 (x), w 3 (x)), (w 2 (y), r 1 (y)), (w 2 (y), w 1 (y)), (w 2 (y), w 3 (y)), (r 1 (y), w 3 (y)), (w 1 (y), w 3 (y))}. Konflikte können also zwischen beliebigen (Daten-) Aktionen entstehen, auch solchen von abgebrochenen Transaktionen. Da die letzteren keinen Einfluss auf die Semantik eines Schedules haben, betrachten wir im folgenden die entsprechend eingeschränkte Konfliktrelation: conf(s) = C(s) active(s) commit(s), im Beispiel also: conf(s) = {(w 1 (x), w 3 (x)), (r 1 (y), w 3 (y)), (w 1 (y), w 3 (y))}. Diese Relation trifft unser intuitives Verständnis vom Umgang mit abgebrochenen Transaktionen. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-48

49 Konflikt-Äquivalenz Definition 3-12: (Konflikt-Äquivalenz) Seien s, s Schedules. s und s heißen konfliktäquivalent, in Zeichen s c s, wenn gilt: 1. op(s) = op(s ) und 2. conf(s) = conf(s ). In Worten bedeutet dies: zwei Schedules sind konflikt-äquivalent, wenn alle Paare im Konflikt stehender Aktionen von nicht abgebrochenen Transaktionen in der gleichen Reihenfolge in beiden Schedules auftreten. Beispiel 3-13: Für die beiden Schedules s = r 1 (x)r 1 (y)w 2 (x)w 1 (y)r 2 (z)w 1 (x)w 2 (y) s = r 1 (y)r 1 (x)w 1 (y)w 2 (x)w 1 (x)r 2 (z)w 2 (y) gilt op(s) = op(s ) und conf(s) = conf(s ), also s c s. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-49

50 Zur Komplexität Der Test auf Konflikt-Äquivalenz zweier Schedules über der gleichen Operationenmenge ist einfach: wir leiten die conf-relation her und test auf Gleichheit. Wie bei der View-Äquivalenz können wir das auf einen Graphen zurückführen, den sog. Conflicting-Step-Graph : Sei s ein Schedule. Definiere D 2 (s) = (V, E) mittels V = op(s) und E = conf(s). Nun gilt: s c s D 2 (s) = D 2 (s ). Falls s als partielle Ordnung gegeben ist, so besteht D 2 (s) genau aus denjenigen Kanten, die wir früher schon (Beispiel 3-1:) zusätzlich zu den in den Transaktionen gegebenen (gestrichelt) eingefügt haben. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-50

51 3.6.2 Die Klasse CSR Der dritte Serialisierbarkeitsbegriff ergibt sich aus der dritten Art von Äquivalenz: Definition 3-13: (Konflikt-Serialisierbarkeit) Eine History s ist konflikt-serialisierbar, wenn es eine serielle History s gibt, so dass op(s) = op(s ) und s c s. Die Klasse aller konflikt-serialisierbaren Schedules wird mit CSR bezeichnet. Beispiele: Der partiell geordnete Schedule aus Beispiel 3-1: liegt in CSR. Für den Schedule s = r 2 (y)w 1 (y)w 1 (x)c 1 w 2 (x)c 2 gilt s / CSR und für s = r 1 (x)r 2 (x)w 2 (y)c 2 w 1 (x)c 1 gilt s CSR. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-51

52 Lost Update und Inconsistent Read Wir betrachten nochmals die beiden kanonischen Schedules Für L erhalten wir L = r 1 (x)r 2 (x)w 1 (x)w 2 (x)c 1 c 2 und I = r 1 (x)r 1 (y)r 2 (z)w 2 (z)r 2 (x)w 2 (x)c 2 r 1 (z)c 1. conf(l) = {(r 1 (x), w 2 (x)), (r 2 (x), w 1 (x)), (w 1 (x), w 2 (x))}. Wogegen die beiden möglichen seriellen Schedules t 1 t 2 bzw. t 2 t 1 jeweils von conf(l) verschiedene conf-relationen haben, also ist L / CSR, wie gewünscht. Für I ergibt sich conf(i) = {(r 1 (x, w 2 (x)), (w 2 (z), r 1 (z))}. Offensichtlich kann keine der beiden möglichen seriellen Reihenfolgen die gleiche conf-relation haben, also ist auch I / CSR. Konflikt-Serialisierbarkeit vermeidet also Lost Updates und Inconsistent Reads. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-52

53 Eigenschaften von CSR Satz 3-8: CSR VSR Beweis. CSR VSR folgt aus der Tatsache, dass der Graph D(s) durch D 2 (s) eindeutig bestimmt wird, wenn die Kantenmenge von D 2 (s) die ganze Konfliktrelation C(s) (aus Definition 3-11:) darstellt. Für die Ungleichheit betrachten wir ein Beispiel: s = r 1 (y)r 3 (w)r 2 (y)w 1 (y)w 1 (x)w 2 (x)w 2 (z)w 3 (x)c 2 c 1 c 3. Es gilt s / CSR, aber s v t 2 t 1 t 3, also s VSR. Korollar 3-9: Es ergibt sich folgende Anordnung: CSR VSR FSR. Ferner kann man zeigen (ohne Beweis): Satz 3-10: 1. Die Eigenschaft E = s CSR ist monoton. 2. s CSR T trans(s) : Π t (s) VSR, d.h. CSR ist die größte monotone Teilklasse von VSR. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-53

54 Serialisierbarkeitstest Wir zeigen, dass bzgl. der Klasse CSR ein effizienter Serialisierbarkeitstest möglich ist. Dazu verwenden wir den sog. Konfliktgraphen einer History s. Intuition: im Konfliktgraph repräsentieren Knoten abgeschlossene Transaktionen, Kanten von t nach t stehen für Schritte p t, q t mit (p, q) conf(s). Wir betrachten etwa die History s = r 1 (y)r 3 (w)r 2 (y)w 1 (y)w 1 (x)w 2 (x)w 2 (z)w 3 (x)c 1 c 2. Der Ausschnitt... r 2 (y)w 1 (y)... besagt, dass in einem äquivalenten seriellen Schedule t 2 vor t 1 ablaufen muss (t 2 < t 1 );... w 1 (x)w 2 (x)... dagegen besagt das genaue Gegenteil. Intuitiv ist also klar, dass s nicht konflikt-serialisierbar ist. Der Konfliktgraph zu s enthält einen Zyklus zwischen den Knoten, die t 1 bzw. t 2 repräsentieren. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-54

55 Definition 3-14: (Konfliktgraph) Sei s ein Schedule. Der Konfliktgraph G(s) = (V, E) zu s ist definiert durch 1. V = commit(s) 2. (t, t ) E t t ( p t)( q t ) (p, q) conf(s) Anmerkung: Der Konfliktgraph G(s) eines Schedules abstrahiert von einzelnen Konflikten, indem zu jedem Paar von Transaktionen jeweils höchstens eine Kante in jede Richtung enthalten ist, also weniger Informationen als im Graphen D 2 (s). Wir werden jedoch sehen, dass die Information in G(s) für den Serialisierbarkeitstest s VSR? ausreichend ist. Beispiel 3-14: Zum Schedule s = r 1 (x)r 2 (x)w 1 (x)r 3 (x)w 3 (x)w 2 (y)c 3 c 2 w 1 (y)c 1 ist der Konfliktgraph G(s): t 1 t 2 t 3 c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-55

56 (Konflikt-) Serialisierbarkeitstheorem Satz 3-11: Sei s eine History. s CSR G(s) ist azyklisch. Beweis: (siehe Vorlesung) Korollar 3-12: Mitgliedschaft eines Schedules s in der Klasse CSR kann in polynomialer Zeit (in der Anzahl Transaktionen in s) getestet werden.... der Konfliktgraph zu einer History kann in linearer Zeit (in der Anzahl Operationen) konstruiert werden, der Zyklustest erfordert maximal quadratisch viel Zeit (in der Anzahl Knoten). c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-56

57 Beispiel 3-15: Wir betrachten die folgenden zwei Histories: s = r 1 (y)r 3 (w)r 2 (y)w 1 (y)w 1 (x)w 2 (x)w 2 (z)w 3 (x)c 1 c 3 c 2 s = r 1 (x)r 2 (x)w 2 (y)w 1 (x)c 2 c 1 Die zugehörigen Konfliktgraphen G(s) und G(s ) sind: G(s) t 1 t 2 G(s ) t 1 t 2 t 3 Da G(s) einen Zyklus enthält, gilt s / CSR; dagegen ist G(s ) azyklisch, also ist s CSR. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-57

58 3.6.3 Konflikte und Kommutativität Wir geben eine andere Charakterisierung von Konflikt-Serialisierbarkeit an. Wieder lassen sich die Ergebnisse auf partiell geordnete Schedules verallgemeinern, wir betrachten jedoch hier nur total geordnete. Wir betrachten folgende Kommutativitätsregeln für die Datenoperationen der Seitenebene (dabei bedeutet das Zeichen, dass linke und rechte Seite für einander ersetzt werden können): Regel C1: r i (x)r j (y) r j (y)r i (x), falls i j Regel C2: r i (x)w j (y) w j (y)r i (x), falls i j, x y Regel C3: w i (x)w j (y) w j (y)w i (x), falls i j, x y Die Regel C1 besagt, dass unmittelbar benachbarte Leseschritte verschiedener Transaktionen vertauscht werden können, das gleiche gilt nach C2 für benachbarte Lese- und Schreibschritte verschiedener Transaktionen auf verschiedenen Objekten. Schließlich können nach C3 auch benachbarte Schreibschritte verschiedener Transaktionen auf verschiedenen Objekten vertauscht werden. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-58

59 Beispiel 3-16: Die Kommutativitätsregeln können schrittweise angewendet werden: s = w 1 (x)r 2 (x)w 1 (y)w 1 (z)r 3 (z)w 2 (y)w 3 (y)w 3 (z) C2 C2 w 1 (x)w 1 (y)r 2 (x)w 1 (z)w 2 (y)r 3 (z)w 3 (y)w 3 (z) w 1 (x)w 1 (y)w 1 (z)r 2 (x)w 2 (y)r 3 (z)w 3 (y)w 3 (z) t 1 t 2 t 3 Definition 3-15: (Kommutativitätsbasierte Äquivalenz) Seien s und s Schedules mit op(s) = op(s ). Wir definieren die Relation s s, wenn s durch eine Anwendung einer Regel C1, C2 oder C3 auf Schritte nicht abgebrochener Transaktionen in s überführt werden kann. Mit bezeichnen wir die reflexive und transitive Hülle von. Das heißt, s s wenn s durch Anwendung beliebig (aber endlich) vieler Schritte C1, C2 oder C3 in s überführt werden kann. Offensichtlich ist eine Äquivalenzrelation auf der Menge aller Schedules zu gegebenen Transaktionen. Satz 3-13: Seien s und s Schedules mit op(s) = op(s ). Es gilt: s c s s s. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-59

60 Endliche Anwendung der Kommutativitätsregeln können einen Schedule auf einen äquivalenten seriellen reduzieren (siehe Beispiel oben). Definition 3-16: ((Kommutativitätsbasierte) Reduzierbarkeit) Eine History s heißt (kommutativitätsbasiert) reduzierbar, wenn es eine serielle History s gibt mit s s, d.h. wenn s durch erlaubte Vertauschungen von Datenoperationen in eine serielle History s überführt werden kann. Korollar 3-14: Eine History s ist (kommutativitätsbasiert) reduzierbar genau dann, wenn s CSR. Bemerkung: Die wichtigste Anwendung dieser alternativen Charakterisierung von Konflikt- Äquivalenz ist ihre unmittelbare Verallgemeinerung auf beliebige Datenoperationen. Es ist völlig irrelevant, von den Schritten eines Schedules zu wissen, ob Objekte gelesen oder geschrieben werden, bzw. ob gleiche oder verschiedene Objekte betroffen sind! Wichtig ist nur, zu wissen welche Schritte im Konflikt stehen. Dies genügt, um die Korrektheit eines Schedules zu entscheiden, ohne jegliches Wissen um die Semantik der Operationen. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-60

61 Beispiel 3-17: Betrachte hierzu den folgenden Schedule, dessen Schritte nicht weiter spezifiziert sind: s = p 1 q 1 p 2 o 1 p 3 q 2 o 2 o 3 p 4 o 4 q 3. Sei s ein Schedule für die Transaktionen P, Q, O. Wir wissen nur, dass die folgenden Paare von Operationen im Konflikt stehen: 1. p 2 und q 1, 2. p 2 und o 1, 3. q 1 und o 1, 4. q 3 und o 4. Wir können nun zu s einen Konfliktgraphen konstruieren und stellen fest, dass s nicht konfliktserialisierbar ist, da G(s) einen Zyklus zwischen O und Q enthält. Die Datenoperationen eines Schedules können also völlig andere sein (z.b. Inkrement und Dekrement auf numerischen Werten (Kontostände), Push und Pop auf Stack-Objekten oder Enqueue und Dequeue auf Warteschlangen), dennoch erlaubt diese Charakterisierung von Äquivalenz die Identifikation serialisierbarer Schedules. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-61

62 3.7 Einschränkungen von Konflikt-Serialisierbarkeit Wir untersuchen eingeschränkte Varianten von CSR, die für die Praxis relevant sind Ordnungserhaltende Konflikt-Serialisierbarkeit Idee: Transaktionen, die im parallelen Schedule nicht überlappend auftreten, sollen im äquivalenten seriellen Schedule nicht vertauscht werden. Zur Motivation betrachten wir das folgende Beispiel 3-18: Gegeben sei der Schedule s = w 1 (x)r 2 (x)c 2 w 3 (y)c 3 w 1 (y)c 1. Der Konfliktgraph G(s) ist azyklisch, folglich ist s CSR. Die äquivalente serielle Reihenfolge lautet: t 3 t 1 t 2. In s ist jedoch die Transaktion t 2 bereits abgeschlossen, bevor t 3 überhaupt beginnt. Insofern ist die Serialisierungsreihenfolge nicht sehr intuitiv! Ein Client könnte z.b. explizit auf das Ende von t 2 gewartet haben, bevor t 3 ausgelöst wurde. In diesem Fall wäre aus Anwendungssicht die äquivalente serielle Reihenfolge falsch. Solche Situationen werden durch das folgende Kriterium vermieden. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-62

63 Definition 3-17: (Ordnungserhaltung) Eine History s heißt ordnungserhaltend (orderpreserving) konflikt-serialisierbar, wenn sie konflikt-serialisierbar ist, wenn also eine serielle History s mit op(s) = op(s ) s c s existiert, und wenn das folgende gilt: Für alle t, t trans(s): wenn t vollständig vor t in s abgearbeitet wird, dann auch in s. Die Klasse aller ordnungserhaltend konflikt-serialisierbaren Schedules wird mit OCSR bezeichnet. Trivialerweise gilt: Korollar 3-15: OCSR CSR Die Inklusion OCSR CSR ergibt sich unmittelbar aus der Definition, die Ungleichheit wird mit dem o.a. Beispiel gezeigt. c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-63

64 3.7.2 Commit-Ordnung Idee: Es genügt, die Commit-Reihenfolge von Transaktionen, die im Konflikt stehen, so zu wählen, dass sie mit der Konflikt-Ordnung übereinstimmen. Definition 3-18: (Konflikt-Ordnung) Eine History s heißt Commit-ordnungserhaltend (commit-order-preserving) konflikt-serialisierbar, wenn gilt: Für alle Transaktionen t i, t j commit(s), i j mit (p, q) conf(s), p t i, q t j, ist c i < s c j, d.h. für abgeschlossene Transaktionen, die im Konflikt stehen, legt die Reihenfolge der Konflikt-Operationen die Commit-Reihenfolge fest. Die Klasse aller Commit-ordnungserhaltend konflikt-serialisierbaren Schedules wird mit COCSR bezeichnet. Aus dem Serialisierbarkeitstheorem folgt: Satz 3-16: COCSR CSR Beweis. (siehe Vorlesung) c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-64

65 Satz 3-17: Sei s eine History. Es gilt s COCSR genau dann, wenn 1. s CSR und 2. es gibt eine serielle History s mit s c s, so dass für alle Transaktionen t, t trans(s) gilt: t < s t = c t < s c t. Beweis. (siehe Vorlesung) c M. Scholl, 2002 Transaktionssysteme: 3. Concurrency Control: Korrektheit 3-65