Konfliktgraph. Satz und Definition

Transkript

1 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 1 Konfliktgraph Der Konfliktgraph von S ist ein gerichteter Graph KG(S) = (V, E), wobei V die Menge aller Transaktionen in S und E die Menge der Kanten gemäß den folgenden Bedingungen (i j): S =... Wi A... R j A... T i T j E, sofern zwischen W i A und R j A in S keine weitere Schreiboperation zu A existiert. (WR-Konflikt) S =... Wi A... W j A... T i T j E, sofern zwischen W i A und W j A in S keine weitere Schreiboperation zu A existiert. (WW-Konflikt) S =... Ri A... W j A... T i T j E, sofern zwischen R i A und W j A in S keine weitere Schreiboperation zu A existiert. (RW-Konflikt) Satz und Definition Ein Schedule S ist serialisierbar, wenn KG(S) zyklenfrei ist. Ein Schedule S heißt konfliktserialisierbar genau dann, wenn KG(S) zyklenfrei ist. SR ist die Menge der serialisierbaren Schedule, CSR die Menge der konflikt-serialisierbaren.

2 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 2 Beispiel 1: S 1 CSR und S 2 CSR. Schedule S 1 : R 1 A W 1 A R 3 A R 1 B W 1 B R 2 A W 2 A W 3 B R 2 B W 2 B Schedule S 2 : R 3 A R 1 A W 1 A R 1 B W 1 B R 2 A W 2 A R 2 B W 2 B W 3 B T 2 T 2 T 0 T 1 T T 0 T 1 T T 3 T 3 Beispiel 2: S 1 SR, S 1 CSR, S 1 S 2. Schedule S 1 : Schedule S 2 : R 3 Z W 3 Y R 1 X R 2 Y W 1 Y W 2 Y R 1 X W 1 Y R 3 Z W 3 Y R 2 Y W 2 Y Im Folgenden betrachten wir nur noch Konflikt-Serialisierbarkeit und verwenden hierfür als Synonym den Begriff Serialisierbarkeit!

3 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite Sperrverfahren Bevor eine Transaktion lesend oder schreibend zu einem Objekt zugreifen darf, muss ihr ein entsprechendes Privileg gewährt werden. Sperroperation (Lock): Leseprivileg L R A Lese- und Schreibprivileg LA Freigabeoperation (Unlock): UA, bzw. U R A. Sperrtabelle Kompatibilitätsmatrix: Pri- angefordertes vileg zu A: Livelock und Deadlock können auftreten. gehaltenes Privileg zu A: L R A LA L R A J N LA N N

4 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 4 Vermeidung von Livelocks und Deadlocks Vermeidung von Livelocks: first-come-first-served-strategie Vermeidung von Deadlocks: Jede Transaktion bewirbt sich zu Beginn um alle benötigten Privilegien auf einmal (in einer atomaren Operation). Auf den Objekten wird eine lineare Ordnung definiert. Die Transaktionen fordern ihre jeweiligen Privilegien gemäß dieser Ordnung an. Wartegraph: Ein Wartegraph hat eine Kante T i T j, wenn T i sich um ein Privileg bewirbt, das T j besitzt und das, aufgrund der Kompatibilitätsmatrix, nicht zugeteilt werden kann. Ein Deadlock liegt nun genau dann vor, wenn der Wartegraph einen Zyklus hat. Wie kann ein Deadlock aufgelöst werden? Nur indem eine beteiligte Transaktion abgebrochen wird.

5 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 5 2-Phasen Sperren 2PL Hat eine Transaktion eine Freigabeoperation ausgeführt, dann darf sie keine Sperroperation mehr ausführen. mögliche Lock- und Unlock-Operationen gemäß 2PL der Transaktion RA WA RB WB RC WC S 1 : LA RA WA LB RB WB LC RC WC UA UB UC, S 2 : LA RA WA LB LC UA RB WB UB RC WC UC, S 3 : LA LB LC RA WA UA RB WB UB RC WC UC, S 4 : LA LB LC RA WA RB WB RC WC UA UB UC. 2PL ist strikt, wenn alle Freigabeoperationen am Transaktionsende ausgeführt werden.

6 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 6 Beispiel T 1 = L 1A R 1A L 1B U 1A W 1B U 1B, T 2 = L 2A R 2A W 2A U 2A, T 3 = L 3C R 3C U 3C. S = L 1A R 1A L 1B U 1A L 2A R 2A L 3C R 3C U 3C W 1B U 1B W 2A U 2A Die Position der ersten Unlock-Operation einer Transaktion T i in einem Schedule S ist der Sperrpunkt von T i in S. Das 2-Phasen Sperrprotokoll garantiert serialisierbare Schedule. Beweis: Sei S ein Schedule einer Menge T = {T 1,..., T n}, wobei jede Transaktion die Bedingung des 2PL-Protokolls erfüllt. Vereinfachend nehmen wir an, dass alle Transaktionen Schreibsperren erwerben.

