5 Mehrversionen-Concurrency Control

5 Mehrversionen-Concurrency Control 5.1 Motivation Bislang sind wir davon ausgegangen, dass jedes Datenobjekt genau einmal im Data Manager zur Verfügung steht, so dass sich parallele Transaktionen bei im Konflikt stehenden Operationen gegenseitig behindern, Schreiboperationen die bisherigen Zustände von Objekten überschreiben und die liest-von-relation zwischen verschiedenen Transaktionen die Isolationsbedingung verletzen kann. Jetzt untersuchen wir, wie sich das Bild ändert, wenn wir mehrere Kopien von Objekten vorhalten. Dies erlaubt es z.b., die alte Version eines Objektes bei Schreiboperationen aufzuheben, mindesten solange bis die ändernde Transaktion ihre neue Kopie (durch ihr commit) freigegeben hat. Allgemeiner können verschiedene Transaktionen verschiedene Versionen desselben Datenobjektes gleichzeitig bearbeiten. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-1

Übersicht Wir untersuchen die sog. Mehrversionen-Concurrency Control (Multi-Version CC, MVCC) bzgl. Serialisierbarkeit, Scheduling-Algorithmen, Protokollen. Wir werden später sehen, dass Transaktionssysteme wegen der Fehlerbehandlung (Recovery) oft ohnehin Versionen von Datenobjekten führen ( Before oder After Images oder beide), so dass auch hier eine enge Verknüpfung mit dieser TXS-Komponente vorliegt. Die Speicherung mehrerer Versionen des gleichen Objektes erhöht den Speicherplatzbedarf deutlich. In der Theorie werden wir dies zunächst unberücksichtigt lassen, dann aber untersuchen, welche Auswirkungen es hat, wenn wir die Zahl der verfügbaren Versionen einschränken. Wir nehmen hier an, dass die Versionierung transparent ist, d.h. dass Anwendungen nichts davon wissen, dass u.u. mehrere Versionen der Objekte existieren. (Im Unterschied zu vielen anderen Szenarios, in denen die Anwendungssicht die Versionierung nutzt, z.b. zum Configuration Management). Wir werden schrittweise unsere bisherigen Definitionen und Ergebnisse erweitern. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-2

5.2 Mehrversionen-Schedules Zunächst beobachten wir den Effekt der Versionierung anhand eines Beispiels: Beispiel 5-1: Wir betrachten die History s = r 1 (x)w 1 (x)r 2 (x)w 2 (y)r 1 (y)w 1 (z)c 1 c 2. Offenbar ist s / CSR, da es einen zyklischen Konflikt zwischen t 1 unf t 2 gibt. Intuitiv: Objekt y wurden bereits von t 2 überschrieben, als t 1 im Schritt r 1 (y) lesend zugriff, mit anderen Worten, der Schritt r 1 (y) kommt zu spät als dass der Schedule, der bereits einen Konflikt zwischen t 1 unf t 2 (auf x) ergeben hat, noch korrekt sein könnte. Wenn nun aber zum Zeitpunkt des Lesezugriffs von t 1 auf y dessen alte Version, in diesem Fall also der Ausgangszustand von y, noch verfügbar wäre, dann könnte t 1 diesen lesen, was einen Schedule ergäbe, der dem folgenden äquivalent wäre: s = r 1 (x)w 1 (x)r 1 (y)r 2 (x)w 2 (y)w 1 (z)c 1 c 2. Dieser Schedule ist serialisierbar: s c t 1 t 2 und damit s CSR. Wenn ein TXS beim Schreiben von Objekten keinen Update-in-Place durchführt, sondern eine neue Version (Kopie) erzeugt, dann muss offenbar der Scheduler bei jedem Datenzugriff entscheiden, welche Version eine Transaktion nutzen soll! c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-3

Formalisierung Leseschritte r(x) lesen eine existierende Version des Objektes x, Schreibschritte w(x) erzeugen immer eine neue Version von x. Definition 5-1: (Versionierungsfunktion) Sei s eine History mit Initialisierungstransaktion t 0 und abschließender Lesetransaktion t. Eine Versionierungsfunktion h für s ist eine Funktion h, die jedem Leseschritt von s einen Schreibschritt auf demselben Objekt in s zuordnet. h(r i (x)) bezeichnet die Version von x, die dem Leseschritt r i (x) durch h in s zugeordnet wird. Die Version, die in einem Schreibschritt w j (x) erzeugt wird, bezeichnen wir mit x j. Folglich können wir Schreibschritte mit w j (x j ) und Leseschritte mit r i (x j ) qualifizieren, wenn dem Leseschritt r i (x) durch h der Schreibschritt w j (x j ) zugeordnet wird. Wir schreiben dann: h(r i (x)) = r i (x j ), und zur Vereinfachung der Notation auch h(w j (x)) = w j (x j ). Die Versionierungsfunktion übersetzt also jede Schreiboperation in einen Versions- Erzeugungsschritt und jede Leseoperation in einen Versions-Leseschritt. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-4

Ein Mehrversionen-Schedule ist nun einfach ein (bisher bekannter) Schedule mit einer Versionierungsfunktion: Definition 5-2: (Mehrversionen-Schedule) Sei T = {t 1,..., t n } eine (endliche) Menge von Transaktionen. 1. Eine Mehrversionen-History (oder ein vollständiger Mehrversionen-Schedule) für T ist ein Paar m = (op(m), < m ), mit < m einer Obermenge der Menge aller möglichen Transaktionsordnungen und (a) op(m) = h( n i=1 op(t i)) für eine Versionierungsfunktion h (wir nehmen an, dass h kanonisch von einzelnen Operationen auf Operationsmengen erweitert wurde), (b) für alle t T und alle Operationen p, q op(t) gilt: p < t q h(p) < m h(q), (c) wenn h(r j (x)) = r j (x i ), i j, und c j in m, dann c i < m c j. 2. Ein Mehrversionen-Schedule ist ein Präfix einer Mehrversionen-History. Bemerkung: Die Bedingung 1c stellt sicher, dass CP(m), die committed projection von m, vollständig ist. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-5

