Dirty Read

A dirty read is a read anomaly that happens when one transaction reads data that has been modified by another transaction but not yet committed. If the modifying transaction later aborts or rolls back, the first transaction ends up using invalid, “dirty” data that never should have existed.

In simple terms:

A dirty read is like reading a change that was temporarily written but then erased, so the reading transaction bases its work on something that does not actually exist in the database.

What Is a Dirty Read?

A dirty read occurs under these conditions:

• Transaction T1 modifies a data item (for example, updates a row’s salary) but does not commit yet.

• Transaction T2 reads that changed value before T1 commits.

• Transaction T1 aborts or rolls back, so its changes are undone.

Now T2 has used a value that never became permanent, yet it may have already computed results, updated other records, or even committed its own work. This is a dirty read.

Example

Suppose a table EMPLOYEE(emp_id, salary).

T1:

Does not commit yet.

T2:

→ reads 60000.

Uses this value for some calculation or another update.

T1:

→ the salary change is undone; the original value (say 50000) is restored.

Here, T2 has read a dirty value (60000) that never actually exists in the committed database, yet its actions are based on this incorrect data.

Why Dirty Read Is a Problem?

• It breaks consistency:
  A transaction may make decisions based on data that later disappears.

• It breaks isolation:
  Uncommitted changes “leak” to other transactions, even though they should be hidden until committed.

• It can cause cascading failures:
  If T2’s work is also committed, it may be logically wrong because it depends on a change that never happened.

Dirty read is one of the three main read anomalies, along with non-repeatable read and phantom read.

How Databases Avoid Dirty Read

To prevent dirty reads, DBMS enforce isolation levels:

• Read Uncommitted (lowest level): allows dirty reads; rarely used in serious applications.

• Read Committed and higher levels: do not allow dirty reads; a transaction cannot read data modified by another transaction until that transaction commits.

At the protocol level, this is achieved by:

• Blocking reads of uncommitted data until the writing transaction commits.

• Using locks or state tracking to hide uncommitted changes from other transactions.

Why It Matters for Beginners

• Dirty read shows that isolation is not only about conflicting writes; it also includes what other transactions can see.

• It explains why most real-world databases use at least Read Committed isolation by default, to avoid basing work on uncommitted, potentially rolled-back changes.

Summary

A dirty read in DBMS occurs when a transaction reads data that has been modified by another transaction but not yet committed, and the modifying transaction later aborts, undoing the change. This leads the reading transaction to use invalid, temporary data, breaking consistency and isolation. To prevent dirty reads, databases use isolation levels such as Read Committed or higher, which block reads of uncommitted data and ensure that transactions only see committed, valid states of the database.