Übung: Transaktionale Systeme 31.05.2007

Organisatorisches Bewertung, Scheinkriterien: Projektzeitplan: 20% Übung: Mindestens einmal vorrechnen! Aktive Teilnahme! 55% Klausur Projektzeitplan: Projektteil C ist optional, relevant nur für Projektscheinerwerb mind. Benotung von 2,0 für Projektteile A, B Entwicklungsumgebung: Java, Eclipse Projektteil Start Abgabe Besprechung A 03.05.2007 24.05.2007 31.05.2007 B 21.06.2007 28.06.2007 (C) 19.07.2007 ---

Projekt: Überblick Ziel: Verteiltes transaktionales Reisebuchungssystem Eine Reise besteht aus Flügen, Hotels, Mietwagen Einzelne Leistungen werden bei verschiedenen Anbietern gebucht Client 1 Client 2 Client n …… ~ X/Open TX Workflow Controller Transaction Manager -RM manages shared resource -RM must be capable of rollback -RM eher abstraktes Konstrukt mit obigen Eigenschaften  z.B. transaktionales DBS oder unser Resource Manager ~ X/Open XA RM RM RM Flight Reservation Hotel Reservation Rental Car Reservation

X/Open DTP Modell

Häufig gemachte Fehler… Das Schattenspeicherkonzept wurde teilweise nicht richtig umgesetzt! Es wird (beim commit) stets nur in eine Datei auf Festplatte geschrieben. Was passiert, wenn ein Fehler bei diesem Schreibvorgang auftritt?  Zwei-Phasen-Schreiben notwendig (Codebeispiel) Beim Start einer Transaktion wird eine Kopie der Datenbasis erstellt. Startet eine weitere Transaktion wird diese Kopie wieder überschrieben. Es sind keine parallelen Transaktionen möglich! Gewünscht war, dass „Updates einer Transaktion auf einer Kopie der Datenbasis“ ausgeführt werden. Von welcher Datenbasis liest eine Transaktion während ihrer Ausführung? Aktuelle Datenbasis, Kopie, beides? Nicht für jede Kopie eine Datei auf Platte erstellen! Welche Eigenschaft sollte durch Schattenspeicher eigentlich erreicht werden?  Atomarität (alles oder nichts) Und zwar Atomarität auf zwei Ebenen (Hauptspeicher und Hintergrundspeicher) Wenn am Anfang Kopie der Datenbasis erstellt wird, so müßte eigentlich auf jedes Datum ein READ-Lock geholt werden! Schattenkopien im Hauptspeicher hauptsächlich dazu da, um einfaches Rücksetzen einer Transaktion gewährleisten zu können. Einige haben sogar eine Art Logging implementiert

Häufig gemachte Fehler… Synchronisation von Datenstrukturen vergessen: Datentyp HashMap ist nicht synchronisiert!  Der RM wird von mehreren Threads (evtl. originär von entferntem Rechner) gleichzeitig genutzt! Besser Hashtable oder ConcurrentHashMap benutzen Oder über einen Aufruf von Collections.synchronizedMap(new HashMap<K><V>()) eine threadsafe HashMap erstellen Das Umsetzen des Schattenspeicher-Pointers geschieht nicht atomar, bzw. ist nicht synchronisiert. Zwei Transaktionen versuchen eventuell in die gleiche Datei zu schreiben, so dass es bei einer evtl. Recovery zu Problemen kommt! Welche? (Codebeispiel)

Häufig gemachte Fehler… Synchronisation von Datenstrukturen vergessen: Verwendung des Schlüsselworts volatile bei Variablen wie shutdown, dieAfter/BeforePointerswitch. Warum sinnvoll? Inkrementieren des XID-Zählers muss atomar sein! synchronized-Block schöner: AtomicInteger.incrementAndSet() Es wird explizit beim Aufruf der Methode dieBefore/AfterPointerSwitch ein Flag gesetzt, ob eine Recovery notwendig ist: Die die…()-Methoden sind ja nur zur Simulation von Fehlern gedacht. Die Recovery muss auch funktionieren, wenn ein Fehler nicht angekündigt wird!

