Christian Kruse: Konkurrierender Betrieb beim SELECT->EDIT -> UPDATE

Beitrag lesen

Hallo TS,

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).

Wie du in deiner Umgebung mit Websockets arbeiten kannst, kann ich dir nicht sagen: ich kenne deine Umgebung nicht. Bei mir ist das ein Application Server, der die Websocket-Verbindungen behandelt.

LG,
CK