Zwei Nutzer bearbeiten denselben Datensatz gleichzeitig. Wie verhinderst du, dass einer den anderen stillschweigend überschreibt?

Nimm für die meisten Fälle Optimistic Locking: gib der Zeile eine Version-Spalte oder einen Timestamp, nimm den ins Update-Prädikat auf, und wenn null Zeilen aktualisiert werden, hat sich der Datensatz unter dir verändert, du gibst also einen Konflikt zurück. Nimm Pessimistic Locking, ein select for update in einer kurzen Transaktion, wenn Konflikte häufig sind oder die Operation sich nicht sicher wiederholen lässt. Das Einzige, was du nicht machen darfst, ist lesen, ändern und schreiben ganz ohne Prüfung.

Der Fehler ist Read Modify Write: beide Requests laden Version eins, beide rechnen mit veralteten Daten, und der zweite Write gewinnt stillschweigend. Meine Standardlösung ist optimistisch: jede Zeile hat eine Version, das Update sagt where id gleich diese und version gleich das, was ich gelesen habe, und zählt die Version hoch. Wenn das Update null geänderte Zeilen meldet, war jemand schneller, und ich gebe eine 409 zurück, statt so zu tun, als hätte es geklappt. Das kostet nichts, solange Konflikte selten sind, und das sind sie meistens. Auf Pessimistic Locking wechsle ich, wenn Contention real ist oder ein Retry nicht akzeptabel wäre, zum Beispiel beim Dekrementieren von Beständen: da nehme ich ein select for update auf die Zeile, mache Prüfung und Write in einer kurzen Transaktion und halte keine Netzwerkaufrufe innerhalb dieser Transaktion. Am wichtigsten ist mir, was der Nutzer sieht. Ein roher Konfliktfehler ist nutzlos, deshalb haben wir bei einem Dokumenteneditor die aktuelle Version zusammen mit dem Fehler zurückgegeben, damit der Client ein Diff zeigen konnte, statt die Arbeit einfach zu verlieren.