Häufig gemachte Fehler… Zustand der Transaktionen wird über einen Systemstart hinweg vergessen: Welche Probleme treten beim Neustart auf, wenn ein Systemabbruch (z.B. durch dieNow) auftrat, während mehrere Transaktionen noch aktiv waren?  Theoretisch könnte der Lockmanager noch Sperren der aktiven Transaktionen halten.  Wie reagiert der RM, wenn ein Klient eine Operation für eine ehemals aktive, dann aber vergessene Transaktion ausführen will?  Eindeutigkeit der XIDs ist nicht mehr gewährleistet, da vergessen wird, welche XIDs bereits vergeben wurden. Der XID-Zählerstand sollte persistiert werden.

Häufig gemachte Fehler… Shutdown-Flag wird zwar gesetzt, aber Shutdown wird nie ausgeführt: Thread in der shutdown()-Methode in einer Schleife schlafenlegen und warten bis keine Transaktion mehr aktiv ist. besser mit Thread.yield() Schöner: Bei jedem Commit/Abort überprüfen, ob gerade die letzte aktive Transaktion fertig geworden ist und dann ggf. System.exit() aufrufen. In einem Fehlerfall (Deadlock, IOException) nicht ein System.exit() aufrufen! Bei erkanntem Deadlock soll die Transaktion zurückgesetzt werden!

Häufig gemachte Fehler… Es wird zu grob-granular gesperrt: Sperre wird über einen Aufruf lock(<xid>,<location>, LockManager.READ) angefordert.  Konsequenz: Komplette Tabelle ist gesperrt.  Und mehr noch: Eventuell sind sogar mehrere Tabellen gesperrt! Einfach auf „<tablename>:<key>“ sperren… Aufwendiges Klonen von Objekten: Wenn shallow-copy ausreichend, dann reicht die Implementierung des Markerinterfaces Cloneable und ein Aufruf von super.clone() in der clone()- Methode. (Codebeispiel) Unterschied shallow-copy / deep-copy?

Projekt: Teil A Schritt 2: Atomarität Gewährleistet durch Schattenspeicherkonzept Führe die Updates einer Transaktion auf einer Kopie der Datenbasis aus z.B. separate Hashtabellen Bei commit:  Bringe Updates in die eigentliche Datenbasis (im Speicher) ein.  Schreibe Datenbasis in separate Datei auf Hintergrundspeicher. (stetiger Wechsel zwischen zwei Dateien)  In atomarem Schritt ändere globalen Zeiger so, dass die neue Datei als aktive Datenbasis markiert ist Bei abort:  Verwerfe die separaten Hashtabellen (im Speicher) Shadowspeicher (Originalliteratur) http://www-depreciated.inf.fu-berlin.de/lehre/WS06/DBS-Tech/Reader/shadowStorage.pdf

Projekt: Teil A Schritt 3: Isolation Implementierung von 2PL (rigoros) mithilfe des Lock Managers für jede Operation auf RM Lese- oder Schreibsperre anfordern bei commit/abort alle Lese-/Schreibsperren aufgeben Granularität der Locks so fein wie möglich für eine Operation maximale Parallelität möglichst keine Table-Locks Lock Manager erkennt Deadlocks durch Timeouts DeadLockException betroffene Transaktion abbrechen (abort)

Projekt: Teil A Schritt 4: Dauerhaftigkeit Persistenz und Recovery Zustand des Resource Managers auf Hintergrundspeicher schreiben: aktive Datenbasis Zustand von Transaktionen (start, commit, abort) XIDs Zeiger auf aktive Datenbasis Recovery, falls RM nicht korrekt heruntergefahren wurde (dieNow(), dieBeforePointerSwitch(), dieAfterPointerSwitch()) Welche Transaktionen waren vor Absturz bekannt? Welchen Zustand hatten diese Transaktionen?

Projekt: Teil A Test-Schnittstelle: shutdown():  warten, bis alle Transaktionen beendet sind  keine neuen zulassen  „korrekten“ Zustand hinterlassen, so dass keine Recovery beim nächsten Start notwendig ist dieNow(): sofortiges System.exit(); dieAfter/BeforePointerSwitch():  setze Flag, so dass System.exit() während der nächsten Commit-Operation aufgerufen wird direkt vor bzw. direkt nach dem Ändern des Zeigers auf aktive Datenbasis