Fixed
Status Update
No update yet.
Comments
da...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit adb154fb2cafd48c853c211122c4cff21db5b91c
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Tue Nov 13 13:47:49 2018
Use a ReentrantReadWriteLock as Database close lock.
Solely using a ReentrantLock would cause lock contention while adding
and removing observers to the InvalidationTracker. It is desired to
'wait' for the InvalidationTracker to finish its operation before
closing the DB but at the same time it shouldn't make syncing triggers
exclusive when adding observers, more so when these can happen
frequently due to Rx observers being subscribed and disposed
on different threads.
Using a ReentrantReadWriteLock minimises lock contention allowing
multiple threads to add and remove observers (read lock) while still
keeping the DB close operation mutually exclusive (write lock). This
change should be safe since the InvalidationTracker and
the ObservedTableTracker already had mechanisms for allowing concurrent
calls of syncTriggers(). Specifically once a single thread gets the
tables to sync all other threads exit out of syncing.
Bug: 117900450
Test: CustomDatabaseTest
Change-Id: Ia6bbdf3a76e3e0c564ddad2f7dbdfc6684305ce4
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
https://android-review.googlesource.com/825600
https://goto.google.com/android-sha1/adb154fb2cafd48c853c211122c4cff21db5b91c
Branch: androidx-master-dev
commit adb154fb2cafd48c853c211122c4cff21db5b91c
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Tue Nov 13 13:47:49 2018
Use a ReentrantReadWriteLock as Database close lock.
Solely using a ReentrantLock would cause lock contention while adding
and removing observers to the InvalidationTracker. It is desired to
'wait' for the InvalidationTracker to finish its operation before
closing the DB but at the same time it shouldn't make syncing triggers
exclusive when adding observers, more so when these can happen
frequently due to Rx observers being subscribed and disposed
on different threads.
Using a ReentrantReadWriteLock minimises lock contention allowing
multiple threads to add and remove observers (read lock) while still
keeping the DB close operation mutually exclusive (write lock). This
change should be safe since the InvalidationTracker and
the ObservedTableTracker already had mechanisms for allowing concurrent
calls of syncTriggers(). Specifically once a single thread gets the
tables to sync all other threads exit out of syncing.
Bug: 117900450
Test: CustomDatabaseTest
Change-Id: Ia6bbdf3a76e3e0c564ddad2f7dbdfc6684305ce4
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
Description
Version used: 2.0.0
Devices/Android versions reproduced on: Any
We recently started seeing a lot of lock contention upon subscription to Observables provided by Room. At first we thought that the problem was caused by `syncTriggers` doing DB work on the main thread (a known issue here:
It seems that the close lock is unintentionally being used to obtain an exclusive lock on the entire database, blocking any other subscriptions while there is either another subscription happening at the same time or the refresh runnable is running. I'm not sure why the protection against closing is required in the first place, but maybe a `ReentrantReadWriteLock` could accomplish the intended goal without the exclusiveness.