Kapitel 4: Synchronisation: Scheduler

Transkript

1 Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler TAV WS

2 Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler TAV WS

3 Wo stehen wir? Wir kennen jetzt ein verwendbares Kriterium für korrekte Historien, die Konfliktserialisierbarkeit Damit können wir entscheiden, ob eine gegebene Historie äquivalent zu einer seriellen Ausführung ist. Noch offen: Wie finden wir Historien, die dem Korrektheitskriterium entsprechen? Thema in diesem Kapitel: Algorithmen (=Scheduler), die solche Historien erzeugen können. Anforderungen an die Scheduler: Sie sollen nur korrekte Historien erzeugen möglichst viele korrekte Historien erzeugen können TAV WS

4 Transaction Scheduler Weikum, Vossen, 2002 Transaction Manager (TM) Data Manager (DM) Requests Client 2 Client 1 Client Layer 5 Layer 4 Layer 3 Layer 2 Layer 1 Clients Data Server Database TAV WS

5 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) TAV WS

6 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) TAV WS

7 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) TAV WS

8 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) TAV WS

9 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) w 2 (y) TAV WS

10 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) w 2 (y) w 3 (y) TAV WS

11 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) w 2 (y) w 3 (y) w 1 (z) TAV WS

12 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) w 2 (y) w 3 (y) w 1 (z) c TAV WS

13 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) w 2 (y) w 3 (y) w 1 (z) c 2 w 3 (z) TAV WS

14 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) w 2 (y) w 3 (y) w 1 (z) c 2 w 3 (z) c TAV WS

15 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) w 2 (y) w 3 (y) w 1 (z) c 2 w 3 (z) c 1 c TAV WS

16 Beispiel Was sollte der Scheduler jeweils tun? Operationen von t 1 t 2 t 3 kommen in der folgenden Reihenfolge beim Scheduler an: w 1 (x) r 2 (x) r 3 (z) w 1 (y) w 2 (y) w 3 (y) w 1 (z) c 2 w 3 (z) c 1 c 3 Ist es Ihrem Scheduler gelungen, einen konfliktserialisierbaren Schedule zu erzeugen? TAV WS

17 Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler TAV WS

18 Aufgaben (1) Dynamikproblem Auf der Grundlage einer (nicht kontrollierbaren) Eingangsfolge ist ein konfliktserialisierbarer Schedule aufzubauen. Beachte: Die Historie schließt aktive Transaktionen ein TAV WS

19 Aufgaben (2) Konstruktionsaufgabe Durchsetzung der geforderten Serialisierbarkeit allein durch Steuerung der aktiven Transaktionen. Dazu muss nebenläufigen Transaktionen ein Fortschreiten gestattet oder Verharren aufgezwungen werden oder es muss mit zusätzlichen Schritten korrigierend in die Transaktionen eingegriffen werden. Stellt sich zu einem bestimmten Zeitpunkt heraus, dass dies nicht möglich ist, muss ein Präfix gefunden werden, von dem aus der Versuch erneut aufgenommen werden kann. Die nach dem Präfix liegenden Operationen müssen in ihrer Wirkung beseitigt werden ( Rücksetzen ) TAV WS

20 Aufgaben (3) Optimierungsproblem Topologisches Sortieren erlaubt eine Vielzahl äquivalenter serieller Schedules. Der Scheduler kann sich bemühen, unter ihnen einen möglichst guten zu bestimmen. Die Planung wird jedoch dadurch behindert, dass das Eintreffen der Transaktionen und häufig auch ihrer Operationen unbekannt ist. Der serielle Schedule entwickelt sich also situationsbedingt. Dies beschränkt die Optimierungsmöglichkeiten, denn alle Maßnahmen können nur noch in die Zukunft wirken TAV WS

21 Aufgaben (4) Protokoll Satz von Zwangsbedingungen, denen ein (ansonsten noch frei bestimmbarer) Ablauf von Transaktionen gehorchen muss, um ein vorgegebenes Serialisierbarkeitskriterium zu erfüllen. Scheduler Komponente, die den Schedule so konstruiert, dass er dem Protokoll gehorcht, und die die Ablaufkontrolle übernimmt. Verifikationsaufgabe Konstruierte Abläufe erfüllen Protokoll und dieses garantiert Serialisierbarkeitskriterium TAV WS

