Konkurrierender Betrieb beim SELECT->EDIT -> UPDATE

[TS]

Hallo und guten Tag,

ich möchte den konkurrierenden Betrieb beim SELECT -> EDIT -> UPDATE besser abfangen.

Ein Datensatz wird per HTTP aus der Datenbank gelesen (SELECT) und auf dem Client zum Ändern (EDIT) angezeigt. Nach einer gewissen Zeit wird versucht, den veränderten Datensatz zurückzuschreiben.

Um die Race-Condition abzufangen, verwende ich bisher einen "Conflict-Counter", der bei jedem Update um 1 erhöht wird. Passt der alte Counter nicht zu dem abgefragten in den Client-Daten, meckert der Update-Trigger.

Da aber zwischen SELECT und UPDATE eine relevante Bearbeitungsdauer liegt, würde ich dem benachteiligten Editor gerne frühzeitig eine Nachricht geben, dass die Daten eben von einem schnelleren zurückgeschrieben wurden. Er kann sich dann die weitere Bearbeitung sparen und muss vorher neu lesen.

Noch besser wäre es, wenn man das per rpc.statd regeln könnte, also den Satz solange sperren könnte, wie er zur Bearbeitung ansteht. Nur da geht HTTP nicht mehr... Wie funktioniert das mit Websockets?

Wie sollte ich das am besten machen?

Grüße
TS