Beschränkungen flacher TA (1)

Transkript

1 Kapitel 2. (Erweiterte) ransaktionsmodelle Inhalt: Gekettete, geschachtelte und verteilte ransaktionen, Mehrebenen-ransaktionen, offen geschachtelte ransaktionen, langlebige ransaktionen, Sagas Beschränkungen flacher (1) nwendungsbeispiele lange Batch-Vorgänge - Beispiel: Zinsberechnung - lles-oder-nichts führt zu hohem Verlust an rbeit - denkbar: Zerlegung in viele unabhängige ransaktionen, dann jedoch manuelle Recovery nach Systemfehler Mehrschritt-ransaktionen, langlebige ktivitäten - Beispiel: mehrere (ggf. verschiedenartige) Reservierungen pro ransaktion - lange Sperrdauer (Isolation) führt zu katastrophalem Leistungsverhalten (Sperrkonflikte, Deadlocks) - Rücksetzen der gesamten ktivität im Fehlerfall i.allg. nicht akzeptabel 2

2 Beschränkungen flacher (2) nwendungsbeispiele Entwurfsvorgänge (D, SE,...) - lange Dauer (Wochen/Monate) - kontrollierte Kooperation zwischen mehreren Entwerfern (vor ommit) - Einsatz von Versionen ktive DBS - DBS reagiert eigenständig auf bestimmte Ereignisse - Spezifikation durch E-Regeln Realzeit-nwendungen - zeitbezogene Konsistenzforderungen (Deadlines) - häufige irreversible Interaktionen mit der ußenwelt 3 Beschränkungen flacher (3) nwendungsbeispiele Föderative DBS / Multi-DBS - Unterstützung lokaler Knotenautonomie - unterschiedliche Synchronisations- und Recovery-Protokolle 4

3 Beschränkungen flacher (4) Beschränkungen auf kurze ransaktionen zugeschnitten, Probleme mit "langlebigen" ktivitäten lles-oder-nichts-eigenschaft oft inakzeptabel: - hoher rbeitsverlust - keine Binnen-Kontrollstruktur - fehlende Kapselung oder Zerlegbarkeit in eilabläufen - keine abgestufte Kontrolle für Synchronisation und Recovery Isolation - Leistungsprobleme durch "lange" Sperren - fehlende Unterstützung zur Kooperation keine Unterstützung zur Parallelisierung fehlende Benutzerkontrolle 5 Beschreibung von -Modellen (1) Zustands-/Übergangsdiagramm für flache ransaktionen aus der Sicht der nwendung Erweiterbar? terminate NULL BEGIN WORK OMMI WORK active ROLLBK WORK committed terminate aborted 6

4 Beschreibung von -Modellen (2) bhängigkeiten zwischen ransaktionen Strukturelle bhängigkeiten - beschreiben hierarchische Organisation eines Systems - festgelegt, da ufrufhierarchie im ode vorgegeben Dynamische bhängigkeiten - durch Nutzung von gemeinsamen Daten - können eine beliebige nzahl sonst unabhängiger atomarer ktionen einhüllen Strukturelle und dynamische bhängigkeiten als Regeln beschreibbar! 1 1 B1 B2 2 7 Beschreibung von -Modellen (3) Regelaufbau ktiver eil - BEGIN WORK (B), ROLLBK WORK (, abort) und OMMI WORK () verursachen Zustandsänderungen einer atomaren ktion - ransaktionsmodelle können Bedingungen definieren, die diese Events auslösen Passiver eil - bhängige atomare ktionen dürfen bestimmte Zustandsübergänge nicht von selbst durchführen - Es sind Regeln erforderlich, die die Bedingungen für diese Zustandsübergänge spezifizieren 8

5 Beschreibung von -Modellen (4) Grafische Notation Zur graphischen Darstellung eines ransaktionsmodells wird jede Instanz einer atomaren ktion () als eine Box veranschaulicht Schattierte Bereiche bezeichnen verbotene Ereignisse oder usgänge! abort begin commit Signaleingänge für die atomare ktion () zur Durchführung eines Zustandsübergangs aborted committed Zustandsindikatoren für den usgang der UID der 9 Beschreibung von -Modellen (5) flache ransaktionen BEGIN WORK Operation 1 Operation 2 Operation k OMMI WORK BEGIN WORK Operation 1 Operation 2 (I got lost!) ROLLBK WORK BEGIN WORK Operation 1 Operation 2 Rollback due to external cause like timeout or deadlock Erfolgreiche Beendigung 96% aller bbruch (Suicide) 3% aller Erzwungenes Ende (Murder) 1% aller 10

6 Beschreibung von -Modellen (6) System- beschreibt blaufumgebung immer aktiv, solange System läuft führt kein ommit durch führt bort nur als Ergebnis eines System-rashs durch flache nur eine strukturelle bhängigkeit: wenn System- bort durchführt, muss sie es auch a) b) c) System System System 11 Beschreibung von -Modellen (7) Beobachtungen flache Beendete kann nicht mehr auf Events reagieren oder ihren Endzustand ändern Flache taugen nicht zur Modellierung komplexer Berechnungen; sind vollständig unabhängig von ihrer Umgebung (bis auf bort durch System- rash); können sich zu beliebigen Zeitpunkten zurücksetzen oder ommit durchführen Regelsprache Regelstruktur - <rule identifier> ":" [<preconditions>] " " [<rule modifier list>] "," [<signal list>] "," <state transition> 12

