Fixed
Status Update
No update yet.
Comments
da...@google.com
ap...@google.com
I'm still working on a fix, but here's the current state of OnConflictStrategy.
# REPLACE
Works as expected. Old rows are replaced.
# IGNORE
Works as expected. New rows are ignored.
# ROLLBACK
This ends the transaction on conflict. Thus, the following call of endTransaction() always fails. This is basically unusable.
# ABORT (default)
As the SQLite doc says, all the changes prior to this statement are preserved, but they are rolled back by the surrounding transaction anyway.
# FAIL
This works pretty much the same as ABORT, except that it does not roll back the current statement at first. It is, however, rolled back by the surrounding transaction along with the preceding changes.
In summary, ABORT and FAIL produce the same results, and unlike the SQLite doc says, they both roll back on conflict (because of the surrounding transaction). ROLLBACK always fails.
# REPLACE
Works as expected. Old rows are replaced.
# IGNORE
Works as expected. New rows are ignored.
# ROLLBACK
This ends the transaction on conflict. Thus, the following call of endTransaction() always fails. This is basically unusable.
# ABORT (default)
As the SQLite doc says, all the changes prior to this statement are preserved, but they are rolled back by the surrounding transaction anyway.
# FAIL
This works pretty much the same as ABORT, except that it does not roll back the current statement at first. It is, however, rolled back by the surrounding transaction along with the preceding changes.
In summary, ABORT and FAIL produce the same results, and unlike the SQLite doc says, they both roll back on conflict (because of the surrounding transaction). ROLLBACK always fails.
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.