4 Concurrency Control: Algorithmen. Ziel: Entwicklung von Schedulern (Scheduling Algorithmen, Scheduling Protokollen), die konfliktserialisierbare

Transkript

1 4 Concurrency Control: Algorithmen 4.1 Vorüberlegungen Ziel: Entwicklung von Schedulern (Scheduling Algorithmen, Scheduling Protokollen), die konfliktserialisierbare Schedules erzeugen. Wie im vorherigen Kapitel bleibt die Fehlerbehandlung noch unberücksichtigt. Neben der Untersuchung von Scheduling-Strategien an sich und deren Korrektheit betrachten wir zwei Kriterien: Safety: jedes untersuchte Protokoll muss sicherstellen, dass alle erzeugbaren Schedules in der Klasse CSR liegen, also (konflikt-) serialisierbar sind. Scheduling Power: wie groß ist die Teilklasse Gen(S) von CSR, die tatsächlich von einem Scheduler S erzeugt wird? Je größer diese Teilklasse, umso mehr potentielle Parallelität lässt ein Protokoll zu. CSR-Safety eines Schedulers S : Gen(S) CSR. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-1

2 Transaktionsscheduling Transaction Manager (TM): nimmt Aufrufe (read, write, commit, abort) von oben entgegen, übernimmt Concurrency Control (und Recovery) -Aufgaben, reicht sie nach unten an Data Manager (DM) weiter; verwaltet Transaktionslisten trans, active, commit, abort; überführt Input- in Output- Schedule; erkennt Beginn ( BOT ) und Ende ( EOT ) einer Transaktion; gibt c i -Schritt bei EOT(t i ) an DM weiter, wenn kein Fehler aufgetreten, gibt a i -Schritt an DM weiter sobald Fehler in t i erkannt. Transaction Manager transactions input schedule scheduler serializable output schedule s Data Manager database BOT /EOT commit(s) abort(s) active(s) trans(s) c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-2

3 Transaktionszustände Der Scheduler versetzt eine Transaktion bei verschiedenen Aktionen in einen der folgenden Zustände: BOT active delay running delayed restart recover reject EOT aborted committed c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-3

4 Prinzipielle Arbeitsweise eines Schedulers Der Scheduler erhält von oben read (r), write (w), commit (c) und abort (a)-aufrufe eines Input- Schedules und überführt diese in einen serialisierbaren Output-Schedule, dazu hat er folgende Optionen: Output: der Aufruf wird sofort ans Ende des bisherigen Output-Schedules angehängt (bei r, w, a, c-schritten), Reject: der Schritt wird nicht ausgeführt, sondern die aufrufende Transaktion wird (mittels eines a-aufrufes) abgebrochen (bei r, w-schritten), Delay: der Schritt wird weder sofort ausgeführt, noch abgebrochen, er wird als derzeit nicht ausführbar betrachtet und später wieder untersucht (bei r, w-schritten). c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-4

5 Generischer Scheduling-Algorithmus Konkrete Algorithmen müssen festlegen Algorithm scheduler; var newstep: step; { state := initial state; repeat on arrival(newstep) do { update(state); if test(state, newstep) then output(newstep) else delay(newstep) or reject(newstep) } forever }; Welche Informationen charakterisieren den Zustand (state) und wie wird diese Information basierend auf einem neuen Schritt aktualisiert? Woraus besteht der Test, der die zu veranlassende Aktion (execute, delay, reject) festlegt? c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-5

6 Scheduler-Typen Agressives Scheduling: die meisten Schritte werden ausgeführt (execute) und nur wenige werden aufgeschoben (delay); dies birgt die Gefahr, dass irgendwann kein serialisierbarer Output- Schedule entstehen könnte ( optimistisches Scheduling ). Konservatives Scheduling: viele Schritte werden (basierend auf Konflikten) aufgeschoben (delay); im Extremfall werden alle bis auf eine Transaktion aufgeschoben, dann entsteht ein serieller Output-Schedule ( pessimistisches Scheduling ). Locking (Sperren) ist ein konservativer Mechanismus, auf dem viele praktische Scheduler beruhen. Non-Locking Schedulers können aggressiv oder konservativ vorgehen (z.b. mit Time-Stamps oder Validation). c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-6

7 4.2 Sperrende Scheduler Grundidee: Zugriff auf gemeinsame Daten wird über Sperren geregelt, die von Transaktionen angefordert und freigegeben werden können. Gesperrte Objekte sind für andere Transaktionen nicht verfügbar. Fordert eine TX eine Sperre an ( lock request, genauer: der Scheduler fordert für ein TX eine Sperre an), so wird geprüft, ob eine andere TX bereits eine Sperre (die im Konflikt steht, s.u.) hält. Wenn dies der Fall ist, so liegt ein Sperrkonflikt (lock conflict) vor, die anfordernde TX wird suspendiert, sie läuft auf einen Lock Wait und wird blockiert. Andernfalls kann die Anforderung befriedigt werden, die Sperre wird gewährt ( acquire lock ) und die TX läuft weiter. Irgendwann gibt die TX die Sperre wieder frei (lock release). Zu diesem Zeitpunkt prüft der Scheduler, ob eine andere Transaktion aufgeweckt ( resumed ) werden kann, dieser wird ggf. die Sperre gewährt. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-7

8 Sperrmodi Da wir (im Seitenmodell) genau zwei Datenoperationen unterscheiden (read, write), werden wir auch zwei Sperrmodi ( lock modes ) für jedes Objekt x betrachten: eine Lesesperre (read lock, auch: shared lock) rl(x) und eine Schreibsperre (write lock, auch: exclusive lock) wl(x). Die Notation rl i (x) bzw. wl i (x) steht sowohl für das Anfordern einer entsprechenden Sperre durch eine TX t i wie für den durch sie gehaltenen Sperrmodus. Analog bezeichnen ru(x) und wu(x) die entsprechenden Sperrfreigabeoperationen. Offenbar gilt: zwei Sperren pl i (x) und ql j (y) mit i j stehen im Konflikt, gdw. x = y und die Datenoperationen p und q im Konflikt stehen (wenn also p = r q = w oder p = w q = r oder p = w q = w). Der Konfliktbegriff überträgt sich also unmittelbar von den Datenoperationen auf die Sperren (das gilt auch für andere Transaktionsmodelle). Üblicherweise stellt man die Sperrmodi und ihre Konfliktrelation in Form einer Kompatibilitätsmatrix dar. In unserem Fall also: rl i (x) wl i (x) rl j (x) + wl j (x) c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-8

9 Sperrprotokolle Offenbar muss ein Scheduler kontrollieren, in welcher Reihenfolge Transaktionen Sperren anfordern und freigeben, d.h. er muss ein bestimmtes Sperrprotokoll erzwingen. Anhand des generischen Scheduling Algorithmus von oben sehen wir: Sei der nächste Schritt (newstep im Algorithmus) von der Form o i (x), o {r, w}. Wenn die Transaktion i noch keine entsprechende Sperre hält, wenn also ol i (x) noch nicht gesetzt ist, testet der Scheduler, ob ein pl j (x), j i, p {r, w} gesetzt ist: 1. wenn dies nicht der Fall ist, so wird ol i (x) gewährt, 2. wenn dies der Fall ist, so muss geprüft werden, ob ol i (x) im Konflikt mit gehaltenen Sperren anderer Transaktionen auf x ist: (a) wenn kein Konflikt vorliegt, wird ol i (x) gewährt (der Scheduler trägt in eine Sperrtabelle ein, dass (auch) t i eine ol-sperre auf x hält), (b) im Konfliktfall wird die Transaktion t i suspendiert. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-9

