AG Datenbanken und Informationssysteme Wintersemester 2006 / Übungsblatt. Aufgabe 2: Sperrprotokolle in Datenbankystemen

Transkript

1 AG Datenbanken und nformationssysteme Wintersemester 26 / 27 Prof. Dr.-ng. Dr. h. c. Theo Härder Fachbereich nformatik Technische Universität Kaiserslautern Aufgabe 1: Verklemmungen 9. Übungsblatt Für die Übung am Donnerstag, 11. Januar 27, von 15:3 bis 17: Uhr in 13/ Gegeben sind die Transaktionen T 1,, T 3, T 4 und T 5 sowie die Datenelemente A, B, C, D, E und F. Es gelte das Zwei-Phasen-Sperr-Protokoll. Dabei bedeutet T i (, A), dass die Transaktion T i eine - Sperre auf dem Datenelement A hält bzw. anfordert. T i (, A) bedeute, dass die Transaktion T i eine -Sperre auf dem Datenelement A hält bzw. anfordert. Folgende Sperren werden aktuell durch die Transaktionen gehalten: T 1 (, A), T 1 (, B), T 1 (, E), (, B), T 3 (, C), T 3 (, E), T 4 (, C), T 4 (, D), T 4 (, E), T 5 (, F) Die einzelnen Transaktionen fordern jeweils folgende Sperren an, um mit der Bearbeitung fortfahren zu können: T 1 (, C), (, F), T 3 (, B), T 4 (, A), T 5 (, D) a) Zeichnen Sie den Wartegraphen dieser Transaktionen. b) Begründen Sie anhand hres Wartegraphen, warum eine Verklemmung vorliegt. c) Lösen Sie diese Verklemmung durch Zurücksetzen einer Transaktion auf. Lösung: a) Folgende Sperren werden zu Beginn gehalten: T 1 (,A) T 1 (,B) T 3 (,C) T 4 (,D) T 1 (,E) T 5 (,F) (,B) T 4 (,C) T 3 (,E) T 4 (,E) Damit ergibt sich der Wartegraph: T 3 C C T 1 T 4 B A B D F T 5 b) m Wartegraph existieren Zyklen (T 3 -> T 1 -> T 3, T 4 -> T 1 -> T 4, usw.) und damit auch Verklemmungen. c) Zurücksetzen von T 1. Seite 1 Aufgabe 2: Sperrprotokolle in Datenbankystemen Die Objekte der Datenbank seien in folgender Weise hierarchisch angeordnet: 1,1 1,2... 1,m(1) t 1,1,1 t 1,1,2... t 1,1,n(1,1) DB S 1 S 2... S k k,1... k,m(k) t 1,m(1),1... t 1,m(1),n(1,m(1)) Datenbank Segmente elationen Tupel Diese Darstellung zeigt, dass sich die elation 1,1 aus den Tupeln t 1,1,1, t 1,1,2,..., t 1,1,n(1,1), das Segment S 1 aus den elationen 1,1, 1,2,..., 1,m(1) und die DB aus den Segmenten S 1, S 2,..., S k zusammensetzen. Die einzelnen Transaktionen T i fordern in folgender zeitlicher eihenfolge in Abständen von jeweils einer Zeiteinheit Objekte zum Lesen () oder Schreiben () an. Schreibsperren werden 1 und Lesesperren 2 Zeiteinheiten lang gehalten. Z 1 : T 1 <-- t 1,1,1 in Z 2 : <-- t 1,1,2 in Z 3 : T 3 <-- 1,1 in Z 4 : T 4 <-- 1,2 in Z 5 : T 5 <-- S 1 in Z 6 : T 6 <-- S 2 in Z 7 : T 7 <-- DB in Freigabe der Schreibsperren, wenn sie sofort gewährt werden, zu den Zeitpunkten Z 11 : T 1 --> von t 1,1,1 Z 14 : T 4 --> von 1,2 Z 16 : T 6 --> von S 2 a) Wie sehen die Sperrprotokolle und Wartebeziehungen bei Partitionssperren jeweils aus, wenn die Sperreinheit ein Tupel, eine elation, ein Segment bzw. die Datenbank ist? b) Wie sehen die Sperrprotokolle und Wartebeziehungen bei hierarchischem Sperrmodus mit einer allgemeinen Anwartschaftssperre () aus? c) Wie viele Sperranforderungen sind nötig? d) Wie oft muss dabei eine Transaktion deaktiviert und in eine Warteschlange gebracht werden? e) Nach wie vielen Zeiteinheiten sind alle Transaktionen bearbeitet? f) Wie hoch ist die durchschnittliche? g) Es seien zwei Arten von speziellen Anwartschaftssperren und vorhanden. Wie ändern sich die Sperrprotokolle? h) Berechnen Sie jeweils die Anzahl der Sperranforderungen und der Deaktivierungen, die insgesamt verbrauchten Zeiteinheiten sowie die durchschnittlichen einheiten. Seite 2