Beispiel 5-2: Das folgende ist eine Mehrversionen-History, in der die Versionierungsfunktion h dem Schritt r 1 (y) die Version y 0 (den Initialzustand, der durch die hier nicht gezeigte Transaktion t 0 geschrieben wurde) zuordnet: m = r 1 (x 0 )w 1 (x 1 )r 2 (x 1 )w 2 (y 2 )r 1 (y 0 )w 1 (z 1 )c 1 c 2. Herkömmliche Schedules sind nun ein Spezialfall, in dem jedem Leseschritt die letzte vorangegangenen Schreiboperation zugeordnet wird, in dem es also in anderen Worten nur eine Version jedes Datenobjektes gibt: Definition 5-3: (Einversionen-Schedule) Ein Mehrversionen-Schedule heißt Einversionen- Schedule, wenn die Versionierungsfunktion jedem Leseschritt die letzte vorangegangene Schreiboperation zuordnet. Beispiel 5-3: Ein Beispiel für einen Einversionen-Schedule ist etwa m = r 1 (x 0 )w 1 (x 1 )r 2 (x 1 )w 2 (y 2 )r 1 (y 2 )w 1 (z 1 )c 1 c 2. Der einzige Unterschied zum vorherigen Beispiel ist die Zuordnung h(r 1 (y)) = w 2 (y 2 ). Im folgenden werden wir mitunter Einversionen-Schedules im bisherigen Sinne wie auch solche im eben definierten Sinne verwenden. Wir werden die erstgenannten weiterhin mit s, s,... und die letzteren mit m, m,... bezeichnen. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-6

5.3 Mehrversionen-Serialisierbarkeit Versionierung soll hier transparent sein, daher muss ein korrekter MV-Schedule äquivalent zu einem gewöhnlichen seriellen Schedule ohne Versionen sein! 5.3.1 Mehrversionen-View-Serialisierbarkeit Die Konflikt-Äquivalenz im bekannten Sinne ist nicht adäquat, wie das folgende Beispiel zeigt: Beispiel 5-4: Wir betrachten den seriellen (Einversionen-) Schedule s = w 0 (x)c 0 w 1 (x)c 1 r 2 (x)w 2 (y)c 2. Ein MV-Schedule mit der gleichen Schritt-Folge ist etwa m = w 0 (x 0 )c 0 w 1 (x 1 )c 1 r 2 (x 0 )w 2 (y 2 )c 2. Während s drei Konflikte (w 0 (x) w 1 (x), w 0 (x) r 2 (x) und w 1 (x) r 2 (x)) enthält, gibt es in m nur noch einen Konflikt (w 0 (x 0 ) r 2 (x 0 )), da t 1 nun eine neue Version von x schreibt. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-7

Man kann Konflikt-Äquivalenz so definieren (s. unten), dass ein MV-Schedule m äquivelent zu einem EV-Schedule s ist, wenn alle Konfliktpaare in m in der gleichen Reihenfolge wie in s auftreten (so dass hier beide Schedules äquivalent wären). Es bleibt jedoch das Problem bestehen, dass beide unterschiedliche liest-von-relationen haben, was intuitiv unerwünscht ist: in s liest t 2 x von t 1, in m dagegen von t 0. Wir würden also erwarten, dass i.a. t 2 in beiden Schedules verschiedene Werte von x liest! Das Beispiel zeigt, dass View-Serialisierbarkeit in diesem Kontext angestrebt werden sollte, dazu sind jedoch Anpassungen erforderlich. Definition 5-4: (Liest-von-Relation) Seien m ein MV-Schedule und t i, t j trans(m). Die liest-von-relation von m ist definiert durch RF(m) := {(t i, x, t j ) r j (x i ) op(m)}. Hierauf basierend definieren wir wieder wie gewohnt: Definition 5-5: (View-Äquivalenz) Seien m und m MV-Schedules mit trans(m ) = trans(m). Die Schedules m und m sind view-äquivalent, m v m, wenn RF(m) = RF(m ). c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-8

Beispiel 5-5: Seien Es gilt m v m. Anmerkungen m = w 0 (x 0 )w 0 (y 0 )c 0 r 3 (x 0 )w 3 (x 3 )c 3 w 1 (x 1 )c 1 r 2 (x 1 )w 2 (y 2 )c 2 m = w 0 (x 0 )w 0 (y 0 )c 0 w 1 (x 1 )c 1 r 2 (x 1 )r 3 (x 0 )w 2 (y 2 )w 3 (x 3 )c 3 c 2 Die Definition der Liest-von-Relation ist nun wesentlich einfacher als im Kapitel 3. Im Unterschied zur Definition der View-Serialisierbarkeit in Kapitel 3 muss hier nicht betrachtet werden, ob von Schreiboperationen gelesen wird oder nicht, da immer neue Versionen erzeugt werden. Dies ändert sich, wenn wir nur beschränkt viele Versionen zulassen. Es genügt nicht, dass ein MV-Schedule view-äquivalent zu einem seriellen MV-Schedule ist, da auch dieser nicht zwingend eine zu einem seriellen EV-Schedule kompatible Liest-von-Relation haben muss. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-9

Beispiel 5-6: Sei m = w 0 (x 0 )w 0 (y 0 )c 0 r 1 (x 0 )r 1 (y 0 )w 1 (x 1 )w 1 (y 1 )c 1 r 2 (x 0 )r 2 (y 1 )c 2. Wenn jeder Leseschritt r i (x j ) durch r i (x) und jeder Schreibschritt w i (x i ) durch w i (x) ersetzt wird, so entsteht der folgende EV-Schedule: s = w 0 (x)w 0 (y)c 0 r 1 (x)r 1 (y)w 1 (x)w 1 (y)c 1 r 2 (x)r 2 (y)c 2. Beide Schedules sind seriell, jedoch liest t 2 in s das Objekt x von t 1, in m dagegen von t 0. Bei der Definition von View-Serialisierbarkeit von MV-Schedules verwenden wir die folgende Definition 5-6: (Standard Mehrversionen-Schedule) Sei m ein MV-Schedule. 1. Die Standard-liest-von-Relation von m ist definiert durch SRF(m) := {(t i, x, t j ) r j (x i ) op(m) x i ist die vor r j (x i ) zuletzt geschriebene Version von x} 2. m heißt Standard-Mehrversionen-Schedule (SMV-Schedule), wenn RF(m) = SRF(m). Schedule m im Beispiel oben ist offensichtlich kein SMV-Schedule! c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-10

