ActiveAndroid.beginTransaction() et multithread

Question

J'ai plusieurs listes que je souhaite stocker dans mon sqlite db dans une manière multithread using activeAndroid. Je cours un fil pour que chaque liste soit persistée.

Le corps de chaque fil ressemble à ceci. La transaction semble ajouter un verrou à la base de données car chaque thread s'exécute les uns après les autres. La transaction semble ajouter un verrou à la base de données. Sans utiliser la transaction, les choses fonctionnent comme prévu, mais les tâches sont assez lentes (a hundred time slowest).

Ce sujet est discuter here.

Quelqu'un sait comment éviter ce comportement? Merci

Answer 1

TL; DR: Un seul thread peut apporter des modifications, mais toutes peuvent lire les données.

Can multiple applications or multiple instances of the same application access a single database file at the same time?

Plusieurs processus peuvent avoir la même base de données ouvertes en même temps. Plusieurs processus peuvent faire un SELECT en même temps. Cependant, un seul processus peut apporter des modifications à la base de données à tout moment. SQLite utilise des verrous de lecture/écriture pour contrôler l'accès à la base de données. (Sous Win95/98/ME qui ne supporte pas les verrous lecteur/graveur, une simulation probabiliste est utilisée à la place.) Mais attention: ce mécanisme de verrouillage peut ne pas fonctionner correctement si le fichier de base de données est conservé sur un système de fichiers NFS. C'est parce que le verrouillage de fichier fcntl() est brisé sur de nombreuses implémentations NFS. Vous devez éviter de placer des fichiers de base de données SQLite sur NFS si plusieurs processus tentent d'accéder au fichier en même temps. Sous Windows, la documentation de Microsoft indique que le verrouillage peut ne pas fonctionner sous les systèmes de fichiers FAT si vous n'exécutez pas le démon Share.exe. Les personnes qui ont beaucoup d'expérience avec Windows me disent que le verrouillage des fichiers réseau est très buggé et n'est pas fiable. Si ce qu'ils disent est vrai, le partage d'une base de données SQLite entre deux machines Windows ou plus peut provoquer des problèmes inattendus.

Nous n'avons connaissance d'aucun autre moteur de base de données Embedded SQL prenant en charge autant d'accès concurrent que SQLite. SQLite permet à plusieurs processus d'ouvrir le fichier de base de données en même temps et à plusieurs processus de lire la base de données à la fois. Quand un processus veut écrire, il doit verrouiller le fichier de base de données entier pendant la durée de sa mise à jour. Mais cela ne prend normalement que quelques millisecondes. D'autres processus attendent simplement que l'auteur termine, puis continuent leur travail. D'autres moteurs de base de données SQL embarqués n'autorisent généralement qu'un seul processus à se connecter à la base de données en même temps. Toutefois, les moteurs de base de données client/serveur (tels que PostgreSQL, MySQL ou Oracle) prennent généralement en charge un niveau de concurrence plus élevé et permettent à plusieurs processus d'écrire simultanément dans la même base de données. Ceci est possible dans une base de données client/serveur car il existe toujours un seul processus serveur bien contrôlé disponible pour coordonner l'accès. Si votre application a besoin d'une grande concurrence, vous devriez envisager d'utiliser une base de données client/serveur. Mais l'expérience suggère que la plupart des applications nécessitent beaucoup moins de simultanéité que ce que leurs concepteurs imaginent. Lorsque SQLite tente d'accéder à un fichier qui est verrouillé par un autre processus, le comportement par défaut est de retourner SQLITE_BUSY. Vous pouvez ajuster ce comportement à partir du code C à l'aide des fonctions de l'API sqlite3_busy_handler() ou sqlite3_busy_timeout().

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