22 Ablaufkontrolle (1) Ein Scheduler hat für jede Operation, die ihn erreicht, drei Möglichkeiten: sofortiges Ausführen (Weitergabe an den Daten-Verwalter) Verzögern (Einreihen in eine Warteschlange) Zurückweisen (Zurücksetzen der zugehörigen Transaktion) Scheduler unterscheiden sich darin,welche (ein oder zwei) dieser Möglichkeiten sie bevorzugen TAV WS

23 Scheduler Actions and Transaction States Weikum, Vossen, 2002 begin active running block resume blocked restart reject aborted commit committed Definition 4.1 (CSR Safety): For a scheduler S, Gen(S) denotes the set of all schedules that S can generate. A scheduler is called CSR safe if Gen(S) CSR TAV WS

24 Ablaufkontrolle (2) Scheduler unterscheiden sich darin, welche (ein oder zwei) dieser Möglichkeiten sie bevorzugen. Aggressive Scheduler bevorzugen sofortiges Ausführen. Dies führt dazu, dass weniger umgeordnet werden kann (weniger serielle Schedules konstruiert werden können). Konservative Scheduler bevorzugen Verzögerung. Sie bewahren sich also die Möglichkeit umzuordnen, verzögern aber den Fortgang von Transaktionen TAV WS

25 Ablaufkontrolle (2) Scheduler unterscheiden sich heißen darin, auch: welche (ein oder zwei) dieser Möglichkeiten sie bevorzugen. optimistisch Aggressive Scheduler bevorzugen sofortiges Ausführen. Dies führt dazu, dass weniger umgeordnet werden kann (weniger serielle Schedules konstruiert werden können). heißen auch: pessimistisch Konservative Scheduler bevorzugen Verzögerung. Sie bewahren sich also die Möglichkeit umzuordnen, verzögern aber den Fortgang von Transaktionen TAV WS

26 Scheduler Classification Weikum, Vossen, 2002 concurrency control protocols pessimistic optimistic hybrid non-locking locking BOCC FOCC TO SGT two-phase non-two-phase AL O2PL WTL RWTL 2PL C2PL S2PL SS2PL TAV WS

27 Scheduler Classification Weikum, Vossen, 2002 concurrency control protocols pessimistic optimistic hybrid non-locking locking BOCC FOCC TO SGT two-phase non-two-phase AL O2PL WTL RWTL 2PL C2PL S2PL SS2PL TAV WS

28 Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler TAV WS

29 Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Einführung: Sperren 2-Phasen-Sperrprotokoll (2 PL) Verklemmungen Varianten von 2PL Nicht-2-Phasen-Sperrprotokolle Nicht-sperrende Scheduler Hybride Scheduler TAV WS

30 Grundidee Zugriff auf Datenelemente wird durch Sperren geregelt. Transaktionen, die auf ein Element zugreifen wollen, fordern eine Sperre für dieses Element an. Wenn sie das Element nicht mehr brauchen, geben sie die Sperre wieder frei. Solange ein Element gesperrt ist, können andere Transaktionen nicht (oder nur eingeschränkt) darauf zugreifen und müssen warten, bis die Sperre freigegeben wird TAV WS

31 Sperren Gemäß den betrachteten Operationen read und write führen wir zwei Arten von Sperren ein: rl(x) : Lesesperre (read lock), genauer: Sperre durch Leser wl(x): Schreibsperre (write lock), genauer: Sperre durch Schreiber Falls die Operation entweder Lesen oder Schreiben sein kann, schreiben wir ol(x), pl(x) oder ql(x). Transaktionszugehörigkeit wird wieder durch Index ausgedrückt. Wir bezeichnen mit ol i (x) nicht nur die Sperren selbst, sondern gegebenenfalls auch die Operation, die diese Sperre anfordert. Die Freigabe wird mit ou i (x) (unlock) bezeichnet TAV WS

32 Sperrverträglichkeit Definition 4.2 Zwei Sperren pl i (x) und ql j (y) stehen in Konflikt miteinander (pl i (x) ql j (y)) p q und i j. Aus dieser Definition ergibt sich die folgende Tabelle zur Sperrverträglichkeit: rl j (x) wl j (x) lock requestor lock holder rl i (x) wl i (x) + _ TAV WS

