Was bedeutet Optimistic Locking?
Die Anwendung merkt sich beispielsweise die Versionsnummer eines Auftrags. Beim Speichern muss diese noch mit dem aktuellen Datenstand übereinstimmen. Andernfalls wird die Änderung als Konflikt behandelt.
So bleiben Daten nicht während der gesamten Bearbeitung gesperrt. Nach einem Konflikt darf die Anwendung jedoch nicht blind erneut speichern. Die zwischenzeitliche Änderung muss berücksichtigt oder gemeinsam geklärt werden.
So sieht das in der Praxis aus
Beispiel: Eine API akzeptiert eine Auftragsänderung nur, wenn die mitgesendete Version dem aktuell gespeicherten Stand entspricht.
Häufige Fragen
Wie unterscheidet sich das von einer dauerhaften Sperre?
Die Bearbeitung reserviert den Datensatz zunächst nicht. Erst beim Schreiben wird ein möglicher Konflikt erkannt. Eine klassische Sperre verhindert bestimmte konkurrierende Zugriffe bereits vorher.
Was sollte der Nutzer bei einem Konflikt sehen?
Eine verständliche Meldung und den aktuellen Datenstand. Je nach Aufgabe kann er Änderungen vergleichen, zusammenführen oder die Bearbeitung bewusst neu beginnen.
Kann die Anwendung nach einem Konflikt automatisch wiederholen?
Nur wenn die fachliche Aktion sicher neu bewertet werden kann. Ein blindes Überschreiben kann sonst die zwischenzeitliche Änderung einer anderen Person verlieren lassen.
