Problem
The SQLite database runs in default journal mode (DELETE/rollback journal). In this mode, SQLite allows only one writer at a time and blocks all readers while a write is in progress. The Node.js Express server handles HTTP requests concurrently. When two requests attempt database operations simultaneously (e.g., a task creation and a task list fetch arriving within milliseconds of each other), one request receives SQLITE_BUSY and typically fails with a 500 error.
Steps to Reproduce
- Use a load-testing tool to send 10 concurrent requests to
GET /api/tasks and POST /api/tasks simultaneously
- Observe
SQLITE_BUSY errors in the server logs and HTTP 500 responses
Proposed Fix
Enable Write-Ahead Logging (WAL) mode immediately after opening the database. WAL allows concurrent reads alongside a single writer:
const db = new Database("studyplan.db");
db.pragma("journal_mode = WAL");
db.pragma("busy_timeout = 5000"); // retry for up to 5 seconds before failing
This is a one-time configuration change that eliminates lock contention in typical usage patterns.
Complexity: Level 2 | Program: GSSOC '26
Problem
The SQLite database runs in default journal mode (DELETE/rollback journal). In this mode, SQLite allows only one writer at a time and blocks all readers while a write is in progress. The Node.js Express server handles HTTP requests concurrently. When two requests attempt database operations simultaneously (e.g., a task creation and a task list fetch arriving within milliseconds of each other), one request receives
SQLITE_BUSYand typically fails with a 500 error.Steps to Reproduce
GET /api/tasksandPOST /api/taskssimultaneouslySQLITE_BUSYerrors in the server logs and HTTP 500 responsesProposed Fix
Enable Write-Ahead Logging (WAL) mode immediately after opening the database. WAL allows concurrent reads alongside a single writer:
This is a one-time configuration change that eliminates lock contention in typical usage patterns.
Complexity: Level 2 | Program: GSSOC '26