Dirty Read

What It Is

A dirty read (also called an "uncommitted dependency" or "reading uncommitted data") occurs when a transaction Tj reads a value that another transaction Ti has written but not yet committed. If Ti subsequently rolls back (aborts), the value Tj read never actually became a permanent part of the database — Tj based its logic on data that, from the database's final point of view, never truly existed.

Concrete Example — Bank Balance

Account A starts at ₹1000. T1 attempts a withdrawal of ₹100 but will end up aborting (say, a later step in T1 fails a business-rule check). T2 reads A in the middle of T1's uncommitted work.

Time  Operation                Effect
1     R1(A)                    T1 reads A = 1000
2     A = 1000 - 100
3     W1(A)                    A is now 900 -- UNCOMMITTED
4     R2(A)                    T2 reads A = 900  <- a DIRTY READ (T1 hasn't committed)
5     T2 uses 900 to compute, say, a loan-eligibility check, and COMMITs its own result
6     ABORT1 / ROLLBACK1       T1 rolls back; A reverts to 1000

At step 6, the database restores A to 1000 — the ₹100 withdrawal never really happened. But T2 already read and acted on (and committed based on) the value 900 at step 4-5. T2's decision was made using a number that, in the database's final consistent history, never existed. If T2's action was something irreversible (e.g., approving a loan, sending a notification, writing an audit log entry), that side effect cannot be undone even though the data it was based on has vanished.

Why It's Dangerous

Unlike a lost update (where at least the final committed values are self-consistent, just wrong), a dirty read can corrupt a transaction's decision-making with a value that is later proven to have never been real. The reading transaction (T2) has no way of knowing, at the time it reads, whether the writer (T1) will ultimately commit or abort — it's the concurrency control's job to prevent it from being exposed to that uncertainty at all.

How It's Prevented

A cascadeless schedule (23.8) is defined exactly to rule this out: it requires that a transaction may only read a data item after the writer has already committed. In practice, this is enforced by the reader taking a (shared) lock request on A that is blocked until T1's exclusive lock on A is released at commit/abort — under strict two-phase locking, this happens automatically, since T1 holds its write lock until it commits or aborts.

Edge Cases

• If T1 aborts before T2 ever reads A, there is no dirty read — T2 would simply see the restored, pre-T1 value (or block until it's available, depending on locking).
• A dirty read is different from a lost update (23.10): in a lost update, both transactions' writes are ultimately committed, and the issue is the second silently overwriting the first; in a dirty read, the issue is a transaction observing data from a write that is never committed at all.
• Some systems deliberately allow dirty reads under a weak isolation level (READ UNCOMMITTED) for performance-critical, tolerance-of-imprecision use cases (e.g., an approximate row-count estimate) — this anomaly is precisely what Chapter 25 (Isolation Levels) formalizes as the first anomaly each isolation level either does or doesn't prevent.

Key Takeaways / Interview Angle

• Q: What is the single condition that defines a dirty read? A transaction reads a value written by another transaction that has not yet committed (and might still abort).
• Q: How is a dirty read prevented at the schedule level? By enforcing cascadelessness — never letting a read happen until the last writer of that item has committed.
• Q: Why is this topic a setup for Chapter 25? Isolation levels are literally defined by which of dirty read, non-repeatable read (23.12), and phantom read (23.13) they prevent — dirty read is the most severe of the three and is the first one every isolation level above the weakest is designed to eliminate.