Understanding Dirty Reads and Writes: How Transaction Isolation Keeps Your Data Safe

When two transactions access the same data without proper coordination, concurrency bugs such as dirty reads and dirty writes can occur.

Dirty Read

A dirty read happens when a transaction reads data that has been modified by another transaction that has not yet committed. Example: transaction 1 sets x=3 but has not committed; transaction 2 reads get x and still sees the old value 2.

Why Prevent Dirty Reads

If a transaction updates multiple objects, a dirty read may show only part of the update, confusing users (e.g., new email but old unread count).

If a transaction aborts, any data it wrote must be rolled back; a dirty read could expose data that will never be committed.

Dirty Write

A dirty write occurs when two concurrent transactions try to modify the same object and the later write overwrites the earlier uncommitted write.

In a used‑car marketplace, two buyers may both update the vehicle list and the invoice table; without protection the invoice could be sent to the wrong buyer.

Dirty write does not prevent lost‑update problems, which require additional mechanisms.

Isolation Levels and Guarantees

Read committed: a transaction sees only data that has been successfully committed (prevents dirty reads).

Write protection: a transaction can overwrite only data that has been successfully written (prevents dirty writes).

Implementation

Most mainstream databases (Oracle, PostgreSQL, SQL Server, etc.) use row‑level locks. When a transaction wants to modify a row, it must acquire a lock and hold it until the transaction ends, ensuring that only one transaction can write the row at a time.

To prevent dirty reads, some systems keep the old committed value and the new uncommitted value separately; reads return the old value until the transaction commits.

Only a few databases (IBM DB2, Microsoft SQL Server with read_committed_snapshot = off) use read locks for read‑committed isolation.