21
Distributed Systems (Subject) / Transactions (Lesson)
Advertisement
- Was sind die fundamentalen Eigenschaften bzw. Vorraussetzungen einer Transkation? ACID Atomicity ganz oder gar nicht ausgeführt (Complete or without impacts) Cosistency Consistency remains(Transformation between consistent states) Isolation Verhindern von gegenseitiger Beeinflussung (No overlapping of concurrent transaction executions) Durability dauerhafte Speicherung der Daten verhindert Datenverlust durch Abstürze (Survival of system failures due to persistent storage) Sie gelten als Voraussetzung für die Verlässlichkeit von Systemen.
- Was ist JDBC? Java Database Connectivity Programmier Interface um auf relationale Datenbanken zuzugreifen benutzt Datenbank-SQL Befehle Datenbankschnittstelle der Java-Plattform, die eine einheitliche Schnittstelle zu Datenbanken verschiedener Hersteller bietet und speziell auf relationale Datenbanken ausgerichtet ist.
- Was ist eine Transaktion? Als Transaktion werden eine Gruppe von logisch zusammenhängenden Datenbankoperationen wie beispielsweise SQL-Anweisungen bezeichnet. Bsp. „Das Buch ‚Die Schatzinsel‘ an den Benutzer Peter Müller ausleihen.“ Diese Transaktion könnte in der formalen Darstellung so aussehen: Anfang der Transaktiondas Feld „Vorbestellung“ der Karte lesen„Peter Müller“ in das Feld „ausgeliehen von“ schreiben„29. Juli 2001“ in das Feld „Rückgabe am“ schreibenEnde der Transaktion
- Warum benötzigt man das Two Phase Commit Protocol (2PC)? In verteilten Systemen erstreckt sich eine Transaktion häufig über mehrere Prozesse, die gemeinsam und voneinander abhängig Daten verändern. Zur Gewährleistung der Atomarität ist hier ein verteiltes Commit-Protokoll erforderlich.
- Was sind die Assumption beim 2-Phase Protocol? •Participants save relevant data before transaction so that the original consistent state can be reset if required •Transaction started: All required operations carried out but only on temporary copies of the data. •Operations can be carried out through RPC and RMI as well as through various local mechanisms on the individual participants
- Beschreibung der zwei Phasen des 2-Phase-Protcols? Erste Phase "Prepare"-Messages werden vom Koordinator zu den Participants gesendet Persistente Kopie der Daten mit den vorgenommen Änderungen und die vorherige Version werden gespeichert (Crash/Neustart) "Ready"-Messages werden von den Participants gesendet nachdem sie erfolgreich die neue Version gespeichert haben "Abort"-Messages werden gesendet, sofern dies nicht geklappt hat Zweite Phase Prüfe ob von allen Participants ein "Ready" ankam? -> Koordinator sendet Commit an Participants -> Alte Version der Daten wird durch neue Ersetzt -> Bestätigung an den Koordinator -> Transaktion erfolgreich beendet Prüfe ob von einem Participant ein "Abort" ankam? -> Koordinator erkennt einen Fehler -> Koordinator sendet "abort" an alle Participants -> Alte Version der Daten wird beibehalten -> Transkation abgebrochen
- Was ist ein bekanntes Problem bei der Phase des 2-Phase Protokoll und was ist die Lösung dagegen? Participant speichert Daten erfolgreich, sendet "Ready" , crashed dann aber (Stromausfall, Speicher voll etc.) Koordinator erkennt dies nicht, da "ready" bekommen und sendet an alle Teilnehmer den Commit Alle Participants führen den Commit aus, außer der defekte -> kein Rollback möglich Lösung: Der defekte Participant startet neu und findet einen Persistent Transaction Log vor, mit der alten und neuen Version der Daten Participant fragt seinen ehemaligen Koordinator (oder einen anderen Participant) wie das Ergebnis der Transaktion war. "Commit" oder "Abort"? Je nach Antwort führt dieser einen Rollback oder Rollforward durch, damit alles wieder konsistent bleibt
- Wie reagiert das Protokoll bei einem Versagen des Koordinators, nach senden der "Prepare" message? Es findet ein Timeout auf Seiten der Participants statt, nachdem diese "Ready" gesendet haben Koordinator wird neugestartet Koordinator recoverd den Transactionstatus und sendet erneut "Prepare" Participants antworten wieder Das selbe gilt für wenn ein Participant failed, aber noch kein "Ready" gesendet hat
- Sequenzdiagramm eines erfolgreichen Ablaufs des 2-Phase Models! Siehe Lösung
- Wozu dient Concurrency Control? Sichert die "Isolation" der Transaktionen
- Advertisement
- Erklärung von optimistic and pessimistic Currency Control! Pessimistic Man geht davon aus, dass es häufige Konflikte und kostenspieglige Rollbacks (undo of Transactions) gibt Locking wird ausgeführt -> Daten sind nur für eine bestimmte Transaktion reserviert, andere müssen warten, bis der Lock aufgehoben wurde Probleme : Deadlocks Optimistic Man geht davon aus, dass es kaum Konflikte und Rollbacks gibt Es werden keine Locks gesetzt, parallel processing of locked data allowed Extra Frage
- Durch welche Phasen läuft der optimistic Approach Concurrency? Work Phase Datenzugriff ohne Locks Read-Set –data objects involved in transaction Write-Set –changes made to the Read-Set Validation Phase Kontrolliert ob Read-Set inkonsistente Daten enthält, zB. durch eine andere Transaktion Ist dies der Fall wird die Transaktion abgrebrochen und die Änderungen rückgängig gemacht Securing Phase Write-Set wird an die Datenbank commited Passiert in einer Verteilten Transaktion durch das 2-Phasen Protokoll
- Wie lauten die zwei Algorithmen beim Pessimistic Concurrency Approach? Simple Two Phase Locking lock released as soon as access finished –higher concurrency Strict Two Phase Locking locks only released at end of transaction -lower concurrency
- Was bezeichnet man als Nested Transaction? Vor und Nachteile im Gegensatz zur simplen Transaktion? Eine Transaktion innerhalb einer weiteren Transaktion Vorteil: Teiltransaktionen können paralell bearbeitet werden, statt sequentiell Ermöglichen die Festlegung von Teilergebnissen von Transaktionen und damit ein feinkörniges Zurücksetzen im Falle eines Failures.
- Warum müssen bei verschachtelten verteilten Transaktionen die Locks abgeschlossener Teiltransaktionen bis zum Abschluss der gesamten umfassenden Transaktion bestehen bleiben? Es besteht weiterhin die Möglichkeit eines Rollback für abgeschlossene Teiltransaktionen, vielleicht aufgrund eines Fehlers in einer anderen Teiltransaktion, der ein Rollback der gesamten umfassenden Transaktion verursachen kann Wenn Locks nicht bis zum Abschluss der gesamten umfassenden Transaktion aufrechterhalten werden, könnten andere Transaktionen auf die Ergebnisse der abgeschlossenen Teiltransaktionen anderer verschachtelter Transaktionen zugreifen und diese Ergebnisse dann ebenfalls ändern. Wenn dann erfolgreich abgeschlossene Teiltransaktionen zurückgenommen werden müssen, kann dies zu einer Kaskade von Rücknahmen führen, was bedeutet, dass die Eigenschaft der Isolierung nicht erfüllt wird.
- Was ist ein Transaction Monitor? Eine Middleware um Verteilte Transaktionen zu unterstützen. Managed die Ausführung und Koordination von Transaktionen. Das Ganze wird mithilfe des 2-Phase Protokolles erreicht Führt commit und reset Befehle aus Mögliche Operationen: Local transactions Remote object calls Parallelization of remote transactions through threads Call of other Transaction Monitors Nested transactions
- Wie heißen die drei Komponenten der Open Group for Distributed Transaction Processing (DTP) ? Resource Managers Application Programmes Transaction Monitors
- Was ist die Aufgabe des Resource Managers RM? •Represents resources involved within a distributed transaction e.g. databases, print servers etc. •Executes local transactions on these resources •Coordinates conclusion of such transactions
- Was ist die Aufgabe des Application Programme (AP)? •Executes operations on various resources involved within a distributed transaction •Defines begin and end of transactions •Decides whether a transaction is concluded with a “commit” or “rollback”
- Was ist die Aufgabe des Communication Resource Manager (CRM)? •Represents services for the communication between components in different management domains of transaction monitors •Mediates calls and associated call data between application components
- Wie heißen die Befehle für den Transaction Manager? TX interface (between AP and TM) •tx_open, tx_close : connect to transaction manager •tx_begin, tx_rollback, tx_commit: demarcate transaction XA interface between TM and RM •xa_open, xa_close: initialization before any other call, termination after all other calls •xa_start, xa_end: associate subsequent calls with a transaction branch •xa_prepare, xa_commit, xa_rollback: classical two phase commit protocol •ax_reg:Register an RM with a TM. •ax_unreg: Unregister an RM with a TM.