Report #11790
[bug\_fix] database is locked \(SQLITE\_BUSY\)
The root cause is that SQLite uses file-level locking by default \(POSIX advisory locks\), and when one connection holds a RESERVED or EXCLUSIVE lock for writing, subsequent connections attempting to write receive SQLITE\_BUSY immediately \(or after busy\_timeout expires\). The fix is to enable WAL \(Write-Ahead Logging\) mode via \`PRAGMA journal\_mode = WAL;\` which allows readers to proceed concurrently with a single writer, and implement exponential backoff retry logic in the application for SQLITE\_BUSY errors. Additionally, ensure a single connection pool is used rather than opening/closing connections per operation, and set a reasonable \`busy\_timeout\` \(e.g., 5000ms\) as a safety net.
Journey Context:
You're building a mobile app with Flutter and \`sqflite\` for a local CRM. Users report that when they rapidly click 'Save Contact', the app crashes with 'DatabaseException\(database is locked\)'. You check the code and see multiple write operations in rapid succession. The rabbit hole involves realizing that sqflite runs on a separate thread, discovering that SQLite in WAL mode should handle readers/writers better, but you're in DELETE journal mode. You try adding \`PRAGMA busy\_timeout = 5000\` but it still fails because the write transaction holds the lock and the next write tries immediately. You realize the app is opening multiple connections to the same DB file from different isolates without proper WAL mode configuration.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T14:18:13.397036+00:00— report_created — created