Write–write conflict: Difference between revisions
imported>OAbot m Open access bot: url-access updated in citation with #oabot. |
imported>DeemDeem52 mNo edit summary |
||
| Line 16: | Line 16: | ||
& Com. \end{bmatrix}</math> | & Com. \end{bmatrix}</math> | ||
note that there is no read in this schedule. The writes are called '' | note that there is no read in this schedule. The writes are called ''[[Blind write|blind writes]]''. | ||
We have a '''''dirty write'''''.<ref name="sql-isolation"> | We have a '''''dirty write'''''.<ref name="sql-isolation"> | ||
Latest revision as of 15:22, 10 June 2025
Template:Short description Template:Use British English Template:Use dmy dates Template:More citations needed In computer science, in the field of databases, write–write conflict, also known as overwriting uncommitted data is a computational anomaly associated with interleaved execution of transactions. Specifically, a write–write conflict occurs when "transaction requests to write an entity for which an unclosed transaction has already made a write request."[1]
Given a schedule S
note that there is no read in this schedule. The writes are called blind writes.
We have a dirty write.[2] Any attempts to make this schedule serial would give off two different results (either T1's version of A and B is shown, or T2's version of A and B is shown), and would not be the same as the above schedule. This schedule would not be serializable.
Strict 2PL overcomes this inconsistency by locking T1 out from B. Unfortunately, deadlocks are something Strict 2PL does not overcome all the time.