Schutz vor gleichzeitigem Bearbeiten: am selben Modell arbeiten, ohne sich gegenseitig zu überschreiben

Zwei Personen öffnen denselben Personalplan. Die eine ändert ein Einstellungsdatum, die andere passt in derselben Zeile eine Gehaltsspanne an, und beide klicken innerhalb weniger Sekunden auf Speichern. Ohne Schutzmechanismus gewinnt schlicht, wer zuletzt speichert – und die erste Änderung verschwindet, ohne Fehlermeldung, ohne Warnung, ohne jede Spur im Interface. Genau dieses Ausfallmuster soll der Schutz vor gleichzeitigem Bearbeiten in Rexfin verhindern.

Das Problem mit einem einfachen Speichervorgang

Ein Speichervorgang, der schlicht überschreibt, was bereits gespeichert ist – ein einfaches Upsert –, funktioniert gut, solange nur eine Person bearbeitet. Sobald mehr als eine Person beteiligt ist, gibt es keine Möglichkeit zu erkennen, dass sich die Zeile zwischen dem Laden und dem Speichern bereits verändert hat. Der zweite Schreibvorgang ist für sich genommen nicht falsch – ihm fehlen nur die Änderungen der ersten Person, und er sieht dabei aus wie ein ganz normaler, erfolgreicher Speichervorgang. Genau dieses Muster wurde beim Personalplan gefunden und behoben: Zwei Bearbeitende desselben Plans konnten sich über den Speicher-Endpunkt gegenseitig überschreiben, ohne dass davon irgendetwas sichtbar blieb.

Wie Rexfin das erkennt

Die Lösung ist optimistisches Sperren: Jeder Planeintrag trägt eine Versionsnummer. Beim Laden eines Plans wird im Hintergrund auch die Version mitgegeben, die man gerade vor sich hat. Ein Speichervorgang darf nur dann durchgehen, wenn die Version auf dem Server noch mit der zuletzt gesehenen Version übereinstimmt. Hat inzwischen jemand anderes gespeichert, hat sich die Version bereits weiterbewegt, und der eigene Speichervorgang wird als Konflikt abgelehnt, statt einfach darübergeschrieben zu werden.

Entscheidend ist, was danach im Interface passiert. Ein abgelehnter Speichervorgang scheitert nicht stillschweigend, und er wird auch nicht heimlich zu einem Teilerfolg zusammengeführt. Stattdessen erscheint eine klare, schwer zu übersehende Meldung: Jemand anderes hat inzwischen gespeichert, ein Neuladen ist nötig, bevor es weitergeht. Das ist eine bewusste Entscheidung – eine Unterbrechung ist das bessere Ergebnis als ein Speichervorgang, der scheinbar funktioniert, dabei aber lautlos fremde Änderungen verworfen hat. Gerät die Versionsangabe eines Eintrags einmal in einen inkonsistenten Zustand, ist das Verhalten auf Selbstheilung ausgelegt statt auf Blockade: Der Eintrag lädt dann mit leerem Plan, aber echter Version, sodass der nächste Speichervorgang ihn repariert, statt in einer dauerhaften Konfliktschleife hängen zu bleiben.

Mehr als nur ein Formular

Nachdem sich dieses Muster beim Personalplan bewährt hatte, wurde derselbe Typ von Speicher-Endpunkt im gesamten Produkt breiter überprüft – und dabei kam ein zweiter, ähnlicher Fall verlorener Änderungen bei den Compliance-Einstellungen ans Licht: Ein Speichervorgang las den bestehenden Datensatz, führte eine Änderung ein und schrieb das Ganze komplett zurück. Das ist dasselbe Risiko des stillschweigenden Überschreibens unter anderem Namen, und es wirkt jetzt nur noch gezielt auf das konkret geänderte Feld statt auf den gesamten Datensatz.

Aus derselben Überprüfung kamen ein paar verwandte Randfälle zum Vorschein. Erstellen zwei Personen etwa fast gleichzeitig eine neu benannte Version, konnten sich deren Namen zuvor in die Quere kommen; die Erstellung versucht es jetzt mit einem angehängten Suffix erneut, sodass beide Speichervorgänge durchgehen, statt dass einer schlicht scheitert. Auch das Verschieben einer Abteilung unter eine andere übergeordnete Abteilung hatte ein schmales Zeitfenster, in dem zwei gleichzeitige Verschiebungen zu einem echten Kreislauf führen konnten – eine Abteilung, die über Umwege letztlich sich selbst unterstellt ist; dieser Vorgang läuft jetzt als eine einzige, ganz oder gar nicht durchgeführte Transaktion. Und ein subtilerer Fall: Der allererste Speichervorgang eines neuen Eintrags erhielt früher dieselbe Versionsmarkierung, die eigentlich „hier existiert noch nichts” bedeutete – wodurch die erste Bearbeitung nach dem Anlegen eines Plans genauso überschrieben werden konnte wie bei einem ungeschützten Speichervorgang. Neu angelegte Einträge starten jetzt mit einer Version, die sich nicht mit einer leeren verwechseln lässt.

Wo das im Workspace ansetzt

Dieser Schutzmechanismus arbeitet still im Hintergrund genau der Bereiche von Rexfin, die ein Finanzteam täglich nutzt. Er macht Team-Workspaces erst wirklich brauchbar für mehr als eine Person gleichzeitig, statt zur Einladung zu werden, sich gegenseitig die Arbeit zu verderben. Er ergänzt den Kommentar- und Review-Workflow, bei dem Diskussion direkt neben der Bearbeitung stattfindet statt in einem separaten Tool, sowie die Versionierung und den Audit-Trail, wo man nachschauen würde, was genau sich wann geändert hat, falls ein Konflikt einmal zum Nachprüfen anregt. Zusammen mit dem Rest der Rexfin-Produkttour sorgt das dafür, dass ein gemeinsames Modell tatsächlich gleichzeitig bearbeitbar ist – und nicht nur nacheinander, im Wechsel, angefasst werden kann.