View-Serialisierbarkeit SMV-Schedules haben nun Liest-von-Relationen, die mit denen von seriellen EV-Schedules kompatibel sind. Daher folgende Definition 5-7: (Mehrversionen-View-Serialisierbarkeit I) Sei m eine MV-History. m heisst mehrversionen-view-serialisierbar, wenn es eine serielle SMV-History m mit der gleichen Transaktionenmenge gibt, so dass m v m. Mit MVSR bezeichnen wir die Klasse aller mehrversionen-view-serialisierbaren Histories. Für eine History m MVSR gibt es also stets eine serielle EV-History s mit m v s, wobei v nun wohldefiniert ist. Beispiel 5-7: Seien m = w 0 (x 0 )w 0 (y 0 )c 0 w 1 (x 1 )c 1 r 2 (x 1 )r 3 (x 0 )w 3 (x 3 )c 3 w 2 (y 2 )c 2 m = w 0 (x 0 )w 0 (y 0 )c 0 r 3 (x 0 )w 3 (x 3 )c 3 w 1 (x 1 )c 1 w 2 (y 2 )c 2 Es gilt m v m und m ist view-äquivalent zur seriellen EV-History s = w 0 (x)w 0 (y)c 0 r 3 (x)w 3 (x)c 3 w 1 (x)c 1 w 2 (y)c 2 Die vorige Definition kann auf beliebige Schedules verallgemeinert werden: c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-11

Definition 5-8: (Mehrversionen-View-Serialisierbarkeit II) Eine MV-History m ist mehrversionen-view-serialisierbar, wenn es eine serielle SMV-History m gibt, so dass CP(m) v m. Eine MV-History verhält sich wie eine eine serielle EV-History, genau dann, wenn sie in MVSR liegt: Satz 5-1: Seien m eine MV-History und s eine serielle EV-History mit der gleichen Transaktionenmenge. Es gilt: RF(CP(m)) = RF(s) m MVSR. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-12

Zur Komplexität Wir erwarten nicht, dass der Test auf Mitgliedschaft in MVSR effizienter ist, als der für VSR, denn es gilt: Satz 5-2: VSR MVSR. Die strikte Inklusion kann mit dem Schedule m = w 0 (x 0 )c 0 r 1 (x 0 )w 1 (x 1 )c 1 r 2 (x 0 )c 2 gezeigt werden, der seriell und in MVSR ist. Die Reihenfolge der Transaktionen t 1 und t 2 ist in m beliebig, da beide von t 0 lesen. In einem aus m abgeleiteten EV-Schedule liest t 2 jedoch von t 1, so dass die Reihenfolge nicht mehr beliebig ist. Man kann tatsächlich zeigen: Satz 5-3: Das Problem zu entscheiden, ob eine gegebene MV-History in MVSR liegt, ist N P-vollständig. Beweis.... über eine Reduktion von VSR auf MVSR. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-13

MV-Konfliktgraph Anders als im Fall von EV-Schedules, können wir eine graphentheoretische Charakterisierung von MVSR-Schedules angeben. Wir nutzen einen Konfliktgraphen für MV-Schedules. Die Definition aus Kapitel 3 vereinfacht sich hier, da alle Konflikte nur noch die Form (w i (x i ), r j (x i )), i j haben können. Der Konfliktgraph G(m) eines MV-Schedules hat also eine Kante der Form t i t j zwischen den Knoten von (committeten) Transaktionen t i, t j genau dann, wenn r j (x i ) in m vorkommt. Offensichtlich gilt dann: Satz 5-4: Für zwei MV-Schedules m, m gilt: m v m = G(m) = G(m ). Wir vervollständigen nun den Konfliktgraphen für MV-Schedules. Für ein Datenobjekt x ist eine Versionsordnung eine nicht-reflexive, totale Ordnung aller Versionen von x, die in m geschrieben werden. Eine Versionsordnung << für m ist einfach die Vereinigung aller Versionsordnungen von Objekten, die in m geschrieben werden. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-14

Beispiel 5-8: Sei m =w 0 (x 0 )w 0 (y 0 )w 0 (z 0 )c 0 r 1 (x 0 )r 2 (x 0 )r 2 (z 0 )r 3 (z 0 ) w 1 (y 1 )w 2 (x 2 )w 3 (y 3 )w 3 (z 3 )c 1 c 2 c 3 r 4 (x 2 )r 4 (y 3 )r 4 (z 3 )c 4 Eine Versionsordnung für m könnte etwa sein: x 0 << x 2, y 0 << y 1 << y 3, z 0 << z 3. Definition 5-9: (MV-Serialisierungsgraph) Zu einem gegebenen MV-Schedule m und einer Versionsordnung << wird der Mehrversionen-Serialisierungsgraph MVSG(m, <<) zu m wie folgt aus dem Konfliktgraphen G(m) = (V, E) erzeugt: MVSG(m, <<) = (V, E ), wobei E aus E durch Hinzufügen der folgenden Kanten entsteht: Für alle paarweise verschiedenen Indices i, j, k mit r k (x j ), w i (x i ) CP(m): wenn x i << x j dann (t i, t j ) E, sonst (t k, t i ) E. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-15

Beispiel 5-9: Seien m und << wie im vorigen Beispiel. Der Graph MVSG(m, <<) entsteht aus G(m) durch Hinzufügen der Kanten (t 1, t 2 ): r 1 (x 0 ), w 2 (x 2 ) op(m), aber x 0 << x 2, (t 1, t 3 ): w 1 (y 1 ), r 4 (y 3 ) op(m), aber y 1 << y 3, (t 2, t 3 ): r 2 (z 0 ), w 3 (z 3 ) op(m), aber z 0 << z 3. t 1 t 0 t 3 t 4 t 2 c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-16

Resultat Wenn eine MV-History einen azyklischen Konfliktgraphen hat, dann können wir topologisch sortieren um eine äquivalente serielle MV-History zu erhalten, diese muss jedoch nicht viewäquivelent zu einer seriellen EV-History sein. Die Kanten aus der Versionsordnung sorgen erst dafür, dass die Liest-von-Relation unverändert bleibt. Die topologische Sortierung muss also noch möglich sein, wenn die Versionsordnungs-Kanten hinzugefügt worden sind: Satz 5-5: Es gilt m MVSR genau dann, wenn es eine Versionsordnung << gibt, für die MVSG(m, <<) azyklisch ist.... dadurch wird das Entscheidungsproblem nicht einfacher, denn es ist nicht klar, dass in polynomialer Zeit eine solche Ordnung << gefunden werden kann. Allerdings geben wir später MV-Scheduler an, die immer solche Ordnungen erzeugen, deren Korrektheit also mit diesem Satz gezeigt werden kann. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-17