33 Sperrender Scheduler: Allgemeines Vorgehen Alle Sperren werden in einer zu Anfang leeren Sperrtabelle gehalten. Der Scheduler arbeitet wie folgt: 1. Treffe o i (x) als nächste Operation ein. 2. Falls ol i (x) noch nicht gesetzt wurde: Überprüfe, ob es pl j (x) in der Sperrtabelle gibt. 1. nein: Setze ol i (x) 2. ja: besteht ein Konflikt? 1. nein: Setze ol i (x) 2. ja: Transaktion i muss auf Freigabe der Sperre warten TAV WS

34 Sperrregeln Weikum, Vossen, 2002 Im Folgenden sollen für jede Transaktion t i die vollständig in einem Schedule s vorkommt, die folgenden Regeln gelten: LR1: Each data operation o i (x) must be preceded by ol i (x) and followed by ou i (x). LR2: For each x and t i there is at most one rl i (x) and at most one wl i (x). LR3: No ru i (x) or wu i (x) is redundant. LR4: If x is locked by both t i and t j, then these locks are compatible TAV WS

35 Sperrregeln Alle Datenelemente werden (irgendwann) vor dem Zugriff Im Folgenden gesperrt. sollen Alle Sperren für jede werden Transaktion t i die vollständig in einem Schedule (irgendwann) s vorkommt, nach die dem folgenden Zugriff Regeln gelten: wieder freigegeben. Weikum, Vossen, 2002 Eine Transaktion kann ein LR1: Each data operation o i (x) must be preceded by ol i (x) and followed Datenelement höchstens einmal by ou i (x). sperren. LR2: For each x and t i there is at most one rl i (x) and at most one wl i (x). Es werden keine unnötigen Sperrfreigaben durchgeführt LR3: No ru Es i (x) werden or wukeine i (x) isinkompatiblen redundant. (= in Konflikt stehenden) Sperren vergeben. LR4: If x is locked by both t i and t j, then these locks are compatible TAV WS

36 Beispiel Beispiel 4.3: t 1 : r 1 (x) w 1 (y) c 1 t 2 : w 2 (y) w 2 (x) c 2 Wir erfassen die Sperroperationen, indem wir Schedules um sie erweitern. Schedule r 1 (x) w 2 (y) w 2 (x) c 2 w 1 (y) c 1 erhält jetzt z.b. das Aussehen s 1 = rl 1 (x) r 1 (x) ru 1 (x) wl 2 (y) w 2 (y) wl 2 (x) w 2 (x) wu 2 (x) wu 2 (y) c 2 wl 1 (y) w 1 (y) wu 1 (y) c 1 s 1 erfüllt die Regeln LR1 LR TAV WS

37 Schedules mit/ohne Sperroperationen Definition 4.4: Sei s ein Schedule unter Einschluss der Sperroperationen. Dann bezeichnet DT(s) die Projektion von s unter Ausschluss der Sperroperationen. Beispiel 4.5: DT(s 1 ) = r 1 (x) w 2 (y) w 2 (x) c 2 w 1 (y) c 1 Bemerkung: Wenn keine Gefahr der Verwechslung besteht, werden wir nicht zwischen s und DT(s) unterscheiden TAV WS

38 Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Einführung: Sperren 2-Phasen-Sperrprotokoll (2 PL) Verklemmungen Varianten von 2PL Nicht-2-Phasen-Sperrprotokolle Nicht-sperrende Scheduler Hybride Scheduler TAV WS

39 Two-Phase Locking (2PL) Weikum, Vossen, 2002 Definition 4.6 (2PL): A locking protocol is two-phase (2PL) if for every output schedule s and every transaction t i trans(s) no ql i step follows the first ou i step (q, o {r, w}) TAV WS

40 Two-Phase Locking (2PL) Weikum, Vossen, 2002 Definition 4.6 (2PL): A locking protocol is two-phase (2PL) if for every output schedule s and every transaction t i trans(s) no ql i step follows the first ou i step (q, o {r, w}). Es werden also von einer Transaktion keine neuen Sperren mehr angefordert, nachdem die erste Sperre freigegeben wurde TAV WS

41 Phasen beim 2PL Sperren einer Transaktion growing phase shrinking phase TAV WS

