Rollbacks und solche Dinge...

[Sven Rautenberg]

Moin!

lies Dir vielleicht das mal durch:
http://www.mysql.com/doc/en/LOCK_TABLES.html
http://www.mysql.com/doc/en/COMMIT.html

commit - ja denkst du ich bin vorhin auf diesen fuc* Begriff gekommen? Das isses! Vielen Dank, morgen klick ich mir deine Links....

Das Problem ist, dass diese Mechanismen das Problem nicht lösen.

Transaktionen sind dazu da, mehrere einzelne Operationen zu einer atomaren Operation zusammenzufassen - also beispielsweise, wenn man mehrere Tabellen mit mehreren UPDATES/INSERTS verändern muß, um beispielsweise eine Kontobuchung auszuführen (das Geld darf ja nicht mittendrin verloren gehen).

Und LOCKs sperren zwar die Tabelle für eine gewisse Zeit, damit ein einzelner Prozess daran arbeiten kann, aber auch nicht für immer.

Das Problem des gleichzeitigen Arbeitens an einer DB ist aber, dass zwei Arbeiter einen Datenbestand aus der DB auslesen und ausgehend von diesem Stand unterschiedliche Änderungen einspielen wollen - zeitlich versetzt.

Die zwei vorgestellten Mechanismen des Artikels sind in meinen Augen wirklich die einzigen Möglichkeiten, das zu regeln.

Also entweder einen Datensatz per Eintrag in diesen Datensatz für alle anderen Benutzer auch zum Lesen zu sperren (und damit erst recht zum Schreiben), oder mit Timestamp zu arbeiten, um den damals ausgelieferten Stand mit dem derzeit vorliegenden Stand zu vergleichen und den Konflikt erkennen zu können.

Das Locking hat den beschriebenen Nachteil: Wer löscht den Lock auf einen Datensatz?

Der Timestamp hat immerhin noch den Nachteil, dass der zweite Benutzer, der den Konflikt angezeigt kriegt, im Prinzip nur den neuen, geänderten Stand sowie seine Änderungen kennt, aber nicht mehr den alten Stand. Welche Daten läßt er dann überschreiben? Man müßte also irgendwie die Unterschiede feststellen.

Wenn User A die Postleitzahl geändert hat, und User B den Namen, wird das für User B irgendwie offensichtlich sein: Ihm wird der derzeitige DB-Eintrag gezeigt, bei dem sich PLZ und Name jeweils unterscheiden, er weiß noch, dass er den Namen geändert hat, also wird die PLZ von User A geändert worden sein - dann muß er das Update nur noch passend zusammensetzen.

Was aber, wenn beide die PLZ geändert haben? Bei identischer Änderung kein Problem - war zwar doppelte Arbeit, aber der Datensatz ist ja schon von User A geändert, User B ändert nichts mehr. Der Konflikt ist also keiner, weil der zu schreibende Datensatz dem bereits geschriebenen entspricht.

Wenn aber die Original-PLZ von A und B unterschiedlich geändert wurde, was ist dann korrekt? Das Original ist in der DB verloren, seit A gespeichert hat, und B sieht, dass seine PLZ mit der von A konkurriert. Der Konflikt ist unlösbar, ohne dass sich A und B verständigen, was denn nun passieren soll.

Bei so simplen Dingen wie einer Postleitzahl dürfte das Problem der Abstimmung noch gering sein, aber wenn beispielsweise Textpassagen geändert wurden, kann man das DB-Feld nicht mehr in seiner Gesamtheit betrachten, sondern muß Textanalyse betreiben, um herauszufinden, ob die Änderungen zu einem Konflikt führen. Das Tool "diff" könnte hierbei hilfreich sein, um zeilenweise Texte miteinander zu vergleichen und ggf. Änderungen, die an komplett unterschiedlichen Orten stattfinden (A ändert ganz oben, B ganz unten), automatisch zu einer neuen Version zusammenzuführen.

Eventuell ist es auch eine gute Idee, sämtliche ändernden Zugriffe auf die DB in ein Logfile oder eine Log-Tabelle zu schreiben. Damit könnte man im Notfall den vorherigen Zustand wiederherstellen. Beispielsweise könnte man alle UPDATEs und INSERTs dort direkt ablegen und ggf. einfach noch mal bis zu dem gewünschten Zeitpunkt auf die DB loslassen. Sowas dürfte aber ziemlich aufwendig sein.

- Sven Rautenberg