Konkurrierender Betrieb beim SELECT->EDIT -> UPDATE

[TS]

Hallo CK,

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.

Das nennt sich „optimistic locking.“

Wie sollte ich das am besten machen?

Ich habe das bei unserer internen Applikation so gelöst, dass ein Datensatz via locked TIMESTAMP WITHOUT TIME ZONE solange gesperrt ist, wie der Browser des Editors den Datensatz offen hat. Dazu wird alle 10 Sekunden via Websocket ein Event an den Server gereicht, der das Lock erneuert. Gleichzeitig läuft alle 30 Sekunden ein Cleanup-Job, der stale locks (Locks, die länger als 30 Sekunden nicht erneuert wurden) entfernt (locked wird wieder auf NULL gesetzt).

So weit war ich ja auch schon. Das ganze System wird dann recht komplex, da man dann in nahzu jeder Abfrage die Flags in den Datensätzen berücksichtigen muss. Es sollte auch sichergestellt sein, dass ein User nicht länger als xx Minuten einen Satz sperrt.

Sinnvoller fände ich es daher, ihm beim Update durch jemand anders eine Nachricht schicken zu können.

Wie wird das hier im Forum mit dem Hinweis gemacht, dass es Veränderungen gab. Wir der auch auf Client-Poll ausgeliefert, oder ist das Server-Push?

Grüße
TS