Editing ACID (section)

=== Isolation failure ===
To demonstrate isolation, we assume two transactions execute at the same time, each attempting to modify the same data. One of the two must wait until the other completes in order to maintain isolation.

Consider two transactions:
* T<sub>1</sub> transfers 10 from A to B.
* T<sub>2</sub> transfers 20 from B to A.

Combined, there are four actions:
# T<sub>1</sub> subtracts 10 from A.
# T<sub>1</sub> adds 10 to B.
# T<sub>2</sub> subtracts 20 from B.
# T<sub>2</sub> adds 20 to A.

If these operations are performed in order, isolation is maintained, although T<sub>2</sub> must wait. Consider what happens if T<sub>1</sub> fails halfway through. The database eliminates T<sub>1</sub>'s effects, and T<sub>2</sub> sees only valid data.

By interleaving the transactions, the actual order of actions might be:
# T<sub>1</sub> subtracts 10 from A.
# T<sub>2</sub> subtracts 20 from B.
# T<sub>2</sub> adds 20 to A.
# T<sub>1</sub> adds 10 to B.

Again, consider what happens if T<sub>1</sub> fails while modifying B in Step 4. By the time T<sub>1</sub> fails, T<sub>2</sub> has already modified A; it cannot be restored to the value it had before T<sub>1</sub> without leaving an invalid database. This is known as a [[Write–write conflict|write-write contention]],<ref>{{Cite book |last1=Silberschatz |first1=Abraham |url=https://www.worldcat.org/title/436031093 |title=Database system concepts |last2=Korth |first2=Henry F. |last3=Sudarshan |first3=S. |date=2011 |publisher=McGraw-Hill |isbn=978-0-07-352332-3 |edition=6th |location=New York |page=1042 |chapter=Advanced Application Development |oclc=436031093}}</ref> because two transactions attempted to write to the same data field. In a typical system, the problem would be resolved by reverting to the last known good state, canceling the failed transaction T<sub>1</sub>, and restarting the interrupted transaction T<sub>2</sub> from the good state.