# Write-Write Conflict Occurs when two concurrent transactions both write to the same data item, potentially causing a **lost update**. ## Example ```text Initial: X = 100 T1: read(X) → 100 T2: read(X) → 100 T2: write(X) = 100 + 50 = 150 T1: write(X) = 100 - 20 = 80 ← T2's update is lost! ``` Correct final value should be 130, not 80. ## Prevention | Method | How it prevents conflicts | |--------|--------------------------| | **Two-Phase Locking (2PL)** | Exclusive lock required before writing; second transaction blocks | | **Timestamp Ordering** | Rejects out-of-order writes; rolls back violating transaction | | **MVCC** | New versions instead of overwriting; conflict detected at commit | | **Optimistic CC** | Validated at commit time; one transaction rolled back on conflict | ## Isolation Levels Write-write conflicts are prevented at **all** standard SQL isolation levels (including Read Uncommitted). However, the higher-level lost update problem (read-then-write sequences) requires at least **Repeatable Read** to prevent. --- See also: [[Blind Write]], [[Database Transaction Schedule]]