From Surf Wiki (app.surf) — the open knowledge base
Write–write conflict
Interleaved transaction conflict
Interleaved transaction conflict
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."
Given a schedule S
S = \begin{bmatrix} T1 & T2 \ W(A) & \ & W(B) \ W(B) & \ Com. & \ & W(A)\ & Com. \end{bmatrix}
note that there is no read in this schedule. The writes are called blind writes.
We have a dirty write. | access-date = 29 July 2012 }} 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.
References
References
- (1981). "Distributed database concurrency controls using before-values". [[Association for Computing Machinery]].
This article was imported from Wikipedia and is available under the Creative Commons Attribution-ShareAlike 4.0 License. Content has been adapted to SurfDoc format. Original contributors can be found on the article history page.
Ask Mako anything about Write–write conflict — get instant answers, deeper analysis, and related topics.
Research with MakoFree with your Surf account
Create a free account to save articles, ask Mako questions, and organize your research.
Sign up freeThis content may have been generated or modified by AI. CloudSurf Software LLC is not responsible for the accuracy, completeness, or reliability of AI-generated content. Always verify important information from primary sources.
Report