5.3.2 Mehrversionen-Konfliktserialisierbarkeit Ziel: eine Subklasse von MVSR, für die ein effizienter Test (in Polynomialzeit) möglich ist. Definition 5-10: (Mehrversionen-Konflikt) Ein Mehrversionen-Konflikt in einem MV- Schedule m ist ein Paar von Schritten r i (x j ) und w k (x k ), für das gilt: r i (x j ) < m w k (x k ). Beobachtungen: offenbar werden jetzt nur noch Schrittfolgen rw als Konflikt bezeichnet; es ist klar, dass ww nicht als Konflikt gelten muss, da verschiedene Versionen geschrieben werden; Bei wr gilt: (Konflikt = Operationen dürfen nicht vertauscht werden!) wenn der r- vor den w-schritt vertauscht wird, so sind weniger Wahlmöglichkeiten für die zu lesende Objektversion übrig. Sollte der resultierende Schedule also serialisierbar sein, so war es der ursprüngliche sicher auch. Daher muss wr nicht als Konfliktpaar betrachtet werden. Bei rw ist es anders: würde hier vertauscht, so entstünden mehr Wahlmöglichkeiten, aus der Serialisierbarkeit des resultierenden Schedules ließe sich also nicht sicher auf die Serialisierbarkeit des Ausgangsschedules schließen! c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-18

Reduzierbarkeit... wegen der Asymmetrie in den Konfliktpaaren kann der MV-Konfliktbegriff nicht ohne weiteres für die Definition einer Äquivalenzrelation auf MV-Schedules verwendet werden. Stattdessen wird ein asymmetrischer Begriff der Transformation eines Schedules in einen anderen eingeführt, der durch wiederholtes Vertauschen von nicht im Konflikt stehenden Operationspaaren gesteuert wird (vgl. konfliktbasierte Reduzierbarkeit in Kapitel 3, hier jedoch mit einer asymmetrischen Konfliktrelation). Schlussfolgerung: wenn durch wiederholtes Vertauschen von konfliktfreien Operationen ein serieller SMV-Schedule entsteht (der also die Reihenfolge von rw-konfliktpaaren unverändert lässt), so ist der Ausgangsschedule sicher in MVSR (dies ist leider nur eine hinreichende, aber nicht notwendige Bedingung...). Definition 5-11: (Mehrversionen-Reduzierbarkeit) Eine MV-History m ist mehrversionen-reduzierbar, wenn sie durch eine endliche Anzahl von Transformationen in eine serielle SMV-History überführt werden kann, bei der nur rw-konfliktpaare, rr-paare oder Paare von Operationen auf verschiedenen Objekten vertauscht werden. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-19

MV-Konfliktserialisierbarkeit Definition 5-12: (Mehrversionen-Konfliktserialisierbarkeit) Eine MV-History m ist mehrversionen-konfliktserialiserbar, wenn es eine serielle SMV-History mit denselben Transaktionen gibt, in der alle Paare von Konfliktoperationen in der gleichen Reihenfolge auftreten wie in m. Die Klasse aller MV-konfliktserialisierbaren Histories bezeichnen wir mit MCSR. Aus den vorgenannten Überlegungen ergibt sich: Satz 5-6: Eine MV-History ist MV-konfliktserialisierbar genau dann, wenn sie MVreduzierbar ist. Satz 5-7: MCSR MVSR. Mitgliedschaft in der Klasse MCSR kann wieder mittels eines entsprechenden Konfliktgraphen gezeigt werden... c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-20

Mehrversionen-Konfliktgraph Definition 5-13: (Mehrversionen-Konfliktgraph) Sei m ein MV-Schedule. der Mehrversionen-Konfliktgraph von m hat die Transaktionen aus m als Knoten und eine Kante von t i nach t j, wenn es Schritte r i (x k ) und w j (x j ) auf einem Objekt x in m gibt, so dass r i (x k ) < m w j (x j ). Nun gilt der folgende Satz 5-8: Ein MV-Schedule ist in MCSR genau dann, wenn sein MV-Konfliktgraph azyklisch ist. Die Klasse MCSR kann also effizient entschieden werden. Alle praktischen MV-Concurrency Control Protokolle fallen in diese Klasse. Dennoch werden wir nachfolgend eine Graph-Charakterisierung der größeren Klasse MVSR mit einer entsprechenden Versionsordnung untersuchen. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-21

Zusammenfassung Das nachfolgende Bild zeigt alle hier behandelten Klassen in ihrer Beziehung zueinander. Die angegebenen Histories enthalten t 0 nicht explizit und sind als Einversionen-Schedules notiert. MVSR Alle Histories VSR s 3 s 5 CSR MCSR s 4 s 2 s 1 s 1 = r 1 (x)r 2 (x)w 1 (x)w 2 (x)c 1 c 2 s 2 = w 1 (x)c 1 r 2 (x)r 3 (y)w 3 (x)w 2 (y)c 2 c 3 s 3 = w 1 (x)c 1 r 2 (x)r 3 (y)w 3 (x)w 2 (y)c 2 c 3 w 4 (y)c 4 s 4 = r 1 (x)w 1 (x)r 2 (x)r 2 (y)w 2 (y)r 1 (y)w 1 (y)c 1 c 2 s 5 = r 1 (x)w 1 (x)r 2 (x)w 2 (y)c 2 w 1 (y)w 3 (x)c 1 c 3 c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-22

5.4 Beschränkte Anzahl von Versionen Bislang: keine Beschränkung der Anzahl verfügbarer Versionen. Diese Annahme ist nicht sehr realistisch, denn obwohl Speicherplatz nicht mehr sehr teuer ist, wird kein Daten-Server unbeschränkt viel Speicherplatz zur Verfügung haben, die Verwaltung einer unbeschränkten Anzahl Versionen wäre kaum effizient möglich. Wir werden jetzt also die Auswirkungen von Beschränkungen untersuchen. Dabei zeigt sich, dass Schedules, die mit unbeschränkter Anzahl Versionen serialisierbar sind, mit beschränkter Anzahl nicht-serialisierbar werden können. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-23