7 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 7 Das 2-Phasen Sperrprotokoll garantiert serialisierbare Schedule (fortgesetzt). Angenommen, S ist nicht serialisierbar ist, d.h. der Konfliktgraph KG(S) enthält einen Zyklus, ohne Beschränkung der Allgemeinheit der Form T 1 T 2 T k T 1. Eine Kante T T eines solchen Zyklus setzt voraus, dass T und T zu einem gemeinsamen Objekt A jeweils eine Operation ausführen, von denen mindestens eine schreibend ist. Da die Operation zu A in T und T jeweils durch eine Sperr- und Freigabeoperation umfasst ist, kann T seine Operation zu A erst nach der Freigabeoperation von T zu A ausführen. Betrachten wir alle Kanten des Zyklus, dann müssen Objekte A 1,..., A k existieren, so dass für die Struktur von S gilt: S =... U 1 A 1... L 2 A 1...,. S =... U k 1 A k 1... L k A k 1..., S =... U k A k... L 1 A k.... Sei l i der Sperrpunkt von T i, 1 i k. Dann impliziert S, dass l 1 vor l 2,..., l k 1 vor l k und l k vor l 1. Aufgrund der Definition eines Sperrpunktes ist dies jedoch ein Widerspruch zu der Struktur von S. Damit ist gezeigt, dass 2PL serialisierbare Schedule garantiert.

8 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 8 Optimalität und Mächtigkeit von 2PL 2PL ist ein optimales Sperrverfahren in dem Sinn, dass zu jeder nicht 2-phasigen Transaktion T 1 eine 2-phasige Transaktion T 2 konstruiert werden kann, so dass zu T 1 und T 2 ein nicht serialisierbarer Schedule existiert. Es existieren konfliktserialisierbare Schedule, die bei Einhaltung von 2PL nicht entstehen können. Sei L 1 A U 1 A L 1 B U 1 B die nicht 2-phasige Folge von Sperr- und Freigabeoperationen einer Transaktion T 1 und L 2 A L 2 B U 2 A U 2 B eine 2-phasige Folge von Sperr-und Freigabeoperationen von T 2. Dann ist der folgende, durch seine Sperr- und Freigabeoperationen definierte nicht serialisierbare Schedule möglich: S = L 1 A U 1 A L 2 A L 2 B U 2 A U 2 B L 1 B U 1 B S = R 1 A R 2 A W 2 A R 3 B W 3 B W 1 B ist konfliktserialisierbar, jedoch nicht bei Anwendung von 2PL entstehbar.

9 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite Verfahren mit und ohne Sperren Sperrverfahren sind nicht die einzige Technik zur Gewährleistung serialisierbarer Schedule. Eine Mehrbenutzerkontrolle wird formal durch eine Abbildung Φ beschrieben, die eine von den Transaktionen angeforderte (Eingabe-) Folge von Operationen S I in eine serialisierbare auszuführende (Ausgabe-) Folge von Operationen S O der Transaktionen transformiert. Es gilt Φ(S I ) = S O, wobei S I ein Präfix eines Schedules und S O ein Schedule.

10 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 10 Protokoll einer auf einem Sperrverfahren basierenden Mehrbenutzerkontrolle Φ 2P L. Für die Transaktionen gilt T 1 = L 1 A R 1 A L 1 B U 1 A W 1 B U 1 B, T 2 = L 2 A R 2 A W 2 A U 2 A, und T 3 = L R 3 C R 3C U R 3 C. angeforderte Folge Sperrtabelle ausgef uhrte Folge L 1A L 1A L 1A R 1A L 1A R 1A L 1A R 1A L 2A L 1A R 1A L 1A R 1A L 2A L R 3 C L1A, LR 3 C R1A L 1A R 1A L 2A L R 3 C R3C L1A, LR 3 C R1A R3C L 1A R 1A L 2A L R 3 C R3C L1B L1A, LR 3 C, L1B R1A R3C L 1A R 1A L 2A L R 3 C R3C L1B U1A LR 3 C, L1B R1A R3C L 1A R 1A L 2A L R 3 C R3C L1B U1A R2A LR 3 C, L1B, L2A R1A R3C R2A L 1A R 1A L 2A L R 3 C R3C L1B U1A R2A W2A LR 3 C, L1B, L2A R1A R3C R2A W2A L 1A R 1A L 2A L R 3 C R3C L1B U1A R2A W2A U2A LR 3 C, L1B R1A R3C R2A W2A

