La fermeture de la base de données dans un ContentProvider

Cette semaine, j'ai été à l'apprentissage tout au sujet de ContentProvider et à l'aide de la SQLiteOpenHelper classe pour gérer la création et la mise à niveau de la base de données à l'intérieur d'un prestataire. Plus précisément, j'ai de la lecture à travers l'exemple le bloc-notes dans le kit de développement du répertoire d'exemples.

Maintenant, je peux voir que SQLiteOpenHelper a une méthode close (). Je suis conscient que le laisser inactif bases de données open est une mauvaise pratique et peut provoquer des fuites de mémoire et autres joyeusetés (sauf cette discussion est dirigé dans la bonne direction). Si je ont été à l'aide de la classe dans une Activité, je voudrais simplement appeler close() dans le onDestroy() la méthode, mais pour autant que je sais, ContentProvider n'ont pas le même cycle de vie que les activités à faire. Le code pour le bloc-notes ne semble jamais à appeler close(), je voudrais donc supposer qu'il est manipulé par SQLiteOpenHelper ou une autre pièce du puzzle, mais j'aimerais vraiment le savoir. Je n'ai pas vraiment confiance en l'exemple de code que beaucoup, que ce soit...

Question résumé: Quand doit-on fermer la base de données à un fournisseur, le cas échéant?

  • Dianne Hackborn a dit, il ya pas besoin de fermer la db.
  • C'est l'information la plus importante sur ce fil. J'ai fait une réponse.