10 Um Sperren erweiterte Transaktionen Formal gesehen, erweitert jeder Scheduler die Input-Transaktionen um Operationen zur Sperr- Anforderung und -Freigabe. Für solche erweiterten ( locked ) Transaktionen in einem Schedule fordern wir die folgenden Wohlgeformtheitsregeln. Jede in einem Schedule s vollständig auftretende Transaktion t i erfüllt die Bedingungen LR1 LR3: LR1: Wenn t i einen Schritt der Form r i (x) [bzw. w i (x)] enthält, dann enthält der Schedule s auch einen Schritt rl i (x) [bzw. wl i (x)] vor diesem Schritt, sowie einen Schritt ru i (x) [bzw. wu i (x)] nach diesem. LR2: Für jedes Objekt x enthält ein Schedule s höchstens einen Schritt rl i (x) und höchstens einen Schritt wl i (x) pro Transaktion t i. LR3: Ein Schedule s enthält keine überflüssigen Schritte ru i oder wu i. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-10

11 Beispiel 4-1: Wir betrachten die Transaktionen t 1 = r 1 (x)w 1 (y) und t 2 = w 2 (x)w 2 (y) und die (wohlgeformte) History s 1 = rl 1 (x)r 1 (x)ru 1 (x)wl 2 (x)w 2 (x)wl 2 (y)w 2 (y)wu 2 (x)wu 2 (y)c 2 wl 1 (y)w 1 (y)wu 1 (y)c 1 Offenbar sind die Regeln LR1 LR3 eingehalten. Dies gilt auch für die (serielle) History s 2 = rl 1 (x)r 1 (x)wl 1 (y)w 1 (y)ru 1 (x)wu 1 (y)c 1 wl 2 (x)w 2 (x)wl 2 (y) w 2 (y)wu 2 (x)wu 2 (y)c 2 Mitunter unterscheiden wir Schedules mit und ohne lock/unlock-operationen. Dazu vereinbaren wir folgende Notation: zu einem um Sperren erweiterten Schedule s bezeichnet DT(s) die Projektion von s auf Operationen der Typen r, w, a, c, also Daten- und Terminierungsoperationen. Beispiel 4-2: Am Beispiel oben: DT(s 1 ) = r 1 (x)w 2 (x)w 2 (y)c 2 w 1 (y)c 1 DT(s 2 ) = r 1 (x)w 1 (y)c 1 w 2 (x)w 2 (y)c 2 (= t 1 t 2 ) c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-11

12 Anmerkungen Der Schedule s 1 aus dem Beispiel ist nicht in CSR, da zwischen ru 1 (x) und wl 1 (y) beide Objekte x, y von der Transaktion t 2 verändert werden! Natürlich muss ein CSR-sicherer Scheduler diese Ausführungsreihenfolge verhindern. Wir werden im folgenden oft die kürzere Notation s anstelle von DT(s) verwenden um uns auf einen Schedule oder eine History ohne Lock- und Unlock-Operationen zu beziehen. Es ist jedoch wichtig, sich klar zu machen, dass ein formaler Unterschied zwischen dem Output eines Sperrprotokolls und demjenigen besteht, das für die Korrektheit der Ausführung betrachtet weden muss! Die Regeln LR1 LR3 über die Wohlgeformtheit gelten für alle Transaktionen eines Schedules, insbesondere auch für aktive und sogar abgebrochene Transaktionen! Wir gehen ferner davon aus, dass die abort-behandlung in einem TX-System auch die Sperrfreigabe beinhaltet. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-12

13 4.2.1 Zwei-Phasen Sperrprotokoll... das mit Abstand für die Praxis wichtigste Verfahren! Sprechweise: Ein Scheduler hält ein Sperrprotokoll ein, wenn für jeden Output-Schedule s und jede Transaktion t i trans(s) gilt: 1. t i genügt den Wohlgeformtheitsregeln LR1 LR3; 2. wenn x von zwei Transaktionen t i und t j, t i, t j trans(s), i j gesperrt ist, dann stehen diese Sperren nicht im Konflikt. Das Zwei-Phasen-Sperrprotokoll wird nun durch die folgende Regel über Freigabezeitpunkte von Sperren charakterisiert: Definition 4-1: (Zwei-Phasen-Sperrprotokoll (2PL)) Ein Sperrprotokoll ist zweiphasig, wenn für jeden Output-Schedule s und jede Transaktion t i trans(s) gilt: nach dem ersten Schritt ou i folgt kein weiterer Schritt pl i, mit o, p {r, w}. Ein zweiphasiges Sperrprotokoll wird mit 2PL-Scheduler oder kurz 2PL abgekürzt. Beispiel 4-3: Am Beispiel 4-1: von oben sieht man, dass es nicht 2PL ist, da ru 1 (x) < s wl 1 (y). c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-13

14 Beispiel 4-4: Wir betrachten den Input-Schedule s = w 1 (x)r 2 (x)w 1 (y)w 1 (z)r 3 (z)w 2 (y)w 3 (y)w 3 (z) Ein 2PL-Scheduler könnte s zum Beispiel in den folgenden Output-Schedule überführen: 1 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 Beachte: t 3 wandelt die gehaltene Lese-Sperre in eine Schreib-Sperre um ( lock upgrade ), später muss nur die Schreib-Sperre freigegeben werden. Außerdem sieht man, dass Sperren nicht in der gleichen Reihenfolge freigegeben werden müssen, in der sie angefordert wurden. Wir zeigen nun die CSR-Safety des 2PL-Protokolls. Dazu benutzt man die folgenden Lemmata der natürlich nicht eindeutig bestimmt ist! c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-14

15 Lemma 4-1: Sei s Output eines 2PL-Schedulers. Dann gilt für alle Transaktionen t i commit(dt(s)): 1. Wenn o i (x)(o {r, w}) in CP(DT(s)) vorkommt, so auch ol i (x) und ou i (x) und zwar in der Anordnung ol i (x) < s o i (x) < s ou i (x). 2. Sei t j commit(dt(s)), i j eine andere Transaktion, so dass Schritte p i (x) und q j (x) aus CP(DT(s)) im Konflikt stehen. Dann gilt entweder pu i (x) < s ql j (x) oder qu j (x) < s pl i (x). (Wenn zwei Operationen im Konflikt stehen, dann auch die entsprechenden Sperren; Sperren, die im Konflikt stehen, werden nicht gleichzeitig gewährt.) 3. Wenn p i (x) und q i (y) in CP(DT(S)) vorkommen, dann gilt pl i (x) < s qu i (y). Lemma 4-2: Sei s Output eines 2PL-Schedulers und G := G(CP(DT(S))) der Konfliktgraph von CP(DT(S)). Es gilt: 1. Wenn (t i, t j ) eine Kante in G ist, dann gilt pu i (x) < s ql j (x) für irgendein x und zwei Konflikt-Operationen p i (x) und q j (x). 2. Wenn (t 1, t 2,..., t n ) ein Pfad in G ist mit n 1, dann gilt pu 1 (x) < s ql n (y) für Objekte x und y Operationen p 1 (x) und q n (y). 3. G ist azyklisch. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-15

