E riguardo il multithreading in Android SQLite?

Question

Nella mia app devo implementare alcuni servizi di interfaccia utente e sincronizzazione. Viene eseguito in background e aggiorna i dati. Il servizio di sincronizzazione non è molto semplice, utilizza il multithreading.

Quindi, ecco la mia storia: Quando ho iniziato a sviluppare questa app non sapevo nulla di sqlite, quindi non ho usato alcuna sincronizzazione dei thread in Java. Risultato: ho ricevuto molte eccezioni come "SQLiteException: database bloccato: BEGIN EXCLUSIVE;"

Quindi ho sincronizzato tutte le mie transazioni con il normale blocco Java sincronizzato() {}. Tutto è andato molto meglio. Ma ho usato i cursori per l'implementazione di CursorAdapter per le mie liste. Così, a volte stavo ottenendo lo stesso "SQLiteException: database è bloccato: BEGIN EXCLUSIVE;"

Ho terminato la creazione di un'utilità sqlite sicura per piccoli thread che gestisce tutta la roba thread-safe. Inoltre devo usare qualcosa come ArrayAdapter (leggi tutti i dati dal Cursore e chiudilo dopo aver letto, sincronizza anche questo blocco) per la mia interfaccia utente. Quindi, funziona OK

Ma, non mi piace tale modo di gestire l'interfaccia utente, perché l'interfaccia utente è molto più lento con questa soluzione: leggere una certa quantità di dati dal cursore è piuttosto veloce, ma è più lento rispetto all'utilizzo di CursorAdapter

Quindi, chi ha trovato la soluzione per questa domanda? Grazie

Answer 1

Quindi, finalmente è venuto fuori la soluzione. Ecco qui.

Ho letto alcuni forum, gruppi di google e ho scoperto che il database SQLite deve essere aperto solo una volta. Quindi, l'ho implementato usando singleton.

Inoltre, ho implementato del codice db per sincronizzare tutte le operazioni di scrittura (per evitare che molti thread eseguissero operazioni di scrittura contemporaneamente). E non mi interessa aprire i cursori, leggendo da loro.

Dopo alcune prove giorni non c'ho le segnalazioni di errori da parte dei miei utenti, quindi penso che questo funziona

Nel mio lavoro precedente ho aperto database SQLite molte volte in tutta l'applicazione, che era il problema.

Answer 2

SQLite implementa un blocco di scrittura esclusivo, modello di blocco di lettura condiviso. Ciò significa che è possibile avere contemporaneamente lettori concorrenti attivi nel database o un singolo writer, non è possibile avere entrambi. Se si utilizza la funzionalità di registrazione WAL, è possibile avere contemporaneamente un singolo writer e più lettori attivi nel database, ma non è possibile avere più di uno scrittore. Vi è un'eccellente documentazione sulla concorrenza SQLite here e here.

Si potrebbe prendere in considerazione di dare un'occhiata a Berkeley DB. Berkeley DB offre un SQL API completamente compatibile con SQLite. In realtà, ciò che abbiamo fatto è aggiungere il parser SQLite, il pianificatore e l'esecutore in cima al livello di archiviazione Berkeley DB. Ciò che questo fornisce allo sviluppatore di applicazioni SQLite è una libreria compatibile con SQLite con scalabilità, concorrenza e affidabilità (HA) aggiuntive, nonché altre funzionalità. Berkeley DB supporta più lettori e scritture che accedono contemporaneamente al database. Esistono due eccellenti white paper scritti da Mike Owens, autore di "The Definitive Guide to SQLite" che confronta Berkeley DB e SQLite (Performance comparison, Behavioral Differences).

Disclaimer: Sono uno dei product manager di Berkeley DB, quindi sono un po 'prevenuto. Ma richieste come la tua (hanno bisogno di maggiore concorrenza, scalabilità, affidabilità da SQLite) è esattamente il motivo per cui abbiamo deciso di fornire una libreria combinata che ti offre il meglio di entrambi i mondi.

Answer 3

Se si utilizza solo una classe di helper singleton per accedere al db non è necessario sincronizzarsi ed è possibile utilizzare l'helper da più lettori/scrittori poiché la classe helper gestisce la sincronizzazione stessa.

Cercare at this post per mor spiegazione dettagliata

Answer 4

Utilizzare un aiutante Singleton per l'apertura di connessioni.

1) Aprire tutte le connessioni leggibili che si desidera e chiudere dopo aver terminato.

2) Per le connessioni scrivibili, è necessario aprire solo una singola connessione scrivibile.

Quando si tenta di aprire un'altra connessione scrivibile, restituire la connessione già aperta. Se non esiste alcuna connessione scrivibile, aprire una nuova connessione scrivibile. Mantieni un contatore writable_connection e chiudi la connessione scrivibile, quando tutti i thread sono finiti con esso.

Sto per implementarlo e farò sapere se funziona quando ho finito.

Answer 5

Bene, leggendo la documentazione la mia risposta precedente sembra errata. Ho un singolo (tonico) SQLiteOpenHelper, quindi sembra che tutte le connessioni siano uguali. Anche quelli leggibili sono uguali alle connessioni scrivibili.

Così ho intenzione di saltare chiamando getReadableDatabase e utilizzare solo getWritableDatabase. Quindi ho intenzione di tenere un contatore, per assicurarmi che il database venga chiuso una sola volta.

Poiché SQLiteOpenHelper serializza le scritture, tutto dovrebbe andare bene in questo modo. Dovrò semplicemente tenere traccia della connessione, per assicurarmi che non ne tenga uno aperto alla fine.

Quindi, nella mia classe DBHelper mi hanno ora:

private int activeDatabaseCount = 0; 
public synchronized SQLiteDatabase openDatabase() { 
    SQLiteDatabase connection = getWritableDatabase(); // always returns the same connection instance 
    activeDatabaseCount++; 
    return connection; 
} 
public synchronized void closeDatabase(SQLiteDatabase connection) { 
    activeDatabaseCount--; 
    if (activeDatabaseCount == 0) { 
     if (connection != null) { 
      if (connection.isOpen()) { 
       connection.close(); 
      } 
     } 
    } 
}