Software-Datenmodell Redesign - Möglichkeiten

[Papaschlumpf73]

Dann würde ich im ersten Schritt prüfen, ob der Flaschenhals tatsächlich bei den Clients oder am Server ist. Wenn es nur die Clients sind, würde ich das ganze System nicht über den Haufen werfen, sondern nur die Verarbeitung der Datensatzänderungen auf den Clients optimieren. Never change a running system.

[SusiT]

Erstmal danke für eure schnellen Reaktionen und Anregungen.

Der Server sendet soweit zuverlässig und schnell, dort sehe ich soweit erstmal keine Probleme.

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?
Oder finden Zugriff innerhalb einer Multi-Thread-Anwendung auf DataSets generell nur via CriticalSections o.Ä. statt?

[jaenicke]

Zitat von SusiT:

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?
Oder finden Zugriff innerhalb einer Multi-Thread-Anwendung auf DataSets generell nur via CriticalSections o.Ä. statt?

Soweit ich weiß, gibt es das nicht.

Das hat aber auch den Hintergrund, dass du Locks bei einer eigenen Implementierung optimieren kannst, während eine allgemeine threadsichere Implementierung alles absichern müsste.

FireDAC ist z.B. bei reinen Lesezugriffen auf geklonte Datasets threadsafe.

Eine Idee zur Optimierung:
Halte einfach für jeden Client zwei DataSets vor. Eins ist das, das bei einer Anfrage geliefert wird, das andere bekommt ein Update. Nach dem Update tauschst du threadsicher die beiden DataSets aus.

Das hat den Vorteil, dass eine Datenanfrage immer schnell beantwortet wird, dafür eine im Moment der Anfrage eingespielte Datenänderung erst bei der nächsten Lieferung enthalten ist.

Ich bin gerade im Urlaub und schreibe am Handy. Insofern kann ich aktuell schlecht recherchieren.

[Papaschlumpf73]

Zitat von SusiT:

Gibt es denn DataSets, welche Threadsafe genutzt werden könnten?

Das kann ich mir kaum vorstellen. Ich würde die Datenaktualisierung auch immer nur seriell vornehmen. Wenn z.B. ein Datensatz geändert und kurz danach gelöscht wird (auf dem Server), und der Client verarbeitet die beiden Änderungen nicht seriell, könnte der Datensatz im Client zuerst gelöscht und dann... nicht mehr gefunden werden.

[Uwe Raabe]

Ich könnte mir vorstellen, dass ein Abrufen der Daten mit einer TFDQuery unter den FireDAC-Regeln für Multi-Threading mit anschließend synchronisierter Übergabe an ein TFDMemTable in den Hauptthread durch simples Zuweisen des Data Properties ein brauchbarer Ansatz wäre.

[SusiT]

@PapaSchlumpf73:

Da hast du vollkommen recht, dieses Szenario habe ich so nicht bedacht.

@jaenicke:

Die Idee für die Optimierung klingt einleuchtend. Im Grunde halte ich dann ein CDS in einem separaten Event-Thread welcher die Updates erhält und in sein CDS einfügt.
Nach dem erfolgreichen Einfügen könnte ich den kompletten Inhalt des CDS dann in das CDS im MainThread kopieren.

Wäre es auch möglich via CloneCursor die Anzeige im MainThread auf die im Event-Thread zu referenzieren? Im Grunde "lese" ich die Daten ja ausschließlich im MainThread um sie dort dem Benutzer zu präsentieren. Oder geht das mit herkömmlichen ClientDataSets nicht und ich müsste auf die FireDac Äquivalente umsteigen?


@Uwe Raabe:

Das ist so leider nicht möglich da die Clients keine direkte Verbindung zur Datenbank haben.

[himitsu]

Bei DataSnap, bzw. RAD-Server, sowie auch einigen anderen IPC-Frameworks,
kann man DataSets als Parameter übergeben und als VAR-Parameter oder Result abrufen.

Die DB-Verbindung oder sonstwas wäre in der Middleware (Server) und die Clients bekämen die Daten von dort durchgereicht.



Für langsame Query, hatten wir mal eine Liste von DataSets im Apps, dort wurden sie regelmäßig in einem Thread aktualisiert
und dann konnten die Clienten sie gemütlich abrufen.

* der Aufruf der Runterladfunktion kommt je in einem Thread an
* dort wurde via CriticalSections das jeweilie DataSet kurz gesperrt
* dann schnell in ein MemoryDataset (z.B. dxMemData oder CDS) umkopiert
* anschließend das MemoryDataset als Result rausgegeben (mit OwnsObjects, damit Datasnap das dann freigibt, wenn fertig)
* im Client kam dann eine Kopie dieses Datasets an (das lief in einem DownloadThread)
* und anschließend wurde das DataSet im Hauptthread (Synchronize) ans Grid gehängt (das alte DataSet dabei freiegeben)

Inzwischen nutzen wir aber MATERIALIZED VIEWs im Postgres, welche die Clients vom DBServer laden, und die regelmäßig über den Apps aktualisiert werden.

[jaenicke]

Zitat von SusiT:

Wäre es auch möglich via CloneCursor die Anzeige im MainThread auf die im Event-Thread zu referenzieren?

Ich kenne die Interna eines ClientDataSets zu wenig um das zu beantworten. Laut Cary Jensen sollte das aber gehen.

Zitat:

So long as no code needs to make changes to Data or Delta, the ClientDataSet is thread safe.

Er hat zum ClientDataSet ein ganzes Buch geschrieben. Das Thema Threads findest du auch in seinem Blogeintrag:
https://caryjensen.blogspot.com/2011...rsors.html?m=1
Ich empfehle dir, dass du dir das genau anschaust, was er dazu schreibt. Ich habe das nur überflogen.