16 2PL garantiert Serialisierbarkeit Die beiden Lemmata zeigen das folgende Ergebnis: Satz 4-3: Ein 2PL-Scheduler ist CSR-safe, d.h. Gen(2P L) CSR. Formal enthält Gen(S) eines Sperrprotokolls S nur die Daten- und Terminierungsoperationen DT(s) eines Output-Schedules s. Die Inklusion aus dem Satz ist echt, wie das folgende Beispiel zeigt, 2PL kann also nicht alle CSR-Schedules erzeugen: Beispiel 4-5: Sei s = w 1 (x)r 2 (x)c 2 r 3 (y)c 3 w 1 (y)c 1. Es gilt s CSR, da s c t 3 t 1 t 2. Andererseits kann aber s nicht durch einen 2PL-Scheduler erzeugt werden: 2PL würde zuerst eine Schreibsperre für t 1 auf x setzen, was sofort t 2 verzögern würde. Die nächste mögliche Sperrvergabe wäre dann die Lesesperre auf y für t 3. Sobald t 3 beendet ist, kann t 1 eine Sperre auf y setzen und zum Ende gelangen. Erst danach könnte t 1 fortfahren. Wenn also s Input für einen 2PL-Scheduler wäre, so würde als Output s = w 1 (x)r 3 (y)c 3 w 1 (y)c 1 r 2 (x)c 2 erzeugt. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-16

17 Das Beispiel zeigt, dass die Tatsache, dass eine Schedule s von einem 2PL-Scheduler erzeugt wurde hinreichende aber nicht notwendige Bedingung für s CSR ist. Dies kann noch präzisiert werden: Satz 4-4: Gen(2P L) OCSR. Wir werden später Alternativen zu 2PL betrachten, die die ganze Klasse OCSR erzeugen können. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-17

18 Wachstums- und Schrupfungsphase von 2PL-Schedules Im Output eines 2PL-Schedulers kann jede Transaktion in eine Wachstumsphase, in der neue Sperren angefordert werden, und eine Schrumpfungsphase, in der nur noch Sperren freigegeben werden können, zerlegt werden: locks of a transaction time growing phase shrinking phase c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-18

19 4.2.2 Deadlock-Behandlung Sperrprotokolle versetzen Transaktionen in Wartezustände, wenn Sperren aufgrund von Konflikten nicht gewährt werden können. Dadurch können zyklische Wartesituationen entstehen. Im einfachsten Fall mit nur zwei beteiligten Transaktionen fordert etwa t 1 eine Sperre an, die von t 2 in einem im Konflikt stehenden Modus gehalten wird, so dass t 1 auf die Freigabe durch t 2 warten muss. Umgekehrt kann danach t 2 eine Sperre anfordern, die von t 1 im Konflikt gehalten wird, also wird nun t 2 auf die Freigabe durch t 1 warten: es entsteht ein Deadlock. Das 2PL-Protokoll ist nicht deadlock-frei: Der Input-Schedule s = r 1 (x)w 2 (y)w 2 (x)c 2 w 1 (y)c 1 wird von einem 2PL-Scheduler schrittweise abgearbeitet, bis folgender Output generiert wurde: rl 1 (x)r 1 (x)wl 2 (y)w 2 (y). Die nun folgende Sperr-Anforderung wl 2 (x) steht im Konflikt zu der von t 1 gehaltenen Sperre rl 1 (x), wird also verzögert. Die letzte verbleibende Operation w 1 (y) erfordert die Sperre wl 1 (y), die mit der von t 2 gehaltenen Sperre wl 2 (y) inkompatibel ist! Der Scheduler kann auch die Sperre von t 1 auf x nicht freigeben (ru 1 (x)), da dann t 1 später keine Sperren mehr anfordern dürfte! Der Scheduler hat also die Transaktionen t 1 und t 2 in einen Deadlock verklemmt. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-19

20 Ein weiterer Auslöser für Deadlocks sind Sperr-Upgrades (lock conversion): Wenn eine Transaktion t 1 ein Objekt x zunächst liest und später ändern will, so kann sie erst rl 1 (x) anfordern und später diese Sperre in wl i (x) konvertieren. Wenn dies zwei Transaktionen zur gleichen Zeit versuchen, etwa für t 1 = r 1 (x)w 1 (x) und t 2 = r 2 (x)w 2 (x), so könnte eine Situation wie die folgende entstehen: rl 1 (x)r 1 (x)rl 2 (x)r 2 (x). Dieses Präfix kann nicht mit einem 2PL-Scheduler fortgesetzt werden, da weder der Upgrade rl 1 (x) wl 1 (x) noch rl 2 (x) wl 2 (x) möglich ist, wieder werden beide Anforderungen (zyklisch) verzögert. Wenn ein Sperrprotokoll Deadlocks erzeugen kann, so muss jede Implementierung diese Situation behandeln können. Dazu gibt es zwei prinzipielle Möglichkeiten: Deadlock-Erkennung: Die Implementierung kann Deadlocks erzeugen, diese müssen erkannt und aufgelöst werden ( Deadlock Detection ). Deadlock-Vermeidung: Die Implementierung wird um weitere Maßnahmen so ergänzt, dass Deadlocks nicht auftreten können ( Deadlock Prevention ). c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-20

21 Deadlock-Erkennung Verfahren basieren auf einem sog. Waits-For Graph (WFG), ein Graph G = (V, E), in dem die Knoten V die aktiven Transaktionen darstellen und jede (gerichtete) Kante (t i, t j ) für eine Wartesituation steht: t i wartet auf die Freigabe einer Sperre durch t j. Offensichtlich liegt ein Deadlock vor, wenn der WFG zyklisch ist. Bei der Deadlock-Erkennung wird dieser WFG explizit aufgebaut und gepflegt. Man unterscheidet Verfahren je nach dem, wie oft und wann der WFG auf Zyklen geprüft wird: Continuous Detection: der Graph wird bei jedem Einfügen einer Kante (also immer dann, wenn eine TX durch eine nicht gewährte Sperre blockiert wird) auf Zyklen geprüft; ein evtl. Zyklus wird sofort aufgehoben. Periodic Detection: der Graph wird nur periodisch (z.b. einmal pro Sekunde) auf Zyklen geprüft. Offenbar ist die Festlegung der Periode kritisch und hat u.u. großen Einfluss auf die Performance des Transaktionssystems. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-21

22 Opfer-Auswahl (Victim Selection) Werden (ein oder mehrere) Zyklen erkannt, so müssen diese aufgelöst werden, indem jeweils mindestens eine Transaktion pro Zyklus abgebrochen (abort) wird. Dazu muss ein Opfer ausgewählt werden. Hierzu gibt es verschiedene Kriterien: Current Blocker: Wähle diejenige TX, die zuletzt blockiert wurde, d.h. bei Continuous Detection diejenige TX, die die Sperre der laufenden Anforderung hält. Random Blocker: Wähle eine beliebige TX aus dem Zyklus zufällig aus. Minimum Locks: Wähle diejenige TX, die die wenigsten Sperren hält. Youngest: Wähle die TX, die die jüngste Startzeit hat. Minimum Work: Wähle diejenige TX, die bislang die wenigsten Ressourcen verbraucht hat (z.b. CPU-Zeit). Most Cycles: Wähle diejenige TX, die (bei mehreren Zyklen) die meisten Zyklen aufbricht. Most Edges: Wähle diejenige TX, die die meisten inzidenten Kanten hat. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-22

