IssueTracker

Is there any updates? This is a big problem!

Hi there - could you provide more context on the issue & a sample project to reproduce? Database locked exceptions are quite difficult to pinpoint without a repro project. Thanks!

Hi. It is reproduceable on some users by using this code:

suspend fun <R> MyDatabase.workaroundWithTransaction(block: suspend TransactionScope<R>.() -> R) {
    useWriterConnection {
        it.immediateTransaction(block)
    }

    // TODO: Temporally fix https://issuetracker.google.com/issues/340606803#comment2
    // Manually triggers invalidation
    invalidationTracker.refreshAsync()
}

Maybe it is about this? https://android-review.googlesource.com/c/platform/frameworks/support/+/3114928

I am not sure.

Hi. Please merge the pull request. This is big problem!

Hi. Is there any updates on this problem?

Hi, I updated my version to alpha12 but still have these crashes. Please release a fix asap.

Will there be fixes released this Wednesday?

Hey, there is no release on Wednesday (holiday in the USA)

We haven't found the root cause of this exception, it happens when SQLite can't commit the transaction because some other connection has a lock, we need more information, a sample project that reproduces the issue preferably, or more details on how the database is being used (is it from multiple process? is there heavy concurrency?).

You can also increase the time SQLite will wait before it error with 'database locked' by executing PRAGMA busy_timeout = <time in ms>, the current default is 3000

Thank you for you response.

1. Isn't these pull request addressed this issue? 1.1 https://android-review.googlesource.com/c/platform/frameworks/support/+/3408679 1.2 https://android-review.googlesource.com/c/platform/frameworks/support/+/3114928
2. According to RoomDB documentation about withTransaction: "Room will only perform at most one transaction at a time, additional transactions are queued and executed on a first come, first serve order." So the transaction should just wait for other transaction to complete and not throw exception instead. Isn't it?

I tried to use this code and still getting the same error from users. (deferredTransaction instead of immediateTransaction)

private val dbMutex = Mutex()

suspend fun <R> MyDatabse.workaroundWithTransaction(block: suspend TransactionScope<R>.() -> R) {
    dbMutex.withLock {
        useWriterConnection {
            it.deferredTransaction(block)
        }

        // TODO: Fix https://issuetracker.google.com/issues/340606803#comment2
        // Manually triggers invalidation
        invalidationTracker.refreshAsync()
    }
}

Moreover now I am also think that @Update function caused particularly this crash. I will monitor the situation to this if this 1 crash or it will be more with the same reason.

After checking I can confirm that this crash happens as many as before.

The crash occurs when the user adds a new record to the database from the interface, and the crash occurs when the application starts in the first 1-2 seconds. The crash also occurs when receiving records from the database.

This is just a disaster, please fix it.

Sorry, I don't believe those two pull request address the issue you are seeing.

If you can reliably reproduce can you please send us a sample project?

Besides adding a Mutex did you also try increasing the busy timeout with the PRAGMA? Can you please share more details how the database is being used? Are you starting a transaction and performing many @Update? Is the coroutine where the transaction occurring getting canceled and restarted? The theory here is maybe cancelation is not recycling the connection correctly and there is a lingering transaction that prevents other ones from finishing.

Can you also try and configure Room with the AndroidSQLiteDriver()? This would help us know if the issue is specific to the BundledSQLiteDriver or not.

I have yet to reproduce to issue, I've tried creating 'stress tests' like the following:

@Test
fun daoUsagesInTransaction() = runTest {
    List(100) {
        launch(Dispatchers.IO) {
            db.useWriterConnection { transactor ->
                transactor.immediateTransaction {
                    val e = SampleEntity(1)
                    db.dao().insert(e)
                    db.dao().update(e)
                    db.dao().delete(e)
                }
            }
            db.invalidationTracker.refreshAsync()
        }
    }.joinAll()
}

Hi. Thank you for your response.

1. My app have BroadcastReceivers and WorkManagers that reads and writes in the same database that the app does. Could it be the problem? But! The logic didn't change since I moved from android only to shared module. On android it was working just fine.
2. Currently I didn't succeed in reproducing it by myself.
3. Have I tried to reproduce it by stress tests? Yes, but I haven't get the crash.
4. "did you also try increasing the busy timeout with the PRAGMA?" - No, I didn't. I thought that it may be command just for my local device for testing. I google it see that I could execute it in query format when setting up Room. But I don't have so match long data read of write. I and thinking about it now.
5. "Can you please share more details how the database is being used?" - As example of my app: task tracking app. The user enters tasks via UI, tasks sync with other user device, task can show local alerts notification to remind.
6. "Are you starting a transaction and performing many @Update?" - It could do non-users operations when:

• Starts the app the notes are being sent or received (the App scope).
• Starts the app the other data updated via WorkManager (the WorkManager scope).
• Receives alert notification and BroadcastReceivers plans new notification and updates info about it in database (BroadcastReceiver scope).

7. "The theory here is maybe cancelation is not recycling the connection correctly and there is a lingering transaction that prevents other ones from finishing." - I am now trying to ger rid of WorkManagers because I heard that they may start in another process then the app. I will see if it would help.
8. "Can you also try and configure Room with the AndroidSQLiteDriver()?" - I tried to implement it but I don't understand how. My database placed in common module. The RoomDB generates implementation for each platform. How could I make my android implementation so I could use AndroidSQLiteDriver()?

1 & 6 - WorkManager workers and broadcast receiver interacting with the same Room database is fine. I was more curious on the operations being done, but it does seem to be write operations in transactions.

4 - You can configure the timeout in Room's onOpen callback, and these can be installed in the builder via addCallback(). In the onOpen just do: conenction.execSQL("PRAGMA busy_timeout = <time in ms>")

7 - You should check your AndroidManifest.xml, WorkManager could run in another process, but only if configured to do so, check if your app has multiple processes by checking the manifest and looking for android:process=

8 - Because AndroidSQLiteDriver is an Android only API you need to create an actual / expect function that return a SQLiteDriver along with the necessary Kotlin multiplatform source set configuration so that for Android it'll return AndroidSQLiteDriver while for other platforms I'll return BundledSQLiteDriver and you pipe that to `setDriver().

Hi. I have updated my app replaced BundledSQLiteDriver with AndroidSQLiteDriver as you suggested.

For now I don't see SQLException: Error code: 5, message: database is locked anymore but I see the new error java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction.

Here is the stack trace.

Fatal Exception: java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction.
       at android.database.sqlite.SQLiteSession.throwIfNoTransaction(SQLiteSession.java:917)
       at android.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:400)
       at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:588)
       at androidx.room.coroutines.AndroidSQLiteDriverPooledConnection.transaction(AndroidSQLiteDriverConnectionPool.android.kt:94)
       at androidx.room.coroutines.AndroidSQLiteDriverPooledConnection.access$transaction(AndroidSQLiteDriverPooledConnection.java:53)
       at androidx.room.coroutines.AndroidSQLiteDriverPooledConnection$transaction$1.invokeSuspend(AndroidSQLiteDriverConnectionPool.android.kt:12)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
       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)
        

Hi. Happy New Year!

After week with AndroidSQLiteDriver I see no SQLException: Error code: 5, message: database is locked but see java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction..

So I think your theory may be right that this is something with "Coroutines and RoomDB".

Hi. This is still a problem. Should I create new issue about java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction. or it is going to be fixed in scope of this issue?

This issue is still blocker for my app and there is already 46 days passed since I reported it.

Hi - Sorry for the delayed response.

I think you are indeed hitting a different issue with the AndroidSQLiteDriver, specifically around the Android version of the connection pool. I can work on this soon.

But I am worried that we still have not found the root cause of your original issue with the BundledSQLiteDriver and the database is locked, if you could somehow create a sample app (I know it can be hard) that would help us a lot.

I also want to mention a 3rd option for Android and that is not using a SQLiteDriver with Room which in turn will cause it to default to using SupportSQLite the underlying SQLite APIs before Room was converted to KMP.

Thats right, not calling setDriver will make Room work in compatibility mode and will use the FrameworkSQLiteOpenHelper and its APIs and will keep the 'before KMP coroutines' behavior.

So. I removed setDriver method. The builder is still in common module. Now the error IllegalStateException: Cannot perform this operation because there is no current transaction happens every time when app trying to make database operation using this code

private val dbMutex = Mutex()

suspend fun <R> MyDatabse.workaroundWithTransaction(block: suspend TransactionScope<R>.() -> R) {
    dbMutex.withLock {
        useWriterConnection {
            it.deferredTransaction(block)
        }

        // TODO: Fix https://issuetracker.google.com/issues/340606803#comment2
        // Manually triggers invalidation
        invalidationTracker.refreshAsync()
    }
}

The stack trace:

java.lang.IllegalStateException: Cannot perform this operation because there is no current transaction.
	at android.database.sqlite.SQLiteSession.throwIfNoTransaction(SQLiteSession.java:1021)
	at android.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:419)
	at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:833)
	at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.endTransaction(FrameworkSQLiteDatabase.android.kt:100)
	at androidx.room.driver.SupportSQLitePooledConnection.transaction(SupportSQLiteConnectionPool.android.kt:90)
	at androidx.room.driver.SupportSQLitePooledConnection.access$transaction(SupportSQLiteConnectionPool.android.kt:51)
	at androidx.room.driver.SupportSQLitePooledConnection$transaction$1.invokeSuspend(Unknown Source:15)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:98)
	at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:113)
	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt: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)

Note: there was AndroidSQLiteDriverPooledConnection now it is SupportSQLitePooledConnection in stack trace.

Also, users report that when using the Android driver, sometimes the database does not return a response from an SQL query where it should have returned it.

The example of such request

@Query("""SELECT * from "${Holder.TABLE_HOLDER}" WHERE "${Holder.COLUMN_HOLDER_ID}" LIKE :holderId""")
fun getHolderById(holderId: String): Flow<Holder?>

I found the way to reproduce it!

First you launch workaroundWithTransaction method, then getHolderById method. The result: getHolderById stops returning result.

This error is ever worse than before because it is reproduceable in almost 100% cases!

I have to return to BundledSQLiteDriver

Can you provide more details on the repro case? Is it possible to create a sample repro? Or maybe a test? Can you please show us some code?

Are you starting a transaction and in the transaction you are also collecting the Flow?

db.workaroundWithTransaction {
  db.dao.getHolderById(...).collect {
    
  }
}

This is not a valid usage of Flow because you are essentially starting a transaction that will never end and that might explain the database locked exception you are seeing.

Here another test I have created based on your description but it works fine for me on all drivers:

@Test
fun check() = runTest {
    async(Dispatchers.IO) {
        // Insert 100 items in a deferred transaction and notifying invalidation tracker
        repeat(100) { id ->
            db.useWriterConnection {
                it.deferredTransaction {
                    db.dao().insert(SampleEntity(id.toLong()))
                }
            }
            db.invalidationTracker.refreshAsync()
        }
    }

    async(Dispatchers.IO) {
        // Collect list of inserted items until list is of size 100, meaning
        // all 100 items where inserted and a result with a list of them was received
        db.dao().getItemListFlow().collect {
            if (it.size == 100) {
                cancel()
            }
        }
    }
}

Hi. The order of reproducing:

1. call db.dao().getHolderById("some_id").first() - will return a result
2. call db.useWriterConnection {...} - to make any change in db
3. call db.dao().getHolderById("some_id").first() - no longer returns a result

Only restarting the app will make db.dao().getHolderById("some_id").first() work again.

For now I can't create a simple repo, maybe later.

I don't have a minimal repro case, but I am facing this issue in my project (https://github.com/tasks/tasks)

I have been using AndroidSQLiteDriver in production and never had a database locked crash. Many months ago I briefly deployed BundledSQLiteDriver but reverted it because of this crash

This weekend I wanted to use window functions on Android so I switched to BundledSQLiteDriver again. It did not crash on my Pixel 9 Pro during development so I thought the issue was fixed. Then I deployed my changes and am getting tons of crashes again

I then tested on a CAT S22. This thing is a potato and I get database locked crashes easily.

I commented out my transactor.withTransaction calls so the only transactions are generated by Room and it still crashes

When I use PRAGMA busy_timeout to increase the timeout then the database just deadlocks instead of crashing

Just to add more details:

I can comment out my @RawQuery, useWriterConnection, and useReaderConnection calls, and I still get database locked crashes using only generated @Query, @Insert, @Update, and @Delete functions. The app runs in a single process

Switching from BundledSQLiteDriver back to AndroidSQLiteDriver fixes the issue completely

On my CAT S22 the app crashes on first launch after a clean install 100% of the time. The app will start after relaunching but it will then crash frequently during synchronization

Hi. Is there any updates? I believe it is should be P1 issue.