Zugriff auf SQLIte DataBase von zwei unterschiedliche Systeme

Wenn Betriebssystem und Dateisystem das File Locking korrekt 
implementieren, gibt es kein Problem. (Solche Fehler findet man meist 
bei Netzwerk-Dateisystemen.)

Scelumbro schrieb:

> Ich denke die entscheidende Frage ist, ist es vorgesehen bzw. kann es
> irgendwie passieren, dass beide Programm gleichzeitig auf die DB Datei
> zugreifen wollen?

... und vor allem wie deine definition von GLEICHZEITIG ist, wenn beides 
in einem ms Slot passieren kann sollte das kein Problem darstellen.

Man kann für jedes SQLite-SQL-Kommando einen timeout setzen,
SQLite führt das Teil dann aus wenn es geht.

zB eine immmediate transaction.

Datenbanken kann man auch read-only öffnen.

MoinMoin,

Bern_Gast schrieb:
> Kommt eigentlich SQLIte damit klar oder ist das Kritisch?
> Ich bin noch in der Spezifikationphase.
ja ist möglich, Erklärung kommt gleich...

Klaus P. schrieb:
> Steht im Manual: https://www.sqlite.org/lockingv3.html
Jupp, hier wird der Mechanismus erläutert, der da greift...

Peter II schrieb:
> bei SQLIte gibt es aber kein Datenbanksystem. Die Datenbank ist komplett
> im Treiber implementiert.
naja, SQLite ist schon eine Datenbank, eine sogenannte "eingebettete" 
Datenbank. Und ja, die Zugriffsschicht ist nicht in einem zentralen 
Dienst, wie z.B. bei Oracle, MySQL etc., implementiert, der die Zugriffe 
koordiniert. Vielmehr gibt es eine API, die jeder beteiligte Prozess 
verwenden sollte und in der auch Mechanismen zur Zugriffssteuerung auf 
die DB zur Verfügung gestellt werden (und auch richtig angewendet werden 
sollten, um Dateninkonsistenzen zu vermeiden!).

Peter II schrieb:
> Wenn mehre User auf eine Datei zugreifen, dann gibt es keinen
> gemeinsamen DB-Prozess der die zugriffe koordiniert. Das muss jeder
> Prozess mit Hilfe vom file-locking machen.
Nein, nicht das "File-Locking" des OS ist da entscheidend, sondern eben 
die erwähnten Mechanismen, die die die API zur Verfügung stellt...!

Ich verwende aus verschiedenen Gründen, teilweise historisch bedingt, 
auch eine SQLite-DB zur Aufzeichnung und Bereitstellung von Messwerten. 
Dabei spielen ebenfalls mehrere unabhängige Prozesse im System 
(teilweise über mehrere Rechner verteilt) mit.

Beim Schreiben von Daten in die DB wird, durch die API ein Lock-Flag in 
der SQLite-DB selbst gesetzt. Bei jedem schreibenden und lesenden 
Zugriff wird durch die API dieses Flag abgefragt. Ist es gesetzt, wird 
eine entsprechende Fehlermeldung generiert, auf die im entsprechenden 
Programm sinnvoll reagiert werden sollte! Für einen schreibenden Prozess 
sollte es also z.B. bedeuten, dass er die Schreibanforderung puffern und 
es später noch einmal versuchen muss. Dieses Lock-Flag wird, nebenbei, 
nicht nur bei schreibenden Zugriffen gesetzt, sondern z.B. bei einem 
SQLite-internen Dump, Backup oder einer gesetzten Transaktion, bei dem 
die Daten auch konsistent bleiben sollen.

Ich habe die Sache sogar soweit getrieben, dass ich seit neuesten die 
Erfassung der Messwerte und das Schreiben in die DB auf zwei Prozesse 
verteilt habe. Die Prozesse kommunizieren via TCP/IP miteinander. Der 
Erfassungsprozess sendet also seine Insert-Statments zum Schreibprozess, 
der diese dann, wenn möglich, in die DB hämmert. Kann er dies nicht kann 
(z.B. DB locked), sendet er eine entsprechende Fehlermeldung an den 
Erfassungsprozess zurück, der die Inserts dann puffert und es irgendwann 
nochmal versucht. Das hat dann auch den Charme, dass man den "Schreiber" 
einfach mal stoppen kann und Wartungsaktionen o.ä. auf der DB 
durchführen kann, ohne dass Messdaten verloren gehen...

Ich habe letztes Jahr mal auf verschiedenen Linux-Veranstaltungen einen 
Vortrag zu dem Thema gehalten, hier die Folien dazu:
https://chemnitzer.linux-tage.de/2015/de/programm/beitrag/144

Grüße Uwe

Bern_Gast schrieb:
> Clemens L. schrieb:
>> das File Locking korrekt
>> implementieren
>
> Was meinst du damit?

Dass es in der Praxis meist läuft. Ausnahmen sind irgendwelche NAS, wo 
Locking ausgeschaltet wird, damit Benchmarks schneller laufen, oder 
nicht korrekt konfigurierte NFS-Implementationen, oder Windows-Systeme, 
die sich zwischendurch aufhängen (oplocks in SMB setzen voraus, dass 
sich alle Systeme schnell genug melden).

Siehe auch http://www.sqlite.org/howtocorrupt.html.

Aha. Gechekt. Neuer IT-Slang ? Geht's auch in verständlich ? ;)

Bern_Gast schrieb:
> --> Dieses Ablauf wird sich stets wiederholen.
>     Also die reihenfolge ist festgelegt und es ist fast unmöglich,
>        dass die beide Systeme gleichzeitig auf die DB zugegriffen wird.

Die fiesesten Bugs, die es gibt, sind die, deren Auftreten "fast 
unmöglich" ist.

Rolf M. schrieb:
> Bern_Gast schrieb:
>> --> Dieses Ablauf wird sich stets wiederholen.
>>     Also die reihenfolge ist festgelegt und es ist fast unmöglich,
>>        dass die beide Systeme gleichzeitig auf die DB zugegriffen wird.
>
> Die fiesesten Bugs, die es gibt, sind die, deren Auftreten "fast
> unmöglich" ist.

An der stelle gibt das aber kein Bug sondern einfach nur nen klleines 
bisschen wartezeit wegen dem lock :)