Scheduler. vereinfachende Annahmen: alle Transaktionen werden wirksam nur Konflikt-Serialisierbarkeit keine Versionen

Transkript

1 Scheduler Der Scheduler des Informationssystems hat zunächst die Aufgabe, die Anweisungen von parallel auszuführenden Transaktionen in einer geeigneten Reihenfolge anzuordnen. Darüber hinaus muß er auch jeweils die zu benutzenden Versionen geeignet bestimmen. Wichtige Gesichtspunkte für das Geeignetsein: Serialisierbarkeit Zuverlässigkeit falls (unter der Annahme, daß alle Transaktionen wirksam werden), (d.h. Serialisierbarkeit auch dann, Transaktionen abgebrochen werden müssen). vereinfachende Annahmen: alle Transaktionen werden wirksam nur Konflikt-Serialisierbarkeit keine Versionen vereinfachtes Modell eines Schedulers: Ein Scheduler ist eine Transformation, die jedem anweisungsweise gegebenen (Eingabe-) Plan zu einer Menge von Transaktionen T, einen (Ausgabe-) Plan zu T, der Konflikt-serialisierbar ist, wiederum anweisungsweise zuordnet. Der Eingabeplan sei durch das zeitlich geordnete Eintreffen der Anweisungen gegeben, wie sie von den die Transaktionen ausführenden Prozessen angefordert werden. Der Ausgabeplan werde dadurch erzeugt, daß die Ausführung einer angeforderten Anweisung gegebenenfalls verzögert wird, d.h. daß sie zunächst in einen Wartebereich eingeordnet wird und erst nach dem Eintreffen bestimmter Bedingungen, die durch die vorgezogene Ausführung später angeforderter Anweisungen eingetreten sind, ausgeführt wird. Der Prozeß, der die verzögerte Anweisung angefordert hat, muß im allgemeinen solange unterbrochen bleiben (und kann damit insbesondere keine weiteren Anweisungen anfordern)

2 Grobstruktur eines Schedulers Konfliktgraphen-Scheduler Folge der Anweisungen des Eingabeplanes Wartebereich Scheduler Bedingungen entsprechend der Vorgeschichte Folge der Anweisungen des Ausgabeplanes Der einfachste, aber leider praktisch kaum brauchbare Ansatz für einen Scheduler besteht offenbar darin, den Konfliktgraphen dynamisch aufzubauen: Wenn eine Anweisung neu angefordert wird, prüft der Scheduler, ob sie mit schon vorher wieder ausgegebenen Anweisungen im Konflikt liegt, und trägt gegebenenfalls neue Kanten in den Konfliktgraphen ein. Falls kein Zykel entstanden ist, so wird die Anweisung sofort wieder ausgegeben und ausgeführt. Falls ein Zykel entstanden ist, so ist die Situation unter unseren Annahmen hoffnungslos: der einzige Ausweg wäre ein Abbruch der anfordernden Transaktion mit all den damit verbundenen Problemen. Der Konfliktgraphen-Scheduler läßt genau die Konflikt-serialisierbaren Pläne unverändert durch, während alle anderen Eingabepläne blockiert werden

3 Sperrprotokoll-Scheduler Der nächste Ansatz für einen Scheduler verlangt, daß die Transaktionen Objekte, aus denen sie lesen oder in die sie schreiben wollen, vorher ausdrücklich sperren (lock) und nachher wieder ausdrücklich freigeben (unlock). Genauer müssen Transaktionen, die einem Sperrprotokoll genügen, aus folgenden Anweisungen aufgebaut werden: Read o : lies aus Objekt o; Write o : schreibe in Objekt o; RLock o : sperre Objekt o zum Lesen; WLock o : sperre Objekt o zum Schreiben (wobei dann auch Lesen erlaubt ist); Erweiterung des Read/Write Modells um Sperren Wie zuvor müssen die in Annahme A3* genannten Bedingungen erfüllt sein. Zusätzlich muß jeder Leseanweisung Read o genau eine Anweisung der Form RLock o oder Wlock o vorausgehen und genau eine Anweisung der Form Unlock o folgen. Entsprechend muß jeder Schreibanweisung Write o genau eine Anweisung der Form WLock o vorausgehen und genau eine Anweisung der Form Unlock o folgen. Ferner setzen wir voraus, daß jedes Lock-Unlock-Paar tatsächlich eine entsprechende Lese- oder Schreiboperation umklammert. Unlock o : gib Objekt o frei

