Kapitel 12: Transaktionen für XML

Transkript

1 Kapitel 12: Transaktionen für XML Transaktionelle Garantien für Zugriff auf XMLDatenbestände. Stoßrichtung insbesondere: XMLDaten, die relational gespeichert sind. Verwendung der Transaktionsmechanismen der. Welche Möglichkeiten gibt es, Transaktionsmanagement effizient zu implementieren. Berücksichtigung der Eigenschaften von XML, XMLspezifische Lösung. Andererseits: Allgemeine Lösung, d. h. keine Beschränkung auf spezielles RDBMS. Einsatz: Transaktionen für 1 Einsatz: Transaktionen für 2 Probleme ohne en Synchronisation in en Transaktionseigenschaften insbesondere und. Beispiel, BankSzenario : Nummer Inhaber Stand Klemens 5000 Erik 200 Überweisung zwei Elementaroperationen. Abbuchung(Klemens, 500), Einzahlung(Erik, 500). auch an diesem Beispiel erklärbar. Transaktionen. Serielle Ausführung von Anwendungsprogrammen. Jene Illusion läßt sich ohne jeglichen Synchronisationsaufwand erreichen. ist nach Ende jeder Programmausführung konsistent. Aber: Extreme Wartezeiten und unbefriedigende Ausnutzung der Ressourcen. (CPU ist während Kommunikation und I/O nicht aktiv.) Einsatz: Transaktionen für 3 Einsatz: Transaktionen für 4

2 Konflikt Serialisierbarkeit Illustration Zwei Operationen p, q konfligieren := p, q greifen auf das gleiche Datenobjekt zu, und p oder q ist eine Schreiboperation. Weitere Operationen Definition von Konflikt muß erweitert werden. Beispiel. Kompatibilitätsmatrix: r 2 [x] w 2 [x] c 2 r 3 [x] w 3 [x] c 3 r 1 [x] w 1 [x] c 1 r 1 [y] w 1 [y] Read Write Increment Decrement Read y n n n Write n n n n Increment n n y y Decrement n n y y Einsatz: Transaktionen für 5 Einsatz: Transaktionen für 6 Serialisierbarkeitsgraph Locking (1) Wie sieht Serialisierbarkeitsgraph aus? Lock für jedes Datenobjekt und für jede Art von Operation Notation: ol i [x] r 2 [x] w 2 [x] c 2 r 3 [x] w 3 [x] c 3 r 1 [x] w 1 [x] c 1 r 1 [y] w 1 [y] Transaktion verschafft sich Lock, Transaktion gibt Lock frei. Locks können konfligieren. T1 T2 A Locks konfligieren in gleicher Weise wie entsprechende Operationen. Locking für sich betrachtet ist nicht ausreichend! Einsatz: Transaktionen für 7 Einsatz: Transaktionen für 8

