A database server loses power without warning seconds after an application received a successful commit for a funds transfer. When the server restarts, the transfer is still present and complete. Which ACID property does this demonstrate, and what mechanism typically provides it?
Select an answer to reveal the explanation.
Short Explanation
Durability is the promise that once the database says committed, it stays committed, even if someone trips over the power cord. The trick is the transaction log: it's written safely to disk before you get the thumbs-up. Data pages can catch up later during recovery.
Full Explanation
Durability guarantees that the effects of a committed transaction survive subsequent failures, including power loss and crashes. Most relational engines implement it through write-ahead logging: before a commit is acknowledged, the log records describing the transaction's changes are flushed to stable storage. The modified data pages may still be only in memory, but after a restart the recovery process replays committed log records into the data files and rolls back incomplete transactions, so the funds transfer reappears exactly as committed. Atomicity concerns all-or-nothing execution of a transaction; it does not depend on writing every data page before each statement, an approach that would be extremely slow and is not how engines work. Isolation controls the visibility of concurrent transactions' work; locks are released at commit or rollback and are not preserved across a restart, so they cannot explain recovered data. Consistency means transactions preserve defined rules, but constraints only validate data; they cannot rebuild lost rows. Exam caveat: disabling synchronous log flushes or using volatile write caches can trade durability for speed, so storage settings matter. Operational check: confirm the log resides on storage with power-protected or disabled write caching and that log flush at commit is enabled.