7 Beschreibung von -Modellen (8) Regelsprache (Forts.) Regelnamen für: - BEGIN WORK: S B ( ) - ROLLBK WORK: S ( ) - OMMI WORK: S ( ) Regelsemantik Signal State transition UID der <rule identifier>":" [<preconditions>] " " [<rule modifier list>] "," [<signal list>] "," <state transition> Regel, die einem Signal zugeordnet ist, wird aktiviert, wenn entsprechendes Event auftritt; sie wird aber erst ausgeführt, wenn <preconditions> erfüllt ist <preconditions> ist einfacher Prädikatsausdruck; oft Prädikate über den Zustand anderer, z. B. () oder () 13 Beschreibung von -Modellen (9) Regelsemantik (Forts.) <rule identifier>":" [<preconditions>] " " [<rule modifier list>] "," [<signal list>] "," <state transition> <rule identifier> spezifiziert, zu welchem Signaleingang der Pfeil (in der graphischen Darstellung) zeigt; <preconditions> unterscheiden, woher das Signal kommt <signal list> beschreibt, welche Signale bei der <state transition> generiert werden: sie sind Identifikatoren von Regeln, die durch das Signal aktiviert werden (in der graphischen Notation: Endpunkt eines Pfeils) <rule modifier list> fügt zusätzliche Signale in (andere!) Regeln ein oder löscht sie (entsprechen Pfeilen in der graphischen Notation; delete blockiert eine Regel mit allen ihren Signalen) <rule modifier> ::= "+" "(" <rule id> " " <signal> ")" v "-" "(" <rule id> " " <signal> ")" v "delete(" <rule id> ")" 14

8 Beschreibung von -Modellen (10) Regelausführung wenn Event auftritt, identifizierte Regel überprüfen <preconditions> nicht erfüllt: Regel nur markieren, um anzuzeigen, dass Event aufgetreten andernfalls rechte Seite der Regel ausführen (erzeugt i. allg. weitere Signale) alle ktionen, die von einem Event ausgelöst werden, atomar ausführen; d.h., die Kette abhängiger Events vollständig abwickeln, bevor unabhängiger (von außen kommender) Event betrachtet wird wenn ihren Endzustand erreicht hat: alle Regeln löschen, alle ihre belegten Signaleingänge entfernen 15 Beschreibung von -Modellen (11) Noch einmal flache Beschriebene Zustände a) ist aktiv; b) hat ommit ausgeführt; Endzustand c) wurde zurückgesetzt; Endzustand a) b) c) System System System 16

9 Beschreibung von -Modellen (12) Noch einmal flache (Forts.) Regeln rule modifier list - S B () : (+(S (system) S ()), delete(s B ())),, signal list (leer) BEGIN WORK state transition - S () : (delete(s ()), delete(s ())),, OMMI WORK - S () : (delete(s ()), delete(s ())),, ROLLBK WORK chtung Im folgenden werden der Übersichtlichkeit halber die delete-klauseln weggelassen, wenn die Situation offensichtlich ist 17 Flache mit Sicherungspunkten (1) Sicherungspunkte innerhalb einer werden explizit durch das nwendungsprogramm gesetzt modifiziertes Rollback benennt einen Sicherungspunkt Begin Work implicit Save Work: 1 action action Save Work: 2 action Save Work: 3 action action action Save Work: 4 action Rollback Work (2) action action Save Work: 5 action Save Work: 6 action action Save Work: 7 action action Rollback Work (7) SQL-ransaktionsanweisungen - SVEPOIN <Rücksetzpunktname> - RELESE SVEPOIN <Rücksetzpunktname> - ROLLBK [O SVEPOIN <Rücksetzpunktname>] JDB seit Version 3.0 / lass onnection: - setsavepoint(savepointname) - releasesavepoint(savepointname) - rollback(savepointname) action action Save Work: 8 action ommit Work 18

10 Flache mit Sicherungspunkten (2) Flache mit Sicherungspunkten (Forts.) Grafische Darstellung System System System trigger trigger trigger S1 a) Start der, Setzen von S1 S1 S1 trigger trigger S2 S2 b) Setzen von S2 trigger S3 c) Setzen von S3 19 Flache mit Sicherungspunkten (3) Flache mit Sicherungspunkten (Forts.) Modell - Folge von - verknüpft durch eine Folge von ommits (von der momentanen Position zurück zum -Beginn) und - verknüpft durch eine Folge von borts, ausgehend von der System- als Folge eines rashs Regelmenge - S 1 = UID der ersten, die ggf. Sicherungspunkt S 1 erzeugt - Ziel des Rollback: R (Parameter), spezifiziert als die UID der ältesten, bis zu deren Sicherungspunkt zurückzusetzen ist (wenn R < S 1, wird die gesamte zurückgesetzt) 20