11 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 11 Scheduler ohne Sperren Angeforderte Aktionen kommen zur Ausführung, sofern der Scheduler sicher ist, dass kein nicht serialisierbarer Schedule in der Entstehung ist. Anderenfalls wird eine aktive Transaktion abgebrochen. Dies kann den Abbruch anderer, abhängiger Transaktionen erfordern.

12 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 12 Aktive und abhängige Transaktionen Eine Transaktion T ist von einer Transaktion T abhängig, wenn ein gerichteter Weg T... T im Konfliktgraphen des zugehörigen Schedules existiert, der durch eine Folge von WR-Konflikten begründet ist. Eine Transaktion T heißt aktiv in einem Schedule S, wenn eine Operation von T in S enthalten ist und T noch nicht ihr Ende erreicht hat. Eine Transaktion signalisiert ihr Ende, indem sie als letztes die Operation Commit ausführt.

13 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 13 Überwachen des Konfliktgraphen Φ KG Sei S die aktuelle Folge der ausgeführten Operationen und sei op die nächste angeforderte Operation einer Transaktion T. Falls KG(S op) zyklenfrei, dann führe op aus. Anderenfalls breche T und alle von T abhängigen Transaktionen ab und streiche die entsprechenden Operationen dieser Transaktionen in S.

14 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 14 Vergabe von Zeitmarken Φ ZM Jeder Transaktion T wird bei ihrem Beginn eine eindeutige Zeitmarke Z(T ) zugewiesen. Sei S die aktuelle Folge der ausgeführten Operationen und sei op die nächste angeforderte Operation einer Transaktion T. Falls für alle Transaktionen T, die bereits eine zu op in Konflikt stehende Operation in S ausgeführt haben, gerade Z(T ) Z(T ), dann führe op aus. Anderenfalls breche T und alle von T abhängigen Transaktionen ab und streiche die entsprechenden Operationen dieser Transaktionen in S.

15 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 15 Optimistisches Verfahren Φ OP Sei S die aktuelle Folge der ausgeführten Operationen und sei op die nächste angeforderte Operation einer Transaktion T. Sei des Weiteren Readset(T ) und Writeset(T ) die Menge der von einer Transaktion T bereits gelesenen, bzw. geschriebenen Objekte. Ist op verschieden von Commit, dann führe op aus. Ist op die Commit-Operation C, d.h. die letzte Operation von T, dann breche T und alle von T abhängigen Transaktionen ab, sofern bzgl. einer anderen aktiven Transaktion T eine der folgenden Bedingungen gilt: Readset(T ) Writeset(T ), Writeset(T ) Writeset(T ), Writeset(T ) Readset(T ). Streiche desweiteren alle Operationen der abgebrochenen Transaktionen in S.

16 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 16 Beispiel S I = R 1 A R 2 A W 2 A C 2 R 3 B W 3 B C 3 W 1 B C 1. T 1 = R 1 A W 1 B C 1, T 2 = R 2 A W 2 A C 2, T 3 = R 3 B W 3 B C 3. S I Φ KG S O S I Φ ZM R 2 A W 2 A C 2 R 3 B W 3 B C 3 Φ OP R 1 A R 3 B W 3 B C 3 W 1 B C 1

17 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite Phantomproblem bisherige implizite Annahme Die Menge der Objekte in der Datenbank ist konstant über der Zeit. Verletzung der Annahme kann zu Phantomen führen.

18 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 18 Schedule mit Phantom Sei eine Transaktion T 1 eine Ausführung eines Programmes P, das zunächst alle Objekte A liest, die eine gewisse Bedingung p erfüllen und anschließend ein weiteres Objekt B. T hat damit eine Historie der Form R 1 A 1... R 1 A k R 1 B. Laufe zeitlich überlappend zu T 1 eine Transaktion T 2 ab, die ein Objekt C liest, ein neues Objekte A k+1 in die Datenbank einfügt, das ebenfalls die Bedingung p erfüllt und anschließend B ändert. Unter diesen Annahmen ist der folgende Schedule möglich: R 2 C R 1 A 1... R 1 A k W 2 A k+1 R 2 B W 2 B R 1 B Dieser Schedule ist formal äquivalent zu T 2 T 1 ; es wird hierbei jedoch ignoriert, dass A k+1 auch die Bedingung p erfüllt und somit T 1 eine Leseoperation R 1 A k+1 enthalten müsste.

19 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 19 Lösung des Phantomproblems Vergrößerung der Granularität der betrachteten Objekte. Anstatt einer Folge von Leseoperationen R 1 A 1... R 1 A k betrachten wir eine einzige Leseoperation, z.b. in der Form R 1 {A p(a)}. Da A k+1 die Eigenschaft p erfüllt, kann der Konflikt mit dem Phantom A k+1 erkannt werden. Sperrverfahren können den Test auf p implementieren, indem ganze Relationen, Schlüsselbereiche oder auch Indexbereiche gesperrt werden.