3 Locking (2) Illustration 2PL Zwei Phasen: Phase, in der Locks hinzugenommen werden, Phase, in der Locks freigegeben werden. ZweiPhasen Sperrprotokoll (twophase locking, 2PL) stellt Serialisierbarkeit sicher. T 1 : r 1 [x] w 1 [y] c 1 ; T 2 : w 2 [x] w 2 [y] c 2 H 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 r 1 [x]<w 2 [x] w 2 [y]<w 1 [y] SG(H 1 ) hat zyklische Abhängigkeit T 1 T 2 T 1 T 1 verletzt twophase Regel. History, die twophase Regel nicht verletzt: H 1 =rl 1 [x] r 1 [x] wl 1 [y] w 1 [y] c 1 ru 1 [x] wu 1 [y] wl 2 [x] w 2 [x] wl 2 [y] w 2 [y] c 2 wu 2 [x] wu 2 [y] Einsatz: Transaktionen für 9 Einsatz: Transaktionen für 10 Beispiel für Deadlock mit 2PL Prädikatsperren Illustration T 1 : r 1 [x] w 1 [y] c 1 ; T 2 : w 2 [y] w 2 [x] c 2 Abfolge: 1. Beide Transaktionen halten zunächst keine Locks. 2. TM sendet r 1 [x] an Scheduler. rl 1 [x], Scheduler sendet r 1 [x] an DM. 3. TM sendet w 2 [y] an Scheduler. wl 2 [y], Scheduler sendet w 2 [y] an DM. 4. TM sendet w 2 [x] an Scheduler. wl 2 [x] nicht möglich. Verzögerung. 5. TM sendet w 1 [y] an Scheduler. wl 1 [y] nicht möglich. Verzögerung. Deadlock. Muß extern zurückgesetzt werden. Beispiel: T 1 : Lese die Summe der Kontostände aller Karlsruher Kunden, die jünger als 20 oder älter als 80 sind. P 1 : ORT = KA (Alter < 20 Alter > 80) T 2 : Erhöhe den Kontostand aller Karlsruher Kunden mit Alter 28 um 10%. P 2 : ORT = KA Alter = 28 Prädikatsperren sind in höheren Schichten der DB (deskriptive Schnittstelle) angesiedelt. Es kommt zu Pseudokonflikten in tieferen Schichten. z Einsatz: Transaktionen für 11 Einsatz: Transaktionen für 12

4 vs. Stable Storage Bestandteile eines Transaktionsmanagers: ging/recovery eine Transaktion, Ausfall eines Knoten (oder mehrerer) möglich. Synchronisation (Concurrency Control) mehrere Transaktionen (aber Ausfälle sind im Kontext von Synchronisation kein Thema). Stable Storage Transaktion besteht aus mehreren Operationen (bzw. ihren Effekten). Transaktion muß nach Ausfall zurückgesetzt werden. Naive Implementierung (Effekt jeder Transaktion sofort in ) stellt im Fehlerfall (Zurücksetzbarkeit unfertiger Transaktion) nicht sicher. Ausfall eines Knotens nur Hauptspeicher. Einsatz: Transaktionen für 13 Einsatz: Transaktionen für 14 Wie wird Commit abgearbeitet? (1) Wie wird Commit abgearbeitet? (1) DBMS arbeitet EOTAufruf durch Benutzer/Anwendung in zwei Phasen ab: Schreibe alle Änderungen in die, schreibe Commit in Datei (Phase 1), Mache Änderungen sichtbar (gebe Sperren frei) und lösche UNDO Information (Phase 2). DBMS arbeitet EOTAufruf durch Benutzer/Anwendung in zwei Phasen ab: Schreibe alle Änderungen in die, schreibe Commit in Datei (Phase 1), Mache Änderungen sichtbar (gebe Sperren frei) und lösche UNDO Information (Phase 2). BOT; w 1 [X, 700] X 500 Y 200 X L Y 200 Obj Undo X 500 Einsatz: Transaktionen für 15 Einsatz: Transaktionen für 16

5 Wie wird Commit abgearbeitet? (1) Wie wird Commit abgearbeitet? (1) DBMS arbeitet EOTAufruf durch Benutzer/Anwendung in zwei Phasen ab: Schreibe alle Änderungen in die, schreibe Commit in Datei (Phase 1), Mache Änderungen sichtbar (gebe Sperren frei) und lösche UNDO Information (Phase 2). BOT; w 1 [X, 700]; w 1 [Y, 100]; DBMS arbeitet EOTAufruf durch Benutzer/Anwendung in zwei Phasen ab: Schreibe alle Änderungen in die, schreibe Commit in Datei (Phase 1), Mache Änderungen sichtbar (gebe Sperren frei) und lösche UNDO Information (Phase 2). BOT; w 1 [X, 700]; w 1 [Y, 100]; COMMIT Ab jetzt Phase 2 Obj Undo X L X 500 Y L Y 200 Einsatz: Transaktionen für 17 X Y 100 Obj Undo X 500 Y 200 T 1 COMMIT Einsatz: Transaktionen für 18 Wie wird Commit abgearbeitet? (1) Undo Redo (1) DBMS arbeitet EOTAufruf durch Benutzer/Anwendung in zwei Phasen ab: Schreibe alle Änderungen in die, schreibe Commit in Datei (Phase 1), Mache Änderungen sichtbar (gebe Sperren frei) und lösche UNDO Information (Phase 2). BOT; w 1 [X, 700]; w 1 [Y, 100]; COMMIT Undo: Änderungen einer Transaktion, die noch nicht committed hat, werden nach Ausfall zurückgesetzt. Redo: Änderungen einer Transaktion, die committed hat, werden in geschrieben. Ab jetzt Phase 2 X L Y 100 L Obj Undo X Y T 1 COMMIT Einsatz: Transaktionen für 19 Einsatz: Transaktionen für 20

