Pessimistische Sperrverfahren für Transaktionen. Pessimistische Sperrverfahren für Transaktionen - Implementierung - von Oliver Lemm

Transkript

1 Pessimistische Sperrverfahren für Transaktionen - Implementierung - von Oliver Lemm Oliver Lemm Seite 1/24

2 I. Übersicht der Theorie I. Zusammenfassung der Theorie 2 Phasen Sperre in der Theorie & Deadlocks Zwei Versionen & hierarchische Sperren Zeitstempel-Verfahren Oliver Lemm Seite 2/24

3 Zwei-Phasen-Sperre Möglichkeit des nebenläufigen Zugriffs durch Sperren Sperren sorgen dafür, dass Transaktionen einen exklusiven Zugriff auf ein Objekt haben. Alle Transaktionen bestehen aus mindestens 2 Phasen 1. Wachstumsphase: Setzen der Sperren 2. Schrumpfungsphase: Freigabe der Sperren strenge Ausführung / strenge Zwei-Phasen-Sperre Hierbei muss eine Transaktion entweder fertiggestellt oder abgebrochen sein (keine dirty reads möglich) Granularität sollte kleinstmöglich sein Oliver Lemm Seite 3/24

4 Sperrtypen Viele Leser & Ein Schreiber Lese- & Schreibsperren Oliver Lemm Seite 4/24

5 Deadlocks Um nun bei Transaktionen diese Deadlocks darzustellen, werden sog. Wartegraphen benutzt. Deadlocks kann man daran erkennen, das sich Schleifen in diesem Graphen befinden Ist nun eine Schleife in einem solchen Graphen entdeckt, kann man anhand von Faktoren wie (Alter, Anzahl der Schleifen) entscheiden welche Transaktion nun abgebrochen werden muss Um Deadlocks aufheben kann man Timeouts verwenden Oliver Lemm Seite 5/24

6 Zwei-Versionen-Sperre Mehrere Transaktionen können auf einem Objekt arbeiten, da Sperren erst beim Festschreiben gesetzt werden Transaktionen müssen beim Festschreiben warten oder werden zurückgewiesen 3 Typen von Sperren existieren Lesesperre: Wird vor read-operation gesetzt Schreibsperre: Wird vor write Operation gesetzt Festschreibsperre: Versucht Schreibin Festschreibsp. umzuwandeln Oliver Lemm Seite 6/24

7 Hierarchische Sperren Bei diesem Sperrschemata werden Sperren mit unterschiedlicher Granularität versehen Es werden Operationen geschachtelt, so dass untergeordnete Operationen automatisch gesperrt werden falls die drüberliegende Operation gesperrt wird Dadurch wird die Anzahl der Sperren vermindert, da sie von der Größe her passend zur Operation sind Oliver Lemm Seite 7/24

8 Zeitstempel-Reihenfolge Jede Operation wird direkt ausgewertet oder abgebrochen Jede Transaktion bekommt einen Zeitstempel, mit welchem die Operationskonflikte gelöst werden Objekte können nur beschrieben oder gelesen werden, wenn sie von einer früheren Operation gelesen oder geschrieben wurden. Es gibt nur 1 Version und auch nur 1 Zugriff gleichzeitig, aber jede Transaktion besitzt eine eigene Versuchsversion write-operationen werden sofort ausgeführt, aber die read- Operation muss auf vorige Transaktionen warten Durch diese strenge Abfolge können keine Deadlocks auftreten Beim Festschreiben einer Transaktion werden Zeitstempel und Wert auf das Objekt übertragen Oliver Lemm Seite 8/24

9 Zeitstempel-Reihenfolge nach Bernstein (1980) Pessimistische Sperrverfahren für Transaktionen write-operationen werden in Versuchsversionen festgehalten, die für andere Transaktionen nicht sichtbar sind Jedes Objekt hat einen Lese- & Schreib-Zeitstempel und es können mehrere Versuchsversionen existieren, die auch jeweils Lese- oder Schreib-Zeitstempel besitzen. Um Daten nicht zu verlieren werden auch die Versuchsversionen permanent gespeichert Zeitstempel-Reihenfolge ist anfällig gegenüber Abstürzen & Neustarts Schreiben ist erfolgreich, wenn der Lese-Zeitstempel niedriger ist Oliver Lemm Seite 9/24

10 II. Übersicht der Implementierung II.Implementierung Art der Implementierung & Überblick der Klassen Transaktion und deren Verwaltung Sperren und Sperrverwaltung Objekte und Aktionen Oliver Lemm Seite 10/24

11 Art der Implementierung Programm ist lokal implementiert um bei Darstellung und Entwicklung weniger Fehleranfällig zu sein Die lokale Implementierung schränkt die zu erklärende Funktionsweise nicht ein Verwendung von Threads bei den Transaktionen Evtl. Verzögerung bei Transaktionen im Programm einstellbar Lokale Implementierung verbessert die Problemdarstellung durch Visualisierung aller Transaktionen an einem Rechner Oliver Lemm Seite 11/24

