Konflikte. Konflikt-Äquivalenz von Read/Write-Plänen, Konflikt-Serialisierbarkeit

Transkript

1 Konflikte Zwei Transaktionen liegen im Konflikt, wenn sie ein Objekt o gemeinsam nutzen, wobei mindestens eine der Transaktionen in o schreibt. Für eine Menge von Transaktionen T kann man nun alle Konflikte im obigen Sinne bestimmen. Für einen Plan P kann man jeweils die Reihenfolge der im Konflikt liegenden Transaktionen bestimmen. Man sucht dann nach einem seriellen Plan P, der alle Konflikte genauso wie P behandelt. Konflikt-Äquivalenz von Read/Write-Plänen, Konflikt-Serialisierbarkeit 1. Sei T = {t 1,...,t k } eine Menge von Transaktionen. Zwei das gleiche Objekt o nutzende Anweisungen aus T, i1.j1 : Op 1 o und i2.j2 : Op 2 o liegen (wegen o) im Konflikt, wenn i1 i2 und Op 1 = Write oder Op 2 = Write. 2. Seien P und P Read/Write-Pläne zu einer Menge von Transaktionen T. P ist Konflikt-äquivalent zu P :gdw je zwei im Konflikt liegende Anweisungen werden in P und P in der gleichen Reihenfolge ausgeführt. 3. Ein Read/Write-Plan P zu einer Menge von Transaktionen T heißt Konflikt-serialisierbar, wenn es einen Read/Write-Plan P gibt, so daß gilt: (K1) P ist serieller Read/Write-Plan, (K2) P und P sind Konflikt-äquivalent

2 Konfliktgraphen Serialisierbarkeits-Test Um festzustellen, ob ein Read/Write-Plan P zu einer Menge von Transaktionen T = {t 1,...,t k } Konflikt-serialisierbar ist, konstruieren wir einen Konfliktgraphen G konflikt (P) = (E konflikt, K konflikt ) : Eckenmenge E konflikt := T Kantenmenge K konflikt := { (t i1, t i2 ) t i1 t i2, und es gibt o O(T), j1, j2: t i1.j1 = Op 1 o, t i2.j2 = Op 2 o, Op 1 = Write oder Op 2 = Write, P -1 (i1.j1) < P -1 (i2.j2) } Sei P ein Read/Write-Plan zu einer Menge von Transaktionen T = {t 1,...,t k } und G konflikt (P) = (T, K konflikt ) der zugehörige Konfliktgraph. 1. P ist Konflikt-serialisierbar genau dann, wenn G konflikt (P) azyklisch ist. 2. Ist G konflikt (P) azyklisch und ist P ein serieller Read/Write-Plan, der durch topologisches Sortieren aus G konflikt gewonnen wird, so sind P und P Konflikt-äquivalent. Es geht also eine Kante von Transaktion t i1 nach Transaktion t i2, wenn t i1 eine Anweisung enthält, die zu einer in P folgenden, aus t i2 stammenden Anweisung im Konflikt liegt

3 Transaktion und Konflikte T = {t 1, t 2, t 3, t 4 } mit 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 ) In T liegen folgende Anweisungen im Konflikt: wegen Objekt A: 2.1: Read A und 3.2: Write A 2.1: Read A und 4.4: Write A 1.1: Read A und 3.2: Write A 1.1: Read A und 4.4: Write A 3.2: Write A und 4.4: Write A wegen Objekt B: 1.3: Write B und 2.2: Read B 1.3: Write B und 4.1: Read B 1.3: Write B und 4.3: Write B 2.2: Read B und 4.3: Write B wegen Objekt C: 1.2: Write C und 3.1: Read C 1.2: Write C und 4.2: Read C Plan und Konfliktgraph Plan mit Datenflüssen 2.1: Read A, 1.1: Read A, 1.2: Write C, 3.1: Read C, 1.3: Write B, 4.1: Read B, 4.2: Read C, 2.2: Read B, 3.2: Write A, 4.3: Write B, 2.3: Write D, 4.4: Write A, Konfliktgraph A B C D A, C A, B, C B t 1 t A A 2 t 3 t 4 Konflikt-äquivalent zu seriellem Plan P = {t 1, t 2, t 3, t 4 } A, B wegen Objekt D: keine Konflikte also Konflikt-serialisierbar

4 Beweis und 2.: Sei G konflikt (P) azyklisch und P durch topologisches Sortieren aus G konflikt gewonnen. Seien i1.j1 : Op 1 o und i2.j2 : Op 2 o zwei im Konflikt liegende Anweisungen mit P -1 (i1.j1) < P -1 (i2.j2). Dann gilt (t i1, t i2 ) K konflikt, und damit wird in P t i1 vor t i2 ausgeführt, d.h. P -1 (i1.j1) < P -1 (i2.j2). Also sind P und P Konflikt-äquivalent. : Sei andererseits G konflikt (P) zyklisch, d.h. G konflikt (P) enthält einen Zykel (t i1,..., t ie, t i1 ). Angenommen, P sei ein serieller, zu P Konflikt-äquivalenter Plan. Dann müssen in P die am Zykel beteiligten Transaktionen in der durch den Zykel gegebenen Reihenfolge durchgeführt werden, d.h. in P wird t i1 vor sich selbst ausgeführt, ein Widerspruch