11 Flache mit Sicherungspunkten (4) Flache mit Sicherungspunkten (Forts.) Regelmenge (Forts.) - S B (S 1 ) : +(S (system) S (S 1 )),, BEGIN WORK - S (R) : (R < S 1 ),, ROLLBK WORK - S (S 1 ) :,, OMMI WORK - S S (S 1 ) : +(S (S 1 ) S (S 2 )), S B (S 2 ), Regelmenge für S n, die ggf. Sicherungspunkt S n erzeugt - S B (S n ):,, BEGIN WORK - S (R): (R < S n ), S (S n-1 ), ROLLBK WORK - S (S n ):, S (S n-1 ), OMMI WORK - S S (S n ): +(S (S n ) S (S n+1 )), S B (S n+1 ), 21 Flache mit Sicherungspunkten (5) Sicherung erfolgt nur auf Seiten des DBS, nicht auf nwendungsseite Sind bei einem Systemcrash DBS und nwendungsprogramm betroffen, muss alles zurückgesetzt werden, da Zustand des nwendungsprogramms unbekannt ist. Daher - nur Unterstützung von ransaktionsfehlern - keine Unterstützung von Systemfehlern Erweiterungen für persistente Sicherungspunkte Koordinierte Sicherung für nwendungs- und Datenbankobjekte Derzeitige Systeme unterstützen solche Erweiterungen bisher nicht 22

12 Gekettete (1) Variation der nwendung von Sicherungspunkten Idee: Statt (flüchtige) Sicherungspunkte zu erzeugen, wird eilarbeit "committed". Modell Folge von atomaren ktionen (), die sequentiell ausgeführt werden eil der ommit-verarbeitung: Signal generieren, das BEGIN WORK bei der nächsten auslöst Zustandsübergang muss atomar sein: hain Work (ommit + Begin) (sonst Änderungen an DB-Objekten in der Zwischenzeit möglich) Regelmenge S B ( n ) : +(S (system) S ( n )),, BEGIN WORK S ( n ) :,, ROLLBK WORK S ( n ) :, S B ( n+1 ), OMMI WORK 23 Gekettete (2) Grafische Darstellung System 1 2 a) Erste der Kette wurde gestartet, Start der zweiten später durch ommit der ersten ausgelöst System b) Erste der Kette hat ommit ausgeführt; zweite nun strukturell abhängig von System 24

13 Gekettete (3) Restart einer geketteten Restart wird aktiviert als Folge des Systemausfalls; übernimmt die Rolle von System und startet 1 (mit denselben bhängigkeiten, die 1 hatte) System 1 2 Restart 1 25 Gekettete (4) Gekettete ransaktionen vs. Sicherungspunkte Vergleich - blaufstruktur: Gekettete erlauben wie Sicherungspunkte Substruktur, die langer ktivität aufgeprägt werden kann (DB-Kontext bleibt erhalten) - ommit vs. Sicherungspunkt: Zurücksetzen nur möglich zum letzten SP (= ommit) vorher: zu beliebigen SP - Sperrbehandlung: ommit erlaubt Freigabe der Sperren, die später nicht mehr benötigt werden - Verlust von rbeit: Sicherungspunkte erlauben flexibleres Zurücksetzen nur, solange System normal arbeitet - Restart-Behandlung: Bei geketteten wird Zustand des jüngsten ommit wiederhergestellt (ber: Problem der Wiederherstellung des P-Zustandes wie bei SP). 26

14 Geschachtelte (1) Ziele Zerlegung eines Vorgangs (unit of work) in eilaufgaben: Verteilung und Bearbeitung in einem Rechensystem - dynamische Zerlegung einer in eine Hierarchie von Sub- - Bewahrung der ID-Eigenschaften für die (äußere) B - Gewährleistung von Ununterbrechbarkeit und Isolation für jede Sub- Vorteile Parallelverarbeitung innerhalb einer ransaktion - usnutzung anwendungsspezifischer Parallelität - bbildung auf mehrere Prozessoren feinere Recovery-Kontrolle innerhalb einer ransaktion - Rücksetzen einer Sub- betrifft nur sie und ihre Kinder - weitere Verfeinerung durch Sicherungspunkt-Konzept möglich D E 27 Geschachtelte (2) Vorteile (Forts.) explizite Kontrollstruktur - einfachere Programmierung paralleler bläufe - lles oder Nichts -Eigenschaft von Sub- reduziert Komplexität Modularität des Gesamtsystems - einfache und sichere Zerlegung eines -Programmes in Sub- - unabhängiger Entwurf / Implementierung von Modulen - Unterstützung von Kapselung und Fehlerisolation verteilte Systemimplementierung - Einsatz verteilter lgorithmen - Erhöhung von Verfügbarkeit und Leistung 28

