Sven Rautenberg: Satz sperren für Änderung

Beitrag lesen

Moin!

mmmh, recht umfangreich. Eigentlich hatte ich auf so was einfaches gehofft wie "read_for_update", und die DB kümmert sich.

Habe ich doch schon irgendwo gehört. Bei Oracle vielleicht?

Wenn mehrere Tabellen von einer Änderung betroffen sind, kann ich ja ein eigenes Projekt aufmachen ...

Dein Problem mit dem parallelen Bearbeiten von Datenbankdaten ist identisch zum parallelen Bearbeiten von Quelltexten.

Für Quelltexte gibt es diverse Versionskontrollsysteme (CVS, Subversion,...), und keines ist "einfach". Alle schlagen sich mit dem Problem herum, dass insbesondere das unterschiedliche Verändern der gleichen Programmzeile zu Konflikten führt, die irgendwie gelöst werden müssen.

Die Methode des Sperrens der Daten gegen Veränderung durch Dritte hilft im Konfliktfall genausowenig, wie die Methode des Zusammenführens und manuellen Bearbeitens.

Das Sperren hat das Problem festzustellen, wann die Sperre wieder entfernt werden kann. Wenn der Bearbeiter zwei Stunden Mittagspause macht (oder auch nur fünf Minuten an dem Datensatz sitzt), und während dieser Zeit muß ein anderer Bearbeiter einfach nur die Telefonnummer ändern, weil der Kunde gerade angerufen hat - und kann das nicht, weil der Datensatz gesperrt ist, dann wird ihn die Zurückweisung seiner Daten extrem nerven und von der Arbeit abhalten.

Das Zusammenführen der Änderungen (Merging) in der Form der Versionskontrollsysteme reduziert diese Konflikte auf die Fälle, in denen tatsächlich das gleiche Datenfeld zweimal in unterschiedlicher Form geändert wurde. Der als zweiter speichernde Bearbeiter hat dann zwar die u.U. schwierige Aufgabe, zu entscheiden, welche Änderung korrekt ist und überlebt, bzw. muß die Änderungen irgendwie zusammenführen (Hintereinanderhängen von zwei Kommentaren wäre ja denkbar), aber er wird solch eine Aktion deutlich seltener durchführen, als durch Sperren behindert werden.

Alternativ kannst du natürlich auch einfach nur die Sessiondauer begrenzen und nach Ablauf einer Zeitperiode das Formular als ungültig zurückweisen - blöd ist dann nur, wenn die Bearbeitung der Daten, Recherche etc., länger gedauert hat, und die Änderungen dadurch verloren gehen würden.

AJAX kann in diesem Zusammenhang übrigend helfen, das doch sehr starre Konzept des "submit complete form" aufzubrechen. Allerdings nicht ohne Preis: Eventbasiert den Client serverseitig von zwischenzeitlichen Änderungen in der Datenbank zu informieren funktioniert in HTTP natürlich auch mit AJAX noch nicht, es sind daher andauernde Requests zum Server notwendig, die entsprechend Performance kosten und natürlich auch hinreichend abgesichert sein müssen.

- Sven Rautenberg

--
"Love your nation - respect the others."