Beispiel

Eine Kette von Vorverkaufsstellen speichert für jede Veranstaltung die Anzahl der verkauften Karten. Es wurden bereits 100 Karten verkauft, als an einer Kasse fünf Karten zurückgegeben werden. Zur gleichen Zeit werden an einer zweiten Kasse drei Karten gekauft. Das System der ersten Kasse zieht die 5 zurückgegebenen Karten von den 100 ab und schreibt den neuen Wert (95) wieder in die Datenbank. Das zweite Kassensystem addiert die drei soeben verkauften Karten zu der 100 dazu und schreibt diesen Wert (103) ebenfalls in die Datenbank. Der zuerst geschriebene Wert geht dabei verloren, das Endergebnis ist falsch (103 verkaufte Karten, obwohl es tatsächlich nur 98 sind).

Methoden zur Umgehung des Problems

Bei der Ausführung des Lesezugriffs wird die gemeinsam genutzte Information gesperrt, damit eine zwischenzeitliche Änderung durch ein anderes Programm nicht möglich ist.

Die dafür benötigten Sperrmechanismen werden von den verschiedenen Datenverwaltungssystemen bereitgestellt:

• der Share-Lock ermöglicht beliebig vielen Transaktionen einen Lesezugriff.
• der Exclusive-Lock ermöglicht nur einer einzigen Transaktion einen schreibenden Zugriff. In dieser Zeit darf keine andere Transaktion die gesperrten Daten lesen.

Diese Sperrmechanismen werden sowohl von den meisten Betriebssystemen und Datenbanken, als auch von Buffer-Managern verwendet, um konkurrierende Zugriffe zu handhaben.

Der Isolationlevel RR

Oft wird der Isolationslevel RR (Repeatable Read) als Lösung des Lost-Update-Problems genannt.

Die meisten RDBMS bieten verschiedene Isolationlevel an. Repeatable Read bedeutet, dass ein Share-Lock bis zum Ende einer Transaktion bestehen bleibt und nicht direkt nach dem Lesezugriff wieder verschwindet.

Wenn man den Isolationlevel RR verwendet, so muss man darauf achten, dass keine Deadlocks entstehen.

Das erste Programm schreibt einen Share-Lock, der nicht wieder entfernt wird. Das zweite Programm schreibt auch einen Share-Lock. Nun will das erste Programm den Share-Lock in einen Exclusive-Lock umwandeln, doch das geht nicht, solange das zweite Programm noch seinen Share-Lock aufrechterhält. Etwas später will das zweite Programm ebenfalls seinen Share-Lock in einen Exclusive-Lock umwandeln. Nun wartet jeder auf den anderen. Das ist die klassische Deadlock-Situation.

Nun kommt es darauf an, wie das RDBMS in so einem Fall reagiert. Einige RDBMS – z. B. DB2 – kann man so parametrisieren, dass eine Transaktion nur eine bestimmte Zeit auf gesperrte Ressourcen wartet. Sobald diese Zeit verstrichen und die Ressource immer noch gesperrt ist, wird die Transaktion zurückgerollt und das Programm erhält eine Fehlermeldung (SQLCODE −911). Das wäre eine Lösung für das Problem, denn durch den Rollback der ersten Transaktion ist auch der Share-Lock entfernt worden und die zweite Transaktion bekommt nun den Exclusive-Lock, auf den sie gewartet hat. Wenn im Programm der SQLCODE −911 gezielt abgefragt wird, dann kann das Programm in einem solchen Fall den Satz erneut lesen und erhält nun den Wert, den das andere Programm gerade geschrieben hat. So geht kein Update verloren.

Der zweite Versuch kann genauso wie der erste Versuch misslingen, falls inzwischen ein drittes Programm einen Share-Lock auf den Satz gelegt hat. Daher muss das Lesen und Schreiben im Programm in einer Schleife ausgeführt werden.

Nun kann man sich überlegen, ob die Schleife beliebig oft wiederholt werden soll, oder ob nach n Versuchen die Verarbeitung dann doch aufgegeben und mit einer Fehlermeldung beendet werden soll.

  Schleife
     Select ...
     Neuen Wert berechnen
     Update ...
     if (sqlcode not in (0, −911)) return(FEHLER)
  Until (sqlcode = 0 or Anz_Schleifen_Durchlaeufe > n)
  if (sqlcode <> 0) return(FEHLER)

Falls das RDBMS im Fall eines Deadlock so lange wartet, bis ein Administrator eingreift, dann ist diese Variante keine gute Lösung.

Verarbeitung serialisieren

Wenn das erste Programm die Information schon gleich beim Lese-Zugriff exklusiv sperrt, dann muss das zweite Programm schon mit seinem Lesezugriff warten. Sobald das erste Programm auch den Schreibzugriff ausgeführt hat und die Ressource wieder freigibt, kann das zweite Programm seine Verarbeitung fortsetzen. Diese Variante ist eine erzwungene Serialisierung der Verarbeitung.

Wenn die Information in einer Datei gespeichert wird, muss das Programm die Datei gleich zum Schreiben öffnen.

Wenn die Information in einer Datenbank-Tabelle gespeichert wird, dann kann der Satz z. B. durch einen CURSOR FOR UPDATE gelesen werden, oder die gesamte Tabelle kann durch LOCK TABLE IN EXCLUSIVE MODE gesperrt werden.

Lese- und Schreibzugriff atomisieren

Wenn zwischen dem Lesezugriff und dem Schreibzugriff keine weitere Verarbeitung erforderlich ist, kann man diese beiden Zugriffe auch zusammenfassen (Siehe Atomare Operation).

Bei einem RDBMS könnte der Zugriff für das Beispiel lauten:

  update Tab
  set Anzahl_verkaufte_Karten = Anzahl_verkaufte_Karten + :Aktueller_Verkauf

Dadurch entfällt ein gesonderter Lese-Zugriff. Ein verlorenes Update kann nicht mehr vorkommen.