SQLite gère-t-il de manière sûre les accès simultanés par de multiples processus qui lisent/écrivent à partir d'une même base de données ? Y a-t-il des exceptions à cette règle ?
En 2019, il existe deux nouvelles options d'écriture simultanée non encore publiées mais disponibles dans des branches distinctes.
L'avantage de ce mode journal par rapport au mode normal "wal" est que les écrivains peuvent continuer à écrire dans un fichier wal pendant que l'autre est en mode checkpointed.
COMMENCER À CONCOURIR - lien vers le document détaillé
L'amélioration BEGIN CONCURRENT permet à plusieurs rédacteurs de traiter des transactions d'écriture simultanément si la base de données est en mode "wal" ou "wal2", bien que le système sérialise toujours les commandes COMMIT.
Lorsqu'une transaction d'écriture est ouverte avec "BEGIN CONCURRENT", le verrouillage effectif de la base de données est différé jusqu'à l'exécution d'un COMMIT. Cela signifie qu'un nombre quelconque de transactions lancées avec BEGIN CONCURRENT peuvent se dérouler simultanément. Le système utilise un verrouillage optimiste au niveau des pages pour éviter que des transactions concurrentes conflictuelles ne soient validées.
Ensemble, ils sont présents dans début-concurrent-wal2 ou chacun dans un propre branche .
Avons-nous une idée de la date à laquelle ces fonctionnalités seront intégrées à la version finale ? Elles pourraient vraiment m'être utiles.
Aucune idée. Vous pourriez construire facilement à partir des branches. Pour .NET, j'ai une bibliothèque avec une interface de bas niveau et WAL2 + begin concurrent + FTS5 : github.com/Spreads/Spreads.SQLite
Oh, bien sûr, merci. Je m'interroge plutôt sur la stabilité. SQLite est plutôt bon quand il s'agit de ses versions, mais je ne sais pas s'il serait risqué d'utiliser une branche dans un code de production.
Ce fil de discussion est ancien mais je pense qu'il serait bon de partager les résultats de mes tests effectués sur sqlite : J'ai exécuté 2 instances du programme python (différents processus, même programme) en exécutant les commandes sql SELECT et UPDATE dans une transaction avec un verrou EXCLUSIF et un délai de 10 secondes pour obtenir un verrou, et les résultats étaient frustrants. Chaque instance a fait une boucle de 10000 pas : - connexion à la base de données avec verrou exclusif - sélection sur une ligne pour lire le compteur - mise à jour de la ligne avec une nouvelle valeur égale au compteur incrémenté de 1 - fermeture de la connexion à la base de données
Même si sqlite a accordé un verrou exclusif sur la transaction, le nombre total de cycles réellement exécutés n'était pas égal à 20 000 mais inférieur (nombre total d'itérations sur un seul compteur compté pour les deux processus). Le programme Python n'a pratiquement pas lancé d'exception (une seule fois pendant la sélection pour 20 exécutions). La révision de sqlite au moment du test était 3.6.20 et python v3.3 CentOS 6.5. À mon avis, il est préférable de trouver un produit plus fiable pour ce type de travail ou de limiter les écritures dans sqlite à un seul processus/thread.
Il semble qu'il faille prononcer quelques mots magiques pour obtenir un verrou en python, comme indiqué ici : stackoverflow.com/a/12848059/1048959 Ceci malgré le fait que la documentation python sqlite vous laisse croire que with con est suffisant.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
5 votes
J'ai oublié de mentionner le prime goall : la plupart des réponses disent que c'est bon : "mais, à mon avis, ne répondent pas en détail / n'expliquent pas clairement ce qui se passe si deux opérations d'écriture arrivent exactement au même moment (cas théorique très rare). 1) Est-ce que cela déclencherait une erreur et interromprait le programme ? ou 2) Est-ce que la deuxième opération d'écriture attendrait que la première soit terminée ? ou 3) Est-ce que l'une des opérations d'écriture serait abandonnée (perte de données !)? 4) Autre chose ? Connaître les limites de l'écriture simultanée peut être utile dans de nombreuses situations.
7 votes
@Basj En bref,2)il attendra et réessayera plusieurs fois(configurable),1)déclenchera une erreur,SQLITE_BUSY.3)vous pouvez enregistrer un Callback pour gérer les erreurs SQLITE_BUSY.