4 Semantik von Sperren Wird eine Sperranweisung i1.j1 : RLock o ausgeführt, so hält die Transaktion t i1 eine Lesesperre auf dem Objekt o, bis die zugehörige Freigabeanweisung i1.j2 : Unlock o ausgeführt wird: dazwischen kann t i1 aus o lesen, und andere Transaktionen können ebenfalls Lesesperren auf o, aber keine Schreibsperren auf o erhalten. Verträglichkeiten Lesesperren können geteilt werden (shared locks). Schreibsperren werden exklusiv gehalten (exclusive locks). Konflikte zwischen Lese- und Schreibanweisungen verschiedener Transaktionen entsprechen genau den Unverträglichkeiten zwischen den zugehörigen Sperranweisungen. Wird eine Sperranweisung i1.j1 : WLock o ausgeführt, so hält die Transaktion t i1 eine Schreibsperre auf dem Objekt o, bis die zugehörige Freigabeanweisung i1.j2 : Unlock o ausgeführt wird: dazwischen kann t i1 in o schreiben oder erst aus o lesen und dann in o schreiben, und andere Transaktionen können weder eine Lese- noch eine Schreibsperre auf o erhalten. Verträglichkeitsmatrix: von t i1 für o RLock angeforderte Sperre: WLock von einer anderen Transaktion bereits gehaltene Sperre auf o: RLock + WLock

5 Sperrprotokoll-Scheduler beachtet nur die Sperr- und Freigabeanweisungen und verfährt dabei wie folgt: Wenn eine Sperranweisung neu angefordert wird, so prüft der Scheduler, ob sie mit den schon gehaltenen Sperren verträglich ist. Falls dies der Fall ist, so wird die Sperranweisung ausgeführt, d.h. die verlangte Sperre wird vergeben. Falls dies nicht der Fall ist, so wird die Sperranweisung verzögert und in den Wartebereich eingeordnet. Wenn eine Freigabeanweisung neu angefordert wird, so wird sie ausgeführt, indem die entsprechende Sperre aufgehoben wird und indem gegebenenfalls auf diese Freigabe wartende Sperranweisungen erneut bearbeitet werden. Ein Sperrprotokoll-Scheduler bearbeitet solche Transaktionen erfolgreich, die dem Zwei-Phasen-Sperrprotokoll genügen, d.h. in denen alle Sperranweisungen vor allen Freigabeanweisungen liegen. Konflikt-Serialisierbarkeit unter dem Zwei-Phasen-Sperrprotokoll Sei P ein Plan zu einer Menge von Transaktionen T = {t 1,..., t k } mit folgenden Eigenschaften: a. [Zwei-Phasen-Sperrprotokoll] Alle Transaktionen aus T genügen dem Zwei-Phasen- Sperrprotokoll. b. [Sperrprotokoll-Scheduler] Im Plan P halten je zwei Transaktionen keine unverträglichen Sperren (d.h. P ist möglicher Ausgabeplan des Sperrprotokoll- Schedulers). Dann gilt: 1. Für i = 1,..., k sei die Sperrzeit z i diejenige Zeitmarke von P, zu der die Transaktion t i ihre letzte Sperranweisung ausführt, und π : {1,..., k} {1,..., k} sei eine Permutation mit z π(1) < z π(2) <... < z π(k). Dann ist (nach dem Weglassen der Sperr- und Freigabeanweisungen) P Konflikt-äquivalent zum seriellen Plan P = (t π(1), t π(2),..., t π(k) ). 2. P ist (nach dem Weglassen der Sperr- und Freigabeanweisungen) Konflikt-serialisierbar