23 Beispiele t t t t 1 t 2 t 3 t 8 t 9 t 6 t 5 t 4 t 7 t 10 t 1 t 2 t 3 Das Einfügen der gestrichelten Kanten führt in beiden Graphen zu mehreren Zyklen. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-23

24 t 3 t 4 t 2 t 5 t 1 Im oberen Graphen liegt ein Zyklus vor. Bei Auswahl von t 1 als Opfer bleiben 2, bei Auswahl von t 2 4 Kanten in dem Graphen erhalten. Offenbar ist daher die Wahl von t 1 besser. t 3 abort of t 6 t t abort of t t 4 t 4 t 2 t 5 t 1 t 5 t 6 t 6 c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-24

25 Deadlock-Vermeidung Es werden nie blockierende Zustände erreicht, die zu zyklischen Wartesituationen führen können. Dazu sind entsprechend konservative Protokolle notwendig. Mögliche Restriktionen sind: Wound-Wait: Führt eine Sperranforderung von t i zu einem Konflikt mit t j, so verfahre wie folgt: wenn t i vor t j gestartet wurde, dann wird t j (abgebrochen und) neu gestartet ( t i wounds t j ); andernfalls wird t i blockiert (t i wartet auf t j ). Eine TX kann nur von einer älteren blockiert werden, jüngere, die im Konflikt stehen, können abgebrochen werden. Wait-Die: Führt eine Sperranforderung von t i zu einem Konflikt mit t j, so verfahre wie folgt: wenn t i vor t j gestartet wurde, wird t i blockiert (t i wartet auf t j ). andernfalls wird t i (abgebrochen und) neu gestartet ( t i dies ). Eine TX kann nur von jüngeren blockiert werden. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-25

26 Immediate Restart: Wenn ein Sperranforderung von t i zu einem Konflikt mit t j führt, so wird t i (abgebrochen und) neu gestartet. Es entsteht also nie eine Wartesituation. Running Priority: Führt eine Sperranforderung von t i zu einem Konflikt mit t j, so verfahre wie folgt: wenn t j zur zeit wegen eines anderen Konfliktes wartet, so wird t j (abgebrochen und) neu gestartet, t i erhält die Sperre. andernfalls wird t i blockiert (t i wartet auf t j ). Blockierte TXs können den Fortschritt anderer nicht behindern. Beachte: die ausgewählten Opfer müssen hier nicht notwendigerweise in einen Deadlock verklemmt sein, das zeigt den konservativen Charakter dieser Verfahren. Eine dritte Sorte von Verfahren zur Deadlock-Behandlung benutzt Timeouts: wenn eine TX länger als eine bestimmte Zeit auf eine Sperre gewartet hat, dann wird sie abgebrochen (und neu gestartet) in der Annahme, dass sie in einen Deadlock verklemmt ist. Offenbar muss das nicht zutreffen, die Wahl des Timeout-Intervalls ist hier kritisch! Dafür sind solche Verfahren jedoch sehr einfach zu realisieren. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-26

27 4.2.3 Varianten von 2PL Aus der Abbildung zur Wachstums- und Schrumpfungsphase können umittelbar mögliche Spezialfälle von 2PL-Schedulern abgelesen werden. Definition 4-2: (Konservatives 2PL (Preclaiming)) Unter dem statischen oder konservativen 2PL-Protokoll (C2PL) fordert jede Transaktion alle Sperren am Anfang, also vor ihrem ersten r- oder w-schritt. Dies wird auch Preclaiming aller Sperren zu Beginn genannt. Die Wachstumsphase entartet dann zu einem Intervall der Länge 0: locks of a transaction Konservatives 2PL (C2PL, Preclaiming) C2PL vermeidet Deadlocks, da alle Sperren auf einmal angefordert werden. Eine TX, die auf Sperranforderungen warten muss, kann also noch keine anderen Sperren halten. Nachteil: der Scheduler muss den kompletten Read-Set und Write-Set jeder TX zu Beginn kennen. time c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-27

28 Definition 4-3: (Striktes 2PL) Unter dem strikten 2PL-Protokoll (S2PL) hält jede Transaktion alle (exklusiven) Schreib-Sperren bis zum Ende (EOT). Hier entartet die Schrumpfungsphase zu einem Intervall der Länge 0 (unter der Annahme, dass alle Sperren Schreibsperren sind): locks of a transaction Striktes 2PL (S2PL) Die meisten Implementierungen nutzen Striktes 2PL. Motivation: ein 2PL-Scheduler kann dann Sperren freigeben, wenn er sicher ist, dass die TX keine weiteren Anforderungen mehr stellen wird. Dies ist sicher bei EOT der Fall. Ein weiterer Vorteil von S2PL ist, dass nur sog. Strikte Histories erzeugt werden, daruf kommen wir bei der Fehlerbehandlung (Recovery) zurück. time c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-28

29 Es macht einen Unterschied, ob alle oder nur die Schreibsperren bis EOT gehalten werden. Dies führt zu einer dritten Variante: Definition 4-4: (Starkes 2PL) Unter dem starken 2PL-Protokoll (SS2PL, strong 2PL) hält jede Transaktion alle Sperren bis zum Ende (EOT). S2PL und SS2PL unterscheiden sich in ihrer Scheduling Power, wie der folgende Satz zeigt (alle Inklusionen sind echt): Satz 4-5: Gen(SS2P L) Gen(S2P L) Gen(2P L) Außerdem gilt: Satz 4-6: Gen(SS2P L) COCSR c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-29

30 4.2.4 Ordered Sharing von Sperren Wir betrachten eine Abschwächung des 2PL-Protokolls, das mehr CSR-Schedules erzeugen kann. Im Beispiel 4-5: haben wir einen CSR-Schedule gesehen, der nicht mittels 2PL erzeugt werden kann: s = w 1 (x)r 2 (x)c 2 r 3 (y)c 3 w 1 (y)c 1. Diese History liegt nicht in Gen(2P L), da die Sperre wl 1 (x) für die erste Operation t 2 nachfolgend blockieren würde. Allerdings ist s CSR, so dass wir s gerne zulassen würden. Das nachfolgend vorgestellte Protokoll erlaubt Situationen wie die bei den ersten beiden Operationen in s, indem zwei im Konflikt stehende Sperren gleichzeitig gewährt werden können. Bislang betrachtete Sperr-Modi: exklusiv (Schreib-Sperre) und nicht-exklusiv (shared) (Lese- Sperre); eine der Sperr-Regeln besagte, dass nur nicht-exklusive Sperren für verschiedene TXs auf dasselbe Objekt gleichzeitig gewährt werden können. Wir definieren einen weiteren Sperrmodus: Zwei Sperren auf demselben Objekt können von verschiedenen Transaktionen gleichzeitig gehalten werden, solange die Sperranforderungen und die Datenoperationen in der gleichen Reihenfolge ausgeführt werden. Offenbar muss der Scheduler jetzt mehr als nur eine Sperrtabelle zur korrekten Implementierung verwenden. Dieser Sperrmodus wird Ordered Sharing genannt und die entsprechende Beziehung zwischen den Sperranforderungen mit pl i (x) ql j (x) bezeichnet. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-30

