Editing Read–write conflict (section)

{{short description |Interleaved transaction conflict}}
{{Use British English |date=February 2024}}
{{Use dmy dates |date=February 2024}}
{{More citations needed |date=February 2024}}
In [[computer science]], in the field of [[database]]s, '''read–write conflict''', also known as '''unrepeatable reads''', is a computational anomaly associated with interleaved execution of transactions. Specifically, a '''read–write conflict''' occurs when a "transaction requests to read an entity for which an unclosed transaction has already made a write request."<ref name="stro81" />

Given a schedule S

:<math>S = \begin{bmatrix}
T1 & T2 \\
R(A) &  \\
 & R(A) \\
 & W(A)\\
 & Com. \\
R(A) & \\
W(A) & \\
Com. & \end{bmatrix}</math>

In this example, T1 has read the original value of A, and is waiting for T2 to finish. T2 also reads the original value of A, overwrites A, and commits.

However, when T1 reads from A, it discovers two different versions of A, and T1 would be forced to [[Abort (computing)|abort]], because T1 would not know what to do. This is an unrepeatable read. This could never occur in a serial schedule, in which each transaction executes in its entirety before another begins. [[Strict two-phase locking]] (Strict 2PL) or [[Snapshot_isolation#History|Serializable Snapshot Isolation]] (SSI) prevent this conflict.