Android Lollipop 5.0.1 SQLiteLog POSIX Errore 11 Errore SQLite: 3850

Question

Ho riscontrato un problema durante l'aggiornamento di un'app per supportare Android Lollipop. L'app implementa un SyncAdapter che scrive su un db attraverso un fornitore di contenuti. Allo stesso tempo può succedere che l'utente stia navigando sul front-end dell'app dove i caricatori leggono gli stessi dati dal database. I caricatori ascoltano anche le modifiche ai dati.

Ora, se eseguo il programma su un dispositivo pre-Lollipop, tutto funziona senza errori.

Sul Lollipop invece ho visualizzato il seguente messaggio logcat:

11:20:59.344 22341-22376/com.example.com E/SQLiteLog﹕ (10) POSIX Error : 11 SQLite Error : 3850 
11:20:59.364 22341-22376/com.example.com E/SQLiteLog﹕ (10) POSIX Error : 11 SQLite Error : 3850 
11:20:59.364 22341-22376/com.example.com E/SQLiteLog﹕ (10) POSIX Error : 11 SQLite Error : 3850 
11:20:59.364 22341-22376/com.example.com E/SQLiteLog﹕ (10) POSIX Error : 11 SQLite Error : 3850 

Ora, da documenti SQLite:

(3850) SQLITE_IOERR_LOCK

The SQLITE_IOERR_LOCK error code is an extended error code for SQLITE_IOERR indicating an I/O error in the advisory file locking logic. Usually an SQLITE_IOERR_LOCK error indicates a problem obtaining a PENDING lock. However it can also indicate miscellaneous locking errors on some of the specialized VFSes used on Macs. Everything seems to work properly on a high level (that is both reads and writes are performed)

e:

A PENDING lock means that the process holding the lock wants to write to the database as soon as possible and is just waiting on all current SHARED locks to clear so that it can get an EXCLUSIVE lock. No new SHARED locks are permitted against the database if a PENDING lock is active, though existing SHARED locks are allowed to continue.

So che la versione di SQLite ha stato aggiornato da alcune versioni principali di Lollipop, quindi sono incline a pensare che l'errore sia dovuto a qualche nuovo comportamento r di SQLite che non riesco a isolare.

Tuttavia, tutto sembra funzionare bene da un punto di vista di livello superiore (l'App non si blocca, vengono eseguite sia le letture che le scritture, il framerate non cala - almeno per gli occhi umani) ma non vorrei ignorare il problema per rilasciare l'app finché non sono sicuro che non causerà problemi di corruzione o di dati.

Forse mi manca su alcune importanti modifiche al lollipop per quanto riguarda le serrature e l'accesso al database multiprocesso, ma sento che è un problema che si trova su un livello inferiore rispetto alla/dominio Arte Dalvik e così deve essere fissato in un NDK contesto.

C'è un modo per risolvere questo problema senza distribuire una versione specifica dell'app di SQLite? C'è qualche opzione manifest/SQLite per evitare l'errore?

Grazie in anticipo

Answer 1

Writer blocca il database sia in lettura e scrittura. Ciò significa che deve attendere che tutti i lettori finiscano e rilasciare i blocchi per ottenere il blocco.

Dopo che lo scrittore ha richiesto un blocco, i nuovi blocchi del lettore devono attendere che lo scrittore prima ottenga il blocco e quindi lo rilasci.

questa potrebbe essere una soluzione per voi: WAL mode

attivare e configurare la modalità WAL:

Uno SQLite default di connessione al database per journal_mode = CANC. Per convertire in modalità WAL, utilizzare il seguente pragma:

PRAGMA journal_mode=WAL; 

WAL non bloccherà i lettori durante la scrittura, il che significa anche che lo scrittore non ha bisogno di aspettare per serrature di lettura di corrente per essere rilasciato.

La versione SQLite minima richiesta per WAL è 3.7.0 (2010-07-21). Lollipop 5.0 utilizza SQLite 3.8.4.3 quindi WAL dovrebbe essere disponibile per te.

Ma WAL non esiste nella versione Android meno di 3.0 sebbene ci siano alcune eccezioni da questo. Dai un'occhiata a Version of SQLite used in Android?. Se non hai bisogno che la tua app funzioni sotto Android 3.0, puoi utilizzare WAL.