SQLite lectura y escritura simultánea

He leído una gran cantidad de temas, pero no puedo entender la respuesta a la pregunta: ¿es posible leer y escribir simultáneamente?

Tengo el hilo de fondo que actualiza algunos datos y UI necesita pequeño pedazo de datos almacenados en DB. Por lo tanto, en la operación SELECT de subproceso UI se realiza. Pero bloquea cuando la actualización está en curso. Como resultado, la interfaz de usuario se congela durante varios segundos.

¿Alguien tiene éxito en la lectura de DB al escribir?

Es posible leer y escribir en DB en el iPhone. ¿La razón de tal diferencia está en la implementación sincronizada de wrapper en las funciones nativas de sqlite?

En Android 3.0 y versiones superiores, SQLiteDatabases admite el modo WAL (registro por adelantado):

Cuando el registro por adelantado no está habilitado (el valor predeterminado), no es posible que se produzcan lecturas y escrituras en la base de datos al mismo tiempo. Antes de modificar la base de datos, el escritor adquiere implícitamente un bloqueo exclusivo en la base de datos que evita que los lectores accedan a la base de datos hasta que se complete la escritura.

Por el contrario, cuando se habilita el registro por escritura anticipada, las operaciones de escritura se producen en un archivo de registro independiente que permite que las lecturas se realicen simultáneamente. Mientras una escritura está en progreso, los lectores de otros subprocesos percibirán el estado de la base de datos tal como era antes de comenzar la escritura. Cuando se completa la escritura, los lectores de otros hilos detectarán el nuevo estado de la base de datos.

http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html#enableWriteAheadLogging ()

Para iniciar una transacción en modo WAL, use beginTransactionNonExclusive () en lugar de beginTransaction (). Mientras beginTransaction () inicia una transacción en modo EXCLUSIVE, beginTransactionNonExclusive () inicia uno en el modo IMMEDIATE

El modo EXCLUSIVE utiliza bloqueos exclusivos ( http://www.sqlite.org/lockingv3.html#excl_lock ), lo que significa que ninguna otra conexión de base de datos, excepto las conexiones read_uncommitted, podrá leer la base de datos y ninguna otra conexión sin excepción podrá escribir la Hasta que la transacción esté completa
El modo IMMEDIATE usa cerraduras reservadas ( http://www.sqlite.org/lockingv3.html#reserved_lock ) lo que significa que ninguna otra conexión de base de datos podrá escribir en la base de datos o hacer BEGIN IMMEDIATE o BEGIN EXCLUSIVE, otros procesos pueden seguir leyendo De la base de datos, sin embargo.

En palabras más simples: llamada beginTransactionNonExclusive () para el modo IMMEDIATE y podemos leer mientras otro thread está escribiendo (el estado antes de que la transacción de escritura se inicie porque no usaremos read_uncommitted connections -> http://en.wikipedia.org/wiki/ Isolation_% 28database_systems% 29 # Dirty_reads ).

No puedes leer ni escribir al mismo tiempo. SQLite es una base de datos sin servidor, basada en archivos.

Desde la FAQ de SQLite:

"Cuando cualquier proceso quiere escribir, debe bloquear todo el archivo de la base de datos durante la duración de su actualización.Pero que normalmente sólo toma unos pocos milisegundos.Otros procesos sólo esperar a que el escritor para terminar y luego continuar con su negocio. Los motores típicamente sólo permiten que un solo proceso se conecte a la base de datos a la vez ".

Comenzando con API 11 Android tiene soporte para el modo WAL. Mantiene los datos originales sin tocar durante la transacción, por lo que otros subprocesos pueden leer cuando se está ejecutando la transacción. Puede consultar mi artículo para obtener más detalles sobre el modo WAL:

http://www.skoumal.net/en/parallel-read-and-write-in-sqlite/

También debe evitar ejecutar consultas de base de datos en el subproceso de UI. Siempre podría volverse lento y bloquear su interfaz de usuario.

No es posible leer y escribir simultáneamente. Sin embargo, si tiene sus clases de base de datos SQLite configuradas correctamente (una sola instancia de su DB y clases de ayuda), diferentes subprocesos deben ser capaces de agarrar la conexión DB de forma síncrona para que no haya ningún retraso notable.

También suena como si estuviera tratando de hacer trabajo de backend (escribir en el db) con su hilo de interfaz de usuario. No deberías estar haciendo esto. Cree un AsyncTask para manejar esto en lugar de tener su hilo de interfaz de usuario manejarlo.

Consulte la documentación de SQLiteOpenHelper . Aquí hay un post anterior que habla de esto también: ¿Cuáles son las mejores prácticas para SQLite en Android?