Android le filetage et le verrouillage de base de données

J'ai résolu ce même exception en s'assurant simplement que tous mes base de données s'ouvre avons ferme, et (plus important) pour assurer cette, rendant la portée de chaque instance de base de données en local UNIQUEMENT à la méthode qui en a besoin. ContentProvider est un bon, coffre-fort classe à utiliser lors de l'accès à une base de données à partir de plusieurs threads, mais aussi assurez-vous que vous êtes en utilisant de bonnes db pratiques:

• Garder les instances db local (pas de SQLiteDatabase les membres de la classe!)
• appel close() sur la db dans la même méthode dans laquelle il est ouvert
• appel close() sur les curseurs que vous obtenez à partir de la db
• écouter LogCat pour toutes les plaintes que SQLiteDatabse pourrait avoir

Avant un peu de code, nous allons reprendre certaines des approches:

• Les sémaphores: de loin la meilleure solution présentée. Il va au cœur du problème: le partage de la ressource! Il permettra de traiter le verrouillage de l'accès à la base, éviter les conflits (database is locked).

• Java synchronisation: Une sorte de sémaphore de la mise en œuvre, mais moins sofisticated. À l'aide de synchronized vous ne sera pas facile à résoudre certains cas liés à des transactions.

• ContentProvider: mettre en œuvre ContentProvider résoudre le problème seulement pour certains cas (ou balayer le problème sous le tapis). Vous aurez encore confrontés aux mêmes problèmes. La différence est que ContentProvider modèle qui va vous guider pour ne pas faire quelques commum des erreurs lors de l'accès à la base de données Sqlite. Le ContentProvider docs dit: "Vous n'avez pas besoin d'un prestataire pour l'utilisation d'une base de données SQLite si l'utilisation est entièrement à l'intérieur de votre propre application."

• Presque obligatoire: garder les instances db local, appel close() sur la db dans la même méthode dans laquelle il est ouvert à l'aide de finally états, close() sur les curseurs à l'aide finally déclarations, etc sont presque obligatoire pour éviter les problèmes à l'aide de Sqlite.

Nous allons montrer un exemple de l'sémaphore solution présentée par la Mousse, que j'ai pris d' CL. et improoved pour couvrir les transactions.

class DataAccess {
private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
private final Lock r = rwl.readLock();
private final Lock w = rwl.writeLock();
public Data readSomething(int id) {
Cursor c = null;
r.lock();
try {
c = getReadableDatabase().query(...);
return c.getString(0);
} finally {
if (c != null) c.close();
r.unlock();
}
}
public void changeSomething(int id, int value) {
w.lock();
try {
getWritableDatabase().update(...);
} finally {
w.unlock();
}
}
private void beginTransactionWithSemaphores() {
getWritableDatabase().beginTransactionWithListener(new SQLiteTransactionListener() {
@Override
public void onBegin() {
w.lock();
}
@Override
public void onRollback() {
w.unlock();
}
@Override
public void onCommit() {
w.unlock();
}
});
}
}

Nous ne pouvions pas partager Db connexion avec plusieurs thread pour effectuer l'opération en lecture et écriture dans la base de données simultanément.Nous aurons à en faire l'unique objet de DB à l'aide de synchronisation concept et nous allons effectuer une tâche à la fois .Nous allons utiliser le pattern singleton pour rendre la base de données de l'objet et il sera partagé au sein de plusieurs threads.À un moment va effectuer la même tâche . ensuite, nous allons commencer d'autres tâches, ou toute autre opération sur DB .
Fournisseur de contenu n'est pas la solution de DB problème de verrouillage .

import java.util.concurrent.atomic.AtomicInteger;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
import android.util.Log;
public class DatabaseManager {
private AtomicInteger mOpenCounter = new AtomicInteger();
private static DatabaseManager instance;
private static SQLiteOpenHelper mDatabaseHelper;
private SQLiteDatabase mDatabase;
//private static String DB_PATH = "";
//  private static String DB_NAME = "xyz.db";// Database name
private static String dbPathh;
public static synchronized void initializeInstance(SQLiteOpenHelper helper,
String dbPath) {
if (instance == null) {
instance = new DatabaseManager();
mDatabaseHelper = helper;
dbPathh=dbPath;
}
}
public static synchronized DatabaseManager getInstance() {
if (instance == null) {
throw new IllegalStateException(DatabaseManager.class.getSimpleName() +
" is not initialized, call initializeInstance(..) method first.");
}
return instance;
}
public synchronized SQLiteDatabase openDatabase(String thread) {
if(mOpenCounter.get() == 0) {
// Opening new database
// mDatabase = mDatabaseHelper.getWritableDatabase();
MyLog.e("Path Of DataBase", dbPathh);
//  mDatabase=mDatabaseHelper.getWritableDatabase();
mOpenCounter.incrementAndGet();
mDatabase=SQLiteDatabase.openDatabase(dbPathh, null,   
SQLiteDatabase.  CREATE_IF_NECESSARY|SQLiteDatabase.OPEN_READWRITE);   
MyLog.e("Open Data Base", " New Connection created" +thread);
}
else{
MyLog.e("Open Data Base", " Old Connection given " +thread);
}
//  Toast.makeText(NNacres.getConfig(), "open conn: present connection = 
"   +mOpenCounter.get(), Toast.LENGTH_LONG).show();
return mDatabase;
}
public synchronized void closeDatabase() {
MyLog.e("Close db connection", ""+mOpenCounter.get());
if(mOpenCounter.get() == 1) {
// Closing database
mDatabase.close();
mOpenCounter.decrementAndGet();
Log.e("DB CLOSED", "DONE");
}
//Toast.makeText(NNacres.getConfig(), "close conn: after close =   
" +mOpenCounter.get(), Toast.LENGTH_LONG).show();
}
}

et d'écrire cette méthode dans votre YourSQLiteDataABse de la classe helper qui s'étend SQLiteOpenHelper Classe

     public SQLiteDatabase getWritableDatabase() {
DatabaseManager.initializeInstance(this,"data/data/your packgae name/databases/xyz");
return DatabaseManager.getInstance().openDatabase(getClass().getSimpleName());
}
public static String getMyDbPath(String DB_NAME, Context context) {
String myDbPath = context.getDatabasePath(DB_NAME).getPath();
MyLog.e("DB Path: "+myDbPath);
return myDbPath;
}

Vous parlent d'une seule action de l'utilisateur qui, à l'intérieur de votre programme, les causes de plusieurs threads pour exécuter plus d'une qui peut être accéder à la base de données en mode de mise à jour ?

C'est une mauvaise conception, de la période. Il n'y a aucun moyen pour vous de savoir l'ordre dans lequel les threads seront programmées par votre système d'exploitation (/VM), et, par conséquent, il n'existe aucun moyen pour vous de savoir l'ordre dans lequel les accès base de données qui va se passer, et qui est très probablement impliquer qu'il n'existe aucun moyen pour vous de savoir que les accès base de données sera toujours le cas dans l'ordre que vous attendez.

Tous les accès base de données généré par/à venir à partir d'une action de l'utilisateur doit être fait dans un seul thread.