31 Wenn also in einem Schedule s pl i (x) ql j (x) gilt, so folgt pl i (x) < s ql j (x) und p i (x) < s q j (x). Ordered Sharing von t i nach t j bedeutet, dass t j eine Sperre auf x bekommen kann, obwohl t i eine Konflikt-Sperre hält, wenn die Ordered-Sharing Bedingung eingehalten wird. Ordered Sharing soll in der Kompatibilitätsmatrix der Sperrmodi die exklusiven Sperren bzw. die Einträge ersetzen. Jedes einzelne in der Tabelle kann durch ersetzt werden, sowie beliebige Kombinationen davon. Das führt zu einer Familie von Sperrtabellen LT i, wobei LT 1 die bekannte 2PL-Tabelle darstellt. LT 1 rl i (x) wl i (x) rl j (x) + wl j (x) LT 2 rl i (x) wl i (x) rl j (x) + wl j (x) LT 5 rl i (x) wl i (x) rl j (x) + wl j (x) LT 3 rl i (x) wl i (x) rl j (x) + wl j (x) LT 6 rl i (x) wl i (x) rl j (x) + wl j (x) LT 8 rl i (x) wl i (x) rl j (x) + wl j (x) LT 4 rl i (x) wl i (x) rl j (x) + wl j (x) LT 7 rl i (x) wl i (x) rl j (x) + wl j (x) c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-31

32 Beispiel 4-6: Wir betrachten die History s 1 = w 1 (x)r 2 (x)r 3 (y)c 3 w 1 (y)c 1 w 2 (z)c 2. Wenn alle Sperren wie angefordert gewährt werden, und wir die Kompatibilitäts-Tabelle LT 2 verwenden, dann kann ein Scheduler den folgenden Output erzeugen: wl 1 (x)w 1 (x)rl 2 (x)r 2 (x)rl 3 (y)r 3 (y)ru 3 (y)c 3 wl 1 (y) w 1 (y)wu 1 (x)wu 1 (y)c 1 wl 2 (z)w 2 (z)ru 2 (x)wu 2 (z)c 2 Insbesondere werden hier die Schreibsperre wl 1 (x) und die Lesesperre rl 2 (x) gleichzeitig gewährt. Die Sperr-Tabellen LT 5, LT 7, LT 8 würden diesen Output ebenfalls zulassen. Die History s 2 = r 1 (x)w 2 (x)r 3 (y)c 3 w 1 (y)c 1 w 2 (z)c 2 würde durch einen Scheduler unter Verwendung von LT 3, LT 5, LT 6, LT 8 in dieser Reihenfolge der Datenoperationen abgearbeitet werden können. Die History s 3 = w 1 (x)w 2 (x)r 3 (y)c 3 w 1 (y)c 1 w 2 (z)c 2 könnte durch einen Scheduler mittels LT 4, LT 6, LT 7, LT 8 abgearbeitet werden. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-32

33 Regeln zur Sperranforderung Wir fügen nun zwei weitere Regeln den vorhandenen Regeln LR1 LR3 hinzu. Die erste drückt die Ordered-Sharing Eigenschaft aus: LR4: Wird in einem Schedule für zwei Operationen p i (x) und q j (x), i j, pl i (x) ql j (x) erlaubt, so folgt aus pl i (x) < s ql j (x) auch p i (x) < s q j (x). Wir brauchen zusätzlich eine Regel über Sperrfreigaben. Wenn die Beziehung pl i (x) ql j (x) für zwei Transaktionen t i, t j gilt und t i noch keine Sperren freigegeben hat, so wartet t j auf t i. Wenn es eine solche Transaktion t i gibt, dann befindet sich t j im Wartezustand ( on hold ). LR5: Wenn eine Transaktion im Wartezustand ist (on hold), dann kann sie keine Sperren freigeben. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-33

34 Familie von Ordered-Sharing Sperrprotkollen Wir benutzen 1. Die Sperr-Regeln LR1 LR5, 2. die Zweiphasigkeit und 3. eine der Kompatibilitätstabellen LR 1 LR 8. Wird der Ordered Sharing Sperrmodus nicht benutzt (und also LT 1 verwendet), so erhalten wir das gewöhnliche 2PL-Protokoll. Bei Verwendung von LT 8 bezeichnen wir das Sperrverfahren als O2PL-Protokoll. Beispiel 4-7: Wir betrachten einen O2PL-Scheduler für den Input s = r 1 (x)w 2 (x)r 3 (y)w 2 (y)c 2 w 3 (z)c 3 r 1 (z)c 1. Der Scheduler wird den folgenden Output erzeugen: s =rl 1 (x)r 1 (x)wl 2 (x)w 2 (x)rl 3 (y)r 3 (y)wl 2 (y)w 2 (y)wl 3 (z)w 3 (z) rl 1 (z)r 1 (z)ru 3 (y)wu 3 (z)c 3 ru 1 (x)ru 1 (z)wu 2 (x)wu 2 (y)c 2 c 1 Transaktion t 2 wartet auf t 1 und auf t 3, ist also on hold. Nach LR5 kann t 2 also keine Sperren freigeben bevor die anderen dies getan haben, d.h. t 2 gibt als letzte ihre Sperren frei. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-34

35 Aus LR4 und LR5 ergeben sich: Lemma 4-7: 1. Sei x von pl i (x) und ql j (x) im Ordered-Sharing Modus gesperrt, also gelte pl i (x) ql j (x). Wenn pl i (x) < ql j (x) so folgt p i (x) < q i (x). 2. Wenn pl i (x) ql j (x) und pl i (x) < ql j (x), dann gibt es eine Sperrfreigabe von t i, die allen Sperrfreigaben von t j vorausgeht. 3. Wenn pl i (x) und ql j (x) unverträglich sind und pl i (x) < ql j (x), dann gilt pu i (x) < ql i (x). Sei nun s eine History, die von einem 2PL-Scheduler mit einer der Tabellen LR 1 LR 8 erzeugt wurde. Eine Kante (t, t ) im Konfliktgraph G(s) bedeutet dann, dass es eine Sperrfreigabe von t gibt, die allen Sperrfreigaben von t vorausgeht. Dies überträgt sich auf Pfade in G(s), so dass in einem zyklischen Konfliktgraphen eine Sperrfreigabe eines t allen Sperrfreigaben von t selbst vorausgehen müßte, ein Widerspruch. Folglich gilt: Satz 4-8: Sei Gen(LT i ), 1 i 8, die Menge aller Histories, die mit einem oben definierten Protokoll unter Verwendung der Sperr-Tabelle LT i erzeugt werden können. Es gilt: Gen(LT i ) CSR. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-35