2 Lösung: a) Sperrprotokolle und Wartebeziehungen: Sperreinheit ist das Tupel. T 1 : (t 1,1,1 ) : (t 1,1,2 ) T 3 fordert (t 1,1,1 ) und muss warten wg. T 1 T 4 : (t 1,2,1 ), (t 1,2,2 ),..., (t 1,2,n(1,2) ) T 5 fordert (t 1,1,1 ) und muss warten wg. T 1 T 6 : (t 2,1,1 ), (t 2,1,2 ),..., (t 2,1,n(2,1) ),(t 2,2,1 ), (t 2,2,2 ),..., (t 2,2,n(2,2) ),..., (t 2,m(2),1 ), (t 2,m(2),2 ),..., (t 2,m(2),n(2,m(2)) ) T 7 fordert (t 1,1,1 ) und muss warten wg. T 1 Warteschlange vor t 1,1,1 : (T 3 ), (T 5 ), (T 7 ) Nach Freigabe der -Sperre von T 1 auf t 1,1,1 : T 3 : (t 1,1,1 ), (t 1,1,2 ),..., (t 1,1,n(1,1) ) T 5 : (t 1,1,1 ), (t 1,1,2 ),..., (t 1,1,n(1,1) ), fordert (t 1,2,1 ) und muss warten wg. T 4 T 7 : (t 1,1,1 ), (t 1,1,2 ),..., (t 1,1,n(1,1) ), fordert (t 1,2,1 ) und muss warten wg. T 4 Warteschlange vor t 1,2,1 : (T 5 ), (T 7 ) Nach Freigabe der -Sperre von T 4 auf 1,2 : T 5 : (t 1,2,1 ), (t 1,2,2 ),..., (t 1,2,n(1,2) ),..., (t 1,m(1),1 ), (t 1,m(1),2 ),..., (t 1,m(1),n(1,m(1) ) T 7 : (t 1,2,1 ), (t 1,2,2 ),..., (t 1,2,n(1,2) ),..., (t 1,m(1),1 ), (t 1,m(1),2 ),..., (t 1,m(1),n(1,m(1) ), fordert (t 2,1,1 ) und muss warten wg. T 6 Warteschlange vor t 2,1,1 : (T 7 ) Nach Freigabe der -Sperre von T 6 auf S 2 : T 7 : (t 2,1,1 ), (t 2,1,2 ),..., (t 2,1,n(2,1) ), (t 2,2,1 ),..., (t k,m(k),n(k,m) ) Sperreinheit ist die elation. T 1 : ( 1,1 ) fordert ( 1,1 ) und muss warten wg. T 1 T 3 fordert ( 1,1 ) und muss warten wg. T 1 T 4 : ( 1,2 ) T 5 fordert ( 1,1 ) und muss warten wg. T 1 T 6 : ( 2,1 ), ( 2,2 ),..., ( 2,m(2) ) T 7 fordert ( 1,1 ) und muss warten wg. T 1 Warteschlange vor 1,1 : ( ), (T 3 ), (T 5 ), (T 7 ) Nach Freigabe der -Sperre von T 1 auf 1,1 : : ( 1,1 ) T 3 : ( 1,1 ) T 5 : ( 1,1 ), fordert ( 1,2 ) und muss warten wg. T 4 T 7 : ( 1,1 ), fordert ( 1,2 ) und muss warten wg. T 4 Warteschlange vor 1,2 :(T 5 ), (T 7 ) Seite 3 Nach Freigabe der -Sperre von T 4 auf 1,2 : T 5 : ( 1,2 ),..., ( 1,m(1) ) T 7 : ( 1,2 ),..., ( 1,m(1) ), fordert ( 2,1 ) und wartet wg. T 6 Warteschlange vor 2,1 :(T 7 ) Nach Freigabe der -Sperre von T 6 auf S 2 : T 7 : ( 2,1 ), ( 2,2 ),..., ( 2,m(2) ),..., ( k,m(k) ) Sperreinheit ist das Segment. T 1 : (S 1 ) fordert (S 1 ) und wartet wg. T 1 T 3 fordert (S 1 ) und wartet wg. T 1 T 4 fordert (S 1 ) und wartet wg. T 1 T 5 fordert (S 1 ) und wartet wg. T 1 T 6 : (S 2 ) T 7 fordert (S 1 ) und wartet wg. T 1 Warteschlange vor S 1 :( ), (T 3 ), (T 4 ), (T 5 ), (T 7 ) Nach Freigabe der -Sperre von T 1 auf S 1 : : (S 1 ) T 3 : (S 1 ) T 4 fordert (S 1 ) und wartet wg., T 3 T 5 : (S 1 ) T 7 : (S 1 ), fordert (S 2 ) und wartet wg. T 6 Nach Freigabe der -Sperre von T 6 auf S 2 : T 7 : (S 2 ), (S 3 ),..., (S k ) Nach Freigabe der -Sperren von, T 3, T 5 und T 7 : T 4 : (S 1 ) 4. Sperreinheit ist die Datenbank. T 1 : (DB) Warteschlange für DB:( ), (T 3 ), (T 4 ), (T 5 ), (T 6 ), (T 7 ) Nach Z 11 (Gewährung aller möglichen Sperren): : (DB) T 3 : (DB) T 5 : (DB) T 7 : (DB) Warteschlange für DB:(T 4 ), (T 6 ) Danach Abarbeitung von zunächst T 4, dann T 6. Sollten davor neue Lesetransaktionen starten (was sehr wahrscheinlich ist), passiert es schnell, dass T 4 und T 6 aushungern. Seite 4

3 b) Wie sehen die Sperrprotokolle und Wartebeziehungen bei hierarchischem Sperrmodus mit einer allgemeinen Anwartschaftssperre () aus? c) Wie viele Sperranforderungen sind nötig? d) Wie oft muss dabei eine Transaktion deaktiviert und in eine Warteschlange gebracht werden? e) Nach wie vielen Zeiteinheiten sind alle Transaktionen bearbeitet? f) Wie hoch ist die durchschnittliche? b) + c) + d) + e) + f): Hierarchische Sperrprotokolle bei allgemeiner Anwartschaftssperre Folgende Sperren werden gewährt: T 1 gewährte Sperren T 1 T 1 T 1 T 3 1,1 T 4 T 3 T 4 T 5 T 6 Zum Zeitpunkt Z 16 keine weitere Gewährung von Sperren aus den Warteschlangen möglich. Es ergibt sich folgende Situation: S 1 t 1,1,1 t 1,1,2 T 3 T 4 T 5 DB 1,2 T 6 T 7 S 2 Warteschlange Transaktion Zeiteinheiten en Bemerkung T 1 Z 1 - Z 11 1 Z 2 - Z 22 2 T 3 Z 3 - Z läuft erst nach Ende T 4 Z 4 - Z 14 1 T 5 Z 5 - Z läuft erst nach Ende T 3 T 6 Z 6 - Z 16 1 T 7 Z 7 - Z läuft erst nach Ende T 5 Gesamtdauer: 82 Zeiteinheiten Durchschnittliche : W = = = 15,9 7 7 g) Es seien zwei Arten von speziellen Anwartschaftssperren und vorhanden. Wie ändern sich die Sperrprotokolle? h) Berechnen Sie jeweils die Anzahl der Sperranforderungen und der Deaktivierungen, die insgesamt verbrauchten Zeiteinheiten sowie die durchschnittlichen einheiten. g) + h): Hierarchische Sperrprotokolle mit speziellen Anwartschaftssperren T5 T6 S 1 T5 DB T6 T7 S 2 T 3 T 5 DB T 7 1,1 1,2 T 3 1,1 Anzahl der Sperranforderungen: nsgesamt 19 Sperren angefordert Anzahl der Deaktivierungen: nsgesamt 3 Transaktionen in Wartestellung T 3 S 1 t 1,1,2 T 5 Zum Zeitpunkt Z 16 ergibt sich folgende Situation: t 1,1,1 t 1,1,2 T5 T5 1,1 T7 S 1 t 1,1,2 DB Anzahl der Sperranforderungen: nsgesamt 19 Sperren angefordert Anzahl der Deaktivierungen : nsgesamt 3 Transaktionen in Wartestellung Seite 5 Seite 6