5 Abbruch, Wirksamwerden und Versionen Eine Transaktion soll gar nicht oder vollständig wirksam werden. Bislang haben wir gemäß der vereinfachenden Annahme A5 nur den Fall betrachtet, daß alle Transaktionen vollständig wirksam werden. Nun wollen wir auch zulassen, daß Transaktionen gar nicht wirksam werden sollen. Dies Ereignis kann aus verschiedenen Gründen eintreten. Gründe gegen Wirksamwerden Um Bedingungen zu erhalten, kann der Abbruch eines eine Transaktion ausführenden Prozesses durch die Verwendung der Anweisung Abort_Trans erzwungen werden. Der Scheduler stellt fest, daß aufgrund der Vorgeschichte der Transaktionsbearbeitung im Informationssystem eine Lage entstanden ist, daß z.b. Serialisierbarkeit oder die Auflösung einer Verklemmung nur noch durch Abbruch einer Transaktion und späteren erneuten Start erreicht werden kann. Es ist eine Fehlersituation, z.b. Programmfehler (der Transaktion, des Informationssystems oder des Betriebssystems), Hardwarefehler, Laufzeitfehler, Speicherfehler entstanden, die eine weitere Ausführung des Prozesses unmöglich macht und somit seinen Abbruch erzwingt. Das Rechensystem als Ganzes bricht zusammen, z.b. wegen eines Stromausfalles oder wegen eines Plattenfehlers, der nicht mehr behebbar ist

6 Die ersten drei Gründe führen zu einem in gewissem Sinne absichtlichen Abbruch. Der vierte Grund stellt ein unvorhersehbares und in keinem Sinne gewolltes Mißgeschick dar. Soll ein eine Transaktion ausführender Prozeß aus einer der erstgenannten Gründe absichtlich abgebrochen werden, so muß sichergestellt werden, daß alle vorher durchlaufenen Schreibanweisungen der Transaktion unwirksam werden, d.h. weder für zukünftige Leseanweisungen anderer Transaktionen beobachtbar werden noch für vorangegangene Leseanweisungen anderer Transaktionen, die möglicherweise eine dieser Schreibanweisungen schon beobachtet haben, bedeutsam bleiben. Die erste Forderung bedeutet, daß nach Schreibanweisungen zunächst zwei Versionen eines Objekts unterhalten werden müssen: die alte Version, die (spätestens) nach einem Abbruch der Transaktion (wieder) als die gültige anzusehen ist, und die neue Version, die (spätestens) nach dem Wirksamwerden der Transaktion gültig werden muß. Dabei bedarf es noch einer genaueren Festlegung, welche Version zu welchem Zeitpunkt für welche Transaktionen gültig sein soll. Die zweite Forderung besagt, daß andere Transaktionen, die schon die neue Version (fälschlicherweise) als gültig angesehen haben (und damit, wie man sagt, schmutzige Daten gelesen haben), ebenfalls abgebrochen werden müssen. Solche Folgeabbrüche können dann natürlich auch kaskadenhaft auftreten. Man kann Folgeabbrüche insbesondere dadurch zu vermeiden versuchen, daß man nach Schreibanweisungen noch möglichst lange die alte Version für andere Transaktionen als gültig ansieht, nämlich bis durch Verwendung der Anweisung Commit_Trans die Änderungen ausdrücklich für wirksam, d.h. die neue Version ausdrücklich als gültig erklärt wird

7 BEGIN_TRANS. Read o; Write o;. IF Bedingung THEN Commit_Trans ELSE Abort_Trans END END_TRANS Objekt o: alte Version neue Version z 0 z 1 z 2 z 3 BEGIN_TRANS Write o Commit_Trans END_TRANS Zeit Zwischen den Zeitpunkten z 0 und z 2 (einschließlich) dürfen absichtliche Abbrüche vorgenommen werden. Zwischen den Zeitpunkten z 1 und z 2 muß geregelt werden, welche Version vom Objekt o unter welchen Umständen als gültig angesehen werden soll. Zwischen den (möglichst kurz aufeinanderfolgenden) Zeitpunkten z 2 und z 3, d.h. also während die Gültigkeit abschließend und für alle Transaktionen verbindlich geregelt wird, muß das Objekt für andere Transaktionen vollständig gesperrt werden. Objekt o: alte Version neue Version z 0 z 1 z 2 z 3 BEGIN_TRANS Write o Abort_Trans END_TRANS Zeit

8 Versionsfunktion Eine Versionsfunktion zu einem Read/Write-Plan bestimmt welche Version eine Leseanweisung lesen soll und welche alte Version durch eine Schreibanweisung überschrieben werden und damit verloren gehen soll, bzw. ob eine neue Version angelegt werden oder überhaupt nichts getan werden soll. Bislang hatten wir immer eine Standard-Versionsfunktion vorausgesetzt, die besagt, daß von einem Objekt stets (die einzig vorhandene) aktuelle Version gelesen und die bislang aktuelle Version überschrieben werden soll