InformationsquelleAutor SilithCrowe | 2010-12-28
  1. 90

    Selon Dianne Hackborn (Android cadre de l'ingénieur) il n'est pas nécessaire de fermer la base de données un fournisseur de contenu.

    Un fournisseur de contenu est créé lors de son processus d'hébergement est créé, et
    reste aussi longtemps que le processus n'est, donc, il n'est pas nécessaire de
    fermez la base de données, il sera fermé, comme une partie du noyau
    nettoyer les ressources du processus, lorsque le processus est tué.

    Merci @bigstones pour le rappeler.

    • Merci. Btw, ils (Android équipe) doit commenter cette "simple" chose en directive, ou au moins dans l'exemple de code, plutôt que de laisser les codeurs de rechercher sur le net.
    • ne me lancez pas sur ce qui est manquant 🙂
    • Ok, mais que fait la fonction arrêt à faire. Le code est: public void shutdown() { Log.w(TAG, "mettre en œuvre ContentProvider arrêt() pour s'assurer de la base de données" + "connexions sont gracieusement arrêt"); }
    InformationsquelleAutor philipp
  2. 21

    Cette question est un peu vieux mais il est encore tout à fait pertinente. Notez que si vous êtes en train de faire des choses "moderne" (par exemple à l'aide de LoaderManager et la création de CursorLoaders à la requête d'un ContentProvider dans un thread d'arrière-plan), assurez-vous que vous n'appelez PAS db.close() dans votre ContentProvider mise en œuvre. J'ai été faire toutes sortes d'incidents relatifs à CursorLoader/AsyncTaskLoader lorsqu'il a essayé d'accéder à la ContentProvider dans un thread d'arrière-plan, qui ont été résolus par le retrait de la db.close() appels.

    Donc, si vous êtes en cours d'exécution dans les incidents qui ressemble à ceci (Jelly Bean 4.1.1):

    Caused by: java.lang.IllegalStateException: Cannot perform this operation because the connection pool has been closed.
at android.database.sqlite.SQLiteConnectionPool.throwIfClosedLocked(SQLiteConnectionPool.java:962)
at android.database.sqlite.SQLiteConnectionPool.waitForConnection(SQLiteConnectionPool.java:677)
at android.database.sqlite.SQLiteConnectionPool.acquireConnection(SQLiteConnectionPool.java:348)
at android.database.sqlite.SQLiteSession.acquireConnection(SQLiteSession.java:894)
at android.database.sqlite.SQLiteSession.executeForCursorWindow(SQLiteSession.java:834)
at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:62)
at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:143)
at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:133)
at android.content.ContentResolver.query(ContentResolver.java:388)
at android.content.ContentResolver.query(ContentResolver.java:313)
at com.hindsightlabs.paprika.loaders.GroceryListLoader.loadInBackground(GroceryListLoader.java:147)
at com.hindsightlabs.paprika.loaders.GroceryListLoader.loadInBackground(GroceryListLoader.java:1)
at android.support.v4.content.AsyncTaskLoader.onLoadInBackground(AsyncTaskLoader.java:240)
at android.support.v4.content.AsyncTaskLoader$LoadTask.doInBackground(AsyncTaskLoader.java:51)
at android.support.v4.content.AsyncTaskLoader$LoadTask.doInBackground(AsyncTaskLoader.java:40)
at android.support.v4.content.ModernAsyncTask$2.call(ModernAsyncTask.java:123)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
... 4 more

    Ou ce (ICS 4.0.4):

    Caused by: java.lang.IllegalStateException: database /data/data/com.hindsightlabs.paprika/databases/Paprika.db (conn# 0) already closed
at android.database.sqlite.SQLiteDatabase.verifyDbIsOpen(SQLiteDatabase.java:2215)
at android.database.sqlite.SQLiteDatabase.lock(SQLiteDatabase.java:436)
at android.database.sqlite.SQLiteDatabase.lock(SQLiteDatabase.java:422)
at android.database.sqlite.SQLiteQuery.fillWindow(SQLiteQuery.java:79)
at android.database.sqlite.SQLiteCursor.fillWindow(SQLiteCursor.java:164)
at android.database.sqlite.SQLiteCursor.getCount(SQLiteCursor.java:156)
at android.content.ContentResolver.query(ContentResolver.java:318)
at android.support.v4.content.CursorLoader.loadInBackground(CursorLoader.java:49)
at android.support.v4.content.CursorLoader.loadInBackground(CursorLoader.java:35)
at android.support.v4.content.AsyncTaskLoader.onLoadInBackground(AsyncTaskLoader.java:240)
at android.support.v4.content.AsyncTaskLoader$LoadTask.doInBackground(AsyncTaskLoader.java:51)
at android.support.v4.content.AsyncTaskLoader$LoadTask.doInBackground(AsyncTaskLoader.java:40)
at android.support.v4.content.ModernAsyncTask$2.call(ModernAsyncTask.java:123)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
... 4 more

    Ou si vous voyez des messages d'erreur dans le LogCat qui ressemblent à ceci:

    Cursor: invalid statement in fillWindow()

    Puis vérifiez votre ContentProvider la mise en œuvre et assurez-vous que vous n'êtes pas la fermeture de la base de données prématurément. Selon cette, le ContentProvider aurez nettoyé automatiquement lorsque le processus est tué de toute façon, de sorte que vous n'avez pas besoin de fermer sa base de données à l'avance.

    Cela dit, assurez-vous que vous êtes toujours correctement:

    1. La fermeture de vos Curseurs qui sont retournés à partir ContentProvider.query(). (CursorLoader/LoaderManager le fait automatiquement pour vous, mais si vous êtes en train de faire des requêtes directes à l'extérieur de la LoaderManager cadre, ou que vous avez mis en œuvre un custom CursorLoader/AsyncTaskLoader sous-classe, vous devrez assurez-vous que vous êtes le nettoyage de vos curseurs correctement.)
    2. La mise en œuvre de votre ContentProvider dans un thread-safe façon. (La meilleure façon de le faire est de s'assurer que votre base de données, les méthodes d'accès sont enveloppés dans un synchronisé bloc.)
    InformationsquelleAutor Steven
  3. 13

    Ive suivre Mannaz de réponse et vu que SQLiteCursor(database, driver, table, query); constructeur est obsolète. Ensuite, j'ai trouvé getDatabase() méthode et l'a utilisé à la place de mDatabase pointeur; et gardé constructeur pour assurer une compatibilité descendante

    public class MyOpenHelper extends SQLiteOpenHelper {
public static final String TAG = "MyOpenHelper";
public static final String DB_NAME = "myopenhelper.db";
public static final int DB_VESRION = 1;
public MyOpenHelper(Context context) {
super(context, DB_NAME, new LeaklessCursorFactory(), DB_VESRION);
}
//...
}
public class LeaklessCursor extends SQLiteCursor {
static final String TAG = "LeaklessCursor";
public LeaklessCursor(SQLiteDatabase db, SQLiteCursorDriver driver,
String editTable, SQLiteQuery query) {
super(db, driver, editTable, query);
}
@Override
public void close() {
final SQLiteDatabase db = getDatabase();
super.close();
if (db != null) {
Log.d(TAG, "Closing LeaklessCursor: " + db.getPath());
db.close();
}
}
}
public class LeaklessCursorFactory implements CursorFactory {
@Override
public Cursor newCursor(SQLiteDatabase db, SQLiteCursorDriver masterQuery,
String editTable, SQLiteQuery query) {
return new LeaklessCursor(db,masterQuery,editTable,query);
}
}
    • J'aime quand les gens prennent le temps de répondre/mettre à jour les anciennes questions. Grâce Pleerock! Semble que j'ai besoin de revenir sur cette...
    • YW. Au fait, j'ai trouvé quelques "fuites" dans notre LeaklessCursor. Elle n'est pas efficace lorsque vous utilisez les fournisseurs de contenu. Par exemple, lorsque vous êtes à la mise à jour des données dans la base de données, votre curseur sera aussi mis à jour. Si ce curseur sera fermé et nouvelle curseur sera ouvert. Lors de notre curseur sera fermé, notre base de données sera fermé trop. Il peut provoquer une erreur. Par exemple: ContentProvider(ouvre la base de données)->query(pour le curseur, utilise db)->mise à jour(toutes les données, utilise db)->informe->ferme d'un vieux curseur(ferme également db)->crée de nouveaux curseur(requête, utilise db) et POOOOW erreur -> db a été fermé, impossible d'ouvrir le nouveau curseur
    • si le getDatabase() appel peut renvoyer null, puis le Journal.d(...) pouvait provoquer un crash, j'ai mis dans une édition qui se déplace dans le Journal pour le if, et met getDatabase() dans une référence, puisque vous l'utiliser 3 fois. Vous pouvez ajouter un Journal à l'extérieur de l'if qui vous permet de savoir que vous "doit" avoir fermé une base de données, indépendamment de si getDatabase() a la valeur null si c'est utile.
    • Remarque. L'idée de la fermeture de la base de données dans un ContentProvider n'est pas si bon. Évitez si vous le pouvez. "La fermeture de la fuite de curseur" peut conduire à beaucoup d'autres fuites. Fournisseur de contenu est pour des requêtes de base de données, de sorte qu'il utilise toujours la base de données. Même si vous avez déjà terminé vos requêtes, fournisseur de contenu (et de l'instance de base de données) peut dépendre d'autres classes
    • Merci, vous avez sauvé ma journée !
    InformationsquelleAutor pleerock
  4. 7

    Si vous voulez que votre Base de données pour fermer automatiquement, vous pouvez fournir une CursorFactory ouverture:

    mContext.openOrCreateDatabase(DB_NAME, SQLiteDatabase.OPEN_READWRITE, new LeaklessCursorFactory());

    Voici les classes:

    public class LeaklessCursorFactory implements CursorFactory {
@Override
public Cursor newCursor(SQLiteDatabase db, SQLiteCursorDriver masterQuery,
String editTable, SQLiteQuery query) {
return new LeaklessCursor(db,masterQuery,editTable,query);
}
}
public class LeaklessCursor extends SQLiteCursor {
static final String TAG = "LeaklessCursor";
final SQLiteDatabase mDatabase;
public LeaklessCursor(SQLiteDatabase database, SQLiteCursorDriver driver, String table, SQLiteQuery query) {
super(database, driver, table, query);
mDatabase = database;
}
@Override
public void close() {
Log.d(TAG, "Closing LeaklessCursor: " + mDatabase.getPath());
super.close();
if (mDatabase != null) {
mDatabase.close();
}
}
}
    • Note pour les autres: Veuillez noter Pleerock de réponse, puisque les mises à jour de cette réponse dans un petit mais important. C'est une excellente solution, en passant, j'ai toujours un peu de vertige quand je vois la bonne utilisation de modèles de conception. 😛
    InformationsquelleAutor whlk
  5. 1

    Le fermer lorsque vous avez terminé avec elle, de préférence dans un bloc finally vous pouvez vous assurer que ça se passe. Je sais que cela semble un peu banal et hors-la-brassard, mais c'est vraiment la seule réponse que je sache. Si vous ouvrez la base de données et effectuer une action, le fermer lorsque vous avez terminé avec cette action, sauf si vous savez pour un fait, il sera à nouveau nécessaire (dans ce cas, assurez-vous de le fermer une fois il n'est plus nécessaire).

    • La seule manière pour nous de savoir si nous aurons encore besoin est à partir de l'extérieur du fournisseur (dans le code qui l'utilise). Je pense qu'à l'intérieur du fournisseur de la base de données est consultée chaque fois getWriteableDatabase() ou getReadableDatabase() est appelée sur le SQLiteOpenHelper. Basé sur votre suggestion, dois-je ajouter une close() par la suite, dans chaque méthode, où ils sont appelés? Il semble comme si plusieurs requêtes ont été exécutées l'une après l'autre, puis il y en avait tout un tas de base de données de l'ouverture et de la fermeture de passe. Je ne suis pas sûr, mais j'imagine qu'aurait une incidence sur les performances.
    InformationsquelleAutor Ginger McMurray
  6. 0

    Si vous êtes à l'aide de votre fournisseur de contenu à l'intérieur d'une activité, alors je ne crois pas que vous avez à maintenir la connexion du fournisseur de contenu. Vous pouvez simplement gérer le curseur de l'objet renvoyé en utilisant startManagingCursor. Dans la méthode onPause de l'activité, vous pouvez relâcher le fournisseur de contenu. ( vous pouvez la recharger en onResume). En supposant que l'activité du cycle de vie le plus souvent limités, cela devrait suffire. (Atleast selon moi ;))

    • Bien sûr, si vous utilisez sql lite, vous pouvez fermer la connexion après l'obtention des résultats. (Encore une fois assurez-vous que le curseur du cycle de vie est géré par l'activité à l'aide de startmanagingcursor.
    InformationsquelleAutor uncaught_exceptions