6 Wie wird Commit abgearbeitet? (2) REDO Illustration: Wie wird Commit abgearbeitet? (2) REDO Illustration: BOT; w 1 [X, 700] X 500 X 500 L Obj Redo X 700 Einsatz: Transaktionen für 21 Einsatz: Transaktionen für 22 Wie wird Commit abgearbeitet? (2) Wie wird Commit abgearbeitet? (3) REDO Illustration: Nachdem Phase 1 erfolgreich geendet hat (CommitEintrag in Datei), ist erfolgreiche Terminierung der Transaktion garantiert ( all ): REDO möglich nach Ausfall des Knotens. Bei Fehler vor dem Ende der Phase 1: Reset ( nothing ). BOT; w 1 [X, 700] COMMIT Wie geht es weiter? Was geschieht im Fehlerfall? X 500 L Obj Redo X 700 Einsatz: Transaktionen für 23 Einsatz: Transaktionen für 24

7 Undo Redo (2) Undo Redo (3) DBMS benötigt Undo := DBMS erlaubt Transaktion, die noch nicht committed hat, zu schreiben. Im Fehlerfall kann Restart Undo ausführen. DBMS benötigt Redo := DBMS erlaubt der TA zu committen, bevor alle Änderungen in. Im Fehlerfall kann Restart Redo ausführen. Einsatz: Transaktionen für 25 Einsatz: Transaktionen für 26 isches ging Zusammenfassung bis hierhin Beschreibe nur Änderungen der Daten, im Gegensatz zu Before Image., wichtige Eigenschaften von Transaktionen. Sicherstellung dieser Merkmale wurde illustriert. Locking, UNDO, REDORecovery. Bis hierhin: Herkömmliche Transaktionen auf relationaler. Einsatz: Transaktionen für 27 Einsatz: Transaktionen für 28

8 XMLSupport relationaler DBMSe Beispiel IBM DB2 (1) Funktionalität: (1) Publizieren relationaler Daten als XML, (2) Speicherung von XML in Relationen. Bezüglich (2) Unterscheidung zwischen side tables, document tables. Shredding der Dokumente vs. CLOBSpeicherung. Sicherstellung der Konsistenz von side tables und document tables z. B. durch Trigger. Einsatz: Transaktionen für 29 Einsatz: Transaktionen für 30 Beispiel IBM DB2 (2) Side Tables SQLKommandos: Einfache Varianten des STOREDAnsatzes. Liefere den Inhalt aller priceelemente, nach double konvertiert, und entsprechendes keyattribut. select key, x.returneddouble from xmldata table(db2xml.extractdoubles(xmltext, '//price')) as x Setze alle priceelemente auf 200. update xmldata set xmltext = db2xml.update(xmltext, '//price', '200') Zugriff jeweils nur auf die Matches (nicht etwa auf übergeordnete Knoten). Queryevaluierung zwei Möglichkeiten: Side Tables reichen aus, um Anfrage zu beantworten. dto. nicht ausreichend. Nur Bestimmung von Kandidaten. Einsatz: Transaktionen für 31 Einsatz: Transaktionen für 32

