SQLiteOpenHelper connexion unique vs connexions multiples

Question

Je suis très confus en ce qui concerne l'accès à SQLiteDatabase . Il faut soit une seule connexion, soit des connexions multiples pour avoir accès à plusieurs fils. J'ai lu de nombreux articles, dont les deux suivants.

https://stackoverflow.com/a/3689883/3027124 http://touchlabblog.tumblr.com/post/24474398246/Android-sqlite-locking

Les deux recommandent d'avoir une seule connexion. Même ma propre réponse à la même question a été acceptée par le PO. J'ai utilisé le Singleton approche de l'accès SQLiteopenHelper classe.

https://stackoverflow.com/a/35358702/3027124

Mais Je suis toujours confus après avoir lu la documentation de enableWriteAheadLogging qui stipule

Cette méthode permet d'exécuter en parallèle des requêtes provenant de plusieurs pays. threads sur la même base de données. Pour ce faire, elle ouvre plusieurs connexions à la base de données et en utilisant une connexion de base de données différente pour chaque requête. Le mode journal de la base de données est également modifié pour permettre d'écrire en même temps que de lire.

Maintenant, c'est la partie qui prête à confusion. Si je veux accéder à la base de données à partir de plusieurs threads simultanés, je dois Singleton l'accès à SQLiteOpenHelper ce qui, dans ma compréhension, signifie l'exécution en série des insertions alors que les lectures simultanées peuvent être faites sans erreur. Mais la documentation ci-dessus dit que pour avoir un accès simultané, enableWriteAheadLogging doit être appelé, ce qui a pour effet de créer des connexions multiples. Que se passe-t-il ? Qu'est-ce que cela signifie si je fais des insertions en appelant getWritableDatabase() en utilisant Singleton SQLiteOpenHelper à partir de plusieurs fils ? Les appels seront-ils sériels ? Est-ce que enableWriteAheadLogging être appelé ?

Veuillez clarifier.

Answer 1

J'utiliserais l'instance singleton, que je sois en train d'utiliser enableWriteAheadLogging ou pas lorsqu'il s'agit de threading, ce qui est le cas dans la plupart des applications, sauf s'il s'agit d'une application très triviale comme un échantillon.

L'utilisation d'une instance singleton garantit Sécurité du fil : L'instance singleton garantit que la synchronisation fonctionne à travers cette instance, ce qui signifie que lorsque vous avez une méthode de lecture et d'écriture appelant la base de données en même temps à partir de différents threads, l'un d'entre eux doit attendre l'autre car la base de données est verrouillée lors de l'écriture dans celle-ci.

Il est très clair que c'est le cas, comme l'indique la documentation et la citation ci-dessous.

ce n'est pas possible que les lectures et les écritures se produisent sur la base de données en même temps. même temps. Avant de modifier la base de données, le rédacteur acquiert implicitement un verrou exclusif sur la base de données. verrou exclusif sur la base de données qui empêche les lecteurs d'accéder à la la base de données jusqu'à ce que l'écriture soit terminée.

enableWriteAheadLogging modifie en fait le comportement ci-dessus, car la déclaration ci-dessus n'est vraie que lorsque la journalisation en écriture n'est pas activée (par défaut).

Alors que se passe-t-il lorsque vous activez la journalisation en écriture anticipée via enableWriteAheadLogging ?

En fait, il modifie le comportement par défaut en permettant un parrallélisme réel, car il modifie le fichier journal de la base de données sous-jacente pour permettre d'effectuer une écriture et une lecture en même temps, mais pour ce faire, il a besoin de plus de mémoire que d'habitude. Lisez la citation de la documentation ci-dessous pour en savoir plus !

En revanche, lorsque l'enregistrement en écriture anticipée est activé (en appelant la commande méthode), les opérations d'écriture se produisent dans un fichier journal séparé qui permet de lire en même temps. Pendant qu'une écriture est en cours, les lecteurs sur d'autres threads percevront l'état de la base de données tel qu'il était avant le début de l'écriture. Lorsque l'écriture est terminée, les lecteurs des autres d'autres threads percevront le nouvel état de la base de données.

C'est une bonne idée d'activer la journalisation en écriture dès qu'une base de données base de données est accédée et modifiée par plusieurs threads en même même temps. Cependant, la journalisation write-ahead utilise beaucoup plus de mémoire que la journalisation ordinaire, car il y a plusieurs connexions à la même même base de données. Donc, si une base de données ne sera utilisée que par un seul thread, ou si l'optimisation de la concurrence n'est pas très importante, la journalisation en écriture doit être désactivée.