Zur Motivation Beispiel 5-10: Betrachte die SMV-History m = w 0 (x 0 )c 0 r 1 (x 0 )w 3 (x 3 )c 3 w 1 (x 1 )c 1 r 2 (x 1 )w 2 (x 2 )c 2. Es gibt 6 mögliche serielle SMV-Histories für die 3 Transaktionen in m, nämlich: m 1 =w 0 (x 0 )c 0 r 1 (x 0 )w 1 (x 1 )c 1 r 2 (x 1 )w 2 (x 2 )c 2 w 3 (x 3 )c 3 m 2 =w 0 (x 0 )c 0 r 1 (x 0 )w 1 (x 1 )c 1 w 3 (x 3 )c 3 r 2 (x 3 )w 2 (x 2 )c 2 m 3 =w 0 (x 0 )c 0 r 2 (x 0 )w 2 (x 2 )c 2 r 1 (x 2 )w 1 (x 1 )c 1 w 3 (x 3 )c 3 m 4 =w 0 (x 0 )c 0 r 2 (x 0 )w 2 (x 2 )c 2 w 3 (x 3 )c 3 r 1 (x 3 )w 1 (x 1 )c 1 m 5 =w 0 (x 0 )c 0 w 3 (x 3 )c 3 r 1 (x 3 )w 1 (x 3 )c 1 r 2 (x 1 )w 2 (x 2 )c 2 m 5 =w 0 (x 0 )c 0 w 3 (x 3 )c 3 r 2 (x 3 )w 2 (x 2 )c 2 r 1 (x 2 )w 1 (x 1 )c 1 Wegen m v m 1 gilt m MVSR. Sei nun die maximale Anzahl gleichzeitig verfügbarer Versionen auf k = 2 beschränkt. Da alle Transaktionen nur das Objekt x schreiben, bedeutet dies, dass nur die jeweils letzten 2 Versionen von x gespeichert werden können. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-24

Für m 1 heisst dies: t 0 und t 1 erzeugen x 0 und x 1, t 2 überschreibt die ältere Version x 0 mit x 2, und dann t 3 x 1 mit x 3. Am Ende sind x 2 und x 3 vorhanden. Der Ausgangsschedule m dagegen hinterlässt am Ende x 1 und x 2, da diese zuletzt geschrieben werden. Folglich kann m nun nicht mehr als äquivalent zu m 1 betrachtet werden! Eine genaue Analyse zeigt, dass m nun zu keinem der seriellen SMV-Schedules m 1 m 6 mehr äquivalent ist! Der MV-Schedule m ist also bei Beschränkung auf nur zwei Versionen pro Objekt nicht mehr Mitglied der Klasse MVSR! Zur Formalisierung: wie in Abschnitt 3.5 wird View-Äquivalenz über gleiche liest-von-relation und gleiche abschließende Schreiboperationen definiert. Die Beschränkung auf maximal k Versionen pro Objekt kann ebenfalls eingebaut werden, so dass wir von der k-versionen View-Serialisierbarkeit sprechen können. Die entsprechenden Klassen von Schedules werden dann mit kvsr, k > 0 bezeichnet. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-25

Ergebnisse Aus dem Beispielschedule m von oben ergibt sich sofort: m MVSR 2VSR. Offensichtlich ist VSR = 1VSR. Ferner gilt: MVSR = k>0 kvsr. Schließlich kann man zeigen, dass die Klassen der auf k Versionen beschränkten Schedules eine strikte Hierarchie bilden: VSR = 1VSR 2VSR 3VSR... MVSR. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-26

5.5 Mehrversionen-Concurrency Control-Protokolle Wir betrachten nun Protokolle für Mehrversionen Daten-Server, indem bekannte Protokolle auf mehrere Versionen erweitert werden. Alle betrachteten Protokolle erzeugen vollständige Versionenordnungen, so dass ihre Korrektheit aus der Mitgliedschaft in MVSR folgt. Sofern nicht anders vermerkt nehmen wir an, dass unbeschränkt viele Versionen gespeichert werden können. 5.5.1 Mehrversionen-Time Stamp Ordering Ein MV-Time Stamp Ordering-Scheduler verarbeitet alle ankommenden Operationen in Eingangsreihenfolge (FIFO, first-in-first-out). Er transformiert Datenoperationen in solche auf Versionen von Datenobjekten, so dass der resultierende Schedule äquivalent zu einem seriellen Einversionenschedule ist, bei dem alle Transaktionen in der Reihenfolge ihrer Zeitstempel (die bei BOT vergeben werden) ausgeführt wurden. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-27

MVTO-Scheduling Jede Version trägt den Zeitstempel ts(t i ) der Transaktion t i, von der sie geschrieben wurde. Der MVTO-Scheduler arbeitet wie folgt: Ein Leseschritt r i (x) wird transformiert in r i (x k ), wobei x k die Version von x ist mit dem größten Zeitstempel ts(t i ). Ein Schreibschritt w i (x) wird wie folgt behandelt: Wenn ein Leseschritt r j (x k ) mit ts(t k ) < ts(t i ) < ts(t j ) bereits ausgeführt wurde, so wird w i (x) zurückgewiesen und t i abgebrochen. Andernfalls wird w i (x) in w i (x i ) transformiert und ausgeführt. Ein Commit c i wird solange verzögert, bis alle c j von Transaktionen t j ausgeführt wurden, die Versionen von Objekten geschrieben haben, die von t i gelesen wurden. (Dieser Teil des Protokolls ist optional. Er wurde hier angefügt, damit korrekte Recovery möglich ist, wir kommen später darauf zurück.) c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-28

Zur Korrektheit Um zu zeigen, dass Gen(MVTO) MVSR können wir die Versionsordnung wie folgt definieren: Beispiel 5-11: x i << x j ts(t i ) < ts(t j ). r 1 (x 0 ) r 1 (y 0 ) r 2 (x 0 ) w 2 (x 2 ) t 2 2 0 2 2 r 3 (x 2 ) r 3 (z 0 ) 5 r 4 (x 2 ) t 4 w 4 (x 4 ) r 4 (y 2 ) w 4 (y 4 ) abort t r 5 (y 2 ) r 5 (z 0 ) c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-29

5.5.2 Mehrversionen-Zwei-Phasen-Sperrprotokoll Wir betrachten einen Strong 2PL Scheduler (SS2PL) und nehmen zunächst unbeschränkte Versionenanzahl an. Wir unterscheiden committete Versionen: solche, die von bereits abgeschlossenen Transaktionen geschrieben wurden, aktuelle Versionen von Datenobjekten: diejenige, die von der zuletzt abgeschlossenen Transaktion geschrieben wurde, nicht committete Versionen: alle übrigen (die von noch laufenden Transaktionen geschrieben wurden). Ein MV2PL-Scheduler stellt sicher, dass zu jedem Zeitpunkt höchstens eine nicht committete Version jedes Datenobjektes existiert. Je nachdem, ob Leseoperationen nur auf der aktuellen oder auch auf nicht committeten Versionen erlaubt werden, können verschiedene Varianten des Protokolls unterschieden werden. Der Scheduler behandelt ferner den jeweils letzten Schritt einer Transaktion (entweder die letzte Datenoperation vor dem commit oder der commit selbst; in den nachfolgenden Beispielen: die letzte Datenoperation vor dem commit) anders als die anderen Schritte. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-30

