Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler 29.11.2005 TAV WS 2005 283
Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler 29.11.2005 TAV WS 2005 284
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 29.11.2005 TAV WS 2005 285
Transaction Scheduler Weikum, Vossen, 2002 Transaction Manager (TM) Data Manager (DM) Requests Client 2 Client 1 Client 3 1 1 1 1 2 2 2 2... 3 2 1 3 1 3 3 3 3 3 Layer 5 Layer 4 Layer 3 Layer 2 Layer 1 Clients Data Server Database 29.11.2005 TAV WS 2005 286
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) 29.11.2005 TAV WS 2005 287
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) 29.11.2005 TAV WS 2005 288
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) 29.11.2005 TAV WS 2005 289
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) 29.11.2005 TAV WS 2005 290
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) 29.11.2005 TAV WS 2005 291
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) 29.11.2005 TAV WS 2005 292
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) 29.11.2005 TAV WS 2005 293
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 29.11.2005 TAV WS 2005 294
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) 29.11.2005 TAV WS 2005 295
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 29.11.2005 TAV WS 2005 296
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 29.11.2005 TAV WS 2005 297
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? 29.11.2005 TAV WS 2005 298
Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler 29.11.2005 TAV WS 2005 299
Aufgaben (1) Dynamikproblem Auf der Grundlage einer (nicht kontrollierbaren) Eingangsfolge ist ein konfliktserialisierbarer Schedule aufzubauen. Beachte: Die Historie schließt aktive Transaktionen ein. 29.11.2005 TAV WS 2005 300
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 ). 29.11.2005 TAV WS 2005 301
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. 29.11.2005 TAV WS 2005 302
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. 29.11.2005 TAV WS 2005 303
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. 29.11.2005 TAV WS 2005 304
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. 29.11.2005 TAV WS 2005 305
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. 29.11.2005 TAV WS 2005 306
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. 29.11.2005 TAV WS 2005 307
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 29.11.2005 TAV WS 2005 308
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 29.11.2005 TAV WS 2005 309
Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler 29.11.2005 TAV WS 2005 310
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 29.11.2005 TAV WS 2005 311
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. 29.11.2005 TAV WS 2005 312
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. 29.11.2005 TAV WS 2005 313
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) + _ 29.11.2005 TAV WS 2005 314
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. 29.11.2005 TAV WS 2005 315
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. 29.11.2005 TAV WS 2005 316
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. 29.11.2005 TAV WS 2005 317
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 LR4. 29.11.2005 TAV WS 2005 318
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. 29.11.2005 TAV WS 2005 319
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 29.11.2005 TAV WS 2005 320
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}). 29.11.2005 TAV WS 2005 321
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. 29.11.2005 TAV WS 2005 322
Phasen beim 2PL Sperren einer Transaktion growing phase shrinking phase 29.11.2005 TAV WS 2005 323
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 3 29.11.2005 TAV WS 2005 324
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. 29.11.2005 TAV WS 2005 325
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. 29.11.2005 TAV WS 2005 326
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. 29.11.2005 TAV WS 2005 327
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. 29.11.2005 TAV WS 2005 328
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. 29.11.2005 TAV WS 2005 329
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 29.11.2005 TAV WS 2005 330
Korrektheit (5) 29.11.2005 TAV WS 2005 331
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 1 29.11.2005 TAV WS 2005 332
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 29.11.2005 TAV WS 2005 333
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. 29.11.2005 TAV WS 2005 334
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. 29.11.2005 TAV WS 2005 335
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. 29.11.2005 TAV WS 2005 336
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. 29.11.2005 TAV WS 2005 337
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 29.11.2005 TAV WS 2005 338
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. 29.11.2005 TAV WS 2005 339
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.) 29.11.2005 TAV WS 2005 340
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. 29.11.2005 TAV WS 2005 341
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. 29.11.2005 TAV WS 2005 342
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, 2002 29.11.2005 TAV WS 2005 343
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 29.11.2005 TAV WS 2005 344
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 29.11.2005 TAV WS 2005 345 locks locks time time
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. 29.11.2005 TAV WS 2005 346
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 29.11.2005 TAV WS 2005 347