6 Beweis: 1: Wir müssen zeigen, daß je zwei im Konflikt liegende Anweisungen in P und P in der gleichen Reihenfolge ausgeführt werden. Seien also für Zeitpunkte w 1 < w 2 P(w 1 ) = i1.j1 : Op 1 o und P(w 2 ) = i2.j2 : Op 2 o zwei Anweisungen, die im Konflikt liegen. Dann ist Op 1 = Write oder Op 2 = Write. Da eine Write-Anweisung eine exklusive Sperre verlangt, muß die Transaktion t i1 nach dem Zeitpunkt w 1, etwa zum Zeitpunkt w 1 *, ein Unlock o ausführen, Die vorliegende Situation kann man sich wie folgt veranschaulichen: Sperrzeit von t i1 Sperrzeit von t i2 z i1 z i2 > Zeit w1 i1.j1: Op 1 o w1 * i1.j1 * : Unlock o w2 2.j2 * : Lock o w2 * i2.j2: Op 2 o bevor Transaktion t i2 vor dem Zeitpunkt w 2, etwa zum Zeitpunkt w 2 *, ein WLock o bzw. RLock o ausführt. Wegen des Zwei-Phasen-Sperrprotokolls erfolgen in jeder Transaktion alle Sperranweisungen vor allen Freigabeanweisungen, also gilt: z i1 < w 1 * < w 2 * z i2. Also werden die beiden betrachteten Anweisungen im seriellen Plan P in der gleichen Reihenfolge ausgeführt. 2. Folgt unmittelbar aus

7 Sperrprotokoll-Scheduler verlangt Zwei-Phasen-Sperrprotokoll Nach Voraussetzung enthält t 1 eine Teilfolge der folgenden Form: Satz Die Transaktion t 1 genüge einem Sperrprotokoll, entspreche aber nicht dem Zwei-Phasen-Aufbau. Dann gibt es eine Transaktion t 2 und für T := {t 1, t 2 } einen Plan P, so daß gilt, 1. [Sperrprotokoll-Scheduler] t 1 und t 2 halten keine unverträglichen Sperren. 2. P ist nicht Konflikt-serialisierbar. t 1 = (. 1.j1 : Op o 1,. 1.j2 : Unlock o 1,. 1.j3 : OpLock o 2,. 1.j4 : Op o 2,. 1.j5 : Unlock o 2,. ) Wir definieren dann: t 2 = ( 2.1 : WLock o 1, 2.2 : WLock o 2, 2.3 : Write o 1, 2.4 : Write o 2, 2.5 : Unlock o 1, 2.6 : Unlock o 2 ) Ferner sei Plan P dadurch definiert, daß t 2 als Ganzes direkt nach der Anweisung 1.j2 : Unlock o 1 angeordnet werde

8 Dann enthält P insbesondere diese Teilfolge: P = (. ) 1.j1 : Op o 1,. 2.3 : Write o 1, 2.4 : Write o 2,. 1.j4 : Op o 2,. Also erzeugen die im Konflikt liegenden Anweisungen, nämlich 1.j1 : Op o 1 und 2.3 : Write o 1, 2.4 : Write o 2 und 1.j4 : Op o 2, einen Zykel im Konfliktgraphen, d.h. P ist nicht Konflikt-serialisierbar. Verklemmungen Transaktionen können in eine Verklemmung (deadlock) geraten, wenn sie wechselseitig schon von der jeweils anderen Transaktion gehaltene Sperren anfordern. Ein typisches Muster für diese Situation ist gegeben, wenn zwei Transaktionen t 1 und t 2 Anweisungen wie folgt in den Scheduler eingeben: angeforderte Anweisung Verhalten des Schedulers 1.1 : WLock A t 1 erhält Schreibsperre auf A 2.1 : WLock B t 2 erhält Schreibsperre auf B 1.2 : WLock B Anforderung ist unverträglich: t 1 muß auf die Ausführung von 2.j2 : Unlock B warten 2.2 : WLock A Anforderung ist unverträglich: t 2 muß auf die Ausführung von 1.j1 : Unlock A warten Also tritt eine Verklemmung ein: t 1 wartet auf t 2, und t 2 wartet auf t 1. Wenn solche Verklemmungen nicht durch geeignete Maßnahmen verhindert werden, so müssen sie durch Abbruch einer Transaktion aufgelöst werden

