Transaction A reads a row showing a balance of $1,000. Transaction B then updates that balance to $500 and commits. Transaction A reads the same row again. Under READ COMMITTED, what does transaction A see on its second read?
A$1,000 — READ COMMITTED ensures a consistent snapshot for the entire transaction
B$500 — each statement sees the latest committed data at the time it runs
CAn error — concurrent reads and writes are blocked under READ COMMITTED
D$1,000 — READ COMMITTED only prevents dirty reads, not committed changes
Under READ COMMITTED, each individual statement sees the most recently committed version of data at the time that statement executes — not a frozen snapshot from when the transaction began. So transaction A's second read sees $500, the newly committed value. This is the non-repeatable read anomaly: the same query returns different results within one transaction. Option D is a common confusion — READ COMMITTED does prevent dirty reads, but it does NOT freeze the snapshot across statements, which is why non-repeatable reads are still possible.
Question 2 Multiple Choice
Which of the following is NOT prevented by the READ COMMITTED isolation level?
AReading data that another transaction has written but not yet committed
BActing on a value that will later be rolled back by another transaction
CSeeing different values for the same row in two reads within one transaction
DReading a version of a row created by a transaction that subsequently aborted
Options A, B, and D all describe dirty reads — reading uncommitted data — which READ COMMITTED specifically prevents. Option C describes a non-repeatable read: two reads of the same row within one transaction return different committed values because another transaction committed a change in between. READ COMMITTED does NOT prevent this. To prevent non-repeatable reads, you need a higher isolation level like REPEATABLE READ or SERIALIZABLE.
Question 3 True / False
Under READ COMMITTED, a transaction generally sees the same data most of the time it reads the same row.
TTrue
FFalse
Answer: False
This is the key limitation of READ COMMITTED. While it guarantees you only see committed data, it does not guarantee consistency across multiple reads within the same transaction. Another transaction can commit a change between your first and second read of the same row, causing you to see different values — the non-repeatable read anomaly. For a frozen, consistent snapshot across all reads in a transaction, you need REPEATABLE READ or SERIALIZABLE.
Question 4 True / False
READ COMMITTED prevents dirty reads by ensuring that a transaction only ever reads data that has already been committed by other transactions.
TTrue
FFalse
Answer: True
This is precisely the guarantee READ COMMITTED provides. In MVCC-based databases like PostgreSQL, each statement sees the most recently committed version of each row at the time the statement runs. In lock-based implementations, readers wait for exclusive write locks to be released before reading. Either way, the result is the same: you never see uncommitted data that might later be rolled back. This is the defining property that distinguishes READ COMMITTED from READ UNCOMMITTED (which allows dirty reads).
Question 5 Short Answer
Explain why READ COMMITTED prevents dirty reads but not non-repeatable reads, and describe a scenario where this distinction matters.
Think about your answer, then reveal below.
Model answer: READ COMMITTED ensures each statement sees only committed data at the moment it runs. This prevents dirty reads because you never act on data from an in-progress transaction that hasn't committed. However, if you read the same row twice within your transaction, the second read takes a fresh snapshot — so if another transaction commits a change in between, you see the new value. This is a non-repeatable read. A scenario where it matters: a transaction reads an account balance, performs a calculation, then re-reads the balance before writing. If another transaction commits a deposit in between, the two reads disagree, and the calculation may be wrong.
The core distinction is between statement-level consistency (READ COMMITTED) and transaction-level consistency (REPEATABLE READ). READ COMMITTED gives you a fresh snapshot per statement — great for concurrency, but it means the same query can return different results within one transaction. Applications that read-then-act (especially those that read multiple times) are vulnerable to non-repeatable read anomalies. Financial report generation is a classic example: if rows change between the start and end of a large aggregation query, the totals may be internally inconsistent.