26 - Transactions & ACID

511 words

3 min read

Visual companion

Python

Type and operator map

Python Week 1: the first filter for runtime behavior

Open gallery Related surface

View

Revision summary

What this note is really saying

Short form

# 26 - Transactions & ACID ## 🎯 Learning Objectives After reading this topic, you will be able to: - Define ACID properties - Describe the transaction state machine - Explain why atomicity and durability are critical - Understand the role of the transaction manager ## 📖 Core Content ### 26.1 Intuition: Why Transac...

26 - Transactions & ACID

🎯 Learning Objectives

After reading this topic, you will be able to:

Define ACID properties
Describe the transaction state machine
Explain why atomicity and durability are critical
Understand the role of the transaction manager

📖 Core Content

26.1 Intuition: Why Transactions?

Consider a bank transfer: ₹500 from Account A → Account B.


python
# Step 1: Read A (balance = 1000)
# Step 2: A = A - 500 (balance = 500)
# Step 3: Read B (balance = 200)
# Step 4: B = B + 500 (balance = 700)
# Step 5: Commit

What if the system crashes after Step 2 but before Step 4? ₹500 disappears! A transaction is a collection of operations that performs a single logical function. The DBMS guarantees that either ALL operations complete or NONE do.

Why This Matters: Without transactions, data integrity is impossible in a concurrent, failure-prone world.

26.2 ACID Properties

Property	Meaning	How It's Achieved
Atomicity	All-or-nothing execution	Recovery system (undo log)
Consistency	Valid state → valid state	Application + integrity constraints
Isolation	Concurrent → appears serial	Concurrency control (locking)
Durability	Committed changes persist	Recovery system (redo log)

Key insight: Consistency follows from atomicity + isolation + integrity constraints.

26.3 Transaction States

(Diagram)

State	Description
Active	Initial state; statements are executing
Partially Committed	After final statement, before commit
Committed	Transaction completed successfully
Failed	Could not complete (error or abort)
Aborted	Rolled back to before the transaction

26.4 Commit and Abort

Commit: Transaction completed successfully. Changes are made permanent (durability).
Abort: Transaction failed. Changes are undone (atomicity).

26.5 Schedule

A schedule is the order in which operations from one or more transactions execute. Serial schedule: Transactions execute one after another (no overlap). Concurrent schedule: Operations from multiple transactions interleave. A correct concurrent schedule must be equivalent to some serial schedule.

📐 Key Concepts

Term	Definition
Transaction	Logical unit of work with ACID properties
Schedule	Order of operations from one or more transactions
Serial schedule	Transactions execute sequentially
Concurrent schedule	Operations interleave

⚠️ Common Pitfall

The Mistake: Thinking consistency is entirely the DBMS's responsibility. Why: The DBMS ensures atomicity + isolation + integrity constraints, but the application must ensure that transactions make sense semantically (e.g., a transfer should debit and credit the same amount).

📝 Practice Questions

Q1. List and explain the ACID properties.

Answer

Atomicity: Transaction completes fully or not at all

Consistency: Database moves from one valid state to another

Isolation: Concurrent transactions don't interfere

Durability: Committed changes persist after failures

Q2. What is the difference between a serial and a concurrent schedule?

Answer

Serial: Transactions execute one at a time (no overlap, simple but slow). Concurrent: Operations interleave (faster, but must ensure correctness via serializability).

Q3. Draw the transaction state diagram.

Answer

Active → (complete) → Partially Committed → (commit) → Committed Active → (fail) → Failed → (rollback) → Aborted

🔗 Cross-References

Next Topic: 27 - Serializability
Related: 30 - Log-Based Recovery (atomicity and durability)
Textbook: Chapter 14 (Transactions) Join Discord Previous25 - HashingNext27 - Serializability