Hallo,
Zitat:
Wie parallele Transaktionen sich auswirken hängt maßgeblich davon ab, wie die WHERE-Klausel des UPDATE-Statements aufgebaut wird.
Einspruch, Euer Ehren
Wir reden hier von Interbase/Firebird.
Da spielt die MGA schon eine größere Rolle (Multi-Generationen-Architektur).
Sch... wetware, da hat sich doch ein Hintergrundprozess in dem Problem verbissen und mußte mich unbedingt mitten in der Nacht wecken, um mir das Ergebnis mitzuteilen. Und jetzt kann ich nicht mehr einschlafen
...
Der Einspruch wurde abgewiesen, allerdings mit der Maßgabe, das es von der Interpretation des Wortes "parallel" abhängt, was denn da relevant ist. Redet man von
zeitlich verschachtelten Transaktionen, (A führt ein Update aus, B tut das gleiche für den gleichen Datensatz bevor A committed ist) ist der Einwand richtig. Diese Art der Kollision kann der Server detektieren und abweisen.
Mir ging es aber mehr um Transaktionen, die zwar den gleichen Datensatz verändern, aber zeitlich soweit getrennt sind, das A bereits committed ist wenn B ausgeführt wird. Das ist ein wesentlich praxisnäheres Scenario. In diesem Scenario kann der Server die Kollision nicht detektieren, da bei Ausführen des Updates von B keine offene Transaktion für den gleichen Datensatz mehr existiert. Selbst wenn er feststellt, dass er mehr als eine Version des Datensatzes in "Generationen" hat, die noch nicht mit der Master-Version der Tabelle gemerged wurden, kann er deswegen das Update nicht abweisen, dann könnte man ja einen Datensatz nicht wieder editieren, bevor dieser Abgleich durchgeführt wurde. Das wäre ein nicht akzeptables Verhalten aus der Sicht des Benutzers.
Nein, der Server kann das Kollisionsproblem nur teilweise lösen, wirklich lösen kann es nur der Programmierer bzw.
DB designer, in dem er sich des Problems bewusst ist und entsprechende Vorkehrungen trifft, mit denen ein Client sicherstellen kann, das er einen Datensatz nur verändert, wenn er noch in dem Zustand ist, in dem er gelesen wurde.
So, vielleicht kann ich jetzt wieder einschlafen...