Atomicity 與 rollback

All or Nothing

A transaction groups several database operations into one unit of work.

The rule is simple. Either every operation takes effect, or none of them do.

That guarantee is called atomicity. An atom cannot be split, and neither can a finished transaction.

Think of a bank transfer. Money leaving one account and arriving in another must succeed together.

Notice that both the debit and the credit sit inside a single sealed boundary, so neither can happen without the other.

The Half-Done Disaster

Imagine the transfer stops halfway.

The first account is already debited $100. The second account never receives it.

The money simply vanishes. The database now holds a state that should never exist.

Atomicity exists to make this partial state impossible, not merely unlikely.

Commit Or Rollback

Every transaction ends in exactly one of two ways.

Commit makes all changes permanent and visible to others.

Rollback undoes every change made inside the transaction, returning the database to how it looked before the transaction began.

There is no third ending. A transaction cannot finish partly applied.

How Rollback Works

Rollback is not magic. The database keeps a record of what it changed.

Before a row is modified, the old value is written to an undo log.

If the transaction fails, the database walks that log backwards and restores each old value.

Once every change is reversed, the transaction is closed as if it never happened.

What Triggers A Rollback

Rollback is not only for crashes.

Your own code can call it on purpose, for example when stock runs out mid-order.

The database can force it when a constraint is violated or a deadlock is detected.

The system can trigger it after a crash, replaying undo logs during recovery.

A Common Misconception

Many people assume a rollback restores the whole database to an earlier point in time.

It does not. Rollback only undoes the changes made by that one transaction.

Other transactions that committed in the meantime stay untouched.

Rollback is surgical, not a time machine.

Using This In Practice

Wrap operations that must succeed together inside one transaction.

Keep transactions short. Long ones hold locks and raise the chance of deadlock rollbacks.

Always handle the failure path. If your code catches an error, decide clearly whether to commit or roll back.

Never assume a write succeeded just because no error was printed.

A bank transfer that debits one account and credits another should be treated as one atomic transaction.

• True
• False

Answer: True

This is correct. Atomicity requires all operations in a transaction to take effect together, preventing a half-completed transfer.

A transaction can _____ to make all changes permanent, or _____ to undo its changes. Before modifying a row, the database writes the old value to an _____.

Answer: A transaction can commit to make all changes permanent, or rollback to undo its changes. Before modifying a row, the database writes the old value to an undo log.

Commit permanently applies the transaction's changes. Rollback reverses them, using the undo log that stored old values before modification.

An order transaction debits inventory for an item, then discovers that a required constraint is violated. What should the database do to preserve atomicity?

• Commit the inventory debit and ignore the violation
• Rollback every change made by the order transaction
• Rollback all changes made by every transaction
• Keep the transaction open until another order succeeds

Answer: Rollback every change made by the order transaction

The database should roll back the transaction, undoing the inventory debit and any other changes made within that transaction. This prevents a partially applied order.