42 Two-Phase Locking (2PL) Weikum, Vossen, 2002 Definition 4.6 (2PL): A locking protocol is two-phase (2PL) if for every output schedule s and every transaction t i trans(s) no ql i step follows the first ou i step (q, o {r, w}). Example 4.7: s = w 1 (x) r 2 (x) w 1 (y) w 1 (z) r 3 (z) c 1 w 2 (y) w 3 (y) c 2 w 3 (z) c 3 t 1 w 1 (x) w 1 (y) w 1 (z) t 2 r 2 (x) w 2 (y) t 3 r 3 (z) w 3 (y) w 3 (z) wl 1 (x) w 1 (x) wl 1 (y) w 1 (y) wl 1 (z) w 1 (z) wu 1 (x) rl 2 (x) r 2 (x) wu 1 (y) wu 1 (z) c 1 rl 3 (z) r 3 (z) wl 2 (y) w 2 (y) wu 2 (y) ru 2 (x) c 2 wl 3 (y) w 3 (y) wl 3 (z) w 3 (z) wu 3 (z) wu 3 (y) c TAV WS

43 Two-Phase Locking (2PL) Weikum, Vossen, 2002 Definition 4.6 (2PL): A locking protocol is two-phase (2PL) if for every output schedule s and every transaction t i trans(s) no ql i step follows the first ou i step (q, o {r, w}). Transaktion wartet auf Sperre und Example 4.7: ist blockiert, bis sie verfügbar wird s = w 1 (x) r 2 (x) w 1 (y) w 1 (z) r 3 (z) c 1 w 2 (y) w 3 (y) c 2 w 3 (z) c 3 w 1 (x) w 1 (y) w 1 (z) t Transaktion erhält Sperre 1 r 2 (x) wund 2 (y) kann weiterarbeiten t 2 t 3 r 3 (z) w 3 (y) w 3 (z) wl 1 (x) w 1 (x) wl 1 (y) w 1 (y) wl 1 (z) w 1 (z) wu 1 (x) rl 2 (x) r 2 (x) wu 1 (y) wu 1 (z) c Transaktion möchte 1 rl 3 (z) r 3 (z) wl 2 (y) w 2 (y) wu 2 (y) ru 2 (x) c 2 Operation ausführen und wl 3 (y) w 3 (y) wl 3 (z) w 3 (z) wu 3 (z) wu 3 (y) c 3 fordert Sperre an TAV WS

44 Zusammenhang 2PL CSR s 1 = rl 1 (x) r 1 (x) ru 1 (x) wl 2 (y) w 2 (y) wl 2 (x) w 2 (x) wu 2 (x) wu 2 (y) c 2 wl 1 (y) w 1 (y) wu 1 (y) c 1 DT(s 1 ) = r 1 (x) w 2 (y) w 2 (x) c 2 w 1 (y) c 1 Analyse von s 1 : s 1 erfüllt die Regeln LR 1 LR 4. Verstoss gegen 2-Phasen-Regel: Freigabe durch ru 1 (x) vor wl 1 (y). Wegen r 1 (x) < s1 w 2 (x) und w 2 (y) < s1 w 1 (y) ist G(DT(s 1 )) zyklisch, also s 1 nicht serialisierbar TAV WS

45 Korrektheit (1) Wir müssen nun beweisen, dass alle durch das 2PL-Protokoll generierten Historien konfliktserialisierbar sind. Dazu gehen wir in zwei Schritten vor: Formalisierung von Eigenschaften, die alle 2PL-Historien haben. Nachweis, dass aus diesen Eigenschaften Konflikt-Serialisierbarkeit folgt TAV WS

46 Korrektheit (2) Zur Erinnerung: Definition 3.5 (Schedules and histories): Let T={t1,..., tn} be a set of transactions, where each ti T has the form ti=(opi, <i) with opi denoting the operations of ti and <i their ordering. A history for T is a pair s=(op(s),<s) s.t. (a) op(s) i=1..n opi i=1..n {ai, ci} (b) for all i, 1 i n: ci op(s) ai op(s) (c) i=1..n <i <s (d) for all i, 1 i n, and all p opi: p <s ci or p <s ai (e) for all p, q op(s) s.t. at least one of them is a write and both access the same data item : p <s q or q <s p (ii) A schedule is a prefix of a history TAV WS

