SQLite und konkurrierender Zugriff mit FireDAC

[Codehunter]

Hallo!

Für ein kleines Spaßprojekt habe ich mir folgendes Konzept ausgedacht: Windows-Netz, Datenbankdatei auf dem Netshare und Clientanwendung auf mehreren Rechnern. Absichtlich ohne Datenbankserver. Das Ganze ist weder Last- noch Zeitkritisch. Die Anwendung funktioniert soweit, lesend wie auch schreibend. Im Grunde wie erwartet gibt es ab und zu wegen der konkurrierenden Zugriffe "Datebase-is-locked"-Fehler. Allerdings habe ich hier und da Hinweise gesehen, dass man SQLite durch verschiedene Connection-Parameter verträglicher machen kann für eine solche Konstellation. Nur hatte ich dabei bisher noch keinen Erfolg. Falls jemand Erfahrungen damit hat wäre ich für Tips dankbar. Alternativ zu FireDAC könnte ich auch mit wenig Aufwand auf ZEOS oder UniDAC wechseln.

Grüße
Cody

[Der schöne Günther]

(Hervorhebung durch mich)

Zitat:

SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result. One should note that POSIX advisory locking is known to be buggy or even unimplemented on many NFS implementations (including recent versions of Mac OS X) and that there are reports of locking problems for network filesystems under Windows. Your best defense is to not use SQLite for files on a network filesystem.

Quelle: https://www.sqlite.org/lockingv3.html


und

Zitat:

A good rule of thumb is to avoid using SQLite in situations where the same database will be accessed directly (without an intervening application server) and simultaneously from many computers over a network.

Quelle: https://www.sqlite.org/whentouse.html

[Codehunter]

@Günther: Kenne ich. Die zitierte Seite weist aber selbst darauf hin, dass es inzwischen Verbesserungen gibt.

[Der schöne Günther]

Uh, wenn du meinst?

Zitat:

All processes using a database must be on the same host computer; WAL does not work over a network filesystem.

Einer schreibt und alle anderen lesen jederzeit nur - Das würde ich mich vielleicht noch trauen. Aber mehr nicht.

[Codehunter]

Wenn ich es wüsste hätte ich ja nicht gefragt. :) SQLite ist hier auch nur ein Versuch. Die Grundidee soll eine Datenbank ohne Serverdienst sein. Der Name der DB ist verhandelbar :D

[Schokohase]

Zitat:

Zitat von Codehunter (Beitrag 1419301)

Die Grundidee soll eine Datenbank ohne Serverdienst sein. Der Name der DB ist verhandelbar :D

Du wirst damit ein einigermassen stabiles System hinbekommen - egal wie der Name der DB lautet. Ein zuverlässig stabiles System aber nicht.

Wenn eingermassen reicht, dann bist du auf dem richtigen Weg.
Wenn du zuverlässig brauchst, dann verbrennst du gerade einfach nur Zeit.

[scrat1979]

Eventuell wäre hier Absolute Database in der MultiUser Edition eine Option. Allerdings kostenpflichtig. Ob es sich für ein Spassprojekt lohnt kannst nur du entscheiden. Ich arbeite sehr gerne damit :)

[jobo]

Was ich an dem Szenario interessant finde:
Du sagst, es gibt keine hohe Last, wenig Teilnehmer/ Konkurrenz. Trotzdem tritt aber der Fehler auf.

Tritt er auf, weil Du Lasttest machst und ihn den Fehler provozierst oder tritt er bereits in der beschriebenen Normalsituation auf?

Und wie sind die Parameter konkret?
Nutzeranzahl:
Schreibzugriffe pro Minute, Stunde, Tag:

[EgonHugeist]

@Cody,

der Fehler tritt auf, weil FireDac ein Performace-Blender ist. FireDac setzt alle !DB defaults! zu max Performace-settings. Wogegen alle ander Komponenten das nicht machen. Bei Zeos mußt du das explizit setzen.

Schau mal in die Antwort von:
https://stackoverflow.com/questions/...qlite-database
Dort steht beschieben, wie du FD wieder für konkurierende Zugriffe nutzbar machen kannst.

kleines ABER:
SQLite ist rasend schnell mit den FD settings. Zum Vergeich: https://synopse.info/forum/viewtopic.php?id=4472
Jedoch in den default-settings solltest du mit wirklich erhöhter Disk-Aktivität rechnen.
SQLite ist einfach nicht dafür gemacht, aber kann es.

[jobo]

Interessant!
normal versus exclusive Lock würde ich jetz nicht gleich als Performance Blendung bezeichnen.
Ein Exclusive Lock entspricht ja vollkommen der Bestimmung von sqlite und neben der dadurch gewonnenen Performance, bringt es ja im Zweifel auch "bessere" Daten (wobei ich nichts über die Qualität des "Normal Lock" Modes von sqlite weiß)

[Codehunter]

Also den Fehler habe ich gezielt provoziert indem ich auf einem Rechner mit einem 1-Sekunden-Timer immer von einer Tabelle gelesen habe und auf einem anderen Rechner mit einem INSERT einen Datensatz in diese Tabelle eingefügt habe. In der Praxis wäre das Intervall eher bei 60 Sekunden, aber nur weil die Wahrscheinlichkeit des Fehlers dadurch kleiner wird, wäre das ja noch keine gute Lösung.

Der besagte Fehler trat auf dem lesenden Rechner auf. Ich habe diesen Fehler ja, nach allem was in den von Günther verlinkten Artikeln zu lesen ist, erwartet und deswegen provoziert. Interessant fand ich die von mir verlinkte Seite mit dem WAL-Modus von SQLite, den ich in diesem Szenario ausprobieren wollte.

Die Hinweise mit den Performance-Einstellungen werde ich mir anschauen sobald ich wieder dazu komme. Sowas hatte ich auch im Verdacht. Ich hätte überhaupt kein Problem damit, wenn die lesende Seite so lange warten müsste, bis die schreibende Seite fertig ist und ihren Exklusiv-Lock wieder fallen lässt.