Implementierung von S2PL (1) Scheduler als Verwalter von Sperren auf Datenelementen sowie Warteschlangen für Sperren (Sperren-Verwalter). Transaktion 1Transaktion.

Slides:



Advertisements
Ähnliche Präsentationen
Mehrbenutzersynchronisation
Advertisements

Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
7.3 Scheduling Zur Erinnerung:
Rücksetzen Bisher betrachtetes Scheduling gewährleistet Isolation, d.h. Serialisierbarkeit, setzt jedoch voraus, dass Transaktionen abgebrochen und rückgesetzt.
Relationentheorie AIFB SS Transitive (funktionale) Abhängigkeiten Transitive (funktionale) Abhängigkeiten (1|3) Geg.: r: (U | F); A,
Apriori-Algorithmus zur Entdeckung von Assoziationsregeln
Granularity of Locks and Degrees of Consistency in a Shared Data Base
C Tutorium – Semaphoren –
Transaktionsverwaltung
Transaktionsverwaltung
© A. Kemper / A. Eickler1 Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt.
Kapitel 5. Stacks und Queues
Synonyme: Stapel, Keller, LIFO-Liste usw.
Vs61 6 Verteilte Datenverwaltung. vs62 Ziel:Zusammengehöriger Datenbestand soll über mehrere Stationen verteilt werden, z.B. Fragmentierung: in mehrere.
1 Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt werden R1-Recovery.
Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
1 Fehlerbehandlung (Recovery) 1.Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt werden R1-Recovery.
Kapitel 5: Transaktionsverwaltung
Time-triggered E Sensor- eingaben P Programm A Ausgabe Aktorik.
Union-Find-Strukturen
Gottfried Vossen 5. Auflage 2008 Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme Kapitel 22: Grundlagen der Crash Recovery.
Prof. Dr. T. Kudraß1 Concurrency Control. Prof. Dr. T. Kudraß2 Korrektheitskriterium: Serialisierbarkeit Zwei Schedules sind konfliktäquivalent wenn gilt:
Kapitel 13: Mehrbenutzersynchronisation
1 Kapitel 12: Transaktionsverwaltung Oliver Vornberger Fachbereich Mathematik/Informatik Universität Osnabrück Osnabrück
1 Kapitel 12: Transaktionsverwaltung. 2 Transaktion Bündelung mehrerer Datenbankoperationen Mehrbenutzersynchronisation Recovery.
Universität Karlsruhe (TH) © 2008 Univ,Karlsruhe, IPD, Prof. LockemannDBI 7 Kapitel 7 Zugriffsschicht: Zuverlässigkeit.
Recovery AIFB SS Recovery 5.1 Fehler im Datenbankbetrieb(1/10) (1)Transaktionsfehler (TF) (2)Systemfehler (SF) (3)Speicherfehler (SpF) Fehlerfallen.
Synchronisation paralleler Transaktionen AIFB SS Synchronisationsverfahren 4.4 Synchronisationsverfahren (1/18) Sperrmodi und Sperrobjekte Sperrprotokoll.
ausdrucksschwächeres
Transaktion 1Transaktion 2... Transaktion n Synchronisation durch Scheduler Datenbasis-Verwalter lokaler Schedule 1lokaler Schedule n konfliktserialisierbarer.
Recovery AIFB SS Einbringstrategie der Pufferverwaltung(1/4) Die bestimmt, wann geänderte Seiten in die Datenbank eingebracht werden. Sie.
Verklemmungen Bei sperrenbasierter Synchronisation können sogenannte Verklemmungen (engl. deadlocks) auftreten, in denen Transaktionen sich gegenseitig.
Recovery AIFB SS (1/8) Sicherungspunkte (Checkpoints) (1/8) (1) Transaktions-Orientierte Sicherungspunkte Transaction-Oriented Checkpoint.
Ausführungsmodell Zustandsübergang einer Transaktion aus Nutzersicht:
Modellierung von Transaktionen Zur Formalisierung der ACID-Garantien muss Verhalten von Transaktionen modelliert werden. Folge aus der Forderung nach lokaler.
ANALYSE UND KONZEPTION VON TUPLE SPACES IM HINBLICK AUF SKALIERBARKEIT Philipp Obreiter Telecooperation Office (TecO) Universitaet Karlsruhe Betreuer:
Gottfried Vossen 5. Auflage 2008 Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme Kapitel 21: Concurrency Control.
Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme
Globale Transaktions-Verwaltung
Mehrbenutzersynchronisation
WS 2012/13 Datenbanksysteme Mi 15:15 – 16:45 R Vorlesung #11 Transaktionsverwaltung.
WS 2011/12 Datenbanksysteme Mi 15:15 – 16:45 R Vorlesung #10 Transaktionsverwaltung.
WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #7 Mehrbenutzersynchronisation (Teil 1)
Synchronisation paralleler Transaktionen AIFB SS Serialisierbarkeitsprinzip 4.3 Serialisierbarkeitsprinzip (11/13) Vermutung: Eine Schedule S.
Festschreibe-Protokoll (1) Globales Zwei-Phasen-Festschreibe-Protokoll (2- Phasen-Commit, 2PC): Phase 1: –Koordinator benachrichtigt Ressourcen, dass Commit.
Transaktion Huang Zhenhao FU Shuai.
Vorlesung #12 Mehrbenutzersynchronisation
Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München.
Lokales 2-Phasen-Festschreibe- Protokoll Segment-Verwalter führt commit(T i ) in zwei Phasen aus: Phase 1: Sicherstellung der Wiederholbarkeit. –Für jedes.
Übung: Transaktionale Systeme
Vorlesung Automatisierungsprojekte Seite 6/1
Mehrbenutzerzugriff auf GIS-Daten
Mehrbenutzersynchronisation
Prüfung auf Serialisierbarkeit (3)
Transaktionsverwaltung
Wiederanlauf nach Systemzusammenbruch Aufgabe: Bei Noforce-Strategie Wiederholung aller noch nicht in die Datenbasis eingebrachten Änderungen bereits abgeschlossener.
Synchronisation paralleler Transaktionen  AIFB SS Sperrverfahren Sperrverfahren (13/18) Behandlung von Konflikten bei der Sperrvergabe.
Gottfried Vossen 5. Auflage 2008 Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme Kapitel 23: Verteilte Transaktionsverarbeitung.
Sicherung gegen Medienverlust (1) Medienverlust = Verlust der Datenbasis und/oder des Protokolls. Vorbeugung durch periodische Sicherung von Datenbasis.
Synchronisation mit Zeitmarken (1) Zeitmarken-Synchronisation = einfaches, aber ineffizientes Verfahren zur Gewinnung konfliktserialisierbarer Schedules.
unpin(a,b,c) flush(a,b,c)
Serialisierbarkeitsprinzip Isolationsprinzip scheint zunächst streng serielle Abwicklung der Transaktionen zu fordern: r 1 (x) r 1 (y)... w 1 (z) c 1 r.
Spezifikation der Module / Programme
Synchronisation paralleler Transaktionen  AIFB SS Synchronisationsverfahren 4.4 Synchronisationsverfahren (1/3) Typen von Synchronisationsverfahren.
Vs51 5 Verteilte Datenverwaltung. vs52 Situation:Zusammengehöriger Datenbestand ist über mehrere Stationen verteilt, z.B. Fragmentierung: in mehrere Fragmente.
Vs Verteilte Transaktionen Situation:Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z.B. verteilte Datenbank, verteiltes Dateisystem,...)
6.3 Verteilte Transaktionen
Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1.Lese den Kontostand von A in die Variable a: read(A,a); 2.Reduziere.
WS 2013/14 Datenbanksysteme Do 17:00 – 18:30 R Vorlesung #12 Mehrbenutzersynchronisation.
6.3 Verteilte Transaktionen
 Präsentation transkript:

Implementierung von S2PL (1) Scheduler als Verwalter von Sperren auf Datenelementen sowie Warteschlangen für Sperren (Sperren-Verwalter). Transaktion 1Transaktion 2... Transaktion n Scheduler Datenbasis-Verwalter Schedule 1Schedule n Globaler Schedule Sperren-Verwalter Warte- schlangen

Implementierung von S2PL (2) Synchronisations-Algorithmus: –Warte auf nächste Operationsanforderung op. –Falls op = r i (x), frage Sperren-Verwalter, ob andere Transaktion bereits exclusive-Sperre auf x besitzt. Wenn nein, fordere shared-Sperre an. Sonst: Sobald Sperre verfügbar ist, führe Operation aus. –Falls op = w i (x), frage Sperren-Verwalter, ob Transaktion i bereits share-Sperre auf x oder keine andere Transaktion eine Sperre auf x besitzt. Wenn ja, fordere exclusive-Sperre an. Sonst: Sobald Sperre verfügbar ist, führe Operation aus. –Falls op = c i, veranlasse Festschreiben aller von Transaktion i vorgenommen DB-Änderungen durch DB-Verwalter, anschließend gebe alle Sperren von Transaktion i frei. –Falls op = a i, veranlasse Rücksetzen aller von Transaktion i vorgenommen DB-Änderungen durch DB-Verwalter, anschließend gebe alle Sperren von Transaktion i frei.

Implementierung von S2PL (3) Sperren-Vergabe-Algorithmus des Sperren- Managers: Verwalte (zumindest konzeptuell) Warteschlange für jedes Datenelement x, welche die aktuellen Inhaber von Sperren auf x gefolgt von den auf Sperren für x wartenden Transaktionen enthält. Falls keine Sperren auf x vergeben sind, ist Warteschlange leer. ST1T1 ST2T2 XT3T3 ST4T4 XT5T5 ST6T6 x Aktuelle Sperreninhaber

Implementierung von S2PL (4) Strategien zur Behandlung einer Sperranforderung für x: –Fair: Einreihung stets am Ende der Warteschlange. –Bevorzugung Leser: Bei Anforderung einer shared- Sperre Einreihung vor allen wartenden Schreibern. Bei Anforderung einer exclusive-Sperre Einreihung am Ende. –Bevorzugung Schreiber: Bei Anforderung einer exclusive-Sperre Einreihung direkt hinter letztem Schreiber bzw. letztem aktiven Leser. Bei Anforderung einer shared-Sperre Einreihung am Ende. –In jedem Fall: direkte Vergabe, falls shared-Sperre gefordert wurde und alle Vorgänger Leser sind oder falls exclusive-Sperre gefordert wurde und keine Vorgänger vorhanden sind.