9 Side Tables Beispiel Beispiel für Anfrage gesucht sind Informationen über Auktionen mit niedrigem Preis. select x.returnedvarchar, y.returneddouble from xmldata as z, table(db2xml.extractvarchar(xmltext, '//shipping')) as x, table(db2xml.extractdouble(xmltext, '//price')) as y where z.key in (select key from auction where price < 50) and y.returneddouble < 50 shippinginfo nicht in Side Tables enthalten. Beispiel für subsuming query : select key from auction where price < 50 Transaktionsmanagement für Übersicht (1) Transaktionen auf Anwendungsebene: Bündel von Requests. Alternativen: Flat Transaction Model, Transaction Management at Application Level Entspricht nicht ganz der Definition von Subsuming Query. Einsatz: Transaktionen für 33 Einsatz: Transaktionen für 34 Transaktionsmanagement für Übersicht (2) Transaktionsmanagement für Übersicht (3) Transaction Management at Application Level: Transaction Management at Application Level: Clients Transaction manager Transaction Manager XMLTM DBMS XML extension Zusätzliches Transaktionsmanagement auf Anwendungsebene. Zerlegt Anwendungstransaktionen in unabhängige Transaktionen und ordnet sie an. Berücksichtigung von Konflikten auf Anwendungsebene. Commit der Transaktionen ist i. Allg. früher möglich. Storage manager Einsatz: Transaktionen für 35 Einsatz: Transaktionen für 36

10 DGLOCKProtokoll (1) DGLOCKProtokoll (2) Unterschied zwischen Constraints in Pfadausdrücken: (1) structural constraints, (2) content constraints Beispiel: /store/auction/price[.>1000] StrukturConstraints Typebene, inhaltliche Constraints Instanzenebene. 2 price > 1000 Locking Protokoll berücksichtigt beide Arten von Constraints. 1 Hierarchische Beziehung zwischen Objekten Konflikte selbst dann, wenn Zugriff auf unterschiedliche Objekte. Illustration: description auction price store... Intention Lock: Signalisiert Intention, S bzw. X Lock für feineres Granulat (im aktuellen Objekt enthalten) zu erlangen. Einsatz: Transaktionen für 37 Einsatz: Transaktionen für 38 DGLOCKProtokoll (3) DGLOCKProtokoll (4) DAG Protokoll: Leseoperationen sperren einen Pfad von Wurzel zu zu lesenden Knoten, Schreiboperationen alle Pfade. Anfordern und Freigeben von Locks zweiphasig. Herkömmliche DAG Lock Kompatibilitätsmatrix: Requested IS IX S SIX X None IS Granted IX S SIX X Schwierigkeit hinsichtlich des XMLLockings: Knoten/Elemente in der i. Allg. nicht explizit repräsentiert. Lösung: Verwende DataGuide fürs Locking. DAG Locking auf DataGuide. T1 T2 IX IS T1 T2 description T2 S IX IS auction price T1 X store... T 1 Update: /store/auction/price T 2 Retrieve: /store/auction/description Einsatz: Transaktionen für 39 Einsatz: Transaktionen für 40

11 Ableitung eines neuen Requests mit DGLOCK (1) Notation: granted pred i read bzw. write sets der Prädikate, die bestehendes Lock annotieren, req pred dto. Lock Request, granted es muß gelten: P U pred i pred req ( ) = i Ableitung eines neuen Requests mit DGLOCK (2) Schritte des Protokolls: 1. Extrahieren der Constraints. Pfadausdruck mit Content Constraints annotieren. 2. Alle ZielKnoten der Pfadausdrücke im DataGuide bestimmen. 3. Für jeden ZielKnoten n: a) Falls Update: IX Locks für alle Knoten entlang aller Pfade zu n; X Lock für n. b) Falls Lesen: IS Locks für alle Knoten entlang eines Pfads; S Lock für n. Einsatz: Transaktionen für 41 Einsatz: Transaktionen für 42 Ableitung eines neuen Requests mit DGLOCK (3) TM verzögert Request, wenn zwei Locks nicht kompatibel. Deadlock Detection erforderlich. Beispiele (1) Beispiel 1: T 1 : Lesezugriff, Pfadausdruck /store/auction[price > 5]/description T 2 : Überschreibt Elemente /store/auction[price < 0.5]/price mit Wert '4'. Locks sind kompatibel. Einsatz: Transaktionen für 43 Einsatz: Transaktionen für 44

