Konsistenz und Mehrbenutzerbetrieb - Relationale Datenbanken und SQL - page 245

1) A hat S-Lock gesetzt:

B kann ebenfalls ein S-Lock setzen und den Zugriff ausführen.

B kann kein X-Lock setzen. Der beabsichtigte Zugriff kann nicht ausgeführt
werden.
2) A hat ein X-Lock gesetzt:

B kann weder ein S-Lock noch ein X-Lock auf dasselbe Objekt setzen.

Beide Typen von Sperren werden jeweils am Ende der Transaktion, in der sie ange-
fordert worden sind, gelöscht - im Allgemeinen also durch COMMIT oder ROLLBACK .
Aber auch jede andere Art der Beendigung ( LOGOUT , EXIT , Systemabsturz etc.) von
Transaktionen sollte gesetzte Sperren aufheben, wenngleich dies nicht bei allen
SQL-Implementierungen der Fall ist.

Die Lösung schafft neue Probleme
Betrachten wir die oben geschilderten Problemfälle noch einmal. Im ersten Beispiel
löst das Lesen eines Tupels der Tabelle kunde durch Prozess 1 ein S-Lock aus. Pro-
zess 2 kann ebenfalls das Tupel lesen und setzt gleichfalls ein S-Lock. Nun will Pro-
zess 1 den geänderten Satz zurückschreiben, fordert also ein X-Lock an. Dies kann
nicht gewährt werden, da Prozess 2 ein S-Lock hält, Prozess 1 muss also warten. In
derselben Lage befindet sich aber auch Prozess 2. Auch hier ist kein X-Lock mehr
möglich, da Prozess 1 das S-Lock hält. Beide Transaktionen warten also wechsel-
seitig aufeinander, keine kann mit COMMIT beendet werden. Zwar ist nun das Lost-
Update-Problem umgangen, aber ein neues Problem geschaffen: das so genannte
»Deadlock«. Dazu im Folgenden mehr.

Auch im zweiten Fall reicht das implizite Setzen eines S-Locks durch die lesende
Transaktion A nicht unbedingt aus. Zwar kann während des Lesevorgangs keine
Änderung durch B erfolgen, denn diese würde ein X-Lock erfordern. Aber in der
Pause zwischen den beiden Abfragen ist das S-Lock von A aufgehoben und B kann
aktiv werden. Hier dürfte aber zwischen zwei Lesevorgängen keine Veränderung
der Daten erfolgen, damit die Analyse konsistent bleibt. Außerdem erfordert die-
ser Fall, dass die Sperrung auf die gesamte Tabelle wirkt und nicht nur auf ein-
zelne Tupel, die gerade bearbeitet werden.

Zusätzliche explizite Sperrmöglichkeiten sind notwendig
Es bedarf also in der Praxis zusätzlicher Möglichkeiten, um auf die Sperrung Ein-
fluss zu nehmen.

In Situation 1 (»lost update«) müsste jede der beteiligten Transaktionen bereits
beim Lesen vorsorglich eine exklusive Sperre für die betreffende Zeile anfordern. B
würde dann schon vor dem Lesevorgang in den Wartezustand gesetzt und könnte
erst dann fortfahren, wenn A mit COMMIT die Transaktion beendet hat. Diese vor-
sorgliche Sperre muss im Allgemeinen aber explizit durch den Benutzer oder das
Anwendungsprogramm erfolgen, da das DBMS bei einem Lesevorgang innerhalb