Progress towards database schema locking.
We recently tried fixing some obscure SQLite deadlocking in a51c3d1c,
but the cure was worse than the disease, since any threads just about
to perform a database operation before we close() the database would
encounter an "Cannot perform this operation because the connection
pool has been closed" exception.
Since we don't have control over the deep inner workings of SQLite
which result in the deadlock, the best we can do is to create a
ReadWriteLock where the "readers" are all normal database mutations
or queries, and the "writers" are schema modifications.
We're going to land this in two phases; the first phase here shifts
all database interactions to be driven by runWithTransaction() or
runWithoutTransaction(), which we'll use to acquire the upcoming
schema ReadWriteLock.
Any SQLiteDatabase instances obtained through getReadableDatabase()
or getWritableDatabase() would be unprotected by this schema lock,
so we adjust those methods to explicitly throw, to ensure that all
future changes interact with the database safely.
Bug: 152005629, 152802030
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ia79fb94e71352744006a7e1182dfeb112889bdf3
6 files changed