Transaction

A transaction is a group of database operations that must be treated as one unit. Think of it like ordering food online - either your entire order is processed (payment, inventory update, delivery scheduled) or nothing happens at all.

Example: Transfer ₹100 from Account A to Account B

BEGIN TRANSACTION
1. Read Account A balance
2. A = A - 100 (deduct money)  
3. Write new balance to A
4. Read Account B balance
5. B = B + 100 (add money)
6. Write new balance to B
END TRANSACTION

Basic Operations

read(X): Copy data item X from database to memory

write(X): Copy data item X from memory back to database

Example Transaction T₁: Transfer ₹50 from A to B

read(A); A := A - 50; write(A); 
read(B); B := B + 50; write(B);

ACID Properties - The Four Rules

1. Atomicity (All or Nothing)

Problem Without Atomicity:

  • A = ₹1000, B = ₹2000

  • System deducts ₹50 from A → A = ₹950

  • System crashes before adding to B

  • Result: A = ₹950, B = ₹2000 (₹50 lost forever!)

With Atomicity: Either both operations succeed or both are undone.

2. Consistency (Rules Always Followed)

Database rules must always be satisfied. Example: "Account balance cannot be negative"

  • If A = ₹30 and you try to transfer ₹50, transaction should fail

  • Total money in system stays same: A + B before = A + B after

3. Isolation (Transactions Don't Interfere)

Each transaction acts like it's the only one running. Problem Without Isolation:

  • A = ₹1000, two people withdraw ₹600 each simultaneously

  • Both see balance ₹1000, both approve withdrawal

  • Result: A = -₹200 (impossible!)

4. Durability (Changes Are Permanent)

Once transaction completes, changes survive system crashes.

Storage Types

  • Volatile Storage: RAM, cache (lost during crashes)

  • Non-volatile Storage: Hard disk, SSD (survives crashes)

  • Stable Storage: Multiple copies on different devices (never lost)

Updated on