Gleichzeitig bearbeiten: Änderungen in Webanwendungen erhalten

Eine Disponentin und ein Kollege öffnen denselben Serviceauftrag. Beide sehen zunächst die alte Anfahrtsadresse. Die Disponentin korrigiert sie und speichert. Der Kollege ergänzt anschließend eine interne Notiz. Wenn seine Anwendung beim Speichern alle ursprünglich geladenen Werte zurückschreibt, kann die alte Adresse unbeabsichtigt wieder gültig werden. Seine Notiz war richtig; trotzdem wurde die Korrektur verdrängt.

Dieses fiktive Beispiel beschreibt einen verlorenen Änderungsstand, häufig als Lost Update bezeichnet. Dafür müssen Personen nicht in derselben Sekunde klicken. Es reicht, dass zwischen dem Laden und Speichern ein anderer Stand entstanden ist. Auch eine einzelne Person kann das mit zwei geöffneten Ansichten auslösen.

Die MDN-Erklärung bedingter HTTP-Anfragen beschreibt das Problem und eine mögliche technische Gegenmaßnahme. Für die Planung beginnt die Frage jedoch beim Fachablauf: Welche Änderungen dürfen unabhängig stattfinden und wann muss der aktuelle Stand erneut geprüft werden?

Schauen Sie deshalb nicht nur auf die Gesamtzahl der Nutzer. Wichtiger ist, wie oft dieselben Aufträge, Kunden oder Planungen gleichzeitig geöffnet sind. Eine selten bearbeitete Stammdatenliste kann wenig Konfliktpotenzial haben. Eine kleine gemeinsam genutzte Disposition kann dagegen genau an einem einzigen aktuellen Vorgang viele Änderungen bündeln.

Eine Anwendung kann beim Laden einen Versionsstand mitgeben und ihn beim Speichern erneut prüfen. Stimmen erwarteter und aktueller Stand nicht überein, darf sie nicht so handeln, als sei zwischenzeitlich nichts passiert. Ein Datum nur dekorativ anzuzeigen genügt dafür nicht.

HTTP kennt dafür unter anderem den Header If-Match mit einem passenden Entity-Tag. RFC 9110, Abschnitt 13.1.1 beschreibt die Vorbedingung und ihren Einsatz gegen versehentliches Überschreiben. Ob eine konkrete Webanwendung diesen Weg oder eine eigene Versionsprüfung verwendet, ist eine Implementierungsentscheidung.

Die MDN-Dokumentation zu If-Match erläutert die starke Vergleichsprüfung und die Antwort bei nicht erfüllter Vorbedingung. Ein Headername allein schützt keine Daten. Client und Server müssen das vereinbarte Verfahren wirksam umsetzen, und der Server muss den Schreibvorgang passend an die Prüfung binden.

Zur fachlichen Abnahme gehört deshalb eine beobachtbare Gegenprobe: Zwei Ansichten laden denselben Stand. Die erste speichert eine Änderung. Die zweite versucht anschließend ihre ältere Fassung zu speichern. Das erwartete Ergebnis wird vorher festgelegt. Es muss erkennbar sein, ob die zweite Änderung übernommen, zurückgewiesen oder nach einer bewussten Konfliktlösung eingearbeitet wurde.

Datenbanken bieten Regeln für parallele Operationen. Die PostgreSQL-Dokumentation zur Transaktionsisolation erklärt unterschiedliche Isolationsstufen und deren Verhalten. Diese Regeln beziehen sich auf die jeweiligen Datenbanktransaktionen. Sie sagen allein noch nicht, wie eine minutenlang geöffnete Browsermaske auf inzwischen veränderte Daten reagieren soll.

Die Entwicklungsplanung muss beide Ebenen verbinden. Eine Speicherung kann mehrere zusammengehörige Datenänderungen enthalten und muss diese passend behandeln. Zusätzlich muss erkennbar sein, ob die Eingabe auf einem veralteten fachlichen Stand beruht. Eine schicke Live-Anzeige anderer aktiver Nutzer ersetzt diese Kontrolle nicht.

Berücksichtigen Sie auch Änderungen durch Hintergrundaufgaben und Schnittstellen. Ein Auftrag kann aktualisiert werden, ohne dass gleichzeitig eine zweite Person im Browser arbeitet. Die Konfliktregel sollte deshalb am tatsächlich geänderten Stand ansetzen und nicht ausschließlich an einer Liste angemeldeter Nutzer.

Das ist besonders bei Aktionen mit knappen Ressourcen wichtig. Wenn zwei Personen denselben letzten freien Platz verwenden möchten, reicht ein nebeneinander angezeigter alter Verfügbarkeitsstand nicht. Ob eine Reservierung oder andere verbindliche Regel gebraucht wird, muss als eigene Fachentscheidung beschrieben werden. Die Oberfläche und der Server müssen dasselbe Ergebnis vermitteln.

Ruhrstack entwickelt individuelle Webfunktionen und Erweiterungen nach dem konkreten Arbeitsablauf. Bei gemeinsam genutzten Vorgängen gehören gleichzeitige Änderungen zu den wichtigen Sonderfällen. Eine passende Lösung muss deshalb nicht das ganze System ersetzen oder eine vollständige Echtzeit-Zusammenarbeit einführen.

Bringen Sie einen typischen Konflikt mit: Wer öffnet welche Ansicht, was wird geändert und welcher Verlust wäre problematisch? Daraus lassen sich Umfang, Rückmeldung und Prüfablauf ableiten. Vorhandene technische Möglichkeiten werden geprüft und mit den fachlichen Anforderungen abgeglichen.

So wird die Zusammenarbeit als überprüfbares Verhalten beschrieben. Der Nutzen liegt darin, dass Änderungen erhalten bleiben oder bewusst geklärt werden und Beschäftigte nach einem Konflikt einen verständlichen nächsten Schritt haben.