- L’un des malentendus les plus fréquents à propos de SQLite est de penser que « SQLite est une base de données qui n’autorise qu’une seule connexion », ce qui conduit certaines personnes à ne pas l’utiliser
- C’est à la fois source de confusion (que signifie exactement « connexion » ici ?) et faux à plusieurs égards
- Opérations de lecture (Read Operations)
- SQLite prend parfaitement en charge plusieurs opérations de lecture simultanées
- Il est possible de lire des données simultanément depuis plusieurs « connexions », sans conflit ni problème
- Opérations d’écriture (Write Operations)
- SQLite utilise un verrou d’écriture au niveau de la base de données (Write Lock) lors des opérations d’écriture
- Il n’autorise pas plusieurs opérations d’écriture en même temps ; ainsi, une seule « connexion » peut effectuer une écriture à la fois
- En général, cela ne pose pas de problème, car il est possible de démarrer une
IMMEDIATE TRANSACTION
- Dans ce cas, SQLite peut réessayer dans la file d’attente afin d’obtenir le verrou d’écriture
- (cette méthode permet d’exécuter automatiquement l’opération d’écriture une fois le verrou d’écriture libéré)
1 commentaires
https://www.sqlite.org/lockingv3.html
5.0 Écriture dans le fichier de base de données
Pour écrire dans la base de données, un processus doit d’abord acquérir un verrou SHARED, comme décrit plus haut. Après avoir acquis un verrou SHARED, il doit ensuite acquérir un verrou RESERVED. Un verrou RESERVED signale que le processus écrira dans la base de données à un moment donné dans le futur. Un seul processus à la fois peut détenir un verrou RESERVED. Cependant, d’autres processus peuvent continuer à lire la base de données pendant qu’un verrou RESERVED est maintenu.