1

I have a ContentProvider access in a AsyncTask which generally works fine while looking up some data stored in sqlite on the phone.

However I also have some other background services that do network checks and download and update some data.

It is observed that this network related background activity is affecting my ContentProvider. The ContentProvider which entirely works on offline data either delays the response or just never returns for a long time.

Are then any locking/queuing mechanisms on the ContentProvider or the sqlite database? The writes do not happen to the same tables as the reads.

Pratik Mandrekar
  • 9,362
  • 4
  • 45
  • 65
  • 1
    also see this: https://nfrolov.wordpress.com/2014/08/16/android-sqlitedatabase-locking-and-multi-threading/ – pskink Aug 02 '15 at 10:34

1 Answers1

1

Are then any locking/queuing mechanisms on the ContentProvider or the sqlite database? The writes do not happen to the same tables as the reads.

  1. ContentProvider implementations require additional synchronization to be thread-safe, i.e the developer is in charge of it

  2. SQLite is synchronized, i.e. writes exclude reads

In your case you might want to enable write-ahead-logging (WAL), api 11+. This enables writes to happen in a separate journal in parallel: holding the lock and excluding parallel reads is not necessary anymore.

See for instance:

SQLite, Content Providers, & Thread Safety

Official docs for SQLite locking

Good explanation of WAL

Community
  • 1
  • 1
Gil Vegliach
  • 3,542
  • 2
  • 25
  • 37
  • Any idea of best practices surrounding this? I guess showing UI feedback is one obvious one. WAL does not always guarantee that things work in parallel. – Pratik Mandrekar Aug 02 '15 at 12:17
  • 1
    Google suggests to access CPs with Loaders, which is handy to automatically reload content after a change. (using setNotifyUri()/notifyChange()). It will be 'too automatic' though, so showing a progress animation will become harder than it should. For the SQLite db, usually a singleton wrapped in the CP is enough. Also no need to close the database in this case. If WAL is not enough on the performance side, I don't know what else you could do, except restructuring your app to avoid lock contention. – Gil Vegliach Aug 02 '15 at 13:03