Read-Committed Isolation prevents dirty reads and dirty writes

Most databases do not support true Isolation because of inherent performance costs with serializing transactions. Instead, they settle for weaker levels of isolation. The most basic level of transaction isolation is Read Committed Isolation.

Databases that support Read Committed Isolation guarantee protection against Dirty Reads. This means that all writes by a transaction become visible to others only after it has been committed, at which point all changes are made available instantaneously.

If Dirty Reads were not prevented, changes made by an ongoing, active transaction might become visible partially to other transactions. This not only causes the other transactions to make incorrect decisions but is also confusing to system users.

Plus, the system may see data that is not guaranteed to be available later. If the transaction aborts, any writes it has made will be rolled back. The system gets into an incorrect state, and reasoning about the source of this irregularity is impossible.

Most databases prevent dirty reads by remembering both the old committed value and the new value set by a transaction holding the write-lock. All requests to read the value when the transaction is in progress receive the old value in response. The new value is visible only after the current transaction is through.

Read-Committed Isolation also guarantees protection from Dirty Writes. When multiple transactions change the same value concurrently, databases delay the second write until the first transaction has been committed or aborted.

If permitted, dirty writes have the adverse effect that changes from different transactions end up being saved, corrupting the wholeness of data controlled within a transaction. It is challenging to fix broken Invariants because data is essentially lost in the middle.

So databases, usually with row-level locks, guarantee that new changes are committed only after all previous writes to the same value are either committed or aborted. This guarantee does not avoid the problem of Lost Updates, though, which needs to be addressed separately.