Transaction A debits $200 from an account (balance drops from $500 to $300) but has not yet committed. Transaction B reads the balance, sees $300, and approves a $250 withdrawal. Transaction A then rolls back. What is the core problem?
ATransaction B has acted on data that never existed in any committed state — the 'true' balance was always $500, and B's decision was based on a phantom value
BTransaction A's rollback is invalid because Transaction B already observed its changes
CThere is no real problem — rollbacks always restore committed state correctly regardless of what other transactions observed
DThe issue is that B should have used SELECT FOR UPDATE to lock the row first
The dirty read problem is that B consumed uncommitted, provisional data. From the database's committed perspective, the balance was $500 the entire time A was running — A's debit was tentative. When A rolled back, committed state was restored correctly, but B has already made a decision (approving a $250 withdrawal) based on a value ($300) that never validly existed. Option C misses the point: the database state is fine, but B's external action or further writes cannot be undone.
Question 2 Multiple Choice
Why does the Read Uncommitted isolation level exist in databases, despite allowing dirty reads?
AIt is a historical artifact that modern databases have deprecated in favor of safer alternatives
BIt prevents phantom reads while permitting dirty reads, making it appropriate for financial applications
CIt offers better performance by skipping locking and versioning overhead, making it acceptable for approximate queries where exact correctness is not required
DIt is required by distributed databases that cannot coordinate transaction commits across nodes
Read Uncommitted exists for performance-sensitive scenarios where approximate results are acceptable — dashboards showing rough row counts, analytics that can tolerate slightly stale or provisional data, or debugging queries. By skipping shared read locks or MVCC versioning, reads complete faster. The isolation level is not deprecated; it's simply dangerous for any logic that requires correctness. Option B is wrong — phantom reads are a different anomaly prevented by higher isolation levels.
Question 3 True / False
A dirty read can primarily cause problems if the reading transaction itself also writes data based on what it read.
TTrue
FFalse
Answer: False
Even a purely read-only transaction is harmed by dirty reads. If Transaction B generates a bank statement based on an uncommitted balance, the statement is wrong regardless of whether B writes anything. The problem is that B's *output* (report, decision, response to a user) was based on data that never entered committed state. Dirty reads corrupt any downstream artifact, not just further database writes.
Question 4 True / False
If Transaction A rolls back after Transaction B has read its uncommitted changes, the database's committed state is correctly restored, but Transaction B may have made decisions or produced output based on data that never existed in any committed form.
TTrue
FFalse
Answer: True
This precisely captures the dirty read problem. The database recovers correctly — committed state is intact. But Transaction B has consumed a 'dirty' (uncommitted, provisional) value. Any logic, output, or further actions B took based on that value are based on a phantom. The rollback fixes the database; it cannot fix what B already did with the data it read.
Question 5 Short Answer
Why is the term 'dirty' used for dirty reads? What specific characteristic of the read makes it dangerous?
Think about your answer, then reveal below.
Model answer: A 'dirty' write is one that is uncommitted and provisional — it may or may not survive. Reading dirty data means reading changes that have not passed the point of no return. The danger is that the writing transaction might roll back, erasing the data the reading transaction observed. The reader then has acted on a value that never validly existed in the committed state of the database. Unlike a committed read (which reflects a stable, permanent fact), a dirty read reflects a tentative fact that may vanish.
The 'dirty' metaphor contrasts with 'clean' (committed) writes. Committed data is clean because it has been durably validated; uncommitted data is dirty because it is still in flux. The specific danger is the possibility of rollback: the writer may undo everything, leaving the reader having consumed a ghost value. This cannot happen with committed reads because committed writes, by definition, are permanent.