What is dirty read in the context of transaction processing?

Transaction isolation anomalies describe the problems that can occur when concurrent transactions access shared data before one of them commits. A dirty read is one such anomaly: it happens when a transaction reads a value that a different, still-active transaction has modified but not yet committed.

Here, only reading a value changed by another transaction before that transaction commits matches this definition. The risk is concrete: if the modifying transaction later rolls back (say, due to a constraint violation or an explicit abort), the value the first transaction already read never becomes real - it read data that turned out to be invalid.

Contrasting this against the other options makes the distinction clear:

• Reading data that sits in a buffer but is not yet written to disk is a durability/storage concern - it says nothing about whether the owning transaction has committed, so it is a different axis from a dirty read.

• Reading data only after it has been committed is the safe, guaranteed-visible read that isolation is designed to provide - it is the absence of the anomaly, not an example of it.

• A transaction overwriting data that another transaction has already updated, with neither aware of the other, describes a lost update - a write-write conflict, not a case of reading someone else's still-uncommitted change.