nicht angemeldet
moin Sven,
vielen Dank für Dein Feedback!
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).
Gottseidank gehts in meinen Anwendungen nicht direkt um Geld ;-)
(IP - Adressverwaltung, Auftragsabwickelungen: Bearbeiten von Anträgen...)
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?
Jow - das ist wirklich ein Problem, evntl. im Intranet lösbar wo sich die user telefonisch oder durch Zuruf verständigen können...
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.
Programmiertechnisch ist das möglich, sowas einzubauen:
-userA und userB laden einen bestimmten Datenbestand
Ort=alter Ort, PLZ=alte PLZ
-userA macht Update mit:
Ort=neuer Ort, PLZ=neue PLZ
-userB will Update machen, er hat:
Ort=alter Ort, PLZ=neue PLZ
userB bekommt einen Hinweis dass die Daten geändert wurden und er bekommt angezeigt:
-die Änderungen die userA gemacht hat
+die Änderungen die erselbst einpflegen will
Somit kann userB entscheiden.... in meinen Anwednungen hab ich das wenigstens so gemacht, dass userB im Falle dass userA was geändert hat - sofort wieder in den *EditModus* kommt und die nunmehr aktuellen Daten sieht. Das ist recht einfach und hat sich bewährt, denn bereits hier kann userB sehen ob er überhaupt noch was machen muss.
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.
Die Idee ist wirklich gut, das ist die Grundlage für Rollbacks und in jedem RDBMS implementiert. Alternative für eigene Entwicklungen: RCS (Revision Control System).
Viele Grüße, Rolf
SELFforum - Das Tor zur Welt!
Theoretiker: Wie kommt das Kupfer in die Leitung?
Praktiker: Wie kommt der Strom in die Leitung?