Hunderte Clients im Sekundentakt über gesperrte Datensätze informieren

[Papaschlumpf73]

Man stelle sich vor: Ein Kunde möchte, dass bis zu 100 Anwender gleichzeitig Datensätze in derselben Tabelle bearbeiten sollen. Jeder Datensatz muss aber nur einmal bearbeitet werden. Es gibt keinerlei Zuständigkeiten; jeder der 100 Anwender bearbeitet diejenigen Datensätze, die er möchte. So, dass am Ende jeder Datensatz einmal bearbeitet wurde.

Klingt verrückt? Ja klar! Aber: Was der Kunde will…

Wenn man jetzt jeden Datensatz vor der Bearbeitung auf eine Sperre testen würde, würde das viel zu lange dauern. Ich habe daher dran gedacht, den aktuellen Bearbeitungsstatus sekündlich zu aktualisieren und die Datensätze, die gerade bearbeitet werden oder schon bearbeitet wurden farblich zu kennzeichnen.

Wenn jeder der 100 Anwender jedoch sekündlich den SQL-Server nach dem Status aller Datensätze (bis zu 10000) befragen würde, ginge dieser wohl ganz schnell in die Knie. Wenn jedoch ein Anwender sekündlich den SQL-Server abfragt und das Ergebnis übers Netzwerk an die anderen 99 Anwender broadcastet, könnte das funktionieren. Oder jeder Anwender broadcastet seine aktuellen Änderungen an die anderen…

Vielleicht gibts ja dafür auch noch ganz andere Methoden, die mir gerade nicht einfallen. Nach Möglichkeit soll kein neuer Server aufgesetzt werden.

Eine gezielte oder zufällige Aufteilung der Datensätze an die 100 Anwender ist keine Option. Das machen wir schon seit 20 Jahren so. Jetzt soll was ganz Neues her :-)

[gubbe]

Also mich müsste man schon noch davon überzeugen, dass diese Vorgehensweise später für die Anwender überhaupt sinnvoll ist, bevor ich mir über die Umsetzung Gedanken mache.

Mal davon abgesehen, wäre eine sekündliche Abfrage der Datenbank kaum die richtige Lösung. Entweder man lässt sich von der Datenbank über Änderungen informieren (z.B. bei Interbase mit Events) oder schaltet einen Message-Broker dazwischen. Das bedingt dann aber natürlich einen weiteren Server bzw. Dienst wie Redis, RabbitMQ oder ähnliches. Oder man verbindet gar nicht direkt mit der Datenbank sondern setzt einen Server-Dienst mit Delphi auf (Rest mit JSON-Daten) und integriert hier ein Realtime-Messaging für alle aktiven Anwender z.B. über Websockets.

Das kann ja auch ganz spannend werden bei der Umsetzung, aber wenn man jetzt dem Kunden vorrechnet, dass die Lösung deutlich aufwendiger und damit teurer wird als das gezielte Zuweisen der Datensätze an die Anwender, wird es vielleicht doch die einfachere Lösung :-D

[himitsu]

Jeder bearbeitet doch gleichzeitig nur einen Datensatz.

Zu Beginn würde dann eine Sperre gesetzt
und wenn jemand Anderes will, wird beim "neuen" Sperren eine Fehlermeldung "besetzt" geworfen. Nur einmal beim Arbeitsbeginn die Liste laden und vielleicht alle Minuten manuell/automatisch refreshen.

Alternativ: Mitarbeiter sagt "gib mir einen Datensatz" und eine Arbrage holt einfach den nächsten Freien und sperrt ihn gleichzeitig.
Wenn fertig, wieder "gib mir einen Datensatz" und ...
Da muß kein Mitarbeiter wissen/sehen, was es sonst noch gibt ... mit den gesperrten (in Arbeit) Datensätzen kann er ja sowieso nix anfangen.

[Papaschlumpf73]

Zitat:

Zitat von himitsu (Beitrag 1537976)

Alternativ: Mitarbeiter sagt "gib mir einen Datensatz" und eine Arbrage holt einfach den nächsten Freien und sperrt ihn gleichzeitig.
Wenn fertig, wieder "gib mir einen Datensatz" und ...

Das klappt leider auch nicht, da es ja wieder eine Zuteilung ist. Jeder Anwender soll sich aber aus der Gesamtliste aussuchen, was er gerne bearbeiten möchte. Das ist irgendein Unfug, den die Frischlinge jetzt von der Uni mitbringen.

[Olli73]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1537966)

Wenn man jetzt jeden Datensatz vor der Bearbeitung auf eine Sperre testen würde, würde das viel zu lange dauern.

Eigentlich brauchst du nur pessimistisches Locking einzustellen und die Datenbank nimmt dir die Arbeit ab ...

[himitsu]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1537977)

Das ist irgendein Unfug, ...