15 Geschachtelte (3) Genauere Definition nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions. ransactions at the leaf level are flat transactions. he distance from the root to the leaves can be different for different parts of the tree. he transaction at the root of the tree is called top-level transaction, the others are called sub-transactions. transaction s predecessor in the tree is called parent; a sub-transaction at the next lower level is also called a child. sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits. So, by induction, any sub-transaction can finally commit only if the root transaction commits. he rollback of a transaction anywhere in the tree causes all its subtransactions to roll back. his combined with the previous point is the reason why sub-transactions have only ()I, but not ()D. 29 Geschachtelte (4) Bemerkung Die Einhaltung von lässt sich an die Erzeuger- delegieren (größere Flexibilität bei der -Zerlegung) Dynamisches Verhalten ommit-regel: (lokales) ommit einer Sub- macht ihre Ergebnisse nur der Erzeuger- zugänglich; endgültiges ommit einer Sub- dann und nur dann, wenn für alle Vorfahren bis zur L- das endgültige ommit erfolgreich ist. Rücksetz-Regel: Wird (Sub-) auf irgendeiner Schachtelungsebene zurückgesetzt, werden alle ihre Sub-, unabhängig von ihrem lokalen ommit-status ebenso zurückgesetzt (rekursiv anwenden). Sichtbarkeits-Regel: lle Änderungen einer Sub- werden bei ihrem ommit für ihre Erzeuger- sichtbar; alle Objekte, die Erzeuger- hält, können den Sub-s zugänglich gemacht werden; Änderungen einer Sub- sind für Geschwister- nicht sichtbar. 30

16 Geschachtelte (6) Geschachtelte ransaktionen sind eine Generalisierung von mit Sicherungspunkten Sicherungspunkt erstellen Begin Work... invoke Sub-... Begin Work invoke Sub-... invoke Sub-... ommit Work Begin Work... ommit Work Begin Work invoke Sub-... ommit Work S 1 S 2 S 2 invoke Sub-... Begin Work... ommit Work S 3 invoke Sub-... ommit Work Begin Work invoke Sub-... ommit Work Begin Work... ommit Work S 4 S 5 31 Geschachtelte (5) Geschachtelte sind das Äquivalent der Modularisierung auf der Ebene des Kontrollflusses Jede Sub- ist eingebettet in die Kontrollsphäre der Erzeuger- lle ID-Eigenschaften gelten nur für die L- Grafische Darstellung (vgl. nachfolgende Folie) bhängigkeiten in einer geschachtelten sind rein strukturell (vgl. Fol.7) bort-signale werden von oben nach unten durchgereicht Übergang in den ommit-zustand hängt davon ab, ob Erzeuger- ihn schon vollzogen hat 32

17 Geschachtelte (7) Grafische Darstellung (Forts.) System System System trigger trigger trigger a) Wurzel- wird ausgeführt trigger 1 wait trigger 1 2 wait trigger b) Sub- 1 wurde gestartet 11 wait wait c) 1 hat Sub-a 11 erzeugt; danach wurde 2 von gestartet 33 Geschachtelte (7) Regelmenge für Sub- kn mit Erzeuger- k - S B ( kn ) : +(S ( k ) S ( kn )),, BEGIN WORK - S ( kn ) :,, ROLLBK WORK - S ( kn ) : ( k ),, OMMI WORK Neu: - Bedingung für ommit - in der graphischen Darstellung Pfeil zurück von ommit-zustand einer Sub- zum ommit-zustand ihrer Erzeuger- (mit wait markiert) 34

18 Geschachtelte (8) Vertiefung: Sperren bei flachen ransaktionen Erwerb gemäß Kompatibilitätsmatrix Halten von Sperren R, X Freigabe bei ommit Regeln zum Sperren bei geschachtelten ransaktionen NL R X R X Zur Realisierung von Sichtbarkeits-Regel und ommit-regel werden Sperren bei ommit von Sub-ransaktion an Vater-ransaktion vererbt (Retain-Sperre), dabei gilt: R1: ransaktion kann X-Sperre erwerben, falls - keine andere ransaktion eine X- oder R-Sperre auf dem Objekt hält, sowie - alle ransaktionen, welche eine r-x oder r-r-sperre besitzen, Vorfahren von sind (bzw. selbst) R2: ransaktion kann R-Sperre erwerben, falls - keine andere ransaktion eine X-Sperre hält, sowie - alle ransaktionen, welche eine r-x besitzen, Vorfahren von sind (bzw. selbst) 35 Geschachtelte (9) Regeln zum Sperren bei geschachtelten ransaktionen (Forts.) R3: Beim ommit von Sub-ransaktion erbt Vater von alle Sperren von (reguläre + retained-sperren). Für reguläre Sperren von werden beim Vater die entsprechenden retained-sperren gesetzt R4: Beim bbruch einer ransaktion werden alle regulären und Platzhalter-Sperren von freigegeben. Sperren der Vorfahren bleiben davon unberührt. Notation: - X-lock auf Objekt O 1 : h(o 1, X), oder wenn klar ist, welches Objekt gemeint ist: X - R-lock vererbt (retained) auf Objekt O 2 : r:(o 2, R) oder wenn klar ist, welches Objekt gemeint ist: r-r 36