4 Transaktion Zeiteinheiten en Bemerkung T 1 Z 1 - Z 11 1 Z 2 - Z 22 2 T 3 Z 3 - Z läuft erst nach Ende T 1 T 4 Z 4 - Z 14 1 T 5 Z 5 - Z läuft erst nach Ende T 4 T 6 Z 6 - Z 16 1 T 7 Z 7 - Z läuft erst nach Ende T 6 Gesamtdauer: 36 Zeiteinheiten Durchschnittliche : W = = = 7 7 3, 7 Aufgabe 3: Vergleich verschiedener Synchronisationsverfahren Gegeben ist der Ablaufplan von vier Transaktionen -: w(y) r(x) a) st der Ablaufplan serialisierbar? Welche seriellen Historien ergeben sich? b) Geben Sie die Serialisierungsreihenfolge an, wenn zur Synchonisation verwendet wird: (1) (2) U (symmetrisch) (3) U (unsymmetrisch) (4) A (5) AC (6) BOCC (7) BOCC+ (mit Zeitstempeloptimierung) (8) FOCC Gehen Sie von starkem 2-Phasen-Locking aus (Halten aller Sperren bis zum EOT, dann atomares Freigeben). Hinweis: Die vom obigen Ablaufplan vorgegebenen Zeitabstände zwischen den einzelnen Operationen innerhalb der individuellen Transaktionen sollen auch im Falle von Blockierungen durch Sperranforderungen beibehalten werden. Sie sind dann als Zeit zwischen der tatsächlichen Ausführung der ersten Operation (d.h. nach der Gewährung einer Sperre) und der (versuchten) Ausführung der zweiten Operation zu verstehen. Seite 7 Seite 8