MV2PL-Protokoll Einzelne Schritte werden wie folgt bearbeitet: Sofern es nicht der letzte Schritt einer Transaktion ist: Ein Leseschritt r(x) wird sofort mit der aktuellen (zuletzt comitteten) oder der noch nicht committeten Version des Objektes x ausgeführt. Ein Schreibschritt w(x) wird nur dann ausgeführt, wenn die Transaktion, die x zuletzt geschrieben hat, bereits committet wurde, so dass keine weiteren nicht committeten Versionen von x bestehen. Der jeweils letzte Schritt einer Transaktion t i wird verzögert bis die folgenden Transaktionen committet sind: alle Transaktionen t j, die die aktuelle Version eines von t i geschriebenen Objektes gelesen haben, sowie alle Transaktionen t j, von denen t i irgendeine Version eines Objektes gelesen hat. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-31

Beispiel Beispiel 5-12: Ein MV2PL-Scheduler sehe die folgende Reihenfolge von Schritten: Die Abarbeitung verläuft wie folgt: s = r 1 (x)w 1 (x)r 2 (x)w 2 (y)r 1 (y)w 2 (x)c 2 w 1 (y)c 1. 1. r 1 (x) wird ausgeführt (auf x 0 ): r 1 (x 0 ) 2. w 1 (x) wird ausgeführt (und erzeugt x 1 ), da keine andere TX aktiv ist: w 1 (x 1 ) 3. r 2 (x) werde x 1 zugeordnet und ausgeführt: r 2 (x 1 ) 4. w 2 (y) wird ausgeführt: w 2 (y 2 ) 5. r 1 (y) werde y 0 zugeordnet und ausgeführt: r 1 (y 0 ) 6. Wäre w 2 (x) nicht der letzte Schritt von t 2, so würde er verzögert, da t 1 noch aktiv ist und x 1 geschrieben hat. So stellt sich dennoch heraus, dass t 2 warten muss, da t 1 die aktuelle Version (y 0 ) von y gelesen hat und t 2 diese Version überschreibt, t 2 die Version x 1 von t 1 gelesen hat. 7. w 1 (y), der letzte Schritt von t 1, wird ausgeführt, da t 2 keine aktuellen Versionen von Objekten gelesen hat, die t 1 geschrieben hat, und t 1 keine Versionen von t 2 gelesen hat w 1 (y 1 ) 8. danach kann schließlich auch w 2 (x) ausgeführt werden: w 2 (x 2 ) c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-32

Zwei-Versionen-2PL-Protokoll 2V2PL Wir betrachten nun die Beschränkung auf max. zwei Versionen jedes Objektes. Dies ist dadurch motiviert, dass ein TX-Server aus anderen (Recovery-) Gründen evtl. ohnehin zwei Versionen (vor bzw. nach jeder Änderung) von Objekten pflegen muss. Solange eine Transaktion läuft, wird von geänderten Objekten x ein Before Image und ein After Image gespeichert. Sobald die Transaktion committet, kann das Before Image gelöscht werden, da die Änderung jetzt stabil ist. Ein 2V2PL-Scheduler hält also immer die aktuelle Version sowie bei laufenden Update-Transaktionen Kandidaten für Nachfolge-Versionen bereit. Zur Implementierung des Tests für Schreiboperationen und letzte Schritte können drei Sperrmodi verwendet werden: rl(x) wl(x) cl(x) rl(x) + + wl(x) + cl(x) c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-33

Erläuterung rl Read Lock: Eine Lesesperre rl(x) wird unmittelbar vor einer Leseoperation r(x) auf die aktuelle Version von x gesetzt. wl Write Lock: Eine Schreibsperre wl(x) wird (unmittelbar) vor einer Operation w(x) zum Schreiben einer neuen nicht committeten Version von x gesetzt. cl Certify (oder Commit) Lock: Eine Sperre cl(x) wird vor Ausführung des letzten Schrittes einer Transaktion auf alle Objekte, die von ihr geschrieben wurden, gesetzt. (Die Sperrfreigaben müssen dem SS2PL-Protokoll genügen.) Schreibsperren stellen lediglich sicher, dass von jedem Objekt jederzeit höchstens eine nicht committete Version erzeugt werden kann. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-34

Zur Korrektheit Die MV-Serialisierbarkeit wird durch die Anforderung der cl-sperren gewährleistet. Die Tests bzgl. der korrekten Anordnung des Lesens von aktuellen Versionen und Schreibens neuer sind in der Kompatibilität der rl- und cl-sperren codiert. cl-sperren spielen folglich die Rolle der wl-sperren in Einversionen-Protokollen. Der Vorteil beim 2V2PL-Protokoll liegt darin, dass die cl-sperren erst beim letzten Schritt, also für ein wesentlich kürzere Zeit, angefordert werden, was eine höhere Parallelität von Transaktionen ermöglicht. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-35

Beispiel 5-13: Für den Input-Schedule r 1 (x)w 2 (y)r 1 (y)w 1 (x)c 1 r 3 (y)r 3 (z)w 3 (z)w 2 (x)c 2 w 4 (z)c 4 c 3 wird der folgende Ablauf erzeugt: (ul i bezeichnet einen Unlock, der alle Sperren der Transaktion t i freigibt) s = rl 1 (x)r 1 (x 0 )wl 2 (y)w 2 (y 2 )rl 1 (y)r 1 (y 0 )wl 1 (x)w 1 (x 1 )cl 1 (x)ul 1 c 1 rl 3 (y)r 3 (y 0 )rl 3 (z)r 3 (z 0 )wl 2 (x)cl 2 (x)wl 3 (y)w 3 (z 3 )cl 3 (z)ul 3 c 3 cl 2 (y)ul 2 c 2 wl 4 (z)w 4 (z 4 )cl 4 (z)ul 4 c 4 Die Transaktion t 2 fordert ihren commit lock cl 2 (y) unmittelbar vor Beginn von t 4 an, dieser kann aber wegen des im Konflikt stehenden read locks von t 3 nicht vor deren Ende gewährt werden. Die Anforderung wl 4 (z) steht im Konflikt mit der gehaltenen Sperre wl 3 (z), daher wartet auch t 4 auf das Ende von t 3 : r 1 (x 0 ) r 1 (y 0 ) t 1 w 2 (y 2 ) t 2 w 1 (x 1 ) w 2 (x 2 ) c 2 r 3 (y 0 ) t 3 r 3 (z 0 ) w 3 (z 3 ) w 4 (z 4 ) t 4 c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-36