9 Striktes Sperrverhalten Phase 1: [Sperren] Alle benötigten Objekte werden gesperrt. (Falls dies als eine unteilbare Operation verwirklicht wird, werden sogar Verklemmungen vermieden; andernfalls können Phase 1 und 2 auch ineinander verschränkt werden.) Phase 2: [Schreiben in eine Logdatei] Alle Schreiboperationen werden zunächst nicht im gemeinsamen Informationssystem, sondern in einer gesonderten Logdatei durchgeführt. Die Logdatei enthält damit für andere Transaktionen unzugängliche Versionen. Phase 3: [Kopieren der Logdatei in das Informationssystem] Erreicht die Transaktion die Commit_Trans-Anweisung, so werden erst dann alle Schreiboperationen auf einmal (als eine unteilbare Operation) tatsächlich im Informationssystem durchgeführt, indem die Logdatei einfach kopiert wird. Phase 4: [Freigeben] Alle gesperrten Objekte werden wieder freigegeben. sperren in Logdatei schreiben Logdatei ins Informationssystem kopieren freigeben BEGIN_TRANS Commit_Trans END_TRANS Phase 1 und 4 verwirklichen das Zwei-Phasen-Sperrprotokoll. Phase 2 und 3 verwirklichen im wesentlichen hinreichende Bedingungen für Zuverlässigkeit. Es gibt eigentlich nur eine einzige abschließende Schreibanweisung, und nur die dabei gültig gewordenen Versionen können als zuletzt erzeugte von nachfolgenden Leseanweisungen anderer Transaktionen gelesen werden. Wird insbesondere eine Transaktion innerhalb der Phasen 1 und 2 absichtlich abgebrochen, so ergeben sich keine Auswirkungen auf andere Transaktionen (außer vielleicht Verzögerungen durch die Sperren). Zeit

10 Sperren für baumartige Objektstrukturen Gemäß unserer Annahme A4 haben wir Objekte bislang als unstrukturiert und in keinerlei Beziehung zueinander stehend angenommen. Oftmals liegen jedoch auf natürliche Weise baumartige Schachtelungs- oder Verzweigungsstrukturen vor. Beispiel für Schachtelungsstruktur: eine relationale Datenbank-Instanz M = (d,r 1,..., r n ) besteht aus Relationen-Instanzen r i, die wiederum in Blöcke aufgeteilt gespeichert werden, die ihrerseits schließlich die Tupel enthalten; Beispiel für Verzweigungsstruktur: ein Index kann durch einen B * -Baum verwirklicht werden. Man kann nun versuchen, Sperrprotokolle gezielt auf solche Strukturen abzustimmen. Baum-Sperrprotokoll Wir betrachten Transaktionen, die aus Folgen von Anweisungspaaren der Form Read o; Write o mit der jeweils zugehörigen Sperranweisung WLock o und der zugehörigen Freigabeanweisung Unlock o aufgebaut sind. Wir behandeln baumartige Verzweigungsstrukturen, Eine Transaktion t genügt dem Baum-Sperrprotokoll, wenn gilt: (1) Das erste von t gesperrte Objekt darf ein beliebiges Objekt im Baum sein. (2) Jedes weitere Objekt o darf von t nur dann gesperrt werden, wenn t eine Sperre auf dem direkten Vorgängerobjekt (bezüglich der Baumstruktur) von o hält. (3) Jedes Objekt darf von t höchstens einmal gesperrt werden

11 Konflikt-Serialisierbarkeit unter dem Baum-Sperrprotokoll Satz Sei P ein Plan zu einer Menge von Transaktionen T = {t 1,..., t k } (der oben beschriebenen Art) mit folgenden Eigenschaften: a. [Baum-Sperrprotokoll] Alle Transaktionen aus T genügen dem Baum- Sperrprotokoll. b. [Sperrprotokoll-Scheduler] Im Plan P halten je zwei Transaktionen keine unverträglichen (d.h. hier gemeinsamen) Sperren. Warn-Sperrprotokoll Wir behandeln baumartige Schachtelungsstrukturen. Hier ist es sinnvoll festzulegen, daß mit dem (ausdrücklichen) Sperren eines Objekts o auch alle in o geschachtelte Unterobjekte (stillschweigend) mitgesperrt werden. Um Unverträglichkeiten zwischen ausdrücklichen und stillschweigenden Sperren leicht erkennen zu können und um Serialisierbarkeit zu sichern, müssen alle Zugriffe über die Wurzel der Baumstruktur längs des Pfades zum zu bearbeitenden Objekt erfolgen. Dann ist P Konflikt-serialisierbar. Dabei werden aber die Oberobjekte des eigentlich zu bearbeitenden Objekts nur gewarnt. Dazu benötigen wir Warnanweisungen der Form Warn o, die ebenso wie Sperranweisungen wieder durch eine zugehörige Freigabeanweisung Unlock o aufgehoben werden müssen