36 Insbesondere ist also auch O2PL CSR-safe. Sei s Gen(O2P L), dann gibt es eine serielle History s c s, in der alle Konflikt-Operationen in der gleichen Reihenfolge wie in s auftreten. Wegen der Verwendung des Ordered-Sharing Modus trifft dies für jedes Paar von Konflikt-Operationen zu, so dass sogar s OCSR gilt. Also: Satz 4-9: Gen(O2P L) OCSR Man kann auch die umgekehrte Inklusion zeigen, so dass gilt: Satz 4-10: Gen(O2P L) = OCSR Wir haben also ein Sperrprotokoll identifiziert, das genau die Klasse der konflikt-ordnungserhaltend konflikt-serialisierbaren Schedules erzeugen kann. In der Praxis wird dieses O2PL-Protokoll dennoch selten verwendet, da es kein reines Sperrprotokoll ist, sondern neben einer Sperrtabelle noch weitere Informationen (über die Anordnung von Operationen) benötigt, was die Implementierung komplex macht. Abhängig von der Workload und den Anwendungscharakteristika ist der Gewinn an potentieller Concurrency diesen Zusatzaufwand nicht wert. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-36

37 4.2.5 Nicht-Zweiphasige Sperrprotokolle Es gibt Sperrprotokolle, die ohne die Bedingung der Zweiphasigkeit Serialisierbarkeit garantieren können. Dort werden spezifische Annahmen über die Transaktionen (bzw. ihr Sperrverhalten) gemacht. Tree Locking: alle Sperranforderungen der Transaktionen folgen einem hierarchischen Zugriffsmuster. Die Daten werden so interpretiert, als ob sie in einer Baumform organisiert sind, jede Transaktion greift auf die Daten in einem Top-Down-Muster zu. Ohne Zweiphasigkeit kann hier Serialisierbarkeit und Deadlock-Freiheit erzielt werden. In der Literatur werden verschiedene solche Verfahren vorgestellt: Write-Only Tree Locking (WTL): es werden nur schreibende Zugriffe betrachtet (bzw. Lesen und Schreiben zu einer Operation kombiniert). Resultat: Gen(WTL) CSR und WTL ist deadlock-frei. Read-Write Tree Locking (RWTL): Das hierarchische Zugriffsmuster alleine garantiert bei unterschiedenen Lese- und Schreibsperren die Serialisierbarkeit nicht. Es sind weitere Maßnahmen erforderlich (Zweiphasigkeit auf gewissen Teilbäumen). Resultat: Gen(RWTL) CSR. DAG-Locking: Das RWTL Protokoll kann auf allgemeine nicht-zyklische Zugriffsmuster erweitert werden. Anmerkung: Solche Sperrprotokolle wurden primär im Kontext interner DBMS-Datenstrukturen untersucht bzw. für die effiziente Implementierung der Concurrency Control auf solchen Strukturen c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-37

38 entwickelt. Dort finden sich tatsächlich oft solche Zugriffsmuster (z.b. bei der Traversierung eines B -Baumes). Für die allgemeine Verwendung (auf den Primärdaten) sind sie meist nicht geeignet. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-38

39 4.3 Nicht-Sperrende Scheduler Serialisierbarkeit kann auch ganz ohne die Vergabe/Verwaltung von Sperren garantiert werden. In kommerziellen Systemen sind solche Verfahren eher selten, allerdings lassen sich hybride Verfahren (s.u.) angeben, die zum Teil auf Sperren verzichten Zeitstempel-Verfahren Idee: Jede Transaktion bekommt (bei BOT) einen Zeitstempel (timestamp). Dieser wird an alle Datenoperationen vererbt. Der Scheduler muss nun im Konflikt stehende Operationen verschiedener Transaktionen in der Reihenfolge ihrer Zeitstempel ausführen (timestamp ordering). Zu jeder Transaktion t i vergibt der TX-Manager einen eindeutigen Zeitstempel ts(t i ) z.b. durch Zugriff auf die Systemuhr bei BOT(t i ) oder durch Nutzung eines Zählers. Die zentrale Regel für den TO-Scheduler (timestamp ordering rule) lautet: Seien p i (x), q j (x), i j im Konflikt stehende Operationen. Es gilt: p i (x) wird vor q j (x) ausgeführt ts(t i ) < ts(t j ). Satz 4-11: Gen(T O) CSR. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-39

40 Implementierungshinweise Einfache Realisierung: Scheduler sendet jede Datenoperation sofort zum Data Manager, außer denjenigen die zu spät kommen. Eine Operation p i (x) kommt zu spät, wenn der Scheduler bereits eine Operation q j (x), i j weitergegeben hat, für die ts(t j ) > ts(t i ). Wenn p i zu spät kommt, dann kann diese Operation nicht mehr ausgeführt werden, ohne die TO-Regel zu verletzen; t i wird abgebrochen (und ggf. später mit neuem Zeitstempel neu gestartet). Für den Test benötigt ein einfacher TO-Scheduler folgende Informationen zu jedem Datenobjekt: max-r-scheduled(x): größter Zeitstempel einer Leseoperation, die bereits an den Data Manager gesandt wurde, max-w-scheduled(x): größter Zeitstempel einer Schreiboperation, die bereits an den Data Manager gesandt wurde. Wenn eine Operation p i (x) beim Scheduler eintrifft, wird ts(t i ) mit max-q-scheduled(x) verglichen für diejenigen q, die mit p im Konflikt stehen. Falls ts(t i ) < max-q-scheduled(x) gilt, wird p i (x) als zu spät zurückgewiesen, andernfalls wird p i (x) an den Data Manager geschickt. max-p-scheduled(x) wird auf ts(t i ) aktualisiert, falls ts(t i ) > max-p-scheduled(x). c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-40

41 Es ist essentiell, dass der Data Manager alle Operationen in der Reihenfolge des Aufrufes ausführt! Beim 2PL wird dies durch das Warten auf Sperren automatisch erzwungen. Beim TO darf der Scheduler eine Operation p i (x), die ausgeführt werden kann, erst dann an den DM weitergeben, wenn alle zuvor übergebenen im Konflikt stehenden Operationen q j (x) ausgeführt sind. Hierzu muss der DM die Ausführung von Operationen an den Scheduler zurück bestätigen (acknowledge), so dass ein Handshake-Protokoll bei den Aufrufen eingehalten wird. Wenn ein TO-Scheduler wie oben beschrieben viele Datenoperationen in anderer als aufsteigender Zeitstempel-Reihenfolge bekommt, dann werden viele Transaktionen abgebrochen. Um dies zu verhindern, könnten Operationen o i (x) mit großen Zeitstempeln künstlich verzögert werden, damit andere noch rechtzeitig ausgeführt werden können. Das Zeitintervall für eine solche Verzögerung (delay) ist offenbar sehr performance-kritisch. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-41

42 4.3.2 Testen des Serialisierbarkeitsgraphen Eine offensichtliche Möglichkeit, Serialisierbarkeit zu garantieren, besteht darin, den Konfliktgraphen ständig auf Zyklenfreiheit zu prüfen, also das Serialisierbarkeitstheorem unmittelbar zum Scheduling zu verwenden. Ein solcher Serialisierbarkeitsgraph-Tester (SGT) arbeitet wie folgt: wenn eine neue Operation p i (x) ankommt, so 1. erzeugt der Scheduler einen neuen Knoten t i im aktuellen Graphen G, sofern dieser noch nicht existiert, wenn also p i (x) die erste Operation von t i ist; 2. werden Kanten (t j, t i ) in G eingefügt für alle Operationen q j (x), i j, die mit p i (x) im Konflikt stehen und die vorher an den DM weitergegeben wurden. Es sind zwei Fälle zu unterscheiden: (a) Der resultierende Graph G ist zyklisch: würde p i (x) ausgeführt, so wäre der Schedule nicht mehr serialisierbar. Folglich wird t i abgebrochen, sowie der Knoten t i und alle inzidenten Kanten aus G entfernt. (b) G bleibt azyklisch. Dann kann p i (x) ausgeführt (an den DM weitergegeben) werden. Der neue aktuelle Graph ist G. Auch hier muss über ein Handshake-Protokoll sichergestellt werden, dass eine Operation erst dann an den DM übergeben wird, wenn alle zuvor übergebenen Konfliktoperationen ausgeführt sind. Satz 4-12: Gen(SGT ) = CSR. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-42

