SQLITE3 Multithreaded geht das?

[QuickAndDirty]

Hallo,
Ich weiß, dass Firedac mit dem FDManager und über separate Connections pro Thread threadsicher ist.
Desweiteren habe ich gelesen, dass es wohl in den Sourcen von SQLITE einen Schalter für eine multithread-fähige SQLITE Version gibt.

Die Frage: Kann ich eine SQLite3 Datenbank mit Firedac aus mehreren Threads heraus nutzen?

Es ist so, dass ich eine App habe, welche Downloads in die Datenbank speichert und das blockiert zum Teil die Oberfläche arg. Ich würde das gerne auslagern in einen Hintergrundthread.
Ich muss aber gleichzeitig die Datenbank weiter aus dem Hauptthread heraus nutzen...die App ist quasi die Datenbank.

Habe ich da 'ne Chance?

[TiGü]

Falls es nicht gehen sollte, was ich nicht weiß, hast du schon die Alternative in Betracht gezogen, die Datei temporär auf dem Gerät zu speichern und erst nach dem Download in die Datenbank zu schieben?

[QuickAndDirty]

Zitat von TiGü:

Falls es nicht gehen sollte, was ich nicht weiß, hast du schon die Alternative in Betracht gezogen, die Datei temporär auf dem Gerät zu speichern und erst nach dem Download in die Datenbank zu schieben?

Ja. Ich mache das ja bereits so.
Das Anlegen in der DB dauert aber einfach sehr lange:
Paremetrisiertes Insert-Statement ist prepared, alles innerhalb einer Transaktion geschrieben und am Ende commited.

Ich brauche einen Thread.

Wenn Multitreading nicht geht. Könnte ich immer noch einen Thread nutzen der alle DB Zugriffe ausführt, während sich die APP aus einem Cache bedient.
Oder ich lagere die Tabellen, welche von solchen größeren Downloads betroffen sind in eine separate Datenbank aus, so dass der Rest der App noch Zugriff auf die Datenbank hat.
Oder ich versuche dafür zu sorgen das wirklich nur die Differenz der Datenbestände zwischen App und Server runtergeladen und in die DB eingepflegt wird, dann müsste ich allerdings,vermutlich serverseitig etwas ändern... und das könnte aufwändige Updates der Server bei den betroffenen Kunden nach sich ziehen...

[Edit]
Ich habe das Hauptproblem(ein Programmierfehler) aber gelöst. Es arbeitet jetzt flott, aber eben nur auf der kleinen Testdatenmenge. Für große Datemmengen wäre es immer noch wünschenswert einen Hintergrundthread zu haben.

[bra]

Dir ist bewusst, dass SQLite nicht zum Speichern von größeren Dateien in der DB geeignet ist? Die Performance ist dann unterirdisch.

https://www.sqlite.org/intern-v-extern-blob.html

[Mavarik]

Zwei gleichzeitige Zugriffe auf SQLite, einen aus der UI und einen aus eine Thread geht nicht.

Ich habe erst kürzlich hierzu für einen Kunden eine Threaded Prioritäts-Queue programmiert, die genau das macht...

Verarbeitung geht dann alles in einen Thread und wenn die UI etwas braucht, kommt die Abfrage sobald es möglich ist...

Mavarik

[QuickAndDirty]

Zitat von Mavarik:

Zwei gleichzeitige Zugriffe auf SQLite, einen aus der UI und einen aus eine Thread geht nicht.

Ich habe erst kürzlich hierzu für einen Kunden eine Threaded Prioritäts-Queue programmiert, die genau das macht...

Verarbeitung geht dann alles in einen Thread und wenn die UI etwas braucht, kommt die Abfrage sobald es möglich ist...

Mavarik

Das habe ich befürchtet.

[QuickAndDirty]

Zitat von bra:

Dir ist bewusst, dass SQLite nicht zum Speichern von größeren Dateien in der DB geeignet ist? Die Performance ist dann unterirdisch.

https://www.sqlite.org/intern-v-extern-blob.html

Mir ist das klar. Aber wenn ein Kunde sagt, er möchte einen großen Teil seiner Server-Datenbank offline und tagesaktuell im Handy benutzen können...

[bra]

Wir haben es bei unserer App so gelöst, dass nur die Metadaten in der SQLite-DB gespeichert sind, die eigentlichen Binär-Dateien liegen so im Dateisystem (verschlüsselt, da das für die Daten notwendig ist).

Ein richtiges Paralleles Schreiben in die Datenbank funktioniert nicht, aber über TCriticalSection ist es möglich, dass mehrere Threads auf dieselbe DB schreiben/lesen.

[Mavarik]

Zitat von bra:

Wir haben es bei unserer App so gelöst, dass nur die Metadaten in der SQLite-DB gespeichert sind, die eigentlichen Binär-Dateien liegen so im Dateisystem (verschlüsselt, da das für die Daten notwendig ist).

Ein richtiges Paralleles Schreiben in die Datenbank funktioniert nicht, aber über TCriticalSection ist es möglich, dass mehrere Threads auf dieselbe DB schreiben/lesen.

Ok, ich würde lieber einen TMonitor nehmen, aber egal...

Mehrere Threads sind ja nicht das Problem... In der Regel will man ja ggf. das die UI auch mal was aus der Datenbank lesen kann...

Da hilft es nicht, wenn der Thread steht und auf die Freigabe wartet, da die UI zwar - wenn event getrieben über den Thread - reaktive bleibt, aber kein Ergebnis liefert.

Mavarik

[bra]

Zitat von Mavarik:

Ok, ich würde lieber einen TMonitor nehmen, aber egal...

Was ist der Vorteil von TMonitor? Ich glaube wir hatten das auch mal untersucht und waren zu dem Fazit gekommen, dass TMonitor deutlich langsamer als TCriticalSection ist (siehe auch: https://www.delphitools.info/2013/06...iticalsection/ )