12 Beispiele (2) Reduzierung des LockingAufwands Erkauft mit tendenziell niedrigerer Nebenläufigkeit. Idee: Locken gröberer Granulate. S oder X Locks anstelle von Intention Locks. Links: Beispiel 1; Rechts: Beispiel 2 (eine der nächsten Folien) Einsatz: Transaktionen für 45 Einsatz: Transaktionen für 46 Beispiele (3) Beispiel 2: Granulat für Locken: auctionelemente. T 3 : Lesezugriff, Pfadausdruck /store/auction[price > 5 AND contains(./description, 'XML')] T 4 : Überschreibt Elemente /store/auction[./description = 'Web'] mit Wert 'XML'. Prädikate description = 'XML' sind inkompatibel. Welcher DataGuide kommt zur Anwendung? (1) Minimaler DG, Strong DG. Minimaler DG: Anzahl Knoten minimal. Strong DG: Baum (wenn Dokument genau eine Wurzel hat), 1:1Beziehung zwischen Label Paths und Knoten des DG. Hinsichtlich Korrektheit egal, welcher DG zur Anwendung kommt. Welcher DG ist überlegen? Einsatz: Transaktionen für 47 Einsatz: Transaktionen für 48

13 Welcher DataGuide kommt zur Anwendung? (2) Optimierung: Niedrigeres slevel Antwort: Strong DG. Es wird stets nur ein Pfad gelockt. DG, der nicht strong ist: I. Allg. werden mehrere Label Paths gelockt. Höhere Lock Contention. Kein wiederholtes Lesen in Transaktionen in unserem Kontext. ANSI Level 2 ist möglich. Erhebliche Beschleunigung. z Einsatz: Transaktionen für 49 Einsatz: Transaktionen für 50 auf der XMLEbene (1) auf der XMLEbene (2) Implementierung von erfordert RecoveryMechanismen. XMLTM implementiert Recovery auf Anwendungsebene. Beispiel: Update Transaktion überschreibt Elemente /store/auction[itemid = '4711']/price mit Wert UndoRecovery, erfordert BOT und EOTMarker, plus ID der globalen Transaktion. XMLTM loggt: BeforeImage, Parameter der Update Requests. Ermöglicht Berechnung der Kompensationsoperation. XMLTM loggt Pfadausdruck und beforeimage des priceelements. Einsatz: Transaktionen für 51 Einsatz: Transaktionen für 52

14 bemerkungen Transaktionelle Garantien als wichtiges Leistungsmerkmal von DBMSen. Änderbarkeit von XMLDatenbeständen. Ausschließliche Verwendung der Transaktionsmechanismen ineffizient. Zusätzlicher Transaktionsmanager (XMLTM), implementiert DGLOCK. Forschungsprototyp, sinnvolle Erweiterung kommerzieller DBMSe. Mögliche Prüfungsfragen Was sind Side Tables? Was sind PseudoKonflikte? Geben Sie hierfür ein Beispiel im XMLKontext. Wie geht man damit um? Wie unterscheidet sich DGLOCK von herkömmlichem Locking für Bäume? Einsatz: Transaktionen für 53 Einsatz: Transaktionen für 54 Literatur T. Grabs, K. Böhm, H.J. Schek: XMLTM: Efficient Transaction Management for XML Documents. Einsatz: Transaktionen für 55