"Single-User" -> "Multi-User" + SQLite

[MichaelT]

Es hat keinen Sinn DMBS Funktionalität in einer Anwendung nachzubauen und schon gar nicht in einer Enduser Anwendung. Selbst die SAP ist froh, dass sie diese Hintegrundverbuchungsprozesse los ist und selbst die laufen in einer isolierten Serverapplikation. Viel mehr User als an deiner Anwendung angemeldet waren auf einem Host auch nicht gleichzeitig aktiv.

Solche Aufgaben erledigt an sich eine Middleware oder du baust die Fähigkeiten der DBMS auf der Business Ebene nach. Darunter leiden alle auf Nachrichten basierten Architekturen.

Was eine DB langsam macht ist der Overhead der Transaktionen und damit verbunden die Aufrechterhaltung der Konsistenz bspw... ACID.

Mal von den bereits genannten Vorschlägen abgesehen.

Du kannst einen Verbuchungsprozess machen der übermittelte Dateien einbucht. Das käme einer Nachricht nahe. Zum Zwecke der Verarbeitung kannst du einen Webserver hernehmen. Der Request an einen Webserver wird vor seiner Bearbeitung genauso in eine File geschrieben.

Mehr als eine Fire und Forget Nachricht die eine nice to have Information beinhaltet würde ich nicht direkt an solch eine Anwendung schicken.

---

SQLite ist ganz gut, wenn man Daten repliziert und viel liest oder lokal hält.

Zitat von wjjw:

Hallo!

Ich habe ein Programm das bis dato im "Single-User" Modus läuft.
Nun soll das Programm auf Multi-User laufen - was bei mir folgendes heisst:
A) Im Hauptprogramm "X" arbeitet ein Benutzer (Windows, Android, iOS)
B) Die Companion-App "Y" läuft auf mehreren mobilen Gräten (Android, iOS, Windows)
C) Die mobilen Apps "Y" schicken Daten an das Hauptprogramm "X"
D) Alle Programme kommunizieren im lokalen Netzwerk (kein Internet oder Cloud)

Nun möchte ich nicht das Hauptprogramm "zu viel" durch die mobilen Apps blockieren und umgekehrt -> Threads.
Problem ist das ich als Datenbank SQLite einsetze (da es auf jeder Platform verfügbar).
Die Datenbankoperationen hab ich schon gekappselt.
Es gibt einige Techniken das umzusetzen, jedoch welche passt bei dem Fall am Besten? TWorker, Critical Sections, ...
Die Datenpakete, die ich von den mobilen Apps bekomme, sind nicht groß - im Prinzip einzelne Datensätze bis zu 50 an der Zahl.

Vielleicht hat ja jemand eine Idee oder ein ähnliches Projekt umgesetzt.

[mkinzler]

Zitat:

Wie bei meiner Beschreibung erwähnt läuft das Hauptprogramm auf allen Platformen (nicht nur Windows). Daher denke ich mal das ich z.B. Oracle auf iOS nicht zum laufen bringe...

Braucht es auch nicht, wenn man den Datenzugriff abstahiert.

Zitat von mkinzler:

GGf. zusätzlich den Datenzugriff per REST kapseln, für den Zugriff von mobilen Geräten ist das sowieso sinnvoll.

Die Speicherung der lokalen Daten kann dann ja in SQLite, FireBird embedded oder IBLite erfolgen.

[wjjw]

Die Kommunikation mit den Clients läuft ja schon perfekt (via Webserver Multi-Thread).
Nun muss ich nur doch die Threads „richtig“ abarbeiten. Speziell DB Operationen. Dazu dachte ich mur das es da vielleicht ein Framework oder Best Practice gibt.
Diser Post sollte dem Zweck dienen.
Also: die Threads synchronisieren / Queuing, ...
Das Hauptprogramm selbst hat einen Thread und der Webserver bekommt von den Clients auch die Nachrichten. Jetzt möchte ich beide so verbinden, das keiner zu lange warten muss bzw. blockiert wird, was als eine nicht verarbeitete Übertragung bedeuten würde.

[mkinzler]

Warum nicht per REST?

Zitat:

Dazu dachte ich mur das es da vielleicht ein Framework oder Best Practice gibt.

REST. da gibt es im Delphi-Umfeld Lösungen wie DataSnap, Mars, DelphiMVC, DataWare, ...

[MichaelT]

Das ehrt deine Programmierkünste hilft aber Ende nicht allzuviel.

Läuft in dem Thread der Anwendung der Webserver?