19 Geschachtelte (10) Härder,., Rothermel, K.: oncurrency ontrol Issues in Nested ransactions, in: VLDB-Journal 2:1, 1993, pp Vererbung von Sperren (upward inheritance of locks) Veränderung der R- und X-Sphären a) X-sphere R-sphere r-x S r-x S r-x S r-r R S retains X-lock after acquired R-lock after ommit() b) r-x S... r-x S... r-x S... r-x X S retains X-lock after acquired X-lock after ommit() 37 Geschachtelte (11) Vererbung von Sperren (upward inheritance of locks) Realisierung - Erzeuger- erbt Log-Information und Sperren von Sub- - Geerbte Daten werden verwaltet von einem Buchhalter oder -Manager Beispiel: Sperren in geschachtelten 1. usgangssituation r: (O 1, X) r: (O 2, R) 2. ommit (1) V 1 2 h: (O 3, X) r: (O 1, X) r: (O 2, R) V Vererbung! 2 h: (O 3, X) 38

20 Geschachtelte (12) Beispiel: Sperren in geschachtelten (Forts.) 3. lle im Kontrollbereich von V können Sperren auf O 1 und O 2 erwerben r: (O 1, X) r: (O 2, R) V h: (O 2, R) 4 2 h: (O 3, X) 3 h: (O 1, X) 4. 3 und 4 führen ommit durch r: (O 1, X) r: (O 2, R) V h: (O 3, X) 2 r: (O 1, X) 39 Geschachtelte (13) Beispiel: Sperren in geschachtelten (Forts.) 5. 5 fordert (O 2, X) an (keine weitere R-Sperre) r: (O 1, X) r: (O 2, R) V 2 h: (O 3, X) r: (O 1, X) 5 h: (O 2, X) 6. V und 5 fordern (O 1, X) an; V muss warten 1 40

21 Geschachtelte (14) Zusätzliche Deadlock-Probleme 1) lock (O, X) h: (O, X) V 1 2 2) lock (O, X) nforderungsreihenfolge wird eingehalten: Die Sperre der Vatertransaktion V wird bis ommit gehalten und Subtransaktion 2 kann Sperre nicht mehr bekommen! r: (O, X) h: (O, X) V Deadlock! 2 lock (O, X) Lösung? Erweiterung des Verfahrens um bwärtsvererbung (Umwandlung X in r-x-sperre) - Zugriff der Vatertransaktion auf Objekt danach aber nicht mehr möglich! 41 Geschachtelte (15) Freiheitsgrade synchrone ufrufe, serielle usführung synchrone ufrufe, parallele usführung asynchrone ufrufe, parallele usführung Repräsentation/usführung von (Sub-) in einem oder mehreren Prozessen lokale oder verteilte nordnung lient-server-beziehung zwischen synchroner ufruf: lient ist blockiert, bis ntwort eintrifft asynchroner ufruf: lient und Server können parallel arbeiten parallele Initiierung mehrerer (synchroner) ufrufe (PRBEGIN... PREND) 42

22 Geschachtelte (16) Schnittstelle zwischen Singe all -Schnittstelle: erzeugt Sub- (und diese ggf. rekursiv weitere); ntwort impliziert Ende der Sub- Konversations-Schnittstelle: erzeugt Sub-; nach einer ntwort bleibt der Kontext der Sub- erhalten; sie kann weitere nforderungen bearbeiten, bis explizit EO der Sub- ausgeführt wird. Kooperation (vgl. Illustration nachfolgende Folie) ufrufprimitive work (w), work & commit (w&c), commit (c), abort (a), accept, done Forderung: Hierarchical ontainment bei Konversationsschnittstelle - Vereinfachung der Schachtelungsstruktur - Begrenzung des Domino-Effekts usw. 43 Geschachtelte (17) Kooperation w&c V w&c w&c K Benutzung von Single-all-Schnittstelle V w w w w&c w&c w w&c K1 K2 Benutzung von Konversations-Schnittstellen 44

23 Geschachtelte (18) 4 rten von Intra-ransaction -Parallelität Serielle usführung von : synchrone ktivierung (z.b. RP) Nur Parallelität zwischen Kind- (sibling parallelism): parallele ktivierung mehrerer synchroner ktionen Vater/Kind-Parallelität: Nur parallele -usführung in hierarchischem Pfad Uneingeschränkte Parallelität: asynchrone -ktivierungen auf allen Ebenen 45 Verteilte (1) Verteilte ransaktion ist typischerweise flache, die in einer verteilten Umgebung abläuft und deshalb mehrere Knoten im Netz aufsucht deren Verteilung von den Daten abhängt die in Scheiben derselben op-level- aufgeteilt ist Struktur einer geschachtelten wird dagegen von funktionaler Zerlegung bestimmt! Kontrollstruktur in einer verteilten Umgebung Wurzeltransaktion Koordinator eiltransaktionen 1 2 n 46