47 Korrektheit (3) Lemma 4.8 (Eigenschaften von 2PL Schedules): Sei s die Ausgabe eines 2PL-Schedulers. Dann gilt für jede Transaktion t i DT(s): 1. o i (x) CP(DT(s)) ol i (x), ou i (x) CP(DT(s)) ol i (x) < s o i (x) < s ou i (x). 2. t j commit(dt(s)), i j: p i (x),q j (x) CP(DT(s)): p i (x) q j (x) pu i (x) < s ql j (x) qu j (x) < s pl i (x) 3. p i (x), q j (y) CP(DT(s)) pl i (x) < s qu i (y). Die Eigenschaften folgen unmittelbar aus LR 1 4 und dem 2PL Protokoll TAV WS

48 Korrektheit (4) Lemma 4.9 (Konfliktgraph von 2PL Schedules): Sei s die Ausgabe eines 2PL-Schedulers und sei G := G(CP(DT(s))) der Konfliktgraph von CP(DT(s)). Dann gilt: 1. (t i, t j ) E(G) x, p i (x), ql j (x): pu i (x) < s ql j (x) 2. Sei (t 1, t 2,.,t n ) ein Pfad in G pu 1 (x) < s ql n (y) 3. G ist azyklisch Beweis TAV WS

49 Korrektheit (5) TAV WS

50 Korrektheit (6) Satz 4.10 Gen(2PL) CSR Beweis: folgt unmittelbar aus 4.9 Echte Teilmenge: s = w 1 (x) r 2 (x) c 2 r 3 (y) c 3 w 1 (y) c TAV WS

51 Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Einführung: Sperren 2-Phasen-Sperrprotokoll (2 PL) Verklemmungen Varianten von 2PL Nicht-2-Phasen-Sperrprotokolle Nicht-sperrende Scheduler Hybride Scheduler TAV WS

52 Verklemmungen (1) Unglücklicherweise können durch dieses Sperrprotokoll Verklemmungen entstehen: Beispiel 4.11 s 1 = rl 1 (x) r 1 (x) rux 1 (x) wl 2 (y) w 2 (y) wl 2 (x) w 2 (x) wu 2 (x) wu 2 (y) c 2 wl 1 (y) w 1 (y) wu 1 (y) c 1 Historie kann durch kein 2PL-Protokoll fortgesetzt werden: Weder t 1 noch t 2 kann weitergeführt werden TAV WS

53 Verklemmungen (2) Besonders häufige Ursache von Verklemmungen: Sperrverschärfung rl zu wl. Beispiel 4.12 Betrachte Transaktionen t 4 : r 4 (x) w 4 (x) c 4 t 5 : r 5 (x) w 5 (x) c 5 und Historie s 3 = rl 4 (x) r 4 (x) rl 5 (x) r 5 (x) Wieder kann die Historie nicht ohne Protokollverletzung fortgeführt werden: t 4 kann wegen rl 5 (x), t 5 wegen rl 4 (x) nicht weitergeführt werden TAV WS

54 Verklemmungen (3) Behandlung von Verklemmungen: Timeout: Wecker für jede Transaktion, der bei zu großer Verzögerung abläuft. Probleme: Vermutungsbasiert, geeignete Wahl des Timeout- Intervalls. Wartegraph WFG = (N,E) mit N = active(s) E = {(t i, t j ) t i wartet auf Sperrenfreigabe durch t j } Verklemmung liegt vor bei Zyklus. Test entweder: ständig (continuous) oder periodisch Probleme: Leistungseinbuße, geeignete Wahl des Testintervalls TAV WS

55 Verklemmungen (4) Beseitigung der Verklemmung nur durch Abbrechen einer am Zyklus beteiligten Transaktion. Zur Auswahl können folgende Kriterien dienen: Bereits durch eine Transaktion entstandene Kosten. Kosten, eine Transaktion zu Ende zu führen. Kosten, eine Transaktion abzubrechen. Anzahl der Zyklen, an denen eine Transaktion beteiligt ist. Anzahl der bereits früher durch Verklemmungen bedingten Abbrüche einer Transaktion. Aus diesen Kriterien lassen sich unterschiedliche Strategien zur Auswahl der abzubrechenden Transaktion ableiten TAV WS