12 Struktur des Programms Package default Main, MainGUI, TimeCounter, Transaction, TransID Package actions Action, ActionOnLAObject Package objects Konto, LAObject, LockableObject Package locks Lock, Lockmanager, LockType Oliver Lemm Seite 12/24

13 Implementierung der Transaktionsverwaltung Zur Verwaltung der Transaktionen dient die Klasse Main.java als eine Art Transaktionsmanager Zum Erzeugen der Transaktionen steht die Methode maketransactions(int count) zur Verfügung Weiterhin werden die als Thread implementierten Transaktionen dort gestartet und durch die Methode addaction(int transnumber, Action action) können der jeweiligen Transaktion Aktionen hinzugefügt werden Über starttransaction(int transnumber) können die Threads gestartet werden Oliver Lemm Seite 13/24

14 Implementierung der Transaktionen Die Transaktionen bestehen aus der Transaktion (Transaction.java) selber und einer Transaktions-ID (TransID.java) Für das Hinzufügen von Aktionen steht die Methode addaction(action) zur Verfügung In der run-methode, überschrieben von der abgeleiteten Klasse Thread, werden alle Aktionen nacheinander durchgeführt Und zuletzt existiert als wichtige setter Methode noch setstartdelay(double startdelay) in der evtl. eine Verzögerung eingestellt werden kann Oliver Lemm Seite 14/24

15 Default Package Oliver Lemm Seite 15/24

16 Implementierung der Sperrverwaltung Die Verwaltung der Sperren ist in der Klasse LockManager.java organisiert und die Sperren liegen in einem HashTable Jedes Objekt dient dabei im Hashtable als Key und der Wert ist die Sperre selber Die Methode setlock(laobject, TransID, LockType) erzeugt entweder eine Sperre (wenn noch keine vorhanden) oder nimmt die auf dem Objekt vorhandene Sperre und fragt in beiden Fällen die Methode aquire(transid, LockType) der Klasse Lock an Die Methode unlock(transid) löst eine Sperre, indem sie diese Transaktion aus dem Vector holders der Sperre entfernt Oliver Lemm Seite 16/24

17 Implementierung der Sperren Die Sperren sind durch die Klasse Lock dargestellt und werden durch die Klasse LockType spezifiziert Bei Erstellung einer Sperre wird ein Vector holders erzeugt indem die Halter aller Sperren vorhanden sind Um eine Sperre zu setzen wird die Methode aquire angefragt, die entweder die Anfrage warten lässt (falls Sperre nicht setzbar) oder die entsprechende Sperre setzt und den Vector holders aktualisiert In der Methode lockgranted(locktype, TransID) wird überprüft ob die Sperre gesetzt werden kann Damit nur 1 Anfrage gleichzeitig bearbeitet wird ist die Methode synchronized Oliver Lemm Seite 17/24

18 Package locks Oliver Lemm Seite 18/24

19 Implementierung der Objekte Die Objekte sind im Package objects enthalten und implementieren das Interface LockableObject.java und die abstrakte Klasse LAObject.java Durch das Interface sind setter und getter für Name und Werte der Objekte vorgegeben Im implementierten Beispiel ist eine Klasse Konto.java erstellt worden, die von der Klasse LAObject.java abgeleitet wurde und das Interface LockableObject.java implementiert. Oliver Lemm Seite 19/24

20 Package objects Oliver Lemm Seite 20/24

21 Implementierung der Aktionen Die Aktionen (Action.java) sind ähnlich wie die Objekte, per Interface (ActionOnLAObject.java) in den getter und setter Methoden vordefiniert vordefiniert Die Aktion hat dabei als Parameter beim instanzieren ein Objekt, einen Aktionentype, eine evtl. Verzögerung und (wenn es ein schreibende Aktion ist) einen Änderungsfaktor mitbekommen Die Aktion wird je nach vordefinierten festen Werten ausgewählt und dann dementsprechend bei Aufruf der Methode makeaction() auf dem jeweiligen Objekt durchgeführt Oliver Lemm Seite 21/24

22 Package actions Oliver Lemm Seite 22/24

23 Weitere Implementierungsmöglichkeiten Durch die Objektstruktur ist es möglich sowohl andere Objekte (als nur Konten) als auch andere Arten von Sperren sowie einen anderen SperrenManager zu integrieren Dennoch muss beachtet werden, das sowohl die Zwei- Versionen Sperre als auch die Zeitstempel Methoden mit Versuchsversionen arbeiten und diese Funktion noch mitimplementiert werden muss Um eine realere Umgebung zu simulieren könnte man einerseits die Anforderung der Sperren verteilt implementieren oder andererseits Faktoren einbauen die einen Absturz oder ähnliche Problematiken simulieren Oliver Lemm Seite 23/24

24 Programmvorführung Vorstellung des Beispielprogramms Oliver Lemm Seite 24/24