Report #16274
[bug\_fix] database is locked \(SQLITE\_BUSY\)
Enable WAL \(Write-Ahead Logging\) mode by executing PRAGMA journal\_mode=WAL; this allows concurrent readers to coexist with a single writer without returning BUSY. Root cause: Default DELETE journal mode requires exclusive locks for writes, causing any concurrent reader or writer to receive SQLITE\_BUSY immediately if the database is locked.
Journey Context:
A developer deploys a Flask application with 10 Gunicorn workers using SQLite for a small-scale API. Under light load, endpoints start failing with 'database is locked'. The developer first increases the busy timeout \(PRAGMA busy\_timeout=5000\), which merely delays the error. Checking the SQLite documentation, they realize the default journal\_mode=DELETE forces exclusive locks. They connect via sqlite3 CLI, run PRAGMA journal\_mode=WAL;, and reload the app. The BUSY errors vanish because WAL mode permits concurrent reads during writes, though writes remain serialized.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T02:17:23.987317+00:00— report_created — created