Databases Reference
In-Depth Information
derlich wäre. Dies ist durch eine besondere Anweisung möglich, die die zu
ändernden Datensätze reserviert. Sie sieht wie folgt aus:
SELECT spaltenliste
FROM tabellenausdruck
[WHERE bedingung]
FOR UPDATE OF spaltenliste
Das Phänomen
dirty read
wird übrigens bei ORACLE dadurch umgangen, dass alle
Lesevorgänge auf die Before-Image-Datei umgeleitet werden, soweit sie Daten
betreffen, die von gerade laufenden Transaktionen verändert werden.
7.1.7 Deadlock
Wenn mehrere Transaktionen wechselseitig auf die Freigabe von Ressourcen war-
ten, spricht man von einer
Verklemmung
oder einem
Deadlock
. Wir haben bereits
oben ein Beispiel für ein Deadlock erwähnt. Es kommt dadurch zustande, dass
(mindestens zwei) Transaktionen zyklisch jeweils auf die Freigabe einer Ressource
durch eine andere warten, um selbst mit
COMMIT
abschließen zu können. Da aber
erst mit
COMMIT
oder
ROLLBACK
die gesetzten Sperren aufgehoben werden, liegt ein
Widerspruch vor, der nur durch Abbruch einer der beteiligten Transaktionen auf-
gehoben werden kann. Eine ebenso typische Situation zeigt folgendes Szenario, bei
dem zwei Tabellen betroffen sind:
Prozess A
Prozess B
LOCK TABLE kunde
IN EXCLUSIVE MODE;
LOCK TABLE auftrag
IN EXCLUSIVE MODE;
...
...
LOCK TABLE auftrag
LOCK TABLE kunde
Prozess A muss auf die Freigabe von
auftrag
warten, während B auf die Freigabe
von
kunde
durch A warten muss. Beide Transaktionen versperren sich gegenseitig
den Zugriff auf Ressourcen.
Automatische Deadlock-Behandlung
Es gehört zu den Aufgaben eines DBMS, solche Deadlock-Situationen zu erkennen
und einige Sperren zu löschen, damit wenigstens eine der Transaktionen abge-
schlossen werden kann. Das Mindeste ist ein automatisches Rollback gegen eine
der beteiligten Transaktionen und eine entsprechende Mitteilung an den Benutzer
bzw. das Anwendungsprogramm. Von diesem Rollback sollte nach Möglichkeit
diejenige Transaktion betroffen sein, die noch am wenigsten fortgeschritten, also
am leichtesten zu wiederholen ist.