Du bist in der Situation aus Sicht der Anwendung dass du viele Formulare offen hast auf denen ein Timer sitzt der per Zufallszahl einen ButtonClick resp. eine andere Ereignisbehandlung auslöst. Da hilft es auch nicht viel wenn du den 'Webserver' in der Anwendung laufen hast, denn du musst dauern den GUI Thread unterbrechen.

Eigentlich wäre deine Applikation am PC eine Anwendung die vom 'Server' gestartet wurde und nicht umgekehrt.

Du kannst einen Thread machen der eine DB Operation nach der anderen durchführt. Es macht auf jeden Fall Sinn den Empfang der Nachrichten von der Verbuchung zu entkoppeln. Schreibe die empfangene Nachricht in eine File und verbuche sie im Hintergrund.

Sobald du mit Messages und Queuing arbeitest sagst du zurecht der Anwendung ist egal was mit den Daten passiert, sie übergibt nur an den der die Daten weiterschickt und der weiß schon wohin.

Critical Section bieten sich. Ich würde aber nicht soweit gehen, dass ich unter der Kontrolle einer Anwendung mehre Nachrichten empfangende Threads mache die dann mit einem Pool von DB Writer und DB Reader Prozessen kommunizieren.

Da hast du bspw. in PHP denn in dem Fall synchronisiert der Runtime die DB Sessions.

Ich persönlich würde diese Verarbeitung hinter einen isoliert laufenden Webserver stecken. Damit hat du zumindest den Empfang vom Verbuchen entkoppelt.

Critical Sections bieten sich zur Synchronisation an.

Zitat von wjjw:

Die Kommunikation mit den Clients läuft ja schon perfekt (via Webserver Multi-Thread).

[Ghostwalker]

Ich persönlich würde die Kommunikation und das DB Handling in ein eigenes Serverprogramm ohne GUI (Dienst/Daemon) auslagern. Das Serverprogramm nimmt die Daten der Clients entgegen, packt diese in eine Que. Ein eigener Thread des Serverprogramm arbeitet die Que ab und trägt diese in die DB ein.

Vorteile:

- Keine Synchronisatzion mit einer GUI
- Keine Blockade der Clients
- Wenns zuviel wird, kann man das ganze auf einen eigenen Rechner auslagern.

[Mavarik]

Zitat von Ghostwalker:

Ich persönlich würde die Kommunikation und das DB Handling in ein eigenes Serverprogramm ohne GUI (Dienst/Daemon) auslagern. Das Serverprogramm nimmt die Daten der Clients entgegen, packt diese in eine Que. Ein eigener Thread des Serverprogramm arbeitet die Que ab und trägt diese in die DB ein.

Sicherlich ein guter Vorschlag!

Aber muss man nicht in jeder App, egal ob Windows, iOS oder Android, die Datenbankzugriffe kapseln?

Ich hatte noch nie ne App bei der ich nicht Daten in einem Thread weg schreibe oder Daten lese, während die UI auch Daten anfordert oder schreiben möchte?

Wenn ich also immer asynchron mit CRUD arbeite habe ich "keine" Probleme egal wie die Anwendung aus sieht.

Es gibt natürlich Situationen, wo die UI auf ein Ergebnis der Datenbank warten muss. Aber wovon sprechen wir hier? 250ms? 1s? 3s?

Wenn ich auf einen Button klicke, erwarte ich eine sofortige Reaktion. IMMER, damit sich die Anwendung flüssig "anfühlt". Wenn also ein Zugriff länger dauert, muss ich sowieso eine Art von Stundenglas/Wait-Animation anzeigen.
Naja und die kann sich auch nur flüssig drehen, wenn mein DB-Zugriff in einem eigenen Thread ist...

Also sind ALLE Datenbankzugriff immer in einem Thread. Hier also einen Queue einzufügen, die dann auch gerne Datenbankanfragen von mehrerer Quellen abhandeln kann ist kein Hexenwerk. Wenn ich dann noch anfragen der lokalen App bevorzuge, läuft alles schnell und sauber.

Wäre es nicht schön, wenn es für Firemonkey ein Framework gäbe, dass so etwas kann?

Mavarik

[Ghostwalker]

Naja, einfach ist es schon.

Die Frage nach der Priorisierung der Zugriffe, ist eine Frage, wie aktuell die Daten für die Clients sein müssen.

Beispiel:

Client A braucht unbedingt die Daten von Client B, die dieser gerade in die Que zum eintragen geschickt hat.

Dann sollte der Schreibzugriff natürlich oberste Prio haben.

Eine andere Situation, die man noch berücksichtigen könnte, wäre, das die Clients auch "Offline" arbeiten können sollen. Dann wärs sinnvoll die Clients mit einer eigenen "lokalen" DB arbeiten zu lassen, die dann entsprechend mit der zentralen Version synchronisiert werden.