Exercise 2: How WAL Mode Achieves the Same Atomicity, Differently — Possible Solution
====================================================================

THE SAME GUARANTEE, VIA A DIFFERENT MECHANISM
------------------------------
Per this chapter, "rather than a before-image journal, new changes
are appended to the WAL file, and the original main database file is
left untouched until a checkpoint. A crash mid-write in WAL mode
still leaves a valid, intact main database file — the old,
pre-transaction state — with the WAL file itself either fully
containing a completed transaction (recoverable) or an incomplete one
(safely discarded on the next open)."

HOW THE ROLLBACK JOURNAL ACHIEVES ATOMICITY
------------------------------
The rollback journal approach WORKS FORWARD from the main file: it
modifies the main file directly, but first saves a copy of what the
affected pages looked like BEFORE the change, so that an incomplete
write can be detected and REVERSED using that saved original content
if a crash happens partway through.

HOW WAL MODE ACHIEVES THE SAME GUARANTEE DIFFERENTLY
------------------------------
WAL mode instead works by NEVER touching the main file at all during
a transaction — new changes are written to a completely separate WAL
file, appended onto the end of it, while the original main database
file sits completely untouched throughout the entire transaction. If a
crash happens mid-write, the main file was never modified in the first
place, so it's automatically still in its valid, pre-transaction state
— no rollback is even needed for the MAIN file, because nothing there
was ever changed. The only question left is what to do with the WAL
file's own partial content: if the crash happened before the
transaction's changes were fully written to the WAL, that partial WAL
entry is recognized as incomplete and simply discarded on the next
open (as if the transaction never happened); if the transaction WAS
fully written to the WAL before the crash, it's recognized as complete
and can be safely applied (or is simply visible to future reads,
depending on checkpoint timing).

THE KEY DIFFERENCE IN APPROACH
------------------------------
The rollback journal achieves atomicity by modifying the main file
directly but keeping a way to UNDO an incomplete change (rollback).
WAL mode achieves the identical guarantee by never touching the main
file directly at all during the transaction, and instead treating an
incomplete WAL entry as something to simply IGNORE rather than needing
to be undone. Both approaches guarantee the same outcome — a
transaction either fully applies or has no effect — but reach it
through structurally opposite strategies (undo an in-place change vs.
never make the in-place change until it's confirmed complete).

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains both mechanisms' own specific strategies precisely using
the chapter's own wording, and directly contrasts the "modify then
undo if needed" approach of the rollback journal against the "don't
modify until confirmed complete" approach of WAL, showing they achieve
the identical guarantee through opposite means.