5 Lösung: a) st der Ablaufplan serialisierbar? Welche seriellen Historien ergeben sich? w(y) r(x) Einzeichnen der Konfliktoperationen ergibt folgenden Serialisierbarkeitsgraphen: Der resultierende Serialisierbarkeitsgraph ist azyklisch, der Ablaufplan daher serialisierbar. Mögliche serielle Ablaufpläne sind: b) Geben Sie die Serialisierungsreihenfolge an, wenn zur Synchronisation folgende Verfahren verwendet werden: SG: (1) (x) (z) (y) (y) w(y) (x) r(x) (z) SG: (y) t=4: schreibt x und erhält dafür die nötige -Sperre. t=5: liest y und erhält -Sperre. t=6: liest ebenfalls y und erhält ebenfalls eine -Sperre ( ist mit verträglich) t=8: versucht y zu schreiben. Die dazu erforderliche Sperrkonversion von der - zur -Sperre führt zur Blockierung, da eine -Sperre hält. t=9: liest z und erhält -Sperre. t=1: versucht z zu ändern, die dazu nötige -Sperre kann zunächst nicht gewährt, werden da parallel z liest, muss warten. t=13: EOT von, Freigabe der -Sperre auf z, folglich kann deblockiert werden und erhält die -Sperre. t=17: EOT von, Freigabe der -Sperren auf x und z. t=18: EOT von, Freigabe der -Sperre auf y, kann deblockiert werden und erhält die - Sperre auf y. t=21: liest x und erhält dafür eine -Sperre. t=: EOT von, Freigabe aller Sperren. m Beispielszenario wird ein Problem des -Verfahrens nicht deutlich, der Konversions-Deadlock. Diese würde auftreten, wenn z.b. zum Zeitpunkt t=15 eine Sperrkonversion des (y) auf (y) probieren würde. n diesem Fall würde auf die Freigabe des von warten und umgekehrt Gesamt AVG 3, Seite 9 Seite 1