Deadlocks Wie schon das 2PL-Protokoll, so ist auch MV2PL nicht Deadlock-frei: Beispiel 5-14: Gegeben sei der Input r 1 (x)r 2 (y)w 1 (y)w 2 (x). Der Scheduler erzeugt den Output rl 1 (x)r 1 (x)rl 2 (y)r 2 (y) Jetzt müsste t 1 die Sperre cl 1 (y), die inkompatibel mit rl 2 (y) ist, erhalten und umgekehrt benötigt t 2 die Sperre cl 2 (x), die wegen rl 1 (x) nicht gewährt werden kann, ein Dealock! Zur Behandlung von Deadlocks können die gleichen Maßnahmen wie im Einversionen-Fall angewendet werden. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-37

5.5.3 Mehrversionen-Serialisierbarkeitsgraph-Tester Im Gegensatz zum Einversionen-SGT-Scheduler kann nun nicht mehr ein Protokoll angegeben werden, das genau die Klasse MCSR erzeugt. Vielmehr gibt es nun eine unbeschränkte Anzahl von Schedulern, die jeweils eine eigene Unterklasse von MCSR erzeugen, deren Vereinigung MCSR ergibt. Wir skizzieren das Vorgehen, wobei nicht-deterministische Schritte enthalten sind. Werden diese Schritte deterministisch spezifiziert, so resultieren die jeweiligen Scheduler. Der MVSGT-Scheduler benutzt einen MV-Konfliktgraphen G, dessen Knoten die Transaktionen inkl. t 0 sind. Zu Beginn enthält G nur Kanten von t 0 zu allen anderen Transaktionen; am Ende sind alle Kanten des MV-Konfliktgraphen, sowie je nach Wahl der nicht-deterministischen Schritte einige weitere enthalten. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-38

Vorgehensweise Bei der Zuordnung von Versionen zu Leseschritten geht man wie folgt vor: einem Schritt r i (x) können als Kandidaten t 0 und solche w j (x) zugeordnet werden, die bereits ausgeführt wurden. Allerdings müssen ausgeschieden werden: diejenigen t j, die auf einem Pfad ausgehend von t i in G liegen, denn diese sollen in der Serialisierungsreihenfolge nach t i liegen; wir nennen diese zu spät; diejenigen t j, für die es Pfade zu einem anderen Kandidaten t k und von t k zu t i gibt, da in der Serialisierungsreihenfolge t k x nach t j schreibt; diese nennen wir zu früh. Ein erster nicht-deterministischer Schritt wählt nun jeweils zu r i (x) eine Version aus, die weder von einer zu frühen noch von einer zu späten Transaktion geschrieben wurde. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-39

Beispiel Beispiel 5-15: Im Beispielgraphen sind t 0 und die Kanten von t 0 zu t i, i {1,..., 7} nicht dargestellt: t 4 t 5 t 6 t 7 t 1 t 2 t 3 Wenn r 1 (x) aufgerufen wird, nachdem t 2 bis t 7 x bereits geschrieben haben, sind diese alle Kandidaten im obigen Sinn. t 2 und t 3 sind jedoch zu spät, während t 0 und t 4 zu früh sind. Der Scheduler kann also zwischen t 5, t 6, t 7 beliebig auswählen. Bemerkung: Wenn G azyklisch ist, gibt es für jeden Leseschritt mindestens eine Transaktion, die weder zu früh noch zu spät ist. (Es sind nie alle zu spät, unter den nicht zu späten wähle eine, die die keinen Pfad zu anderen nicht zu späten hat, diese ist nicht zu früh.) c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-40

Pflege des MV-Konfliktgraphen Wenn w i (x) ausgeführt wird, füge eine Kante (t j, t i ) für diejenigen t j hinzu, die bereits ein r j (x) ausgeführt haben; so bleibt G ein Obergraph des MVSG. Wenn G so zyklisch würde, wird w i (x) nicht ausgeführt, sonst wird die neue Version gespeichert. Wenn r i (x) mit einer Version w j (x) ausgeführt wird, füge die Kante (t j, t i ) in G ein; da t j nicht zu spät ist, wird kein Zyklus geschlossen. Zusätzlich wird jeweils eine beliebige der Kanten (t k, t j ) oder (t i, t k ) hinzugefügt, wenn w k (x) bereits ausgeführt wurde und t k weder zu früh noch zu spät ist. Im obigen Beispiel würden bei Auswahl von t 7 aus den Kandidaten die Kanten (t 7, t 1 ) und (t 5, t 7 ) (die alternative Kante (t 1, t 5 ) würde zu einem Zyklus führen), sowie entweder (t 1, t 6 ) oder (t 6, t 7 ) hinzugefügt. Genauer wird die Auswahl von (t k, t i ) getroffen, wenn es einen Pfad von t k nach t i in G gibt, und (t i, t k ) anderfalls. Man kann zeigen, dass G so azyklisch bleibt und dass jeder so entstandene Schedule in MCSR liegt. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-41

5.5.4 Ein Mehrversionen-Protokoll für Read-Only Transaktionen Motivation: viele Anwendungen beinhalten lange Lesetransaktionen, die große Datenmengen lesen/analysieren. Durch ihre lange Laufzeit werden so mit herkömmlichen (z.b. (SS)2PL- Schedulern) extrem hohe Konflikt- und Blockierungswahrscheinlichkeiten erzeugt. MV-Protokolle vermeiden diese lange Wartezeiten durch die Zuweisung von alten Versionen zu diesen Lesetransaktionen; umgekehrt erfordern sie jedoch signifikant größeren Implementierungsaufwand Idee: wende MV-Concurrency Control nur für die Lesetransaktionen an hybride Protokolle, so dass mit wenig Aufwand ein Großteil des Nutzens von MV-Protokollen erreicht werden kann. Lesetransaktionen müssen beim BOT explizit als solche gekennzeichnet werden! c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-42