43 Beweis. (-Idee:) Die Richtung ist trivial, die Umkehrung kann durch Induktion über die Länge eines Schedules s CSR gezeigt werden. Anmerkung: ohne weitere Maßnahmen würde der Serialisierbarkeitsgraph immer weiter anwachsen! Leider kann eine Transaktion nicht unmittelbar bei ihrem Ende aus dem Graphen entfernt werden: Beispiel 4-8: Sei s = w 1 (x)w 2 (x)w 2 (y)c 2... w 1 (y). Offenbar ist s / CSR. Würden wir den Knoten t 2 beim Commit aus G entfernen, so gäbe es keine Chance, später den Zyklus im Konfliktgraphen zu erkennen, wenn t 1 die Operation w 1 (y) ausführen will. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-43

44 Beobachtungen Ein SGT-Scheduler kann einen Knoten t i nur dann aus dem Graphen G entfernen, wenn dieser nicht mehr in einen Zyklus verwickelt werden kann auch nicht in beliebig ferner Zukunft! Ein Knoten, der in einen Zyklus verwickelt ist, hat mindestens eine eingehende und mindestens eine ausgehende Kante. Auch nach Transaktionsende können ausgehende Kanten an einen TX-Knoten angefügt werden, jedoch keine eingehenden Kanten mehr. Knoten von abgeschlossenen Transaktionen, die keine eingehenden Kanten mehr haben, können also entfernt werden. Ein andere, hinreichende aber nicht notwendige, Bedingung für die Knotenelimination, die einfach zu testen ist, ist: Transaktionsknoten t i kann entfernt werden, wenn keine anderen Transaktionen mehr aktiv sind, die zum Commit- bzw. Abort-Zeitpunkt von t i aktiv waren. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-44

45 Zur praktischen Relevanz Obwohl SGT-Scheduler die ganze Klasse CSR erzeugen (theoretisch also interessant sind), stehen in der Praxis folgende Gründe gegen eine Anwendung Die (worst case) Speicherplatzanforderungen steigen mit dem Quadrat der Anzahl relevanter Transaktionen (von denen einige sogar bereits abgeschlossen sind). Der Zyklentest (linear in der Anzahl Kanten, also quadratisch in der Anzahl Knoten; worst case) ist zu aufwendig, da er sehr oft ausgeführt werden muss ( in der innersten Schleife eines Data Servers). c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-45

46 4.3.3 Optimistische Protokolle Bisherige Annahme: Konflikte sind häufig. Daher lohnt es sich für den Scheduler, jeweils bei Eintreffen einer Operation sofort zu prüfen, ob die Operation ausgeführt, zurückgestellt oder zurückgewiesen werden soll ( pessimistische Annahme ). Jetzt: Wir nehmen an, dass Konflikte selten sind! (in vielen Anwendungen durchaus realistisch) ein 2PL-Scheduler vergeudet viel Zeit mit Sperr-Anforderungen, Kompatibilitätsprüfungen und Sperr-Freigaben, anstatt Datenoperationen auszuführen. Idee: Optimistische Scheduler lassen ankommende Datenoperationen i.w. passieren (werden an DM weitergeleitet) und prüfen lediglich von Zeit zu Zeit, ob der so entstandene Output- Schedule (noch) serialisierbar ist (Validierung des Outputs). Daher werden diese Scheduler auch Validierungsprotokolle genannt. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-46

47 Drei Phasen einer Transaktion Bei Ausführung mit einem optimistischen Scheduler zerfällt eine Transaktion also logisch in drei Phasen: Read Validate Write Lesephase: Die TX wird ausgeführt, alle Schreiboperationen werden auf einer TX-lokalen Kopie ausgeführt, die für andere TXen (noch) nicht sichtbar ist. Zum Ende der Lesephase stehen der Read-Set RS(t) und der Write-Set W S(t) der Transaktion t fest. Validierungsphase: Die TX ist bereit zum Commit. Der Scheduler prüft die Korrektheit (bzgl. Konfliktserialisierbarkeit) der Ausführung und ob die lokal modifizierten Daten in die DB zurückgeschrieben werden können. Ist dies nicht der Fall, so wird die Transaktion abgebrochen; anderfalls erfolgt der Eintritt in die nächste Phase. Schreibphase: Die lokal modifizerten Kopien der DB-Objekte werden zurück in die gemeinsame Datenbank geschrieben, damit ist der Commit der Transaktion abgeschlossen. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-47

48 Anmerkungen Zur Vereinfachung nehmen wir hier an, dass die Phasen 2 und 3 unteilbar (in einem Kritischen Abschnitt) ausgeführt werden, so dass in diesem Abschnitt alle anderen Transaktionen suspendiert sind. Wir sprechen dann von der Val-Write -Phase. Wenn in der Schreibphase größere Datenmengen aus der lokalen Kopie in die DB kopiert werden müssen, so entsteht dadurch ein signifkanter Performance-Engpass! Würden wir die Forderung nicht erheben, so können sich die Schreiboperationen mit Leseoperationen anderer Transaktionen unkontrolliert überlappen. Da die Validierung vor der Schreibphase erfolgt ist, muss anderweitig sichergestellt werden, dass diese Schreiboperationen nicht zu zyklischen Abhängigkeiten im Konfliktgraph führen. Es gibt hierfür verschiedene Lösung, die wir z.zt. jedoch nicht weiter verfolgen. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-48

49 Validierungsregeln Wir sind auch hier an Konfliktserialisierbarkeit (also an azyklischen Konfliktgraphen) interessiert. Wir verwenden für die Validierungsregeln folgendes Lemma 4-13: Sei G ein DAG. Wenn in G ein neuer Knoten so eingefügt wird, dass keine Kanten von ihm ausgehen, dann ist der resultierende Graph wieder ein DAG (und insbesondere azyklisch). (Entstünde nach Einfügen eines Knotens in einen DAG ein Zyklus, so müsste der eingefügte Knoten in diesem enthalten sein.) Man unterscheidet zwei Klassen von Optimistischen Protokollen (OCC = Optimistic Concurrency Control): Backward-Oriented OCC (BOCC): eine validierende Transaktion führt Konflikttests gegen alle bereits erfolgreich abgeschlossenen Transaktionen durch. Forward-Oriented OCC (FOCC): eine validierende Transaktion führt Konflikttests gegen alle noch (in der Lesephase) aktiven Transaktionen durch. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-49

