Erste Seite Zurück Weiter Letzte Seite Übersicht Grafik

Problem: Parallelität

Notizen:

Parallele Transaktionen
Wenn mehrere Transaktionen parallel laufen, die auf die selben Ressourcen (Tabellen[teile]) zugreifen, kann es im Fehlerfall Probleme geben:
Die Concurreny Control - Einheit eines DBMS ermöglicht mehreren Benutzern, eine DB gemeinsam zur selben Zeit zu benutzen, ohne ihre Konsistenz zu gefährden. Das traditionell verwendete Korrektheitskriterium ist dabei die „Serialisierbarkeit“ (besagt, dass das Ergebnis von parallel ausgeführten Transaktionen dem Ergebnis der hintereinander ausgeführten Transaktionen entspricht. Wir kommen darauf zurück). Um die Serialisierbarkeit von Transaktionen zu gewährleisten, verwenden DBMSe ein Sperrverfahren.
Benützt man aber „niedrigere“ Isolationsstufen, können bestimmte Parallelitätsfehler auftreten:
Wird im vorigen Beispiel die Transaktion A zurückgerollt, nachdem Transaktion B bereits den Kontostand von Konto A ausgelesen hat, kommt es zu inkonsistenten Daten.
Anm.: Beim "Zurückrollen" werden nicht die Befehle "verkehrt herum" abgearbeitet, sondern es wird einfach der Zustand wiederhergestellt, der vor Beginn der Befehlsausführung bestanden hatte.
Dieses Problem nennt man "dirty read" (uncommitted Daten können von anderen Transaktionen gelesen werden)
Non Repeatable Read
Eine Transaktion liest Daten 2x, wobei die Daten zwischen dem 1. und 2. Mal von einer anderen Transaktion verändert (und committed) wurden:
Die Transaktion liest 2x unterschiedliche Daten, obwohl derselbe Datensatz gelesen wird.
Phantom Read
Eine Transaktion wiederholt eine Suchabfrage, wobei beim 2. Mal eine andere Anzahl an Datensätzen zurückgegeben wird als beim ersten Mal.
Datensätze können bei der 2. Abfrage "aufgetaucht" und/oder verschwunden" sein (sog. "Phantom Records") weil eine parallel laufende Einfüge- oder Löschabfrage die Ergebnismenge zwischendurch verändert hat.