Serializable Isolation & SSI

Does Serializable Remove Concurrency?

Not completely — but yes, it heavily restricts it. Serializable doesn't mean transactions run literally one by one — it means the final result must be equivalent to some serial execution.

How It's Implemented

Option 1 — Strict Locking (older approach)

• Puts locks on every read/write/range
• Other transactions wait until lock is released
• This kills concurrency heavily

Option 2 — MVCC + Serializable Snapshot Isolation (SSI)

• Used by PostgreSQL
• Transactions work on snapshots of data
• Run concurrently, but DB detects conflicts at commit time
• If conflict found → one transaction is aborted & retried
• Much better concurrency

Problems With Read Committed That SSI Solves

Problem 1 — Non-Repeatable Read

T1: SELECT balance → 500 (snapshot at t=100)
T2: UPDATE balance = 800 → COMMIT
T1: SELECT balance → 800 (fresh snapshot at t=101)

Same query, same transaction → different results.

Problem 2 — Read Skew

T1: SELECT balance from Account A → 500 (t=100)
T2: transfers 200 from A to B → COMMIT (t=101)
T1: SELECT balance from Account B → 300 (t=101, fresh snapshot)

Report shows: Account A = 500 (before), Account B = 300 (after) → inconsistent view.

Problem 3 — Write Skew

Rule: At least 1 doctor must be on call at all times. Currently: Doctor A = on call, Doctor B = on call.

T1: checks → 2 doctors on call → sets Doctor A = off call
T2: checks → 2 doctors on call → sets Doctor B = off call
Both commit successfully
Result: 0 doctors on call — Rule violated!

SSI Dependency Tracking

SSI tracks 3 types of dependencies between transactions:

• wr-dependency → T2 writes what T1 reads
• rw-dependency → T2 reads what T1 writes
• ww-dependency → T2 writes what T1 writes

If a dangerous cycle is detected → one transaction is ABORTED and retried → consistency maintained.

Comparison Table

Problem	Read Committed	Repeatable Read	Serializable / SSI
Non-Repeatable Read	No	Yes	Yes
Read Skew	No	Yes	Yes
Lost Update	No	Partial	Yes
Write Skew	No	No	Yes