Fixed
Status Update
Comments
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #2
That seems quite bad :/ weird.
We have fairly large test projects which do not take anywhere close to it, maybe your code is triggering some bad code path.
Can you provide a sample or share your project with us? It is impossible to do something here unless we have a reproduction case. Might also possibly be related to your machine configuration.
We have fairly large test projects which do not take anywhere close to it, maybe your code is triggering some bad code path.
Can you provide a sample or share your project with us? It is impossible to do something here unless we have a reproduction case. Might also possibly be related to your machine configuration.
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.