12 Warn-Sperrprotokoll Eine aus Warn-, Sperr-, Lese/Schreib- und Freigabeanweisungen aufgebaute Transaktion t genügt dem Warn-Sperrprotokoll wenn gilt: (1) Die erste Anweisung von t sperrt oder warnt die Wurzel der Baumstruktur. (2) Jedes weitere Objekt o darf von t nur gesperrt oder gewarnt werden, wenn t eine Warnung auf dem direkten Vorgängerobjekt (bezüglich der Baumstruktur) von o hält. (Falls t sogar eine Sperre auf dem Vorgängerobjekt hält, so hat t stillschweigend auch o mitgesperrt und braucht also bezüglich o keine weiteren Vorbereitungen zu treffen.) Warn-Sperrprotokoll-Scheduler arbeitet im wesentlichen wie der gewöhnliche Sperrprotokoll-Scheduler, wobei jetzt die folgenden Verträglichkeiten gelten: von t für o angeforderte Warn i1 Warnung oder Sperre: WLock von einer anderen Transaktion bereits gehaltene Warnung oder ausdrückliche Sperre auf o: Warn + WLock (3) t darf ein Objekt nur freigeben, wenn t keine Sperre oder Warnung auf einem der (direkten) Nachfolgerobjekte von o hält. (4) t besteht aus einer anfänglichen Warn-Sperr-Phase und einer anschließenden Freigabe-Phase, d.h. alle Sperr- und Warnanweisungen liegen vor allen Freigabeanweisungen

13 Konflikt-Serialisierbarkeit unter dem Warn-Sperrprotokoll Satz Sei P ein Plan zu einer Menge von Transaktionen T = {t 1,..., t k } (der oben beschriebenen Art) mit folgenden Eigenschaften: a. [Warn-Sperrprotokoll] Alle Transaktionen aus T genügen dem Warn- Sperrprotokoll. b. [Warn-Sperrprotokoll-Scheduler] Im Plan P halten je zwei Transaktionen keine unverträglichen Warnungen oder ausdrücklichen Sperren. Dann ist P Konflikt-serialisierbar. Zeitmarken-Scheduler Ein Ansatz für einen Scheduler, bei dem jeder Transaktion t i bei ihrem Start eine (statische) Zeitmarke s i := Startzeit von t i zugeordnet wird und für jedes Objekt o zwei geeignet initialisierte (dynamische) Zeitmarken o read := max {s i t i hat aus Objekt o gelesen} o write := max {s i t i hat in Objekt o geschrieben} unterhalten werden. Ein Zeitmarken-Scheduler beobachtet und verändert nun die Zeitmarken mit dem Ziel, nur solche Ausgabe-Pläne zuzulassen, die (Konflikt-) äquivalent zu demjenigen seriellen Plan sind, in dem die Transaktionen in der Reihenfolge ihrer Zeitmarken ausgeführt werden. Falls wegen eines sichtbar werdenden Konflikts das Ziel gefährdet wird, bricht der Scheduler eine am Konflikt beteiligte Transaktion ab

14 Zeitmarken-Scheduler verfährt gemäß folgender Regeln: 1. [Leseanforderungen] Falls Transaktion t i eine Leseanweisung Read o anfordert, so wird die Zeitmarke s i verglichen mit den Zeitmarken der Transaktionen, die vorangehende, im Konflikt liegende Schreibanweisungen enthalten: falls o write < s i, falls o write > s i, dann wird die Leseanweisung ausgeführt und o read := max {o read, s i } gesetzt; dann wird Transaktion t i abgebrochen. 2. [Schreibanforderungen] Falls Transaktion t i eine Schreibanweisung Write o anfordert, so wird die Zeitmarke s i verglichen mit den Zeitmarken der Transaktionen, die vorangehende, im Konflikt liegende Lese- oder Schreibanweisungen enthalten: falls o read s i und o write < s i, dann wird die Schreibanweisung ausgeführt und o write := s i gesetzt; Transaktionen: t 1 := ( 1.1: Read A, t 3 := ( 3.1: Read C, 1.2: Write C, 3.2: Write A ) 1.3: Write B ) t 2 := ( 2.1: Read A, t 4 := ( 4.1: Read B, 2.2: Read B, 4.2: Read C, 2.3: Write D ) 4.3: Write B, 4.4: Write A ) Zeitmarken, entsprechend ihrer Startzeiten zugeordnet: s 1 := 1, s 2 := 2, s 3 := 4, s 4 := 6. falls o read > s i oder o write > s i, dann wird Transaktion t i abgebrochen