6 t=4: t=5: t=6: t=8: t=9: t=1: t=13: (2) U (symmetrisch) (x) (z) U(y) U->(y) w(y) (x) r(x) (z) SG: (y) schreibt x und erhält dafür die nötige -Sperre. liest y mit Änderungsabsicht und erhält eine U-Sperre. liest ebenfalls y und erhält eine -Sperre ( ist beim symmetrischen U mit verträglich) versucht y zu schreiben. Die dazu erforderliche Sperrkonversion von der U- zur -Sperre führt zur Blockierung, da eine -Sperre hält. liest z und erhält -Sperre. versucht z zu ändern, die dazu nötige -Sperre kann zunächst nicht gewährt, werden da parallel z liest, muss warten. EOT von, Freigabe der -Sperre auf z, folglich kann deblockiert werden und erhält die -Sperre. t=17: EOT von, Freigabe der -Sperren auf x und z. t=18: EOT von, Freigabe der -Sperre auf y, kann deblockiert werden und erhält die - Sperre auf y. t=21: liest x und erhält dafür eine -Sperre. t=: EOT von, Freigabe aller Sperren. Der resultierende Ablaufplan ist für dieses Beispiel identisch zu dem von. Der bei der Erläuterung von geschilderte Fall des Konversions-Deadlocks kann bei U nicht eintreten. Hier hätte zum Zeitpunkt t=6 eine U-Sperre angefordert, und wäre daraufhin blockiert worden (U mit gesetztem U unverträglich). m symmetrischen U-Verfahren könnten während der von auf das Ende beliebige neue Leser hinzukommen ( ist mit gesetztem U verträglich) und so die Bearbeitung von unbegrenzt verzögern (Starvation). t=4: t=5: t=6: t=8: t=9: t=1: t=11: t=13: t=17: t=21: t=33: (3) U (unsymmetrisch) (x) (z) U(y) U->(y) (x) w(y) r(x) (z) (y) schreibt x und erhält die -Sperre. liest y mit Änderungsabsicht und erhält U-Sperre. versucht, y zu lesen. ist jetzt jedoch unverträglich mit gesetztem U, daher muss warten. schreibt y, die dazu erforderliche Sperrkonversion von der U- zur -Sperre ist nun möglich, da kein paralleler Leser eine -Sperre hält (es könnten jedoch noch Lesesperren von älteren Lesern gesetzt sein, die ihr vor dem U von angefordert haben). liest z und erhält -Sperre. versucht z zu ändern, die dazu nötige -Sperre kann zunächst nicht gewährt, werden da parallel z liest, muss warten. versucht x zu lesen, allerdings ist x noch von mit gesperrt, muss warten. EOT von, Freigabe der -Sperre auf z, folglich kann deblockiert werden und erhält die -Sperre. EOT von, Freigabe der -Sperren auf x und z. kann deblockiert werden und erhält (x). EOT von, Freigabe von (y) und (x), kann deblockiert werden und erhält (y). EOT von, Freigabe von (y). Die Gesamtdauer des Ablaufplans und die durchschnittliche der Transaktionen verschlechtern sich im gezeigten Szenario, allerdings wird das Aushungern von Schreibern durch neu hinzukommende Leser verhindert und so die "Fairness" verbessert. SG: Gesamt 33 AVG 6 Seite 11 Seite 12

7 (4) A A(x) -> x 2 A(z) -> z 2 A(x) -> (x) warten A(z) -> (z) OK SG: A(y) -> y 2 (x) -> x 1! w(y) A(y) -> (y) warten r(x) (z) -> z 1 (y) ->y 1! Alle Transaktionen fordern nun vor dem Schreiben (bzw. vor dem Lesen mit Änderungsabsicht) eine A-Sperre an und erhalten (wenn die Sperre gewährt wird) eine neue Version des Objekts, auf der sie arbeiten können. Während der Bearbeitung dieser Kopie sehen neue Leser die alte Version. t=4: ändert x und erhält so eine neue Version x 2. t=5: liest y mit Änderungsabsicht und erhält ebenfalls eine private Version. t=6: liest y und erhält die alte Version y 1. t=8: ändert ihre private Version. t=9: liest z und sieht die (zu diesem Zeitpunkt einzige) Version z 1. t=1: ändert z und erstellt somit eine neue Version z 2. t=11: liest x und sieht die alte Version x 1, da die Änderung von noch nicht freigegeben wurde. t=13: EOT von, Freigabe der -Sperre auf z. t=14: EOT von, Konversion aller A-Sperren nach zum Einbringen der geänderten Version. Konversion von A(z) nach (z) gelingt (da keine Leser die alte Version z 1 noch benötigen). Konversion von A(x) nach (x) blockiert, da der "alte" Leser noch auf der alten Version x 1 arbeitet. t=15: EOT von, Konversion von A(y) nach (y) blockiert, da der alte Leser noch auf der alten Version y 1 arbeitet. 3 Die resultierende Schedule hat eine kürzere Gesamtdauer und eine geringerer durchschnittliche als und die beiden Varianten von U. Allerdings ist A nicht chronologieerhaltend, da hier im äquivalenten seriellen Ablaufplan vor ausgeführt würde Gesamt 18 AVG 1,75 t=18: EOT von gibt Lesesperre auf y frei. kann seine geänderte Version y 2 freigeben, y 1 wird nicht mehr benötigt und kann verworfen werden. gibt bei seinem erfolgreichen EOT die Lesesperre auf x frei, daraufhin kann seine geänderte Version x 2 einbringen und abgeschlossen werden. Seite 13 Seite 14