24 Verteilte (2) Behandlung von Isolation (Sperren), Konsistenzsicherung, Rücksetzen, ommit? Kopplung zwischen Sub- und ihrer übergeordneten in diesem Modell viel stärker als bei geschachtelten Regelmenge (für den Fall einer Sub- 1) S B () : +(S (system) S ()),, BEGIN WORK S () :,, ROLLBK WORK S () :,, OMMI WORK S B (1) : (+(S () S (1)), +(S () S (1))),, BEGIN WORK S (1) :, S (), ROLLBK WORK S (1) :, S (), OMMI WORK 47 Verteilte (3) Grafische Darstellung System System a) Wurzel- wird ausgeführt 1 2 b) entfernte Sub-s 1 und 2 wurden gestartet 48

25 Mehrebenen- (1) Motivation: Dynamische ufrufhierarchie in einem DBS (Bsp.) nforderung an das DBMS Datensystem... Zugriffssystem Datenmodelloperationen Hole/Modifiziere tom... Speichersystem... Lese/Schreibe Seite 49 Mehrebenen- (2) Motivation (Forts.) Hoher Leistungsbedarf bei komplexen nforderungen, z. B bei heckout/heckin- oder bei interaktiver nfrage-verarbeitung - Reduktion der ntwortzeit, Erhöhung der Verfügbarkeit - Parallelisierung und Verteilung von Operationen - feinere Recovery-Granulate - Bildung von Subtransaktionen im DBS-Kern Verallgemeinerung geschachtelter : offene Schachtelung Sub- dürfen vor Ende der Erzeuger- ommit ausführen ( pre-commit ), aber nicht umgekehrt! danach einseitiges Zurücksetzen (Rollback) nicht mehr möglich aber: Kompensation - Wirkung der Sub- rückgängig machen, wenn Erzeuger scheitert - kompensierende selbst wieder geschachtelte oder Mehrebenen- 50

26 Mehrebenen- (3) Grafische Darstellung System trigger System trigger System trigger a) Wurzel- wirdausgeführt trigger trigger N N N b) Sub- N wurdegestartet c) Sub- N ist abgeschlossen und hat Kompensations- N installiert Ein bort darf nicht fehlschlagen! Kompensierende N muss ommit durchführen; Wirkung einer Blockierung des -Eingangs und des -Zustands wird durch Restart- N realisiert; 51 Mehrebenen- (4) Kompensations- installieren, wenn Sub- ommit ausführt aufbewahren, solange Erzeuger- noch läuft nach bschluss der Erzeuger- wegwerfen wichtig: Kompensations- muss ommit erreichen! Regeln für Wurzel- identisch zu denen für flache Regeln für Sub- N S B (N) : (+(S () S (N)), +(S () S (N))),, BEGIN WORK S (N) :,, ROLLBK WORK S (N) : +(S () S B (N)),, OMMI WORK 52

27 Mehrebenen- (5) Regeln für Kompensations- N Vorsorge für den Fehlerfall während des N-blaufs N im Falle des Scheiterns neu starten als N (vgl. gekettete ) - S B (N) : +(S (restart) S B (N )),, BEGIN WORK - S (N) :, S B (N ), ROLLBK WORK - S (N) : delete(s B (N )),, OMMI WORK Beachte - N hat denselben ode, erhält dieselben Daten, hat aber einen anderen Namen; eine kann nur einmal ausgeführt werden, d. h. unter anderem, dass mit ihr kein Restart ausgeführt werden kann; 53 Mehrebenen- (6) Nutzung: Strukturierung der Operationshierarchie im Schichtenmodell SELE.. INSER... UPDE... SELE.. Insert tuple Insert B-tree entry Update page Insert address table entry Locate position Insert entry Split page 54

28 Mehrebenen- (7) Nutzung: Strukturierung der Operationshierarchie im Schichtenmodell (Forts.) SQL-nweisungen können als Sub- aufgefasst werden, ebenso die internen Modulaufrufe Vergleich - geschachtelte : - Sperren auf Seiten, dresstabellen, B-Baum-Seiten(!) bleiben erhalten (bei der Erzeuger-) - Mehrebenen-: - Sperren werden freigegeben! z.b. Seite für andere Sub- zugänglich - Kompensation: upel wieder aus Seite löschen. - Voraussetzung dafür ist, dass eine Gegenaktion zur Verfügung steht, welche die ursprüngliche Operation kompensieren kann 55 Mehrebenen- (7) Nutzung (Forts.) Reihenfolge der ktionen ufruf: insert_tuple (t, retcode) find free page; let the number be P update free space info locate free space info for page P update free space info read page P remove tuple t update page header release DB key K Entfernung des upels funktioniert auch, wenn Seite inzwischen von anderen geändert wurde! read page P update pager header insert tuple grab free DB key K insert K into page header of page P as entry pertaining to t read page with entry for DB key K insert pointer to P into table entry t remove K from t s page header entry in page P read page containing entry for DB key K remove pointer from table entry remember page P ufruf: remove_tuple (K, retcode) Reihenfolge der Gegenaktionen t 56