Read-Only MV-Protokoll (ROMV) 1. Update-Transaktionen: werden mit dem bekannten (S)S2PL behandelt, fordern also wie gewohnt Sperren an und folgen bei der Freigabe der S2PL- bzw. SS2PL-Strategie. Im Gegensatz zum normalen (S)S2PL erzeugen Update-TXs allerdings neue Versionen von geänderten Objekten, die mit dem Zeitstempel der ändernden Transaktion (= ihrem Commit-Zeitpunkt) markiert werden. 2. Read-Only-Transaktionen: werden mit einem MV-Zeitstempelverfahren ähnlich MVTO behandelt, allerdings werden committete und nicht committete Versionen in ihrer Rolle vertauscht: Jede solche TX erhält einen Zeitstempel (= ihren Beginn-Zeitpunkt!). Jeder Leseoperation einer RO-TX wird die neueste zu ihrem Beginn-Zeitpunkt committete version zugeordnet (also die Version mit dem größten Zeitstempel kleiner als der Zeitstempel der Lese-TX). Beachte die unterschiedliche Vergabe von Zeitstempeln bei Lese- bzw. Änderungstransaktionen! c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-43

Beispiel Beispiel 5-16: t 2, t 3 seien Update-, t 1, t 4, t 5 Read-Only-Transaktionen. Die gestrichelte Linie bei t 3 zeigt einen Lock-Wait (wg. des wr-konfliktes auf x) an. r 1 (x 0 ) r 1 (y 0 ) t 1 r 2 (x 0 ) w 2 (x 2 ) r 2 (y 0 ) w 2 (y 2 ) t 2 r 3 (x 2 ) w 3 (x 3 ) t 3 r 4 (z 0 ) r 4 (x 0 ) t 4 r 5 (z 0 ) r 5 (x 2 ) t 5 c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-44

Anmerkungen Zur Korrektheit: die Versionsordnung ist durch die Commit-Reihenfolge (die Zeitstempel der Update-Transaktionen) gegeben. Lese-Transaktionen werden in der Serialisierungsreihenfolge nach ihrem Zeitstempel (zwischen die Änderungstransaktionen) eingefügt. So lässt sich zeigen, dass der MV-Serialisierungsgraph zu dieser Versionsordnung azyklisch ist. Implementierungsprobleme: Versionen dienen lediglich der Synchronisation, sollten also sobald sie nicht mehr benötigt werden gelöscht werden. Hinreichende Bedingungen hierfür sind: 1. eine Version ist nicht die neueste committete Version eines Objektes, und 2. ihr Zeitstempel ist älter als der älteste Zeitstempel einer noch aktiven Lese-Transaktion. Dieser Ansatz setzt voraus, dass keine Beschränkung der Anzahl Versionen existiert. Gibt es eine solche, dann müssen u.u. Lese-TXs abgebrochen werden, wenn die Versionen, die sie lesen müssen, nicht mehr verfügbar sind. Die Zeitstempel-Verwaltung wird dadurch kompliziert, dass Update-Transaktionen den Zeitstempel ihres Commit-Zeitpunktes bekommen. Hierzu könnten die Zeitstempel in den gespeicherten Objekten abgelegt werden (müssten dann aber beim Commit alle verändert werden), oder es werden zusätzliche Datenstrukturen benötigt, die temporär Write-Sets und Zeitstempel von Update-Transaktionen verwalten. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-45

5.6 Zusammenfassung Das Vorhalten von mehreren Versionen gespeicherter Datenobjekte ist theoretisch wie praktisch eine attraktive Möglichkeit, die potentielle Parallelität von Transaktionen zu erhöhen. Die Erweiterung der Theorie (z.b. Serialisierbarkeitsklassen) ist, nach Definition passender Einschränkungen bei der Standard-Versionierungsfunktion, einfach. Probleme und interessante Ergebnisse ergeben sich bei Beschränkung der Anzahl vorgehaltener Versionen (eine ganze Hierarchie von Serialisierbarkeitsklassen). Die Implementierung (z.b. mit entsprechenden Sperr-Modi) ist nicht sehr komplex. Mehrere Versionen eröffnen Freiheitsgrade bei der Zuordnung von Versionen zu Lese- Operationen. Die Verwendung von Versionen zur Behandlung langer Lese-Transaktionen ist besonders einfach und praxisrelevant (einige kommerzielle Datenbanksysteme implementieren das angegebene oder ähnliche hybride Protokolle). c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-46

5.7 Literaturhinweise Die Idee der Versionierung zur Synchronisation geht auf (Reed 1978; Reed 1983) und (Bayer et al. 1980), von dort stammen auch MVTO bzw. 2V2PL. Praktisch relevante hybride Protokolle finden sich in (DuBourdieu 1982; Chan et al. 1982); zu Implementierungsaspekten siehe (Mohan et al. 1992). Eine nette Übersicht über die Idee der Versionierung findet sich in (Schueler 1977). Nicht-transparente Versionen (also Benutzern sichtbare Verionen von Objekten, etwa im CAD-Kontext) werden z.b. in (Cellary und Jomier 1990; Katz 1990) diskutiert. Bayer, R., H. Heller und A. Reiser (1980). Parallelism and Recovery in Database Systems. ACM Transactions on Database Systems, 5:139 156. Cellary, W. und G. Jomier (1990). Consistency of Versions in Object-Oriented Databases. In: Proc. Intl. Conf. on Very Large Databases, S. 432 441. Chan, A., S-Fox, W. Lin, A. Nori und D. Ries (1982). The Implementation of an Integrated Conmcurrency Control and Recovery Scheme. In: Proc. ACM SIGMOD Conference on Management of Data, S. 184 191. DuBourdieu, D. (1982). Implementation of Distributed Transactions. In: Proc. 6th Berkeley Workshop on Distr. Data Mmgt. and Computer Networks, S. 81 93, Berkeley, CA. Katz, R.H. (1990). Toward a Unified Framework for Version Modeling in Engineering Databases. ACM Computing Surveys, 22:375 408. Mohan, C., D. Haderle, B. Lindsay, H. Pirahesh und P. Schwarz (1992). ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging. ACM Transactions on Database Systems, 17:94 162. Reed, D.P. (1978). Naming and Synchronisation in Decentralized Computer System. PhD Thesis, MIT, Cambridge, MA. Reed, D.P. (1983). Implementing Atomic Actions on Decentralized Data. ACM Transactions on Computer Systems, 1(1):3 23. Schueler, B.-M. (1977). Update Reconsidered. In: Proc. IFIP Working Conf. on Architecture and Models in DBMS, S. 149 164, Nice, France. North-Holland Publ. c M. Scholl, 2002 Transaktionssysteme: 5. Mehrversionen-Concurrency Control 5-47