Status Update
No update yet.
Comments
yb...@google.com
ne...@gmail.com
This happens when blocking thread interrupted.
Use case: RxJava, When switchMap is upstream, downstream blocking operation will be interrupted.
In older version room, runInTransaction is not interruptible, never throws exception like this.
fl...@google.com
fl...@google.com
fl...@google.com
We updated Room internals to Coroutines and one of the improvements is interruption. Before the internal changes, Room would ignore thread interruption, database operations where not really cancellable, but in the latest version and due to Coroutines, Room can be interrupted but since it has to return some value which it couldn't compute it then throws InterruptedException as part of the runBlocking used to bridge blocking DAO functions with Coroutine internals. I think you will need to handle the exception as any other and determine what to return or ignore since Room can't make that decision for you.
bo...@gmail.com
That's a big change.
I think some method should be marked with @Throws(InterruptedException::class) like runBlocking.
ne...@gmail.com
runBlocking used to bridge blocking DAO functions with Coroutine internals
It seems that all non-suspend DAO query function are throws InterruptedException.
Huge migration.
bo...@gmail.com
An update: I agree this is a big behavior change and for compatibility reasons we want to continue having Room blocking DAO functions and API be uninterruptible. We are trying to work on a solution for this.
yb...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Use Coroutines RxJava builders in RxRoom
Expand for full commit details
Use Coroutines RxJava builders in RxRoom
The coroutines-rxjava builders have better handling for cancellation and allows Room to use Coroutine internals more natively which in turns avoids performBlocking.
Bug: 400584611
Test: RxJava2Test and RxJava3Test
Change-Id: I639162c82584eea358d061d0e2c48ce0f260a47c
Files:
- M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/DeferredBooksDaoTest.kt - M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/RxJava2QueryTest.kt - M
room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/UpsertTest.kt - M
room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/RxJava2Test.java - M
room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/RxJava3Test.java - M
room/room-rxjava2/src/main/java/androidx/room/RxRoom.kt - M
room/room-rxjava3/src/main/java/androidx/room/rxjava3/RxRoom.kt
Hash: 52899e0b7ab58364d7467f39dfee82cc3dc2c04d
Date: Wed Mar 12 11:38:37 2025
Description
Version used: 1.0.0-alpha2
Looking at the source of LiveDataReactiveStreams.fromPublisher() the Publisher that is passed in is never unsubscribed. This means that the underlying Publisher has no opportunity for releasing resources and stopping work which may result in memory leaks and other bugs. I would have expected the Publisher to be unsubscribed in LiveData onInActive() callback and subscribed in onActive() as this signals that there are consumers interested in the LiveData.
Alternatively I think the publisher should at least be unsubscribed then the associated LifecycleOwner goes away (when the Lifecycle moves to destroyed).