29 Mehrebenen- (8) Strukturelle Voraussetzungen für den Einsatz von Mehrebenen- bstraktionshierarchie: Gesamtes System besteht aus strikter Hierarchie von Objekten mit ihren Operationen Schichtenweise bstraktion: Objekte der Schicht n werden vollständig implementiert unter Verwendung von Operationen der Schicht n-1 Disziplin: Schicht n darf nur auf Objekte von Schicht n-1 zugreifen 57 Mehrebenen- (9) Wirkungsprinzip der Mehrebenen- beruht nicht auf einer Enthaltenseinshierarchie, sondern auf bbildungshierarchie der Objekte - Jede Ebene übt ommit-kontrolle über die auf ihr anfallenden Objektänderungen aus - Objekthierarchie schützt implizit alle Objekte auf niedrigeren Ebenen, die zur Implementierung von Objekten auf höherer Ebene benötigt werden - Bei Objekthierarchie upel - Seite - Block erlaubt eine upelsperre die vorzeitige Freigabe der Seitensperre, die zum Einfügen benötigt wird 58

30 Mehrebenen- (10) Wirkungsprinzip der Mehrebenen- (Forts.) INSER uple_x uple_y Insert_B-ree Insert_uple Insert_Log Page P Insert database key Insert into page bbildung von Operationen bbildung von Objekten 59 Mehrebenen- (11) Schachtelung der lässt sich auf beliebige Schichten (beliebige Operationen) verallgemeinern theoretisch fundierter nsatz ransaktionsverwaltung in jeder Schicht usnutzung von nwendungssemantik zur Synchronisation möglich Wahl unterschiedlicher Synchronisationstechniken pro Schicht möglich potentiell hoher ufwand zur -Verwaltung, insbesondere für Logging und Recovery (Protokollierung in mehreren Schichten) 60

31 Mehrebenen- (12) Beispiel: serialisierbarer blaufplan mit 2 Ebenen 1 2 BO( 1 ) ändere 11 (x) BO( 2 ) ändere 21 (y) EO( 2 ) ändere 12 (y) EO( 1 ) BO( 11 ) l 111 (p) s 112 (p) EO( 11 ) BO( 21 ) l 211 (p) s 212 (p) EO( 21 ) BO( 12 ) l 121 (p) s 122 (p) EO( 12 ) Wesentliche Eigenschaften reduzierte Konfliktgefahr zwischen auf niedrigeren Ebenen unter Wahrung von Serialisierbarkeit vorzeitiges ommit (Freigabe von Änderungen/Sperren) von Sub- aber: Schutzschirm auf höherer Ebene bleibt erhalten (z.b. striktes 2-Phasen-Sperrprotokoll für L-) für Gesamt- gelten weiterhin ID-Eigenschaften 61 Offen geschachtelte (1) ID für langlebige? sehr lange Sperren Sperren vieler Objekte Erhöhung der Blockierungsrate und Konfliktrate höhere Rücksetzrate (Deadlock-Häufigkeit stark abhängig von -Größe) höhere hance, durch einen Systemfehler zurückgesetzt zu werden Leistungsprobleme "narchische" Variante der Mehrebenen- keine Restriktionen bzgl. semantischer Beziehung zwischen Sub- und Erzeuger- insbesondere auch keine Objekthierarchie 62

32 Offen geschachtelte (2) Beispiel Bestell-Bearbeitung eile aus Lager entnehmen Kundenkonto belasten Gutschrift für Verkäufer Rechnung erstellen Subtransaktionen i arbeiten oft auf verschiedenen Datenbeständen Prinzipien Sperren werden vor Beendigung der L- freigegeben für jede ändernde Sub- i wird Kompensations- i bereitgestellt im Fehlerfall: usführung von i (kein UNDO( i )) keine Serialisierbarkeit 63 Langlebige (1) Verarbeitung langer Batch-nwendungen Einsatz von flachen ransaktionen? kontextfreie Verarbeitung: output_msg = f (input_msg) Exactly once -Semantik wird eingehalten Kosten im Restart-Fall Sicherungspunkt oder geschachtelte helfen bei rash nicht Zerlegung in Mini-Batches Nutzung von Verarbeitungskontexten Hintereinander-usführung der -Folge unter Beibehaltung des -Verarbeitungskontextes output_msg = f (input_msg, context) 64

33 Langlebige (2) Kontextinformationen ransaktion - ursorpositionen,... Programm - letzte, die erfolgreich ommit durchgeführt hat,... erminal - Liste der Funktionen, die aufgerufen werden können - letztes ausgegebenes Fenster - Liste der Benutzer, die das erminal benutzen dürfen,... Benutzer - letzter uftrag, den der Benutzer bearbeitet hat - nächstes zu benutzendes Passwort, Langlebige (3) Einsatz von Verarbeitungskontexten usführung eines kontext-sensitiven -Programms beruht auf - den Parametern in der Eingabe-Nachricht - und Zustandsinformationen als Kontext SimpleProgram() { read (input_message); BEGIN WORK; /* perform computation based on input message and context */; send (output_message); OMMI WORK; }; Privater Kontext Globaler Kontext Ergebnis - ist eine usgabenachricht - und ein geänderter Kontext 66