15 Wertverlauf der dynamischen Zeitmarken für einen Plan P P z A r A w B r B w C r C w D r D w erfüllte Bedingung : Read A A w < s 1 2.1: Read A A w < s 2 1.2: Write C C r s 1 C w < s 1 3.1: Read C C w < s 3 1.3: Write B B r s 1 B w < s 1 4.1: Read B B w < s 4 4.2: Read C C w < s 4 2.2: Read B B w < s 2 3.2: Write A A r s 3 A w < s 3 4.3: Write B B r s 4 B w < s 4 2.3: Write D D r s 2 D w < s 2 4.4: Write A A r s 4 A w < s 4 Würde man im Plan P die ersten beiden Anweisungen vertauschen, so erhielte Transaktion t 1 die Startzeit s 1 := 2 und Transaktion t 2 die Startzeit s 2 := 1. Dieser Plan ist nicht Konflikt-äquivalent zum seriellen Plan P = {t 2, t 1, t 3, t 4 }. Die Anforderung der Leseanweisung 2.2 : Read B würde zum Zeitpunkt 8 zum Abbruch der Transaktion t 2 führen, weil die Bedingung B w < s 2 für B w = 2 und s 2 = 1 nicht erfüllt wäre

16 Konflikt-Serialisierbarkeit unter dem Zeitmarken-Scheduler Satz Sei P ein Plan zu einer Menge von Transaktionen T = {t 1,..., t k } mit der Eigenschaft, daß er möglicher Ausgabeplan des Zeitmarken-Schedulers ist. Nutzlose Schreibanweisungen Durch Verfeinerung der Regeln kann man im Konflikt liegende, aber erkennbar nutzlose Schreibanweisungen einfach überspringen: 2* [Schreibanforderungen] Transaktion t i fordert eine Schreibanweisung Write o an: 1. Für i = 1,.., k sei s i die Startzeit von t i und π : {1,..., k} {1,..., k} eine Permutation mit s π(1) < s π(2) <... < s π(k). Dann ist P Konflikt-äquivalent zum seriellen Plan P = (t π(1),..., t π(k) ). 2. P ist Konflikt-serialisierbar. Beweis: 1. Wir müssen zeigen, daß je zwei im Konflikt liegende Anweisungen in P und P in der gleichen Reihenfolge ausgeführt werden. Genau dies wird aber durch die Regeln des Zeitmarken- Schedulers sichergestellt. 2. Folgt unmittelbar aus 1. falls o read s i und o write < s i, falls o read > s i, falls o read s i und o write > s i, dann wird die Schreibanweisung ausgeführt und o write := s i gesetzt; dann wird Transaktion t i abgebrochen; dann wird die Schreibanweisung einfach übersprungen

17 Unvergleichbarkeit von Zwei-Phasen- Sperrprotokoll und Zeitmarken-Scheduler Unter dem Zwei-Phasen-Sperrprotokoll wird Konflikt- Äquivalenz zu dem seriellen Plan sichergestellt, der die Transaktionen in der Reihenfolge ihrer Sperrzeiten ausführt. Unter dem Zeitmarken-Scheduler wird Konflikt- Äquivalenz zu dem seriellen Plan sichergestellt, der die Transaktionen in der Reihenfolge ihrer Startzeiten ausführt. Der folgende Satz besagt, daß beide Verfahren manche eigentlich Konfliktserialisierbaren Pläne als Ausgaben ausschließen und daß die beiden Klassen der jeweils erzeugbaren Ausgabepläne (bezüglich Mengeninklusion) unvergleichbar sind. Satz 1. Es gibt einen Plan P1, der als Ausgabeplan unter dem Zwei-Phasen-Sperrprotokoll (nach dem Weglassen von Sperr- und Freigabeanweisungen) möglich ist, aber nicht unter dem Zeitmarken-Scheduler. 2. Es gibt einen Plan P2, der als Ausgabeplan unter dem Zeitmarken-Scheduler möglich ist, aber nicht unter dem Zwei-Phasen-Sperrprotokoll. 1. Wir betrachten den folgenden Plan zur Menge von Transaktionen T = {t 1, t 2 }: P * := z ( 2.1 : RLock B, : Read B, : RLock A, : Read A, : WLock C, : Write C, : Unlock C, : Unlock A, : WLock C, : Write C, : Unlock C, : Unlock B ) 12 Die Transaktionen t 1 und t 2 genügen dem Zwei-Phasen- Sperrprotokoll, und der Plan vergibt keine unverträglichen Sperren

