überschreiben von Änderungen vermeiden

[Michael Schröpl]

Hi Lude,

genau für diesen Fall wurde das Konzept der Transaktionen in Datenbanksystemen erfunden.
ich kenne Transaktionen so, dass man mithilfe dieser sicherstellt, dass mehrere Aktionen entweder zusammen ausgefuehrt werden oder gar nicht.

nicht nur das. Insbesondere gewährt Dir eine Transaktion eben _auch_ eine konsistente Sicht auf die entsprechenden Tabellen, welche nicht durch andere Prozesse verändert wird.

Ausserdem sollten Transaktionen immer sehr schnell geschlossen werden, da diese sehr ressourcenfressend sind.

Richtig. (Rollback-Segmente etc. - gerade das Bereitstellen der konsistenten Datensicht kann bei parallelen Zugriffen auf diese Tabelle teuer werden.)

• Optimismus, d.h. wenn ein Datensatz mehrfach fuer Editierzwecke gelesen wird, gestattet man beim Zurueckschreiben einfach das jeweils alles ueberschrieben wird.

Eine Transaktion kann ein UPDATE-Statement mit einer WHERE-Klausel enthalten, welche sicherstellen soll, daß eben genau niemand vorher diesen Inhalt verändert.
Würdest Du 'zwischendurch' eine weitere Änderung des Inhaltes erlauben, dann würde dies die Semantik des SQL-Statements ändern (stell Dir vor, das Statement liest einen Zähler aus und erhöht ihn um 1 - in Deinem Modell würde die Zwischendurch-Änderung verloren gehen).

• Pessimismus, d.h. ein Locking verhindert, dass ein ausgecheckter Datensatz (unter http ist das Aus-Checken rein "logischer" Art) ein zweites mal fuer Editierzwecke geladen werden kann

Im Prinzip macht dies das RDMBS auch so, glaube ich. Es merkt sich, daß ein Prozeß eine Transaktion auf einer Tabelle offen hat, markiert die entsprechenden Blöcke und stellt sicher, daß von diesen on the fly eine Kopie hergestellt wird, sobald innerhalb der Transaktion darin Änderungen vorgenommen werden - denn andere, lesende Prozesse müssen zu diesem Zeitpunkt ja noch die vorherige Sicht auf diese Tabelle erhalten.

Erst bei Festschreiben der Transaktion werden die Änderungen aus in die eigentliche Tabelle übertragen, vermute ich - wie das genau implementiert ist, müßte man dem Quelltext des jeweiligen Tabellentreibers (im Falle von mySQL) entnehmen können (wobei die Standard-Tabellentreiber von mySQL gar keine Transaktionen unterstützen, aber z. B. der InnoDB-Treiber schon).

Ich vermute, es ist tatsächlich eine Mischung all Deiner Ideen - ein solcher Locking-Mechanismus ist zumindest erforderlich, um Kollisionen zu erkennen.
Tatsächlich wird es aber möglich sein, daß zwei Prozesse gleichzeitig eine Transaktion auf demselben Abschnitt derselben Tabelle durchführen - und wer zuerst committet, der gewinnt, während der andere seine Transaktion zurückgerollt bekommt und von vorne beginnen muß (das ist der "optimistische" Ansatz - denn so etwas sollte natürlich möglichst selten tatsächlich passieren).

Die Hauptsache ist, daß kein Statement unter falschen Voraussetzungen ausgeführt wird. Eine Garantie für den erfolgreichen Abschluß einer Transaktion gibt es nicht - aber wenn eine Transaktion tatsächlich festgeschrieben wurde, dann wurde sie auch unter den gewünschten Voraussetzungen ausgeführt. Wenn nicht, dann muß die Anwendung es eben noch einmal versuchen - oder was auch immer.

Ausserdem denkbar noch eine Revisionierung von Aenderungen mit spaeterer Konfliktaufloesung, was aber meist wegen grossen Aufwands nicht in Betracht gezogen wird.

Um eine Transaktion zurückzurollen, kann man entweder zuerst eine Kopie ziehen und diese später festschreiben, oder sofort festschreiben und Revisionsinformationen speichern - eines von beidem ist unvermeidlich, weil für parallele Transaktionen eine parallele Buchführung erforderlich ist.

Was von beidem wie gut funktioniert, hängt von der zu erwartenden Kollisionsrate ab.

Viele Grüße
      Michael