34 Langlebige (4) Eigenschaften langlebiger ransaktionen Minimierung der verlorengegangenen rbeit im Fehlerfall wiederherstellbarer Verarbeitungszustand expliziter Kontrollfluss Einhaltung der ID-Eigenschaften (für Einzel-) 67 Langlebige (5) Beispiel: Zinsberechnung 68

35 Langlebige (6) Beispiel: Zinsberechnung (Forts.) 69 Sagas (1) Linderung der LL-Probleme bei speziellen nwendungen vorzeitige Freigabe von Ressourcen LL nicht mehr atomar, jedoch keine Preisgabe der DB-Konsistenz Koordinierte Fehlerbehandlung bzw. Rücksetzung erforderlich Spezielle rt von zweistufigen geschachtelten Saga LL, die in eine Sammlung von Subtransaktionen aufgeteilt werden kann spekte der blaufsteuerung und -kontrolle i geben alle Ressourcen (z. B. Sperren) frei expliziter Kontrollfluss zwischen den i (Sequenz) im W-Programm Synchronisation verlangt Serialisierbarkeit der i, jedoch nicht von Konfliktbehandlung durch Warten oder bbruch von i oder von Fehlerbehandlung von i durch UNDO( i ) und Kompensation i-1,..., n 70

36 Sagas (2) Es muss für Kompensation gesorgt werden! alle i gehören zusammen Bereitstellung von Kompensationstransaktionen i für jede i keine teilweise usführung von (!) Saga: Menge flacher ransaktionen 1, 2,..., n, die im einfachsten Fall sequentiell verarbeitet wird Zusicherung des DBS Das Endergebnis einer Saga ist entweder die usführungsfolge 1, 2,..., i,..., n-1, n oder bei einem Fehler im Schritt j 1, 2,..., j (abort), j-1,..., 2, 1 DBS garantiert LIFO-usführung der Kompensationen im Fehlerfall j, j UNDO( j ) im allgemeinen Fall für j müssen Ressourcen wieder angefordert werden Deadlock-Gefahr 71 Sagas (3) Grafische Darstellung (Momentaufnahme mit Planung künftiger ) System

37 Sagas (4) Zusätzliche Kontroll-Operationen: BEGIN_SG (BS), BOR_SG (S), END_SG (ES) blauf a) BS...BO( 1)...EO( 1)...BO( 2)... EO( 2) 1 2 n...eo( n)...es b) BS...BO( 1)...EO( 1)...BO( 2)... BOR 1 2 UNDO c) BS...BO( 1)...EO( 1)...BO( 2)... BOR_SG EO ( 1 )... 1 BO ( 1 ) 2 UNDO d) Unterbrechung durch Systemfehler: wie Fall c 73 Sagas (5) Eigenschaften ID für jede Sub- i (D kann durch Kompensation aufgehoben werden) D für umfassende Verfeinerung Reduktion des ufwandes beim Scheitern einer Saga oder bei Systemfehler durch Nutzung von Savepoints - Sicherung des P-Zustandes - Übergabe der Savepoint-ID an BOR_SG Partielles Rücksetzen möglich Szenario blauf - Savepoint nach 1 und 3 - rash nach 2 und 5 - BS, 1, 2, 2, 2, 3, 4, 5, 5, 4, 4, 5, 6, ES 74

38 Sagas (6) i ist nwendungsprogramm (vordefinierte ) Speicherung in DB vorteilhaft keine unkontrollierten Programme aktuelle Parameter für i aus DB automatische Recovery möglich! 75 Zusammenfassung (1) ransaktionskonzept (ID) hat sich durchgesetzt gut verstanden leistungsfähige Implementierungen Einsetzbarkeit über den DB-Bereich hinaus (Dateisysteme, Mail-Service,...) Geschlossen geschachtelte ransaktionen Unterstützung von Intra-ransaktionsparallelität feinere Rücksetzeinheiten v.a. in verteilten Systemen wichtig 76

39 Zusammenfassung (2) Mehrebenen-ransaktionen bbildungshierarchie von Objekten Reduzierung der Konfliktgefahr zwischen auf niedrigeren Ebenen durch vorzeitiges ommit (Freigabe von Änderungen/Sperren) von Sub- aber: Schutzschirm auf höherer Ebene Offen geschachtelte ransaktionen (z.b. Sagas) Unterstützung langlebiger ransaktionen Reduzierung der Konfliktgefahr durch vorzeitige Sperrfreigabe (erhöhte Inter-ransaktionsparallelität) Recovery durch Kompensation 77 usblick Entwurfs- -Konzept in Entwurfsanwendungen anwendungsbezogene Definition Nutzung von Semantik bei Synchronisation und Recovery Rücksetzen auf Binnen-Sicherungspunkte Nutzung von Versionen Ggf. Orientierung der Recovery und Synchronisation an W-Objekten Unterstützung der Kooperation zugeschnittene Verarbeitungsmodelle Workstation/Server-rchitektur Unterstützung von Gruppenarbeit (System-)Kontollierte Kooperation (Delegation von eilaufträgen, ustausch vorläufiger Entwurfsdaten, Verhandeln von Entwurfszielen) 78

40 bschließender Vergleich 79