SQLiteDatabaseLockedException: database is locked
mwshubham opened this issue · 3 comments
✍️ Describe the bug
💣 Steps to reproduce
Not able to reproduce it. This might be due to multiple process used by our application
Stack Trace:
2023-02-15 18:17:29.037 5055-6422/? E/AndroidRuntime: FATAL EXCEPTION: DefaultDispatcher-worker-3 Process: com.eterno:stickyProcess, PID: 5055 android.database.sqlite.SQLiteDatabaseLockedException: database is locked (code 5 SQLITE_BUSY) at android.database.sqlite.SQLiteConnection.nativeExecute(Native Method) at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:707) at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:321) at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:300) at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:571) at android.database.sqlite.SQLiteDatabase.beginTransactionNonExclusive(SQLiteDatabase.java:505) at androidx.sqlite.db.framework.a.c(FrameworkSQLiteDatabase.java:78) at androidx.room.RoomDatabase.q(RoomDatabase.java:570) at androidx.room.RoomDatabase.j(RoomDatabase.java:555) at com.chuckerteam.chucker.internal.data.room.b$7.a(HttpTransactionDao_Impl.java:333) at com.chuckerteam.chucker.internal.data.room.b$7.call(HttpTransactionDao_Impl.java:330) at androidx.room.CoroutinesRoom$Companion$execute$2.a(CoroutinesRoom.kt:65) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.b(ContinuationImpl.kt:33) at kotlinx.coroutines.ar.run(DispatchedTask.kt:106) at androidx.room.ae$1.run(TransactionExecutor.java:47) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:923) Suppressed: kotlinx.coroutines.DiagnosticCoroutineContextException: [cf{Cancelling}@2e14398, Dispatchers.IO]
🔧 Expected behavior
Application should not crash for such scenario
📷 Screenshots
NA
📱 Tech info
- Device: NA
- OS: NA
- Chucker version: 3.5.2
📄 Additional context
NA
Ideally a reproducer here would be help to debug what's going on 👍
This could be due to this faq
https://www.sqlite.org/faq.html#q5
When SQLite tries to access a file that is locked by another process, the default behaviour is to return SQLITE_BUSY. You can adjust this behaviour from C code using the sqlite3_busy_handler() or sqlite3_busy_timeout() API functions.
We can use the content provider approach if the DB operation is performed on a process other than the main process.
I believe we might be able to fix this by specifying enableMultiInstanceInvalidation() when creating the Room DB. Having a reproducer of your app would help greatly