Pessimistische Sperrverfahren für Transaktionen
Werbung
Pessimistische Sperrverfahren für Transaktionen Pessimistische Sperrverfahren für Transaktionen Implementierung von Oliver Lemm Oliver Lemm Seite 1/24 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen Sperrtypen ● Viele Leser & Ein Schreiber ● Lese- & Schreibsperren Oliver Lemm Seite 4/24 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 readOperation 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen Zeitstempel-Reihenfolge nach Bernstein (1980) ➔ ➔ ➔ ➔ ➔ 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen Struktur des Programms ● Package „default“ ➔ ● Package „actions“ ➔ ● Action, ActionOnLAObject Package „objects“ ➔ ● Main, MainGUI, TimeCounter, Transaction, TransID Konto, LAObject, LockableObject Package „locks“ ➔ Lock, Lockmanager, LockType Oliver Lemm Seite 12/24 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen Default Package Oliver Lemm Seite 15/24 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen Package locks Oliver Lemm Seite 18/24 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen Package objects Oliver Lemm Seite 20/24 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen Package actions Oliver Lemm Seite 22/24 14.12.2004 Pessimistische Sperrverfahren für Transaktionen 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 ZweiVersionen 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 14.12.2004 Pessimistische Sperrverfahren für Transaktionen Programmvorführung Vorstellung des Beispielprogramms Oliver Lemm Seite 24/24 14.12.2004