18 Nach dem Weglassen der Sperr- und Freigabeanweisungen erhält man den Plan P1 = ( 2.2 : Read B, 1.2 : Read A, 1.4 : Write C, 2.4 : Write C ), dessen Konfliktgraph t C 1 t 2 ist. Diese Reihenfolge entspricht gerade den Sperrzeiten z 1 = 5 ( Zeitpunkt von 1.3 : WLock C ) und z 2 = 9 ( Zeitpunkt von 2.3 : WLock C ). Der Zeitmarken-Scheduler versucht jedoch mit Hilfe der Startzeiten s 1 = 2 und s 2 = 1, Konflikt-Äquivalenz zum seriellen Plan P = (t 2, t 1 ) sicherzustellen, was zum Abbruch der Transaktion t 2 bei Anweisung 2.4 : Write C führt: P1 z A r A w B r B w C r C w erfüllte Bedingung : Read B B w < s 2 1.2: Read A A w < s 1 1.4: Write C C r s 1 C w < s 1 2.4: Write C 4 Abbruch wegen C w = 2 > 1 = s

19 2. Wir betrachten den folgenden Plan P2 zur Menge von Transaktionen T = {t 1, t 2, t 3 } mit Startzeiten s 1 = 1, s 2 = 2 und s 3 = 3, der als Ausgabeplan unter dem Zeitmarken-Scheduler möglich ist: P2 z A r A w B r B w erfüllte Bedingung : Read A A w < s 1 2.1: Read A A w < s 2 3.1: Write A A r s 3 A w < s 3 1.2: Write B B r s 1 B w < s 1 2.2: Write B B r s 2 B w < s 2 Diese Reihenfolge ist jedoch unter dem Zwei-Phasen- Sperrprotokoll nicht erreichbar. Denn einerseits müßten die Transaktionen t 1 und t 2 vor dem Zeitpunkt 3 ihre Sperren auf Objekt A wieder freigeben, damit Transaktion t 3 zum Zeitpunkt 3 eine exklusive Sperre auf das Objekt A erhalten kann. Andererseits müßten aber sowohl t 1 als auch t 2 eine exklusive Sperre auf Objekt B noch vor der jeweiligen Freigabe von A erhalten, damit das Zwei-Phasen-Sperrprotokoll erfüllt wird; Der Konfliktgraph A t 1 B t 2 A t 3 damit würden aber unverträgliche Sperren vergeben werden. besagt, daß P = (t 1, t 2, t 3 ) der einzige Konflikt-äquivalente serielle Plan ist, was auch der Reihenfolge s 1 < s 2 < s 3 der Startzeiten entspricht

20 Pessimistische und optimistische Scheduler Ein pessimistischer Scheduler versucht durch weitreichende Vorsorge das Eintreten von nichtserialisierbaren oder verklemmten Situationen möglichst frühzeitig zu verhindern; im allgemeinen sind dazu ein verhältnismäßig großer Aufwand für den Scheduler oder verhältnismäßig einschneidende Einschränkungen an die erlaubten Transaktionen notwendig. Ein optimistischer Scheduler versucht zunächst die Anweisungen möglichst unmittelbar wie angefordert auszuführen und erst nachträglich, wenn dies in der Regel leichter erkennbar ist, nichtserialisierbare oder verklemmte Situationen durch Abbruch einer Transaktion wieder aufzulösen