Assigned
Status Update
No update yet.
Comments
ae...@gmail.com
After looking more into this issue, ViewModels are persisted using retained fragments. After adding retained fragments to the sample app, we can observe that retained fragments are not able to survive landscape lock and unlock scenario either.
el...@google.com
Hey, currently I can't reproduce your issue.
Link you provided doesn't work, in my simple test project I don't observe described issue.
Could you please say reupload your project somewhere else?
Could you please say what kind of lockscreen, do you use? (it may effect issue)
Could you reproduce this behavior on other devices?
Link you provided doesn't work, in my simple test project I don't observe described issue.
Could you please say reupload your project somewhere else?
Could you please say what kind of lockscreen, do you use? (it may effect issue)
Could you reproduce this behavior on other devices?
ae...@gmail.com
Hey,
Sorry about the repo link, here is the public one:https://github.com/karmazindmitriy/viewmodelscoping , git@github.com:karmazindmitriy/viewmodelscoping.git
Tested on:
1. Device: NEXUS 5X, API level: 24, lock method: PIN / PATTERN / SWIPE / PASSWORD. Can reproduce by unlocking with any of the unlocking methods. Can also reproduce by unlocking with fingerprint.
2. Device: NEXUS 5X, API level: 27, lock method: PIN / PATTERN / PASSWORD . Can reproduce only when unlocking the device with a fingerprint. Unlocking with PIN / PATTERN / PASSWORD works fine.
3. Device: Pixel, API level: 27, lock method: PIN (haven't tested other) + fingerprint. Can reproduce only when unlocking the device with a fingerprint. Unlocking with PIN / PATTERN / PASSWORD works fine.
Hope this is helpful, please let me know if you need any other info.
Sorry about the repo link, here is the public one:
Tested on:
1. Device: NEXUS 5X, API level: 24, lock method: PIN / PATTERN / SWIPE / PASSWORD. Can reproduce by unlocking with any of the unlocking methods. Can also reproduce by unlocking with fingerprint.
2. Device: NEXUS 5X, API level: 27, lock method: PIN / PATTERN / PASSWORD . Can reproduce only when unlocking the device with a fingerprint. Unlocking with PIN / PATTERN / PASSWORD works fine.
3. Device: Pixel, API level: 27, lock method: PIN (haven't tested other) + fingerprint. Can reproduce only when unlocking the device with a fingerprint. Unlocking with PIN / PATTERN / PASSWORD works fine.
Hope this is helpful, please let me know if you need any other info.
ae...@gmail.com
Thanks, yep, I was able to reproduce it.
ae...@gmail.com
Oh, another instance when platform doesn't call onSaveInstanceState, but calls onStop and onRetainNonConfiguration, so fragments are confused, we are going to fix fragments so they work around this behavior.
ae...@gmail.com
Are you referring to the first `onStop` that happens right after unlock (line 12 in screenshot)?
ae...@gmail.com
yep
ae...@gmail.com
Hello, I Have notice the same issue when using ViewModel, here is the scenario:
1) open ActivityA
-gets ViewModel with reference: TestViewModel@e71fab8
2) rotate device
-gets ViewModel with reference: TestViewModel@e71fab8
3) open ActivityB
4) rotate device
5) press back (finish Activity B)
6) Activity A comes back from stack
-gets ViewModel with reference: TestViewModel@260072e
I have tested with two kinds of ViewModel, with factory and default creation method:
ViewModelProviders.of(this).get(TestViewModel::class.java)
ViewModelProviders.of(this, factory).get(DashboardViewModel::class.java)
Both Activities extends AppCompatActivity class.
I have made some research and find case when this issue do not happend:
1) open ActivityA (vertical)
-gets ViewModel with reference: TestViewModel@e71fab8
2) rotate device (horizontal)
-gets ViewModel with reference: TestViewModel@e71fab8
3) open ActivityB (horizontal)
4) rotate device (vertical)
5) rotate device (horizontal)
6) press back (finish Activity B)
7) Activity A comes back from stack (horizontal)
-gets ViewModel with reference: TestViewModel@e71fab8
So when I rotate device twice on Activity B and press back the Activity A do not recreate ViewModel, mayeby it is becouse it has the same orientation as befor putting it in activities stack.
1) open ActivityA
-gets ViewModel with reference: TestViewModel@e71fab8
2) rotate device
-gets ViewModel with reference: TestViewModel@e71fab8
3) open ActivityB
4) rotate device
5) press back (finish Activity B)
6) Activity A comes back from stack
-gets ViewModel with reference: TestViewModel@260072e
I have tested with two kinds of ViewModel, with factory and default creation method:
ViewModelProviders.of(this).get(TestViewModel::class.java)
ViewModelProviders.of(this, factory).get(DashboardViewModel::class.java)
Both Activities extends AppCompatActivity class.
I have made some research and find case when this issue do not happend:
1) open ActivityA (vertical)
-gets ViewModel with reference: TestViewModel@e71fab8
2) rotate device (horizontal)
-gets ViewModel with reference: TestViewModel@e71fab8
3) open ActivityB (horizontal)
4) rotate device (vertical)
5) rotate device (horizontal)
6) press back (finish Activity B)
7) Activity A comes back from stack (horizontal)
-gets ViewModel with reference: TestViewModel@e71fab8
So when I rotate device twice on Activity B and press back the Activity A do not recreate ViewModel, mayeby it is becouse it has the same orientation as befor putting it in activities stack.
da...@google.com
This behavior is due to FragmentActivity.onDestroy() calling into mViewModelStore.clear() if mRetaining is false. This is the case when the device is rotated and the affected activity is in the background (and probably in other conditions outlined above as well). It is not the case if the configuration changes when the activity is in the front.
Since the view model store has ben cleared, a new view model will be created for the affected activity after a configuration change in the background.
The behavior can be observed easily using a break point in ViewModelStore.clear()
Since the view model store has ben cleared, a new view model will be created for the affected activity after a configuration change in the background.
The behavior can be observed easily using a break point in ViewModelStore.clear()
ae...@gmail.com
Easy way to detect the condition from within onDestroy() on your own activity:
override fun onDestroy() {
val current = ViewModelProviders.of(this).get(VM::class.java)
super.onDestroy()
val fresh = ViewModelProviders.of(this).get(VM::class.java)
if (current != fresh) {
Log.e("Main", "View model has been destroyed")
}
}
override fun onDestroy() {
val current = ViewModelProviders.of(this).get(VM::class.java)
super.onDestroy()
val fresh = ViewModelProviders.of(this).get(VM::class.java)
if (current != fresh) {
Log.e("Main", "View model has been destroyed")
}
}
ae...@gmail.com
And a dirty workaround:
override fun onDestroy() {
val current = ViewModelProviders.of(this).get(VM::class.java)
super.onDestroy()
@Suppress("UNCHECKED_CAST")
val fresh = ViewModelProviders.of(this, object : ViewModelProvider.Factory{
override fun <T : ViewModel?> create(modelClass: Class<T>) = current as T
}).get(VM::class.java)
if (current != fresh) {
Log.e("Main", "View model destroyed!")
}
}
override fun onDestroy() {
val current = ViewModelProviders.of(this).get(VM::class.java)
super.onDestroy()
@Suppress("UNCHECKED_CAST")
val fresh = ViewModelProviders.of(this, object : ViewModelProvider.Factory{
override fun <T : ViewModel?> create(modelClass: Class<T>) = current as T
}).get(VM::class.java)
if (current != fresh) {
Log.e("Main", "View model destroyed!")
}
}
ae...@gmail.com
It's happening also after entering to multi-window mode
ae...@gmail.com
Somebody put my issue https://issuetracker.google.com/issues/78095959 as a duplicate of this one. I would like to clarify, if this is really the case and if the issue that I reported will also be taken into account when fixing this issue.
Quote #6:
"Oh, another instance when platform doesn't call onSaveInstanceState, but calls onStop and onRetainNonConfiguration, so fragments are confused, we are going to fix fragments so they work around this behavior."
In the case which I presented, onSaveInstanceState IS called. But after that the activity is destroyed, so are the fragments. But ViewModel is not being cleared. There is a condition which skips clearing ViewModel after state is saved:
/**
* Called when the fragment is no longer in use. This is called
* after {@link #onStop()} and before {@link #onDetach()}.
*/
@CallSuper
public void onDestroy() {
mCalled = true;
// Use mStateSaved instead of isStateSaved() since we're past onStop()
if (mViewModelStore != null && !mHost.mFragmentManager.mStateSaved) {
mViewModelStore.clear();
}
}
But for fragments that are destroyed, loaders must be reset, like it happens in case of activity. I think the right condition for loader lifecycle to work correctly should be something like this:
if (mViewModelStore != null) {
// Do not reset loaders on activity rotation
final Activity activity = getActivity();
if (activity != null && !activity.isChangingConfigurations()) {
fragment.mViewModelStore.clear();
}
}
So loaders are always reset in Fragment.onDestroy(), unless the activity is rotated. I think this is also applicable to ViewModel.
Quote #6:
"Oh, another instance when platform doesn't call onSaveInstanceState, but calls onStop and onRetainNonConfiguration, so fragments are confused, we are going to fix fragments so they work around this behavior."
In the case which I presented, onSaveInstanceState IS called. But after that the activity is destroyed, so are the fragments. But ViewModel is not being cleared. There is a condition which skips clearing ViewModel after state is saved:
/**
* Called when the fragment is no longer in use. This is called
* after {@link #onStop()} and before {@link #onDetach()}.
*/
@CallSuper
public void onDestroy() {
mCalled = true;
// Use mStateSaved instead of isStateSaved() since we're past onStop()
if (mViewModelStore != null && !mHost.mFragmentManager.mStateSaved) {
mViewModelStore.clear();
}
}
But for fragments that are destroyed, loaders must be reset, like it happens in case of activity. I think the right condition for loader lifecycle to work correctly should be something like this:
if (mViewModelStore != null) {
// Do not reset loaders on activity rotation
final Activity activity = getActivity();
if (activity != null && !activity.isChangingConfigurations()) {
fragment.mViewModelStore.clear();
}
}
So loaders are always reset in Fragment.onDestroy(), unless the activity is rotated. I think this is also applicable to ViewModel.
ae...@gmail.com
Was about to report this issue. I too am observing the same issue - exactly as do...@gmail.com https://issuetracker.google.com/issues/73644080#comment9 describes it. I also noted that if the ViewModel is instantiated with a Fragment - ie: mViewModel = ViewModelProviders.of(<Fragment>).get(TestViewModel.class); - the ViewModel will always get the same instance back - even in the above described scenarios.
I found a sample project on GitHub where the issue is easily reproduced as well:https://github.com/jshvarts/SimpleViewModel
I found a sample project on GitHub where the issue is easily reproduced as well:
da...@google.com
- I have a temporary solution that we have implemented using retained fragments to hold the ViewModel.
See:https://bitbucket.org/sajeevmadu/viewmodeltest for the solution.
See:https://issuetracker.google.com/issues/78788599
for a video of the issue.
See:
See:
for a video of the issue.
ae...@gmail.com
This is fixed internally and will be available in future releases of the fragment dependency.
da...@google.com
when and which version will this fix be included?
ae...@gmail.com
The fix is available in 28.0.0-alpha3 and AndroidX 1.0.0-alpha3
el...@google.com
da...@google.com
For anyone still following this thread: tried with 28.0.0-alpha3 and AndroidX 1.0.0-alpha3 and it doesn't happen anymore.
ae...@gmail.com
Sadly moving to AndroidX is a huge issue for large projects. It makes so many build errors. I hope it gets fixed in future version of Android Studio
da...@google.com
If you're comfortable with alpha releases of the support library, you can raise your target to 28 and use 28.0.0-alpha3.
ae...@gmail.com
Raising targetSdk is not needed. Only compileSdk needs to be raised to be able to use support lib 28
ae...@gmail.com
Right, sorry about that. Realized this soon after but couldn’t edit the response :(
ae...@gmail.com
This issue is not fixed in 2.0.0-rc01. How can you consider calling this version release candidate with this bug!
da...@google.com
Supportlib 28 and AndroidX 2.0.0-rc01 releases are not related to navigation - navigation/workmanager are still in alpha in a separate release process. They have yet to release an androidx-package version, so they aren't included included in the initial 2.0 arch components release process. See https://developer.android.com/topic/libraries/architecture/adding-components#navigation - you need to update your navigation library version specifically.
ae...@gmail.com
I faced the same issue after calling startActivityForResult and rotate screen and then return the resulting intent. I noticed that this also caused the onCleared() of the ViewModel to be invoked in the calling activity's viewmodel.
ba...@gmail.com
Re #29, if you're still having an issue with 28.0.0-alpha3 or higher (or 1.0.0-alpha2 in AndroidX), please file a new issue with a sample project that reproduces your issue.
ba...@gmail.com
Can anyone please make a sample project to test it out, and say what are the steps?
I think the issue was fixed, at least for loaders.
I think the issue was fixed, at least for loaders.
ae...@gmail.com
"Retained fragments to hold the ViewModel" is not a reliable solution. After reverted some requested runtime permissions, such as Storage, Location and so on, retained ViewModel will be changed to a fresh one!
ba...@gmail.com
I'm getting a similar issue. Multiple instances on my view model are being created on screen rotate. Here's a link to my repo: https://github.com/rahulchowdhury/elly/tree/add-elephant-profile
da...@google.com
Re #33 - you're unconditionally adding a new Fragment in your MainActivity, meaning you're adding a new instance for every rotation. You need to surround that code with if (savedInstanceState == null).
ba...@gmail.com
Whoops. Totally missed that one out. Sorry. 😅
da...@google.com
@34 @35 Or check if the fragment exists, using findfragmentbytag .
ba...@gmail.com
Reading data via a Flow returned from a @Dao has never required a transaction, unless specified in the DAO via @Transaction. Would love to hear more about the surprising performance issues.
The issue we were having was that on startup our sync loop would sometimes start a transaction before our UI created a Room flow, and the UI flow would be blocked until the sync transaction finished. I think we jumped to the conclusion that Room flows acquire a transaction when they're started, but I just looked at the library code again and I think its just acquiring a transaction the first time you observe a table 🤦 edit: OK I'll stop derailing this ticket, but when a flow is started and its the first observer on a table there is a transaction, and when a flow finishes and its the last observer on a table there is a transaction
I was able to successful run the Tasks app but indeed haven't had luck reproducing the issue, so if you do end up creating that branch with seed data I will gladly use it.
I will get this to you ASAP
da...@google.com
Yes, if a Flow needs to observe tables that have no observer 'installed' then Room has to create some TRIGGERs to start observing the tables and it does it in a transaction. Unfortunately this has to block the Flow's initial query to guarantee consistency. I think we would need a different invalidation system, not TRIGGER based, to possibly avoid that start and end transaction but I don't think we have enough strong compelling reasons to change the system.
al...@beeper.com
I have attached a backup file that you can import into Tasks by tapping on 'Settings > Backups > Import' and selecting the file.
On my CAT S22 with BundledSQLiteDriver it crashes with a database locked error, and the
The next-worst phone I have is a Galaxy S9 and I cannot get the database locked error on there, even with 10x as much data in the database
When I look at Firebase, these are the types of phones experiencing this crash: TP-Link Neffos A5 Tinno Y52 ZTE Blade A34 Moto E13 & E20 Xiamo Redmi A1 & A2 Alcatel 1C Transsion Tecno Spark Go 1 Mobiwire Smart C11
This list is not exhaustive, I just grabbed it from the first 5 distinct crashes. I've never even heard of most of these phones until just now
ae...@gmail.com
Thank you for participating. I am really glad to see some progress and discussion on this issue.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Reduce no-op transaction while syncing triggers
Expand for full commit details
Reduce no-op transaction while syncing triggers
The ObservedTableStates instance will return a list of observe operations (add or remove triggers) to perform if it 'needs sync'. A sync is required if at least a trigger needs to be added or removed from a table since the last sync. However, it might be that multiple observers are added and removed such that the end result of operations is actually to do nothing. In this case Room still tries to start a database transaction to not add or remove any triggers. Since transactions have lock implications it is best to avoid the transaction that if all observer operations are no-op.
Example case this change is optimizing:
1. Flow A in UI begins collecting, trigger A is installed
2. UI is rotated, not using collectAsStateWithLifecycle() or equivalent
2.a Flow A stops collecting, a sync is required
2.b Flow A starts collecting, a sync is still required
3. Triggers are synced, operation on table A is no-op
Bug: 380088809
Test: Existing
Change-Id: Iae612a1c4f8b8f1e8e15d2f60eb9bf68241570ef
Files:
- M
room/room-runtime/src/commonMain/kotlin/androidx/room/InvalidationTracker.kt
Hash: a0e5f03fe83ec6446228a4b872f1d72fb2bf8216
Date: Thu Jan 23 11:06:08 2025
ae...@gmail.com
Are you were able to reproduce the issue and fix it or it is an other issue got fixed?
al...@beeper.com
I've spent an hour trying to repro the deadlock I mentioned in PRAGMA busy_timeout = <time in ms> with the CAT S22. I have not been successful, so maybe that does fix my problem. I'm going to try releasing with BundledSQLiteDriver again 🤞
ae...@gmail.com
Hi. Are there any updates on this?
da...@google.com
Hey - 2.7.0-alpha13 has a change that should reduce the issue, but not guaranteed.
But I was not able to reproduce the issue with the project and data from
Things got busy so I have to dedicate more time to this issue, but its sort of a wild goose chase without a reliable repro.
ck...@gmail.com
Starting with the latest version, 2.7.0-alpha13, we switched to BundledSQLiteDriver, which produces hundreds of database-locked exceptions.
Non-fatal Exception: android.database.SQLException: Error code: 5, message: database is locked
at androidx.sqlite.driver.bundled.BundledSQLiteStatementKt.nativeStep(BundledSQLiteStatement.jvmAndroid.kt)
at androidx.sqlite.driver.bundled.BundledSQLiteStatementKt.access$nativeStep(BundledSQLiteStatement.jvmAndroid.kt)
at androidx.sqlite.driver.bundled.BundledSQLiteStatement.step(BundledSQLiteStatement.jvmAndroid.kt:100)
at app.resubs.core.database.dao.PendingNotificationDao_Impl.getAll$lambda$1(PendingNotificationDao_Impl.kt:94)
at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$lambda$1$$inlined$internalPerform$1.invokeSuspend(DBUtil.kt:68)
at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$lambda$1$$inlined$internalPerform$1.invoke(DBUtil.kt:8)
at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$lambda$1$$inlined$internalPerform$1.invoke(DBUtil.kt:4)
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invokeSuspend(ConnectionPoolImpl.kt:144)
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invoke(ConnectionPoolImpl.kt:8)
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invoke(ConnectionPoolImpl.kt:4)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:43)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:166)
at kotlinx.coroutines.BuildersKt.withContext(Builders.kt)
at androidx.room.coroutines.ConnectionPoolImpl.useConnection(ConnectionPoolImpl.kt:144)
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$1.invokeSuspend(ConnectionPoolImpl.kt:13)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:35)
ae...@gmail.com
Hi
da...@google.com
I did found that we were not configuring the busy_timeout in the initial connection which can lead to SQLITE_BUSY (error code 5). I've sent a cl to fix that.
I have another alternative / workaround for those with this issue which will also hint me to the root of the cause. In
val actualDriver = BundledSQLiteDriver()
val driverWrapper =
object : SQLiteDriver by actualDriver {
override fun open(fileName: String): SQLiteConnection {
return actualDriver.open(fileName).also { newConnection ->
newConnection.execSQL("PRAGMA busy_timeout = $customBusyTimeout")
}
}
}
roomDatabaseBuilder
.setDriver(driverWrapper)
Let me know if this helps or not.
ae...@gmail.com
Hi
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Apply busy_timeout config for initial connection
Expand for full commit details
Apply busy_timeout config for initial connection
Fix an issue where busy_timeout was not being configured in the initial connection where schema validation is also done. The busy_timeout must be set on all connections to avoid SQLITE_BUSY.
Bug: 380088809
Test: BaseBuilderTest#setCustomBusyTimeout
Change-Id: I9320856f64363b05bcf6407eed0efe36ef3312a3
Files:
- M
room/integration-tests/multiplatformtestapp/src/commonTest/kotlin/androidx/room/integration/multiplatformtestapp/test/BaseBuilderTest.kt - M
room/room-runtime/src/commonMain/kotlin/androidx/room/RoomConnectionManager.kt - M
room/room-runtime/src/commonMain/kotlin/androidx/room/coroutines/ConnectionPool.kt
Hash: ba379355137898cf40a16bff549863ab6a55f093
Date: Mon Feb 10 09:32:51 2025
ae...@gmail.com
Hi. I have applied this fix to my app and release for 10% of users. I got 4000 installs and for now I don't see this error. I am going to try with version 2.7.0-rc01.
se...@scrapgolem.com
I'm still seeing this or a similar issue on 2.7.0-rc01. I haven't tried using AndroidSQLiteDriver or any of the other workarounds listed here. Previously, I was using setQueryCoroutineContext(Dispatchers.IO.limitedParallelism(1)) which did solve the problem. I removed that after upgrading to 2.7.0-rc01.
I got this crash yesterday:
android.database.SQLException: Error code: 5, message: database is locked
at androidx.sqlite.driver.bundled.BundledSQLiteStatementKt.nativeStep(SourceFile)
at androidx.sqlite.driver.bundled.BundledSQLiteStatementKt.access$nativeStep(BundledSQLiteStatement.jvmAndroid.kt:0)
at androidx.sqlite.driver.bundled.BundledSQLiteStatement.step(BundledSQLiteStatement.jvmAndroid.kt:0)
at androidx.sqlite.driver.bundled.BundledSQLiteStatement.step(BundledSQLiteStatement.jvmAndroid.kt:100)
at androidx.sqlite.SQLite.execSQL(com.google.android.gms:play-services-mlkit-barcode-scanning@@18.3.1:56)
at androidx.room.coroutines.PooledConnectionImpl.endTransaction(ConnectionPoolImpl.kt:420)
at androidx.room.coroutines.PooledConnectionImpl.transaction(ConnectionPoolImpl.kt:388)
at androidx.room.coroutines.PooledConnectionImpl.isRecycled(ConnectionPoolImpl.kt:0)
at androidx.room.coroutines.PooledConnectionImpl.access$isRecycled(ConnectionPoolImpl.kt:0)
at androidx.room.coroutines.PooledConnectionImpl.withTransaction(ConnectionPoolImpl.kt:0)
at androidx.room.coroutines.PooledConnectionImpl.withTransaction(ConnectionPoolImpl.kt:344)
at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsKt.getCOROUTINE_SUSPENDED
at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3$invokeSuspend$$inlined$internalPerform$1.invokeSuspend(DBUtil.kt:0)
at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3$invokeSuspend$$inlined$internalPerform$1.invokeSuspend(DBUtil.kt:59)
at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3$invokeSuspend$$inlined$internalPerform$1.invoke(DBUtil.kt:0)
at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3$invokeSuspend$$inlined$internalPerform$1.invoke(DBUtil.kt:0)
at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsKt.getCOROUTINE_SUSPENDED
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invokeSuspend(ConnectionPoolImpl.kt:0)
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invokeSuspend(ConnectionPoolImpl.kt:144)
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invoke(ConnectionPoolImpl.kt:0)
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$4.invoke(ConnectionPoolImpl.kt:0)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(ChildStackFactory.kt:43)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext
at kotlinx.coroutines.BuildersKt.withContext(DebugStrings.kt:0)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext
at kotlinx.coroutines.BuildersKt.withContext(DebugStrings.kt:1)
at androidx.room.coroutines.ConnectionPoolImpl.useConnection(ConnectionPoolImpl.kt:144)
at androidx.room.RoomDatabase.useConnection$room_runtime_release(RoomDatabase.android.kt:0)
at androidx.room.RoomConnectionManager.useConnection
at androidx.room.RoomDatabase.useConnection$room_runtime_release(RoomDatabase.android.kt:587)
at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsKt.getCOROUTINE_SUSPENDED
at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3.invokeSuspend(DBUtil.android.kt:0)
at androidx.room.util.DBUtil__DBUtil_androidKt$performInTransactionSuspending$3.invokeSuspend(DBUtil.android.kt:243)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:0)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
at java.lang.Thread.run(Thread.java:1012)
ae...@gmail.com
Hi. I got a new error: Fatal Exception: android.database.SQLException: Error code: 5, message: Timed out attempting to acquire a reader connection.
Writer pool:
Xu1@d088033 (capacity=1)
[1] - ow@e204ff0
Status: Free connection
Reader pool:
Xu1@6c0ec8f (capacity=4)
[1] - ow@dd27b1c
Status: Acquired connection
Coroutine: [go2@7c92325, eo2{Active}@cf76cfa, Dispatchers.IO]
Acquired:
at lR.C(Unknown Source:310)
at iR.invokeSuspend(Unknown Source:13)
at dq.resumeWith(Unknown Source:8)
at TR1.o(Unknown Source:6)
at W.resumeWith(Unknown Source:22)
at dq.resumeWith(Unknown Source:31)
at xc0.run(Unknown Source:109)
at K2.run(Unknown Source:1024)
at qc2.run(Unknown Source:2)
at SV.run(Unknown Source:93)
[2] - ow@71a2d08
Status: Free connection
[3] - ow@c0dcca1
Status: Free connection
[4] - ow@bbf5ec6
Status: Free connection
da...@google.com
"Timed out attempting to acquire a reader connection" is a better error than "database is locked", hehe
It seems you have 3 zombie connections in your pool. I suspect this is because currently don't refill the pool when a connection dies. I'll work on a change to make sure the pool is always of the correct size. Thanks again for your patience on helping us make the library better.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Reimplement suspending pool with Semaphore
Expand for full commit details
Reimplement suspending pool with Semaphore
This changes the implementation of Room's connection pool to use a Semaphore instead of a Channel. It makes the implementation simpler and removes the possibility of connections getting 'lost' due the the various branches needed to handle when a channel send / receive fails.
The Channel was also used as a 'queue' instead a circular array is used to push and pop connections acquired and released into the pool. The semaphore still controls the amount of connections being locked and unlocked and is the suspending API that waits for a connection to be free.
Bug: 322386871
Bug: 380088809
Test: BaseConnectionPoolTest
Change-Id: I9b7f2d44b511eb3e3d8cdaf8cb8905bb6203f8c5
Files:
- M
room/room-runtime/src/commonMain/kotlin/androidx/room/coroutines/ConnectionPoolImpl.kt - M
room/room-runtime/src/commonTest/kotlin/androidx/room/coroutines/BaseConnectionPoolTest.kt
Hash: dc4715197f7869c87af3025acba91a0c8a57db4d
Date: Mon Mar 17 12:01:10 2025
da...@google.com
The next release (2.7.0-rc03) will have a change that should alleviate the 'Timed out attempting to acquire a reader connection' issue, I'll continue to keep this issue open so others can report if they are still experiencing it or not.
ae...@gmail.com
Hi. Thank you for your fixes. I have released 2.7.0-rc01 for 100% of users. For now it have about 22000 installs and I don't see the error SQLException: Error code: 5, message: database is locked anymore.
ae...@gmail.com
Hi. Got 1 android.database.SQLException: Error code: 5, message: database is locked
RoomDB: 2.7.0-rc03. Device: Oppo, Android 11
Note: before this was at native step, now I got it at nativePrepare.
Fatal Exception: android.database.SQLException: Error code: 5, message: database is locked
at androidx.sqlite.driver.bundled.BundledSQLiteConnectionKt.nativePrepare(BundledSQLiteConnection.jvmAndroid.kt)
at androidx.sqlite.driver.bundled.BundledSQLiteConnectionKt.access$nativePrepare(BundledSQLiteConnection.jvmAndroid.kt)
at androidx.sqlite.driver.bundled.BundledSQLiteConnection.prepare(BundledSQLiteConnection.jvmAndroid.kt:36)
at androidx.sqlite.SQLite.execSQL(SQLite.java:56)
at androidx.room.BaseRoomConnectionManager.configureSynchronousFlag(BaseRoomConnectionManager.java:156)
at androidx.room.BaseRoomConnectionManager.configurationConnection(BaseRoomConnectionManager.java:135)
at androidx.room.BaseRoomConnectionManager.access$configurationConnection(BaseRoomConnectionManager.java:36)
at androidx.room.BaseRoomConnectionManager$DriverWrapper.openLocked$lambda$1(BaseRoomConnectionManager.java:83)
at androidx.room.concurrent.ExclusiveLock.withLock(ExclusiveLock.java:50)
at androidx.room.BaseRoomConnectionManager$DriverWrapper.openLocked(BaseRoomConnectionManager.java:65)
at androidx.room.BaseRoomConnectionManager$DriverWrapper.open(BaseRoomConnectionManager.java:57)
at androidx.room.coroutines.ConnectionPoolImpl._init_$lambda$4(ConnectionPoolImpl.java:85)
at androidx.room.coroutines.Pool.tryOpenNewConnectionLocked(ConnectionPoolImpl.kt:234)
at androidx.room.coroutines.Pool.acquire(ConnectionPoolImpl.kt:219)
at androidx.room.coroutines.ConnectionPoolImpl$acquireWithTimeout$2.invokeSuspend(ConnectionPoolImpl.kt:171)
at androidx.room.coroutines.ConnectionPoolImpl$acquireWithTimeout$2.invoke(ConnectionPoolImpl.kt:12)
at androidx.room.coroutines.ConnectionPoolImpl$acquireWithTimeout$2.invoke(ConnectionPoolImpl.kt:12)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturnIgnoreTimeout(Undispatched.kt:54)
at kotlinx.coroutines.TimeoutKt.setupTimeout(Timeout.kt:149)
at kotlinx.coroutines.TimeoutKt.withTimeout(Timeout.kt:44)
at kotlinx.coroutines.TimeoutKt.withTimeout-KLykuaI(Timeout.kt:72)
at androidx.room.coroutines.ConnectionPoolImpl.useConnection(ConnectionPoolImpl.kt:542)
at androidx.room.RoomConnectionManager.useConnection(RoomConnectionManager.java:126)
at androidx.room.RoomDatabase.useConnection$room_runtime_release(RoomDatabase.android.kt:588)
at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$$inlined$compatCoroutineExecute$DBUtil__DBUtil_androidKt$1.invokeSuspend(DBUtil.android.kt:109)
at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$$inlined$compatCoroutineExecute$DBUtil__DBUtil_androidKt$1.invoke(DBUtil.android.kt:12)
at androidx.room.util.DBUtil__DBUtil_androidKt$performSuspending$$inlined$compatCoroutineExecute$DBUtil__DBUtil_androidKt$1.invoke(DBUtil.android.kt:12)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:43)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(BuildersKt__Builders_common.kt:166)
at kotlinx.coroutines.BuildersKt.withContext(Builders.kt:1)
at androidx.room.util.DBUtil__DBUtil_androidKt.performSuspending(DBUtil__DBUtil_android.kt:247)
at androidx.room.util.DBUtil.performSuspending(DBUtil.java:1)
at androidx.room.coroutines.FlowUtil$createFlow$$inlined$map$1$2.emit(Emitters.kt:224)
at kotlinx.coroutines.flow.FlowKt__ChannelsKt.emitAllImpl$FlowKt__ChannelsKt(FlowKt__Channels.kt:33)
at kotlinx.coroutines.flow.FlowKt__ChannelsKt.access$emitAllImpl$FlowKt__ChannelsKt(FlowKt__Channels.kt:1)
at kotlinx.coroutines.flow.FlowKt__ChannelsKt$emitAllImpl$1.invokeSuspend(Channels.kt:11)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:113)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:586)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:820)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)
ae...@gmail.com
I also got 1 exception: android.database.SQLException: Error code: 5, message: Timed out attempting to acquire a writer connection.
Fatal Exception: android.database.SQLException: Error code: 5, message: Timed out attempting to acquire a writer connection.
Writer pool:
fv1@6e0810d (capacity=1, permits=0, queue=(size=0)[], )
[1] - Aw@1f718c2
Status: Acquired connection
Coroutine: [Ac0{Active}@7ccd6d3, Dispatchers.IO]
Acquired:
at xR.C(Unknown Source:328)
at iK1.w(Unknown Source:6)
at il2.h(Unknown Source:77)
at Wk2.invokeSuspend(Unknown Source:28)
at pq.resumeWith(Unknown Source:8)
at Bc0.run(Unknown Source:109)
at K2.run(Unknown Source:1024)
at wc2.run(Unknown Source:2)
at fW.run(Unknown Source:93)
Reader pool:
fv1@7a12109 (capacity=4, permits=4, queue=(size=0)[], )
[1] - null
[2] - null
[3] - null
[4] - null
at androidx.sqlite.SQLite.throwSQLiteException(SQLite.java:67)
at androidx.room.coroutines.ConnectionPoolImpl.throwTimeoutException(ConnectionPoolImpl.kt:191)
at androidx.room.coroutines.ConnectionPoolImpl.useConnection(ConnectionPoolImpl.kt:142)
at androidx.room.coroutines.ConnectionPoolImpl$useConnection$1.invokeSuspend(ConnectionPoolImpl.kt:13)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:35)
at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:101)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:98)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:113)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:586)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:820)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)
ae...@gmail.com
And also I got 10 java.lang.UnsatisfiedLinkError: dlopen failed: library "libsqliteJni.so" not found
Maybe it may be linked with nativePrepare error?
Fatal Exception: java.lang.UnsatisfiedLinkError: dlopen failed: library "libsqliteJni.so" not found
at java.lang.Runtime.loadLibrary0(Runtime.java:1131)
at java.lang.Runtime.loadLibrary0(Runtime.java:1051)
at java.lang.System.loadLibrary(System.java:1664)
at androidx.sqlite.driver.bundled.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:21)
at androidx.sqlite.driver.bundled.BundledSQLiteDriver$NativeLibraryObject.<clinit>(BundledSQLiteDriver.jvmAndroid.kt:62)
at androidx.sqlite.driver.bundled.BundledSQLiteDriver.open(BundledSQLiteDriver.java:55)
at androidx.sqlite.driver.bundled.BundledSQLiteDriver.open(BundledSQLiteDriver.java:42)
at androidx.room.BaseRoomConnectionManager$DriverWrapper.openLocked$lambda$1(BaseRoomConnectionManager.java:72)
at androidx.room.concurrent.ExclusiveLock.withLock(ExclusiveLock.java:50)
at androidx.room.BaseRoomConnectionManager$DriverWrapper.openLocked(BaseRoomConnectionManager.java:65)
at androidx.room.BaseRoomConnectionManager$DriverWrapper.open(BaseRoomConnectionManager.java:57)
at androidx.room.coroutines.ConnectionPoolImpl._init_$lambda$5(ConnectionPoolImpl.java:92)
at androidx.room.coroutines.Pool.tryOpenNewConnectionLocked(ConnectionPoolImpl.kt:234)
at androidx.room.coroutines.Pool.acquire(ConnectionPoolImpl.kt:219)
at androidx.room.coroutines.ConnectionPoolImpl$acquireWithTimeout$2.invokeSuspend(ConnectionPoolImpl.kt:171)
at androidx.room.coroutines.ConnectionPoolImpl$acquireWithTimeout$2.invoke(ConnectionPoolImpl.kt:12)
at androidx.room.coroutines.ConnectionPoolImpl$acquireWithTimeout$2.invoke(ConnectionPoolImpl.kt:12)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturnIgnoreTimeout(Undispatched.kt:54)
at kotlinx.coroutines.TimeoutKt.setupTimeout(Timeout.kt:149)
at kotlinx.coroutines.TimeoutKt.withTimeout(Timeout.kt:44)
at kotlinx.coroutines.TimeoutKt.withTimeout-KLykuaI(Timeout.kt:72)
at androidx.room.coroutines.ConnectionPoolImpl.useConnection(ConnectionPoolImpl.kt:542)
at androidx.room.RoomConnectionManager.useConnection(RoomConnectionManager.java:126)
at androidx.room.RoomDatabase.useConnection$room_runtime_release(RoomDatabase.android.kt:588)
at androidx.room.TriggerBasedInvalidationTracker.syncTriggers$room_runtime_release(InvalidationTracker.kt:300)
at androidx.room.TriggerBasedInvalidationTracker$createFlow$1$1.invokeSuspend(InvalidationTracker.kt:233)
at androidx.room.TriggerBasedInvalidationTracker$createFlow$1$1.invoke(InvalidationTracker.kt:12)
at androidx.room.TriggerBasedInvalidationTracker$createFlow$1$1.invoke(InvalidationTracker.kt:12)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:43)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(BuildersKt__Builders_common.kt:166)
at kotlinx.coroutines.BuildersKt.withContext(Builders.kt:1)
at androidx.room.TriggerBasedInvalidationTracker$createFlow$1.invokeSuspend(InvalidationTracker.kt:233)
at androidx.room.TriggerBasedInvalidationTracker$createFlow$1.invoke(InvalidationTracker.kt:12)
at androidx.room.TriggerBasedInvalidationTracker$createFlow$1.invoke(InvalidationTracker.kt:12)
at kotlinx.coroutines.flow.SafeFlow.collectSafely(SafeFlow.java:57)
at kotlinx.coroutines.flow.AbstractFlow.collect(AbstractFlow.java:226)
at kotlinx.coroutines.flow.internal.ChannelFlowOperatorImpl.flowCollect(ChannelFlow.kt:191)
at kotlinx.coroutines.flow.internal.ChannelFlowOperator.collectTo$suspendImpl(ChannelFlow.kt:153)
at kotlinx.coroutines.flow.internal.ChannelFlowOperator.collectTo(ChannelFlow.kt:5)
at kotlinx.coroutines.flow.internal.ChannelFlow$collectToFun$1.invokeSuspend(ChannelFlow.kt:56)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.java:113)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:586)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:820)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:717)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:704)
Description
Component used: RoomDB
Version used: Room - 2.7.0-alpha11, sqlite-bundled - 2.5.0-alpha11
Devices/Android versions reproduced on: Transsion Tecno, Nokia C21 Plus, Redmi A1+. Android 11-14.
Crash stack:
Please fix it.