DB de SQLite accedido desde múltiples subprocesos

Considere la siguiente: Tengo el Service , que escribe en DB en AsyncTask . Y mi actividad lee datos de DB (considere el hilo de UI para la simplicidad). Tengo acceso a DB usando SQLiteOpenHelper . Crear instancia única en Application onCreate () y luego obtenerlo en servicio y actividad. ¿Existe alguna posibilidad de que mi DB 'bloqueado'? Anteriormente, usé ContentProvider para estas operaciones. Sin embargo, se basa en el uso de una sola instancia de SQLiteOpenHelper , decidí simplificar mi proyecto excluyendo ContentProvider .

Considere el código:

 public class App extends Application { private OpenHelper openHelper; @Override public void onCreate(){ super.onCreate(); openHelper=new OpenHelper(); } public OpenHelper getHelper(){ return openHelper; } } 

En Actividad:

 OpenHelper helper=(App)getApplication().getHelper(); SQLiteDatabase db=helper.getReadableDatabase(); // Do reading 

Y dentro de Serice, en hilo separado:

 OpenHelper helper=(App)getApplication().getHelper(); SQLiteDatabase db=helper.getWritableDatabase(); //Do writing 

¿Sería seguro?

UPD Esta puede ser la solución, pero no está seguro de cómo usarla.

5 Solutions collect form web for “DB de SQLite accedido desde múltiples subprocesos”

Respuesta tardía y tardía. Estás totalmente bien. Esa es la manera correcta de hacerlo, en realidad. Ver mi entrada en el blog: http://touchlabblog.tumblr.com/post/24474750219/single-sqlite-connection/ . Cavar a través de mi perfil aquí. Muchos ejemplos de esto. ContentProvdier es sólo un montón de gastos generales y no es necesario a menos que esté compartiendo datos fuera de su aplicación. Las transacciones son buenas para acelerar las cosas y (obviamente) mejorar la consistencia, pero no es necesario.

Sólo usa un SqliteOpenHelper en tu aplicación y estás a salvo.

Mi apuesta: no es seguro.

Para estar en una posición más segura debe utilizar transacciones SQL. Comience con beginTransaction() o beginTransactionNonExclusive() y finalice con endTransaction() . Como se muestra aquí

Esta es mi solución Creé una clase y un objeto estático privado para sincronizar todos los acceso db

 public class DBFunctions { // ... private static Object lockdb = new Object(); /** * Do something using DB */ public boolean doInsertRecord(final RecordBean beanRecord) { // ... boolean success = false; synchronized (lockdb) { // ... // // here ... the access to db is in exclusive way // // ... final SQLiteStatement statement = db.compileStatement(sqlQuery); try { // execute ... statement.execute(); statement.close(); // ok success = true; } catch (Exception e) { // error success = false; } } return success; } 

}

Intenté utilizar la tarea ASYNC y funciona bien. Espero que sea la manera correcta de resolver el problema.

Cualquier otra sugerencia ???

Buena pregunta. Mi primer pensamiento es que no sería seguro. Sin embargo, de acuerdo con los documentos SQLite, SQLite se puede utilizar en 3 modos. El modo predeterminado es el modo "serializado":

Serializado. En modo serializado, SQLite puede ser utilizado de forma segura por múltiples subprocesos sin restricción

Así que supongo que esto está compilado en modo serializado en Android.

Sólo vi esto mientras estaba buscando algo más. Este problema parece que sería resuelto eficientemente utilizando un ContentProvider. De esta manera tanto la actividad como el servicio pueden utilizar el proveedor de contenido y que se ocupará de los problemas de contención de Db.

  • Insertar o actualizar en SQlite y Android utilizando la base de datos.query ();
  • SQLite Android no puede abrir el archivo de base de datos
  • ¿Cómo actualizar una base de datos SQLite y NO perder todos los datos existentes?
  • Depuración de la base de datos sqlite en el dispositivo
  • ORM en Android SQLite y esquema de base de datos
  • Consulta sqlite de Android para que coincida con la columna que contiene el texto
  • Android - Seleccionar máximo en contentProvider
  • Cómo implementar una base de datos de objetos de uno a muchos en sqlite para android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.