SQLite et MultiThreading (via Wrapper C++)

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 :roll:
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 ?

Bonjour,

Je viens de voir ça sur la doc officielle :

Citation:

---

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?

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

salut, regarde là http://www.developpez.net/forums/d51...lite3_prepare/ cela ressemble à ton problême non ? donc de facto tu as peut être une réponse

... et peut être aussi


ainsi que
http://www.sqlite.org/lockingv3.html
et
http://www.sqlite.org/faq.html#q5
et2
http://sqlite.org/atomiccommit.html

hope this helps :)

Sur ta base, tu as vérifié que le "PRAGMA locking_mode" est sur la valeur NORMAL?

http://www.sqlite.org/pragma.html

Hello,
merci pour vos messages ; j'étais passé à autres choses entre temps.
Pour revenir à mon problème... et bien il est toujours là.
Je commence à connaître par coeur la doc SQLite sur les locks, mais sans avoir trouvé mon bonheur :( . En plus du lock géré automatiquement par SQLite, il y a un lock positionné par le wrapper (mutex décrit dans mon premier post).
Visiblement tout à l'air bien, le locking_mode se trouve à sa valeur par défaut (NORMAL).
Je ne peux utiliser le "atomic commit" du fait de contraintes sur le programme : les écritures doivent se faire dès que possible afin que la lecture suivante possède les mises à jour.
J'ai réussi à réduire l'occurrence du problème en travaillant en RAM (fichier copié vers un disque RAM) et en désactivant le rollback. Les temps d'accès sont de fait raccourcis.
Mais il arrive encore que le problème se pose :cry:
Lorsque je trouverai l'origine du problème, je vous tiendrai informé. (je ne désespère pas encore !)
Encore merci pour votre aide.
Aymerik

Bonsoir,

Si tu tiens à une réponse en béton, je te conseille la démarche suivante :
- tu reformules ta question avec les termes et l'environnement le plus précis qu'il te semble possible : mais en anglais,
- tu t'abonnes au forum de discussion anglais des utilisateurs :
http://sqlite.org:8080/cgi-bin/mailm...o/sqlite-users

ou à celui des développeurs si tu n'as aucune réponse correcte (dans ce cas, tu as intérêt à bien cerner ton problème)
http://sqlite.org:8080/cgi-bin/mailm...nfo/sqlite-dev

Pour ma part, c'est le top et tu auras un retour d'expérience à la hauteur de tes difficultés. Il est même probable que l'un des concepteurs de SQLite te réponde. Ils sont accessibles et passionnés.

Bonne traque,
++

Salut Bigane,
merci de ta réponse ;)
En fait, j'ai déjà posté sur la mailing list 'users' ici : http://www.mail-archive.com/sqlite-u.../msg51325.html , mais n'ai pas eu de réponse... :cry:
Je vais donc tenter comme tu me l'as conseillé la mailing list 'dev'.

J'en profite au passage : trouves-tu mon message clair, ou y aurait il quelque chose à clarifier avant de le poster sur l'autre mailing list ?

Merci bien,
++
Aymerik