Hunderte Clients im Sekundentakt über gesperrte Datensätze informieren

[gubbe]

Muss die Anzeige denn tatsächlich so aktuell sein? Unabhängig davon wie oft Du die Anzeige aktualisierst ist sie wie Du auch schreibst nie 100%-ig aktuell. Dann brauchst Du also sowieso eine Routine, die prüft, ob der gewählte Datensatz noch zu bearbeiten ist.

Also:
- Komplette Liste der noch zu bearbeitenden Datensätze wird angezeigt
- Der Anwender wählt einen Datensatz zur Bearbeitung
- Das Programm prüft, ob der inzwischen gesperrt ist oder schon bearbeitet wurde
- Der Datensatz wird gesperrt und nach der Bearbeitung z.B. mit Änderungsdatum gekennzeichnet
- Die Liste wird neu geladen

Optional kann der Anwender die Liste auch manuell neu laden. Am besten sortiert man die Liste zufällig, damit nicht alle Anwender oben anfangen und sich um die ersten Datensätze streiten.

Wenn es unbedingt sein muss, kannst Du natürlich trotzdem regelmässig mit einer separaten Abfrage ermitteln, welche Datensätze gesperrt oder bereits bearbeitet wurden. Wenn es ein Datumsfeld dafür gibt (Letzte Änderung) kannst Du gezielt nur die abfragen, die sich seit dem letzten Abruf geändert haben. Die Haupttabelle wird dann neu gezeichnet und dabei - wenn der Datensatz auch in der Änderungstabelle existiert - eingefärbt. Nach einer Bearbeitung durch den Anwender lädst Du automatisch neu, so dass er jetzt nur noch die Unbearbeiteten sieht.

Eine Abfrage jede Sekunde ist dabei doch wahrscheinlich gar nicht notwendig solange es kein Wettbewerb ist und die Anwender alle gleichzeitig auf die Daten losgelassen werden und sich um "die besten Datensätze" streiten. Ansonsten eben einen Messagebroker einsetzen (als Ersatz für das Chattool, das rapante erwähnte)

Oder wie Du schon schreibst, den Auftrag nicht annehmen, wenn man nicht davon überzeugt ist.

[Papaschlumpf73]

Zitat von Klaus01:

Sind die Clients alle im gleichen Netz - dann wären udp broadcasts vielleicht eine Möglichkeit.

Grüße
Klaus

Jupp, sind alle im selben LAN. Ich habe allerdings noch nie mit UDP-Broadcasts gearbeitet; mir fehlt da noch ein bißchen Erfahrung. Theoretisch könnte ja dann jeder Client seine "in Bearbeitung" genommenen Datensatz-IDs an alle anderen im LAN broadcasten und jeder Client baut sich daraus selbst eine komplette Sperrliste.

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

[gubbe]

Zitat von Papaschlumpf73:

Jupp, sind alle im selben LAN. Ich habe allerdings noch nie mit UDP-Broadcasts gearbeitet; mir fehlt da noch ein bißchen Erfahrung. Theoretisch könnte ja dann jeder Client seine "in Bearbeitung" genommenen Datensatz-IDs an alle anderen im LAN broadcasten und jeder Client baut sich daraus selbst eine komplette Sperrliste.

Ich würde mich nicht darauf verlassen, dass die Broadcasts in jedem Fall durchkommen. Am Ende sind es doch irgendwie voneinander getrennte Netze für verschiedene Abteilungen oder einzelne Mitarbeiter arbeiten im Home Office per VPN und dann siebt eine Firewall Deine schönen Broadcasts aus. Ist sowieso nicht gesichert, dass UDP ankommt.

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

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