Premier League Predictor: Astro — Chapter 11, Exercise 2
====================================================

TASK
Explain precisely what WAL mode fixes and what it doesn't, using
SQLite's own documented distinction between reader/writer concurrency
and writer/writer concurrency, and explain why busy_timeout is still
set even with WAL enabled.

SOLUTION

SQLite's own documentation states the real benefit directly: "readers
do not block writers and a writer does not block readers" under WAL
mode, because a writer appends its changes to a separate WAL file
while readers keep reading from the original database file (checking
the WAL file first for anything newer than what they started reading
with). That's a genuine, real fix for exactly the scenario this
chapter names — an admin entering a match result at the same instant
a browser is loading the league table. Under the older default
rollback-journal mode, the writer would hold an exclusive lock that
blocks that read entirely until the write finishes; under WAL, both
can genuinely proceed at the same time.

What WAL does NOT fix is two writers happening at once. The
documentation is explicit that only one writer at a time is still
allowed even in WAL mode — the concurrency WAL adds is specifically
between one writer and any number of readers, not between multiple
writers. SQLite's own docs go further and warn that even in WAL mode,
"there are some obscure cases where a query against a WAL-mode
database can return SQLITE_BUSY, so applications should be prepared
for that happenstance" — meaning WAL reduces how often contention
happens, but doesn't guarantee it can never happen at all.

busy_timeout is set specifically to handle that remaining possibility
gracefully. Without it, a connection that finds the database locked
(even briefly, even under WAL) throws a real SQLITE_BUSY error
immediately. With busy_timeout = 5000, that same connection instead
waits and quietly retries for up to 5 seconds before giving up — for
a brief, real moment of write contention between, say, two nearly-
simultaneous admin actions, this is enough time for the first write to
finish and the second to proceed normally, instead of the second one
failing outright with an error the user would have to see and retry
manually.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly separates WAL's own real, documented benefit
(reader/writer concurrency) from what it explicitly does not provide
(writer/writer concurrency), quotes SQLite's own honest admission that
SQLITE_BUSY remains possible even under WAL, and explains precisely
what busy_timeout does about that remaining case — turning an
immediate hard failure into a brief, usually-successful retry window.