FACHWISSEN · TECHNIK & PROZESSEINSIGHTS · TECHNOLOGY & PROCESSES
Gleichzeitige Änderungen: Wie eine Versionsprüfung verlorene Aktualisierungen verhindertConcurrent changes: How version checks prevent lost updates
Zwei Abläufe lesen denselben Datensatz. Der erste ergänzt einen Lieferhinweis, der zweite ändert die Zuständigkeit. Speichern beide anschließend jeweils ihren vollständigen alten Datenstand, kann die spätere Speicherung die frühere Änderung überschreiben. Beide Aufrufe können dabei technisch erfolgreich erscheinen.
Lesen ist noch keine Reservierung
Optimistische Nebenläufigkeitskontrolle erlaubt parallele Bearbeitung und prüft erst beim Schreiben, ob die gelesene Version noch aktuell ist. Bei HTTP kann ein starker ETag zusammen mit einer If-Match-Bedingung solche verlorenen Aktualisierungen verhindern. Ist die Bedingung nicht erfüllt, wird die Änderung normalerweise mit „412 Precondition Failed“ abgewiesen.
Die Versionskennung muss vom Zielsystem zuverlässig erzeugt und geprüft werden. Ein zusätzliches Feld im aufrufenden Ablauf allein schützt nichts, wenn das Ziel die Bedingung ignoriert oder Prüfung und Änderung nicht konsistent ausführt.
Ein nachvollziehbarer Konfliktfall
Ein fiktiver Serviceauftrag liegt in Version 7 vor. Zwei Bearbeitungen lesen diese Fassung. Nach der ersten Änderung entsteht Version 8. Die zweite Bearbeitung sendet ihre Änderung mit der Voraussetzung „Version 7 ist noch aktuell“. Das System erkennt den Konflikt, statt den neueren Stand still zu ersetzen.
Nun wird die aktuelle Fassung erneut gelesen. Änderungen an unterschiedlichen Feldern können nach einer dafür vorgesehenen Regel zusammengeführt werden. Betreffen beide Änderungen dieselbe fachliche Angabe, braucht es eine ausdrückliche Entscheidung. Ein Konflikt ist ein Informationssignal und nicht automatisch ein technischer Defekt.
Einfaches Wiederholen kann den Schutz aushebeln
Wird nach dem Konflikt nur eine neue Versionskennung eingesetzt und derselbe alte Dateninhalt erneut gesendet, kann die aktuelle Änderung trotzdem verloren gehen. Die erneute Verarbeitung muss den neuen Inhalt berücksichtigen und die beabsichtigte Änderung darauf neu bewerten.
Für eine Automatisierung sollte daher feststehen, welche Konflikte sie selbst auflösen darf. Beispielsweise kann ein zusätzlicher unabhängiger Vermerk angehängt werden; das Ersetzen eines bereits geänderten Verantwortlichen könnte dagegen zur Klärung weitergegeben werden.
Konflikte bewusst testen und messen
Ein geeigneter Test lässt zwei Bearbeitungen denselben Ausgangsstand lesen und schreibt anschließend nacheinander. Erwartet wird eine nachvollziehbare Konfliktmeldung beim zweiten veralteten Schreibversuch. Zusätzlich wird geprüft, dass keine Information unbemerkt verschwindet.
Viele Konflikte können auf zu große Datensätze, unnötiges vollständiges Überschreiben oder ungeeignete Zuständigkeiten hinweisen. Die Versionsprüfung schützt den aktuellen Stand; sie ersetzt keine saubere fachliche Aufteilung der Arbeit.
Two workflows read the same record. One adds a delivery note; the other changes the responsible team. If both then save their complete old copy, the later write can overwrite the earlier change. Both requests may appear technically successful.
A read does not reserve the record
Optimistic concurrency control permits parallel editing and checks at write time whether the version read is still current. In HTTP, a strong ETag combined with an If-Match condition can prevent these lost updates. An unmet condition normally results in “412 Precondition Failed” rather than applying the change.
The target system must reliably create and enforce the version identifier. Adding a field in the calling workflow provides no protection if the target ignores it or does not perform the check and update consistently.
A traceable conflict example
A fictional service order is at version 7. Two operations read it. The first change creates version 8. The second operation submits its change on the condition that version 7 is still current. The system detects the conflict rather than silently replacing the newer state.
The current version is then read again. Changes to different fields can be combined if an established rule permits it. Changes to the same business value may need an explicit decision. A conflict provides information; it is not automatically a technical defect.
A blind retry can defeat the protection
Simply inserting a new version identifier and resending the same stale content can still lose the current change. Reprocessing must take the new content into account and reassess the intended modification against it.
Automation therefore needs a clear policy for conflicts it may resolve itself. Appending an independent note may be acceptable, while replacing a responsibility that has already changed could be referred for clarification.
Test and measure conflicts deliberately
A useful test makes two operations read the same starting version and then write one after the other. The second stale write should produce a traceable conflict. The test should also establish that no information disappears unnoticed.
Frequent conflicts may indicate oversized records, unnecessary full-record replacement or unclear responsibilities. Version checks protect the current state; they do not replace a sensible division of business work.