The Runtime Theory

Transaction Lifecycle: From BEGIN to Durable COMMIT

Follow a database transaction through its full lifecycle — BEGIN, statement execution, WAL append, fsync, COMMIT — and see why the log write order makes durability work.

The Runtime Theory Team08 stages

trace / request.md

BEGINASSIGNS AN IDSTATEMENTS RUN INTHE BUFFER POOLPAGES GO DIRTYWAL RECORDAPPENDEDFSYNC MAKESIT DURABLECOMMIT RECORDWRITTENCHANGESBECOME VISIBLEROLLBACK DISCARDSEVERYTHING

readyBEGIN opens a transaction and assigns it a transaction ID. The session leaves autocommit mode, and the database records the starting point in its internal state. No data has been touched yet.

This diagram is the transaction as the database actually lives it: a sequence of in-memory changes that a file keeps honest. BEGIN only assigns an ID and a state. The real work happens in the buffer pool, where rows are modified in pages that may never reach disk during the transaction at all. What makes it a transaction is the write-ahead log. The database appends change records first, fsyncs them, and only then writes a commit record — the append-before-write ordering means the log is always ahead of the data pages. The fsync calls are the commit point; nothing counts as committed until the log says so durably.

The ordering matters because crash recovery reads the same log. Replay a committed transaction's records and the data pages are reconstructed; find a transaction with no commit record and everything it did is undone. ROLLBACK is the same machinery, run eagerly. Each stage in the diagram is a distinct mechanism — buffer pool, WAL append, fsync, commit record, visibility — and the boundaries between them are where durability is won or lost.