Nja, im Notfall kann der Mitarbeiter noch sagen "nee, gefällt mir nicht, gib mir was Anderes" ... und nach paar hunter Klicks hat er dann ja alles durch :stupid:

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1537966)

würde das viel zu lange dauern.

Soooo langsam kann es doch nicht werden.

* entweder es gibt direkt in der Tabelle ein Feld mit der MitarbeiterID, welcher das aktuell gesperrt hat. (eventuell noch ein Feld mit der Zeit, oder ein allgemeines LastModified-Feld für den ganzen Datensatz, um zu langandauernde Sperren finden oder beseitigen zu können)
* oder es gibt eine weitere Tablle mit DatensatzID, Mitarbeiter ID und vielleicht noch der Zeit ... einmal ist ein Index für den Zugriff schnell und dann gibt es sowieso nicht zu viele Datensätze (maximal je Einen, für die 100 Mitarbeiter)
* oder auch, wenn man Lockingmechanismen der DB verwendet, wird sich das zeitlich kaum unterscheiden

Und sekündlich ist eh ein Schwachsinn.
erstmal brauchen nur die paar Mitarbeiter diese Liste, welche grade eben nach dem nächsten Datensatz suchen (die meiste Zeit werden sie doch wohl hoffentlich an den Datensätzen arbeiten)
und selbst dann muß es nicht so oft aktualisiert werden ... NIEMAND liest die komplette Liste in einer Sekunde und wählt umgehend was aus
* einmal zu Beginn des Guckens und dann z.B. alle 30, 60 oder vielleicht über 100 Sekunden
* und falls doch eher, dann manuell auf Refresh klicken
Mich würde es auch extrems nerven, wenn ich was anklicken will und es ständig unter der Maus wegrennt, weil die Liste dauernd aktualisiert wird und sich was verschieben kann.
Dann doch lieber seltener aktualisieren und beim Auswählen ein "ohh, jemand war schneller ... nimm was Anderes" (vielleicht gleich ein/einige automatischer alternativer Vorschlag im Dialog, um schnell "nehm ich" sagen zu können)

[Jasocul]

Jeder bekommt aus der allen Datensätzen einen bestimmten Anteil zugewiesen. Diese Datensätze hat sonst Niemand zur Verfügung. Dabei wird nicht die gesamte Menge aufgeteilt, wodurch Spätbeginner immer noch freie Datensätze bekommen können.
Aus diesem Kontingent kann dann ausgewählt, was man will. Ist alles abgearbeitet, kann ein Refresh für den nächsten Block an Datensätzen gemacht werden. Oder man macht ein Refresh, wenn keine Datensätze mehr da sind, die man bearbeiten möchte.
Eventuell steuert man die Anteile noch über die Anzahl der angemeldeten Benutzer. Außerdem muss noch berücksichtigt werden, dass wegen der Verteilungskriterien kein unbearbeiteter Rest übrig bleibt.

Alternativ wählt der Anwender vorher aus, welche Datensätze er bearbeiten möchte. Diese sind dann für die anderen für deren Vorauswahl gesperrt, bzw. werden gar nicht erst angezeigt. Hierbei muss berücksichtigt werden, dass es bei der Vorauswahl zeitlich Überschneidungen geben kann. Dies muss bei der anschließenden Zuweisung berücksichtigt werden.

Selbst wenn man jede Sekunde prüfen würde, ist damit nicht sichergestellt, dass es Überschneidungen geben kann. Man wäre trotzdem darauf angewiesen vor der Bearbeitung eine Prüfung durchzuführen, ob der Datensatz gesperrt/schon bearbeitet wurde.

[Papaschlumpf73]

Vielen Dank für eure Vorschläge. Wir sind uns wahrscheinlich alle einig, dass die Vorgaben ziemlich bescheuert sind. Daran ist aber nicht zu rütteln. Alle Anwender sollen gleichzeitig die Auswahl aus allen Datensätzen haben, sofern die Datensätze nicht schon bearbeitet wurden oder gerade durch einen anderen Anwender bearbeitet werden. Es soll keine Vorauswahl oder Zuteilung an die Anwender erfolgen.

Damit die Datensätze nicht unter der Maus „verschwinden“ war meine Idee, die Datensätze, die gerade von anderen Anwendern bearbeitet werden/wurden farblich zu kennzeichnen und für diese Datensätze die Bearbeitungsfunktionen zu deaktivieren - natürlich ist das nicht 100%ig.

Daher suchte ich eine technische Möglichkeit, eine Liste mit allen „gesperrten“ Datensatz-IDs möglichst häufig (sekündlich) an alle Clients zu verteilen.

Falls noch jemand Idee zur technischen Umsetzung hat… Wie gesagt: An den Vorgaben ist leider nicht zu rütteln; manche Geschäftsleitungen sind einfach beratungsresistent. Im Zweifel sage ich denen einfach ab - hab auch so genug zu tun :-)

[Klaus01]

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

Grüße
Klaus

[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 ;)