Hunderte Clients im Sekundentakt über gesperrte Datensätze informieren

[rapante]

Moin,
für unseren Kalender/Ressourcenplaner gab es ähnliche Anforderungen. Es sollte vernmieden werden, dass 2 Leute gleichzeitig einen Datensatz bearbeiten. Änderungen sollen sofort für alle Clients sichtbar sein.

Gelöst haben wir das vor Jahren über einen ChatServer. Alle Clients sind Mitglieder des Chats. Änderungen/Locks (Datensatz ID/Status) werden in die Datenbank geschrieben und im Chat publiziert. Jeder Client prüft für sich, ob ein Refresh der aktuellen Ansicht nötig ist.
Unmittelbar vor dem Bearbeiten eines Datensatzes wird noch einmal geprüft, ob er eventuell gesperrt ist (DB-Abfrage) und ggf. eine Meldung angezeigt.

Anstelle eines Chatserver kann man das heute wohl eleganter lösen, aber das Prinzip sollte das gleiche sein

[Uwe Raabe]

Wenn jeder Anwender jeden Datensatz bearbeiten kann, dann lass sie das doch einfach machen. Beim Schreiben der Änderung in die DB kannst du ja mit einer WHERE-Klausel, die alle (relevanten) vorigen Werte enthält, sicherstellen, dass der Datensatz noch unverändert ist. Falls dem nicht so ist, ändert das UPDATE nichts und du kannst das ja dem Anwender mitteilen.

Bei FireDAC kann man das weitegehend automatisieren in dem in der Query bei UpdateOptions.UpdateMode das upWhereAll oder upWhereChanged einstellt.

[Papaschlumpf73]

Zitat von Uwe Raabe:

Wenn jeder Anwender jeden Datensatz bearbeiten kann, dann lass sie das doch einfach machen. Beim Schreiben der Änderung in die DB kannst du ja mit einer WHERE-Klausel, die alle (relevanten) vorigen Werte enthält, sicherstellen, dass der Datensatz noch unverändert ist. Falls dem nicht so ist, ändert das UPDATE nichts und du kannst das ja dem Anwender mitteilen.

Bei FireDAC kann man das weitegehend automatisieren in dem in der Query bei UpdateOptions.UpdateMode das upWhereAll oder upWhereChanged einstellt.

Das eigentliche Problem ist etwas anders. Ich muss den Datensatz schon für die anderen Anwender sperren, wenn er durch einen Anwender ausgewählt wird - also noch gar nicht verändert wurde. Es könnte sich ja theoretisch um eine Anrufliste handeln, in der nur das Ergebnis vermerkt werden soll. Wenn ein Anwender einen Datensatz auswählt, sollte er daher schon für die anderen gesperrt sein, damit nicht zwei Anwender gleichzeitig anrufen, bevor sie dann versuchen das Ergebnis zu dokumentieren.

Da man ja auch einfach nur so durch eine solche Liste scrollen kann, um sich vielleicht die besten Einträge rauszusuchen, wollte ich die Auswahl des Datensatzes noch nicht in die DB schreiben sondern die ID des Datensatzes nur auf die Sperrliste nehmen und schnellstmöglich an alle anderen Anwender verteilen.

[taveuni]

Zitat von Papaschlumpf73:

Das eigentliche Problem ist etwas anders. Ich muss den Datensatz schon für die anderen Anwender sperren, wenn er durch einen Anwender ausgewählt wird - also noch gar nicht verändert wurde. Es könnte sich ja theoretisch um eine Anrufliste handeln, in der nur das Ergebnis vermerkt werden soll. Wenn ein Anwender einen Datensatz auswählt, sollte er daher schon für die anderen gesperrt sein, damit nicht zwei Anwender gleichzeitig anrufen, bevor sie dann versuchen das Ergebnis zu dokumentieren.

Da man ja auch einfach nur so durch eine solche Liste scrollen kann, um sich vielleicht die besten Einträge rauszusuchen, wollte ich die Auswahl des Datensatzes noch nicht in die DB schreiben sondern die ID des Datensatzes nur auf die Sperrliste nehmen und schnellstmöglich an alle anderen Anwender verteilen.

Vielleicht verstehe ich es nicht richtig. Was hindert denn den Server daran alle (anderen) Clients zu notifizieren wenn einer einen Datensatz "sperrt" (von mir aus auch nur selektiert)? Wie ist denn die Client/Server Kommunikation realisiert?

[Uwe Raabe]

Würde es nicht reichen, die Sperrung beim Versuch, den Datensatz zu bearbeiten, zu überprüfen?

Es mag vielleicht von dem konkreten Anwendungsfall abhängen, aber ich finde eine Live-Aktualisierung der aktuellen Sperrungen im Sekundentakt schon etwas übertrieben.

[Papaschlumpf73]

Zitat von Uwe Raabe:

Würde es nicht reichen, die Sperrung beim Versuch, den Datensatz zu bearbeiten, zu überprüfen?

Es mag vielleicht von dem konkreten Anwendungsfall abhängen, aber ich finde eine Live-Aktualisierung der aktuellen Sperrungen im Sekundentakt schon etwas übertrieben.

Finde ich nicht ganz so toll und würde ich so auch nicht anbieten wollen. Der Anwender würde eine lange Liste mit Datensätzen sehen. Jetzt klickt er einen an und merkt erst dann, dass dieser DS gesperrt ist, beim nächsten Datensatz dann ggf. das gleiche nochmal. Und beim Scrollen durch die Liste (Bleifinger auf CURSOR_DOWN) werden dann die Prüfungsanfragen an den SQL-Server im 100-Millisekundentakt abgefeuert.

Es geht bei den Aktualisierungsinformationen auch wirklich nur um die IDs der gesperrten Datensätze; was ein anderer Anwender mit dem Datensatz gemacht hat, ist völlig egal und muss auch nicht angezeigt werden. Nur eben der Status, dass dieser Datensatz nicht mehr bearbeitet werden kann.

[Rollo62]

TL;DR;

Ich würde nicht versuchen die Tabelle selbst zu locken.
Wäre es nicht denkbar mit einer zweiten, schnellen Lock-Tabelle zu arbeiten, bevor man dann die eigentliche Tabelle ändert?
Der Erste, der da einen Record belegt setzt ein Flag mit Timestamp und der schnellere gewinnt.
Wenn weitere den gleichen Record locken wollen, dann sollte es krachen.
Danach kann man doch in aller Ruhe den Record bearbeiten.

Zusätzlich könnte diese Lock-Tabelle eine Kopie des eigentlichen Records enthalten.
Nach einer Änderung könnte man das dann wieder freigeben, indem man nur den Status auf READY ändert.
Dann könnte ein anderer Prozess meinetwegen regelmäßg drüberlaufen und alle die READY sind abschliessen und zum Zielrecord übertragen.
So würde keiner direkt auf der Ziel-Tabelle arbeiten, sondern immer nur über die "Shadow"-Tabelle,
die nach einer Bearbeitung sich selbst aufräumen kann.
Das Ganze könnte man noch mit StoredProcedures und Transactions garnieren.

Ist es vielleicht sowas, was Dein Kunde sucht?

[Jasocul]

Zitat von Papaschlumpf73:

Zitat von Uwe Raabe:

Würde es nicht reichen, die Sperrung beim Versuch, den Datensatz zu bearbeiten, zu überprüfen?

Es mag vielleicht von dem konkreten Anwendungsfall abhängen, aber ich finde eine Live-Aktualisierung der aktuellen Sperrungen im Sekundentakt schon etwas übertrieben.

Finde ich nicht ganz so toll und würde ich so auch nicht anbieten wollen. Der Anwender würde eine lange Liste mit Datensätzen sehen. Jetzt klickt er einen an und merkt erst dann, dass dieser DS gesperrt ist, beim nächsten Datensatz dann ggf. das gleiche nochmal. Und beim Scrollen durch die Liste (Bleifinger auf CURSOR_DOWN) werden dann die Prüfungsanfragen an den SQL-Server im 100-Millisekundentakt abgefeuert.

Ich denke, dass das anders gemeint war. Wenn ein DS gesperrt ist, gibt es ein Refresh aller Datensätze. Dann muss nicht jeder einzelne geprüft werden.

[Papaschlumpf73]

Zitat von taveuni:

Zitat von Papaschlumpf73:

Das eigentliche Problem ist etwas anders. Ich muss den Datensatz schon für die anderen Anwender sperren, wenn er durch einen Anwender ausgewählt wird - also noch gar nicht verändert wurde. Es könnte sich ja theoretisch um eine Anrufliste handeln, in der nur das Ergebnis vermerkt werden soll. Wenn ein Anwender einen Datensatz auswählt, sollte er daher schon für die anderen gesperrt sein, damit nicht zwei Anwender gleichzeitig anrufen, bevor sie dann versuchen das Ergebnis zu dokumentieren.

Da man ja auch einfach nur so durch eine solche Liste scrollen kann, um sich vielleicht die besten Einträge rauszusuchen, wollte ich die Auswahl des Datensatzes noch nicht in die DB schreiben sondern die ID des Datensatzes nur auf die Sperrliste nehmen und schnellstmöglich an alle anderen Anwender verteilen.

Vielleicht verstehe ich es nicht richtig. Was hindert denn den Server daran alle (anderen) Clients zu notifizieren wenn einer einen Datensatz "sperrt" (von mir aus auch nur selektiert)? Wie ist denn die Client/Server Kommunikation realisiert?

Die Clients verbinden sich direkt via TADOConnection mit dem SQL-Server.