Questions: Isolation Level: READ UNCOMMITTED (Dirty Reads)

Question 1

Transaction A updates an account balance from $1,000 to $500 but has not committed. Transaction B reads the $500 balance and approves a loan. Transaction A then rolls back. What happened under READ UNCOMMITTED?

• A. The database automatically reverses Transaction B's loan approval to maintain consistency
• B. Transaction B made a consequential decision based on data that never existed in any committed state
• C. The rollback returns the system to a safe state with no lasting effects on Transaction B
• D. Transaction B would have been blocked until Transaction A committed or rolled back

Answer: (B)

Under READ UNCOMMITTED, Transaction B read a 'dirty' value — data from an uncommitted transaction that subsequently rolled back. The $500 balance was phantom data: it appeared real during B's read but never became a committed, durable fact. Transaction B's loan approval was based on this phantom, so B's decision rests on data that, from the database's perspective, never existed. The database does not automatically reverse B's side effects; the dirty read simply happened, and B's downstream actions (loan approval, report, transaction denial) are now inconsistent with the actual committed state.

Question 2

Which workload is most appropriate for READ UNCOMMITTED isolation?

• A. Processing a credit card payment where balance accuracy is critical
• B. Running a stock trade that must execute on exactly committed price data
• C. Generating an approximate row count across a massive table for a monitoring dashboard
• D. Any transaction that will be audited for regulatory compliance

Answer: (C)

READ UNCOMMITTED is appropriate only when approximate or slightly stale data is acceptable and lock contention is a serious performance bottleneck. A monitoring dashboard showing an approximate row count can tolerate small inaccuracies — it does not drive individual financial decisions. Credit card payments and stock trades, by contrast, require exactly correct data: acting on a phantom balance or stale price can cause real monetary loss. Auditable transactions demand a verifiable, repeatable data state — READ UNCOMMITTED provides neither. The pattern is: READ UNCOMMITTED is a deliberate performance tradeoff, never a careless default.

Question 3

READ UNCOMMITTED reduces lock contention because transactions at this level do not need to acquire read locks before reading data written by other in-progress transactions.

• T. True
• F. False

Answer: True

This is exactly why READ UNCOMMITTED exists as an option. At higher isolation levels, a reader must wait for a writer to commit (or acquire a shared lock that blocks while an exclusive lock is held). Under READ UNCOMMITTED, readers bypass this: they read whatever is currently on disk or in memory, committed or not. The result is that readers never block writers and writers never block readers, maximizing concurrency. The cost is the dirty read anomaly — the fundamental correctness risk that makes this isolation level dangerous for precision-sensitive workloads.

Question 4

READ UNCOMMITTED should be the default isolation level for most production database applications because it maximizes throughput and most applications can tolerate minor data inconsistencies.

• T. True
• F. False

Answer: False

Most production applications cannot tolerate dirty reads. Acting on uncommitted data that later rolls back produces logical inconsistencies: funds approved that don't exist, inventory reserved that was never actually available, reports generated from phantom records. The performance benefit of READ UNCOMMITTED comes at the cost of correctness, and most application domains cannot accept that trade. The standard default is READ COMMITTED or higher. READ UNCOMMITTED is a narrow, deliberate exception for specific workloads — approximate analytics, progress monitoring — where correctness is explicitly deprioritized. Using it carelessly is a significant risk.

Question 5

What is a 'dirty read' and why does it create a genuine correctness risk rather than just a theoretical concern?

Model answer: A dirty read is a read of data from a transaction that has not yet committed. The risk is concrete: if the writing transaction later rolls back, the reading transaction has acted on data that was never a real committed fact — phantom data. Any decision made on that data (approving a transaction, generating a report, updating another record) is now based on something that, from the database's perspective, never existed. This is not a theoretical edge case: rollbacks happen regularly due to constraint violations, timeouts, deadlocks, and application errors. A system that allows dirty reads will produce inconsistent state in all those situations.

The key insight is that uncommitted data is not tentative-but-probably-correct — it is genuinely uncertain. The whole point of transactions is that uncommitted changes may be rolled back, leaving no trace. A dirty read imports that uncertainty into a separate transaction. Once the dirty-reading transaction uses the data and commits its own changes, those changes are durable — but they are inconsistent with the actual committed history of the database. This is why isolation levels exist: they define how much of this uncertainty a transaction is allowed to observe.