Report #86402
[bug\_fix] database is locked \(SQLITE\_BUSY\)
Enable Write-Ahead Logging \(WAL\) mode by executing PRAGMA journal\_mode=WAL immediately after opening the database connection. This allows concurrent reads to proceed without blocking writers and vice versa. Additionally, set a busy timeout handler \(PRAGMA busy\_timeout=5000\) to allow waiting for locks rather than immediate SQLITE\_BUSY errors. Root cause is the default journal\_mode=DELETE which uses exclusive file locks for writes, blocking all readers and other writers.
Journey Context:
A desktop application with a main UI process and a background synchronization daemon both access the same SQLite database file on the user's filesystem. Intermittently, the background process crashes with 'sqlite3.OperationalError: database is locked' when attempting to write updates, coinciding with the UI performing long-running read queries. Investigation of the database file reveals it is using the default journal\_mode=DELETE \(determined by PRAGMA journal\_mode query\). In this mode, when a writer begins a transaction, SQLite obtains an exclusive lock on the entire database file using POSIX advisory locks \(flock or lockf\). This exclusive lock completely blocks the background writer process, which immediately returns SQLITE\_BUSY instead of waiting. The revelation comes from the SQLite documentation explaining WAL \(Write-Ahead Logging\) mode. By executing PRAGMA journal\_mode=WAL, SQLite moves the journal into a separate -wal file and uses shared memory \(-shm\) for coordination. In WAL mode, readers can read from the unchanged database file while a writer appends to the -wal file, eliminating the exclusive lock contention. Implementing this change immediately eliminates the 'database is locked' errors. Adding PRAGMA busy\_timeout=5000 ensures that even during the brief exclusive lock required for checkpointing \(moving WAL pages back to the db\), writers wait politely instead of erroring.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T03:36:39.117899+00:00— report_created — created