SQLite et MultiThreading (via Wrapper C++)

**Aymerik** · 20/03/2010, 16h36

Bonjour à tous,
je poste ici un problème que je n'arrive pas à résoudre, malgré mes recherches et tentatives...

Le contexte : je bosse sur une application C++ sous WinCE (donc domaine embarqué) ; qui utilise SQLite (version 3.6.11) à travers un wrapper C++. Une seule DB (qui contient 3 tables), DB stockée en local.
Voici ce qui me pose problème : il y a deux threads concurrents, l'un accèdant à la DB uniquement en lecture, l'autre en écriture ou lecture.
Le wrapper cité précédemment gère les accès concurrents via un mutex (les deux threads utilisent bien sûr la même instance d'objet Database) : chaque nouvel objet Query créé "locke" l'instance de Database (et la "unlocke" dans son destructeur). De fait, il ne peut y avoir en même temps deux instances de Query faisant référence à la même Database (j'ai vérifié tout cela avec des traces/assert ; tout est OK, la Database est bien "unlockée" après chaque Query...)
Sauf qu'il arrive que des écritures ou des lectures échouent (erreur remontée par le moteur SQLite : "database is locked" / SQLITE_BUSY)

Par rapport aux contraintes que j'ai, je ne peux me permettre de mémoriser l'ensemble des écritures à faire pour les faire par paquet au sein d'une seule transaction ; je dois donc les faire au fur et à mesure.

La documentation officielle parle d'un flag de compilation (THREADSAFE=1) afin d'utiliser des mutex directement au niveau de la couche SQLite3. La définition de ce flag n'a pas résolu mon problème, j'ai toujours ces conflits. (En même temps, le wrapper gère normalement déjà l'exclusivité d'utilisation de la DB).
Edit : après activation du flag, j'ai remplacé l'ouverture de la base de donnée sqlite3_open (fait dans Database::grabdb) par un sqlite3_open_v2 avec les flags (SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_FULLMUTEX) ; mais sans succès...

Vous aurez compris, je cherche à ne plus avoir d'erreur d'accès, mais là je suis un peu à cours d'idée

L'un d'entre vous aurait il des suggestions svp ?
(Si jamais je n'ai pas été très clair, dites le moi, je tenterai de réexpliquer plus clairement !)
Merci d'avance et bon week-end,
Aymerik

ps : question annexe : à travers une appli de test reproduisant systématiquement le cas décrit ci-dessus, j'ai remarqué qu'après la fin des accès des threads à la DB (threads quittés), je vois le fichier journal apparaître/disparaître pendant plusieurs secondes (ou dizaines de secondes selon le temps d'éxécution des threads, donc selon le nombre de requêtes effectuées). Comment cela se fait il ? Y a t il une sorte de cache au niveau sqlite3 ?

**Kentin** · 22/03/2010, 09h37

Bonjour,

Je viens de voir ça sur la doc officielle :

But use caution: this locking mechanism might not work correctly if the database file is kept on an NFS filesystem. This is because fcntl() file locking is broken on many NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at the same time.

http://www.sqlite.org/faq.html#q5

C'est peut-être ton cas?

**Aymerik** · 24/03/2010, 11h21

Salut Kentin,
merci de ta réponse.
J'ai suivi le lien que tu m'as donné, et le cas décrit n'est malheureusement pas mon cas : le système de fichier est de la FAT (plus précisément de la TexFAT).
Je continue à chercher ; vous serez informés si je trouve quelque chose !
Cordialement,
Aymerik