50 BOCC Eine validierende Transaktion t j wird akzeptiert (positiv validiert), wenn für alle Transaktionen t i, die zuvor committed wurden, eine der folgenden Bedingungen gilt: t i wurde beendet bevor t j gestartet wurde (also wurden alle Operationen von t i vor denen von t j ausgeführt): alle Konfliktkanten zwischen t i und t j sind von der Form (t i, t j ) und nicht umgekehrt, also kein Zyklus möglich. RS(t j ) W S(t i ) = und die Val-Write-Phase von t i wurde beendet bevor die von t j begann: dann konnte t j nichts von t i lesen, so dass alle möglichen Konflikte von der Form (t i, t j ) und nicht umgekehrt sein müssen. Satz 4-14: Die BOCC Validierungsregeln erzeugen nur zyklenfreie Konfliktgraphen (also Gen(BOCC) CSR). c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-50

51 FOCC Wenn der zweite Validierungstest nach der BOCC-Regel fehlschlägt, also RS(t j ) W S(t i ) gilt, so muss t j nicht zwingend von t i gelesen haben, denn der Schedule könnte auch so aussehen:... r j (x)... w i (x)... validate(t j )... Nach BOCC würde t j bei der Validierung abgebrochen, obwohl es bereits viel früher, als t i das Objekt x geschrieben hat, klar war, dass t j nicht positiv zum Ende kommen könnte. Daher die Idee, eine Transaktion t j gegen alle anderen zu validieren, die noch in der Lesephase sind. Sei hierzu RS n (t i ) der Read-Set der Transaktion t i zum Zeitpunkt n. Das FOCC-Protokoll akzeptiert eine validierende Transaktion t j zum Zeitpunkt n, wenn für alle zu diesem Zeitpunkt lesenden Transaktionen t i gilt: W S(t j ) RS n (t i ) =. Dies ist insbesondere dann erfüllt, wenn t j eine reine Lesetransaktion ist. Für solche muss also gar keine Validierung erfolgen. Satz 4-15: Die FOCC Validierungsregeln erzeugen nur zyklenfreie Konfliktgraphen (also Gen(FOCC) CSR). c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-51

52 Beispiel BOCC read phase write phase t1 r 1 (x) r 1 (y) val. w 1 (x) t2 r 2 (y) r 2 (z) val. w 2 (z) t3 r 3 (x) r 3 (y) val. abort t4 r 4 (x) val. w 4 (x) t 1 : OK, denn es gibt keine parallele, zuvor beendete TX. t 2 : OK, da ( RS(t 2 ) = {y, z} ) ( W S(t 1 ) = {x} ) =. t 3 : nicht OK, da ( RS(t 3 ) = {x, y} ) ( W S(t 1 ) = {x} ) = {x} =. t 4 : OK, da ( RS(t 4 ) = {x} ) ( W S(t 2 ) = {z} ) =. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-52

53 Beispiel FOCC read phase write phase t1 r 1 (x) r 1 (y) val. w 1 (x) t2 r 2 (y) r 2 (z) val. w 2 (z) t3 r 3 (z) abort t4 r 4 (x) r 4 (y) val. w 4 (y) t5 r 5 (x) r 5 (y) c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-53

54 Validierung von t 1 : vergleiche W S(t 1 ) = {x} mit dem aktuellen Read-Set von t 2 Zeitpunkt der Validierung von t 1, RS(t 2 ) = {y}. zum Validierung von t 2 : Write-Set W S(t 2 ) = {z} ist mit den aktuellen Read-Sets von t 4 und t 5 zum Validierungszeitpunkt disjunkt (RS(t 4 ) = {x, y}, RS(t 5 ) = {x}), aber nicht-disjunkt mit dem von t 3, RS(t 3 ) = {z}. Jetzt gibt es anders als bei BOCC mehrere Möglichkeiten für t 2 : t 2 könnte sich selbst abbrechen, oder die störende Transaktion t 3. Da t 2 schon seit einiger Zeit lief, t 3 jedoch gerade erst gestartet wurde, nehmen wir an, dass t 3 abgebrochen wird, damit nicht zuviel Arbeit verworfen werden muss. Validierung von t 4 zeigt eine dritte Option: t 4 stellt, dass W S(t 4 ) = {y} mit dem aktuellen Read-Set von t 5, RS(t 5 ) = {x, y} überlappt. Alternativ zum Abruch von entweder t 4 oder t 5 ergibt sich nun: t 4 könnte warten (vgl. die gestrichelte Linie) und t 5 zuerst validieren lassen (in der optimistischen Erwartung, dass t 5 positiv validiert), und erst danach ebenfalls positiv validieren. Im Beispiel wäre diese Strategie erfolgreich, da t 5 eine Read-Only TX ist, die trivialerweise positiv validiert wird, so dass anschließend auch t 4 akzeptiert werden kann. FOCC hat gegenüber BOCC den Vorteil einer größeren Flexibilität bei der Auswahl von Opfern, mitunter kann durch Verzögerung der Val-Write-Phase ein Abbruch sogar ganz vermieden werden. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-54

55 4.4 Hybride Protokolle Wir kennen nun eine ganze Reihe von Synchronisationsprotokollen (vgl. nachfolgendes Bild). Die Anzahl der Protokolle kann leicht quadriert werden, indem wir für die folgenden Teilaufgaben unabhängige Lösungen auswählen: 1. rw-synchronisation zwischen Lese- und Schreiboperationen (und umgekehrt), 2. ww-synchronisation zwischen Schreiboperationen. Natürlich müssen beide aufeinander abgestimmt werden, so dass hybride Scheduler entstehen: wenn etwa für die rw-synchronisation ein 2PL-Scheduler verwendet wird und für die ww- Synchronisation ein SGT-Scheduler, so garantieren beide bzgl. der von ihnen betrachteten Fälle Konfliktserialisierbarkeit. Die so erzeugten Serialisierungsreihenfolgen müssen jedoch kompatibel sein: Wenn t 1 bzgl. rw vor t 2 serialisiert wird, so muss dies auch bzgl. ww gelten. Nicht nur die einzelnen Konfliktgraphen bzgl. rw bzw. ww müssen azyklisch sein, sondern auch deren Vereinigung. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-55

56 Übersicht Concurrency Control Protokolle concurrency control protocols pessimistic optimistic non-locking locking BOCC FOCC two-phase non-two-phase TO SGT O2PL 2PL WTL RWTL C2PL S2PL SS2PL c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-56

57 4.5 Zusammenfassung Es gibt eine Vielzahl von Synchronisationsmethoden (Concurrency Control-Protokollen) im Seitenmodell von Transaktionen. Sperrende Scheduler: für Lese- bzw. Schreibzugriffe werden explizit Sperren angefordert (und freigegeben), zweiphasige Sperrprotokolle: jede Transaktion zerfällt in eine Anforderungs- und eine Freigabephase nicht-zweiphasige Sperrprotkolle: die Kontrolle der Zugriffsreihenfolgen erfolgt auf andere Art Nicht-sperrende Scheduler: kommen ohne explizite Sperren aus. Wir werden in anderen TX-Modellen sehen, dass dies die wesentlichen Ansätze für die Synchronisation überhaupt sind. Sie lassen sich meist ohne weiteres auf allgemeinere TX-Modelle übertragen. Das 2PL-Protokoll ist das CC-Protokoll überhaupt. Es ist in den meisten kommerziellen TX-Servern implementiert, da es sehr vielseitig und robust ist. Ferner erreicht es oftmals in praxisrelevanten Lastverteilungen einen höheren TX-Durchsatz als andere Protokolle. c M. Scholl, 2002 Transaktionssysteme: 4. Concurrency Control: Algorithmen 4-57