DSAverse

Initializing Sorting Algorithms...

Sorting

Trees

Graphs

Preparing interactive visualizations...

Back to Database Systems

Transaction Isolation Levels

Two transactions share one table. Each isolation level is a different promise about what one may see of the other — watch the anomalies appear, and the locks that make them disappear.

4 levels

4 anomalies

Lock-based model

Scenario

Level

Animation Speed: 1100ms

Step 1 of 0Textbook interleaving

Click Play to begin.

What Each Level Allows

Level	Dirty read	Non-repeatable read	Phantom	Lost update
Read Uncommitted	yes	yes	yes	yes
Read Committed	no	yes	yes	yes
Repeatable Read	no	no	yes	no
Serializable	no	no	no	no

Every cell is produced by running this page’s engine on that scenario. Real engines differ in places: PostgreSQL treats Read Uncommitted as Read Committed and reaches the stronger levels with MVCC snapshots instead of read locks.

How Reads Are Protected

Read Uncommitted
Reads take no locks at all, so they can see writes that have not committed yet.
Read Committed
A read takes a shared lock only for as long as the read itself, so it never sees uncommitted data — but the row can change straight afterwards.
Repeatable Read
Every row a transaction reads stays share-locked until it commits, so nobody can change it underneath. Rows that do not exist yet cannot be locked.
Serializable
Read locks are held to commit and a predicate lock covers the WHERE clause itself, so even a new row that would match has to wait.

Knowledge Check

Question 1 of 3

Which anomaly can still happen at Read Committed?

DSAverse

Transaction Isolation Levels

What Each Level Allows

How Reads Are Protected

Knowledge Check

See also

Transaction Isolation Levels

What Each Level Allows

How Reads Are Protected

Knowledge Check

See also