56 Deadlock Resolution Weikum, Vossen, 2002 Choose a transaction on a WFG cycle as a deadlock victim and abort this transaction,and repeat until no more cycles. Possible victim selection strategies: 1. Last blocked 2. Random 3. Youngest 4. Minimum locks 5. Minimum work 6. Most cycles 7. Most edges TAV WS

57 Example 4.13: Illustration of Victim Selection Strategies Weikum, Vossen, 2002 t 8 t 9 t 6 t 5 t 4 t 7 t 10 t 1 t 2 t 3 Most-cycles strategy would select t 1 (or t 3 ) to break all 5 cycles. Example 4.14: t 2 t 1 t 3 t 4 t 5 t 6 Most-edges strategy would select t 1 to remove 4 edges TAV WS

58 Deadlock Resolution: Problem alle genannten Strategien können zu Livelock (auch Starvation genannt) führen: Dieselbe Transaktion wird immer wieder zum Abbruch ausgewählt und neu gestartet (und gerät dann wieder in einen Zyklus und wird als Opfer gewählt etc.) TAV WS

59 Alternative zur Verklemmungsbehandlung statt abzuwarten bis im WFG-Graphen ein Zyklus enthalten ist und diesen dann aufzubrechen, kann man auch versuchen, die Entstehung von Zyklen zu verhindern TAV WS

60 Deadlock Prevention Restrict lock waits to ensure acyclic WFG at all times. Reasonable deadlock prevention strategies: 1. Wait-die: upon t i blocked by t j : if t i started before t j then wait else abort t i 2. Wound-wait: upon t i blocked by t j : if t i started before t j then abort t j else wait 3. Immediate restart: upon t i blocked by t j : abort t i 4. Running priority: upon t i blocked by t j : if t j is itself blocked then abort t j else wait Weikum, Vossen, 2002 Abort entails later restart TAV WS

61 Deadlock Prevention Restrict lock waits Transaktionen to ensurekönnen acyclic nur WFG von jüngeren at all times. Reasonable deadlock prevention strategies: 1. Wait-die: upon t i blocked by t j : if t i started before Transaktionen t j thenblockiert wait else werden. abort t i 2. Wound-wait: upon t i blocked by t j : if t i started before t j then abort t j else wait 3. Immediate restart: upon t i blocked by t j : nicht abort behindern t i 4. Running priority: upon t i blocked by t j : if t j is itself blocked then abort t j else wait Abort entails later restart. Transaktionen blockiert werden. Transaktionen können nur von älteren hier gibt es gar keine Blockaden blockierte Transaktionen dürfen aktive Weikum, Vossen, TAV WS

62 Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Einführung: Sperren 2-Phasen-Sperrprotokoll (2 PL) Verklemmungen Varianten von 2PL Nicht-2-Phasen-Sperrprotokolle Nicht-sperrende Scheduler Hybride Scheduler TAV WS

63 Variants of 2PL Weikum, Vossen, 2002 general 2PL locks Definition 4.14 (Conservative 2PL): Under static or conservative 2PL (C2PL) each transaction acquires all its locks before the first data operation (preclaiming). Definition 4.15 (Strict 2PL): Under strict 2PL (S2PL) each transaction holds all its write locks until the transaction terminates. Definition 4.16 (Strong 2PL): Under strong 2PL (SS2PL) each transaction holds all its locks (i.e., both r and w) until the transaction terminates. time TAV WS locks locks time time

64 Properties of S2PL and SS2PL Weikum, Vossen, 2002 Theorem 4.17: Gen(SS2PL) Gen(S2PL) Gen(2PL) Theorem 4.18: Gen(SS2PL) COCSR Sowohl S2PL als auch (und insbesondere) SS2PL werden später noch sehr wichtig sein. Wir werden sie, wenn wir uns mit Fehlerbehandlung beschäftigen, wieder treffen. SS2PL ist das Protokoll, das von den meisten kommerziellen Systemen verwendet wird TAV WS

65 Beispiele Beispiel 4.19 s = r 1 (x) w 1 (z) r 2 (z) w 1 (y) c 1 r 3 (y) w 2 (z) c 2 w 3 (x) w 3 (y) c 3 2PL C2PL S2PL SS2PL TAV WS