8 (5) AC A(x) -> x 2 A(z) -> z 2 A(x) -> C(x) OK A(z) -> C(z) OK A(y) -> y 2 (x) -> x 1! w(y) A(y) -> C(y) OK r(x) (y) ->y 1! t=4 bis t=13: wie A t=14: EOT von, Konversion der A-Sperren nach C-Sperren für jedes geänderte Objekt. Keine Konflikte bei der Konversion von A(x) nach C(x), da die alte Version x 1 für noch bereitgehalten wird. Nach erfolgtem Einbringen der geänderten Versionen von x und z erfolgt eine Freigabe der C-Sperren sobald alle alten Leser fertig sind (im Falle von z also unmittelbar, für x nach dem Ende von ). t=15: EOT von, Konversion von A(y) nach C(y) erfolgreich, y 1 wird noch für bereitgehalten. Freigabe des C(x), das von hinterlassen wurde. Beibehalten des C(y) bis zum Ende von. t=18: EOT von. Freigabe von (y) und damit auch des C(y) von. m Vergleich zu A werden Schreiber bei ihrem Commit nicht blockiert, da bei AC zwei gültige Versionen gleichzeitig zum Lesen bereitgehalten werden können (erkennbar an gesetztem C). Die alte Version wird für alle Leser bereitgehalten, die vor dem EOT des Schreibers eine Lesesperre angefordert haben, die neue Version ist für alle neuen Leser sichtbar. Wenn die letzten "alten" Leser fertig sind, kann C entfernt werden. Erst jetzt kann ein neuer Schreiber eine neue Version mit A anlegen. Der resultierende Schedule sieht auf den ersten Blick aus wie der in der Aufgabenstellung vorgegebene. Allerdings ist hier wie auch bei A durch die Versionierung die eihenfolge von und in den äquivalenten seriellen Abläufen invertiert. (z) -> z Gesamt 18 AVG SG: 3 (6) BOCC Bei BOCC validiert jede TA bei EOT gegen alle Schreiber, die während ihrer Laufzeit erfolgreich validiert (und somit ihre Änderungen festgeschrieben) haben. Dabei wird die Schnittmenge der von der validierenden Transaktion gelesenen Objekte (ihr eadset) mit der Menge aller von den erfolgreich validierten TAs geschriebenen Objekte (Vereinigung der Writesets) verglichen. Wenn diese Schnittmenge nicht leer ist, wird dies als Konflikt erkannt und die Transaktion zurückgesetzt. Andernfalls werden die Änderungen der Transaktion, die zuvor in einem privaten Puffer durchgeführt wurden, in die Datenbank eingebracht (Schreibphase). Validierung : keine vorher validierenden Schreiber, kein Konflikt Validierung : S 2 = {x,y}, WS = WS 1 = {x} S 2 WS 1 = { x} => Konflikt, verwerfen der Änderungen und Wiederanlauf Validierung : keine vorher validierenden Schreiber, kein Konflikt Validierung : Schreiber von y validiert nicht erfolgreich, daher kein Konflikt 2. Validierung von : kein parallel validierender Schreiber auf x oder y, kein Konflikt. w(y) r(x) (14) Gesamt 28 AVG 3,5 vnok! w(y) r(x) vok Neustart 3 Seite 15 Seite 16

