You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have encountered a nasty deadlock during debugging some db-related code and traced it down to this thread. So, basically, SQLite is advertised as a multiple-readers-single-writer db, but does not work that way in Android, unless you call beginTransactionNonExclusive instead if beginTransaction. The notifications about changes are delivered in order via ContentResolver, so there should not be any concurrency issues from the first glance.
What possible downsides to doing that can you imagine? Would it make sense to use that method by default in AnnotatedSQL?
The text was updated successfully, but these errors were encountered:
the main idea was - lock for write and allow read always.
in this case UI can load data from database during write process and reload it again when it will be finished.
I have encountered a nasty deadlock during debugging some db-related code and traced it down to this thread. So, basically, SQLite is advertised as a multiple-readers-single-writer db, but does not work that way in Android, unless you call
beginTransactionNonExclusive
instead ifbeginTransaction
. The notifications about changes are delivered in order via ContentResolver, so there should not be any concurrency issues from the first glance.What possible downsides to doing that can you imagine? Would it make sense to use that method by default in AnnotatedSQL?
The text was updated successfully, but these errors were encountered: