Durability property: In a durable transaction, are all changes that were committed guaranteed to be permanent?

Introduction / Context:
Durability is the “D” in ACID. It ensures that once a transaction commits, its effects survive power loss, crashes, or restarts. This question checks that understanding directly.

Given Data / Assumptions:

• The system uses write-ahead logging (or equivalent) and stable storage.
• Commit protocol ensures log records and relevant data are persisted.
• Recovery procedures reapply or undo as needed after a crash.

Concept / Approach:
On commit, the DBMS forces necessary log records to durable storage (fsync/flush). After a crash, REDO ensures committed updates reappear; UNDO removes effects of uncommitted transactions. Thus, committed changes are permanent from the application’s perspective.

Step-by-Step Solution:

Verification / Alternative check:
Examine DBMS guarantees for synchronous commit vs. relaxed (asynchronous) modes; durability can be configured, but the contract of durability assumes synchronous commit.

Why Other Options Are Wrong:

• “Only until the next checkpoint” is wrong: checkpoints optimize recovery; they do not limit durability.
• “Only if the server does not crash” contradicts durability’s purpose.

Common Pitfalls:
Confusing user-configured non-durable modes (e.g., delayed fsync) with the definition of durability itself.

Final Answer:
Correct