9 (7) BOCC+ (mit Zeitstempeloptimierung) [2] x,z ->[2] OK x[2] = x[2] NOK! x[] < x[2] y -> [4] [] w(y) r(x)[] v [] w(y) r(x)[2] v [] [] Neustart [1] [3] BOCC+ verzichtet auf das führen von Writesets. Stattdessen verteilt es aufsteigende Zeitstempel für erfolgreich validierende TA. Alle von der TA geschriebenen Objekte werden mit diesem Zeitstempel versehen. Beim Lesen eines Objekts wird dessen Zeitstempel im eadset der lesenden TA vermerkt. Bei Validierung wird für jedes gelesene Objekt überprüft, ob der zum Validierungszeitpunkt aktuelle Zeitstempel gleich dem Zeitstempel zum Lesezeitpunkt ist. st der Lesezeitstempel kleiner, hat zwischenzeitlich eine andere TA das Objekt geändert und erfolgreich validiert, die Transaktion muss abgebrochen und ggf. wiederholt werden. Validierung : keine Leseoperationen, kein Konflikt Validierung : liest y mit Zeitstempel und vermerkt dies in seinem eadset. Vor der Validierung von validiert und erhöht dabei den Zeitstempel von y auf 1. Bei der Validierung von wird erkannt, dass der nun aktuelle Zustand von y jünger als der von gelesene ist, es erfolgt ein Wiederanlauf. Validierung : Zeitstempel von z zum Lese- und Validierungszeitpunkt sind identisch, kein Konflikt. z wurde zwar bereits von geändert (in dessen privatem Puffer), aber noch nicht eingebracht. Validierung : Zeitstempel von y zum Lese- und Validierungszeitpunkt sind identisch (da nicht erfolgreich validiert hat und daher auch der Zeitstempel von y nicht erhöht wurde), kein Konflikt. 2. Validierung : Zeitstempel von z zum Lese- und Validierungszeitpunkt sind identisch, kein Konflikt Gesamtdauer und en wie BOCC. BOCC+ bringt einen Vorteil gegenüber BOCC, wenn eine Transaktion ein Objekt einer während ihrer Laufzeit validierenden Schreib-TA liest, nachdem die Schreib-TA validiert hat. Hier würde das ungenauere BOCC einen Konflikt erkennen, obwohl das korrekte Objekt gelesen wurde. (8) FOCC FOCC vergleicht das Writeset einer validieren TA mit den eadsets aller zum Validierungszeitpunkt aktiven TAs. st die Schnittmenge nicht leer, wurde ein Konflikt erkannt. m Gegensatz zu BOCC kann hier die zurückzusetzende TA frei gewählt werden. Dadurch kann der Verlust an bereits getaner Arbeit minimiert oder bereits einmal wegen eines Konflikts wiederholte TAs können bevorzugt werden. m obigen Beispiel wird von einem naiven TA-Manager grundsätzlich die validierende TA zurückgesetzt, was in der Praxis nicht die optimale Strategie wäre. Validierung : WS 1 = {x,z}, S 2 = {x,y}, S 4 = {y}, S 2 S 4 = S = { x, y} WS 1 S = { x} => Konflikt, Neustart von Validierung : WS 2 = {y}, S 1 = {}, S 4 = {y}, S 1 S 4 = S = { y}, WS 2 S = { y} => Konflikt, Neustart von Validierung : leeres Writeset, kein Konflikt Validierung : leeres Writeset, kein Konflikt 2. Validierung : WS 1 = {x,z}, S 2 = S = {x,y}, WS 1 S = { x} => Konflikt, 2. Neustart von! 2. Validierung : WS 2 = {y}, S 1 = S = {}, WS 2 S = => kein Konflikt 3. Validierung : keine parallelen TA, kein Konflikt w(y) r(x) 42 (28) 28 (14) Gesamt 42 AVG 1,5 NOK! v NOK! v w(y) r(x) Neustart 3 NOK v Seite 17 Seite 18

10 FOCC mit einem "intelligenteren" Transaktionsmanager: w(y) r(x) NOK! => KLL v Validierung : WS 1 = {x,z}, S 2 = {x,y}, S 4 = {y}, S 2 S 4 = S = { x, y} WS 1 S = { x} => Konflikt, Abbruch und Neustart der "anderen" TA Validierung : leeres Writeset, kein Konflikt Validierung : leeres Writeset, kein Konflikt Validierung : keine parallelen TA zum Validierungszeitpunkt, kein Konflikt ABOT! w(y) r(x) vok Neustart (14) Gesamt 28 AVG 3,5 Seite 19