Hunderte Clients im Sekundentakt über gesperrte Datensätze informieren

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

[Jasocul]

Gerade viel mir ein, dass ich vor ca. 20 Jahren ein ähnliches Problem hatte.
Meine damalige Lösung:
Sobald ein Datensatz gespeichert wird, wird die gesamte Liste aktualisiert und bearbeitete Datensätze hatten eine Markierung. Die Anwender konnten über einen Schalter auch die erledigten Datensätze ausblenden. Natürlich war der zuletzt bearbeitete Datensatz immer noch selektiert, damit man nicht wieder alles durchblättern musste.
Der wesentliche Vorteil war, dass nach dem Refresh auf jeden Fall der aktuellste Stand verfügbar war und ein ständige Aktualisierung entfallen konnte.