Read–write conflict

In computer science, in the field of databases, read–write conflict, also known as unrepeatable reads, is a computational anomaly associated with interleaved execution of transactions.

Given a schedule S

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, because T1 would not know what to do. This is an unrepeatable read. This could never occur in a serial schedule. Strict two-phase locking (Strict 2PL) prevents this conflict.

Real-world example

Alice and Bob are using a website to book tickets for a specific show. Only one ticket is left for the specific show. Alice signs on first to see that only one ticket is left, and finds it expensive. Alice takes time to decide. Bob signs on and also finds one ticket left, and orders it instantly. Bob purchases and logs off. Alice decides to buy a ticket, to find there are no tickets. This is a typical read-write conflict situation.

gollark: It's not as if two mimic pygmy eggs even look like a silver.
gollark: I assume they think "well, they don't *ask* for this, and it's not *worth* what they have, but maybe they don't know that despite clearly being trade-savvy or good at hunting enough to get slightly rare things".
gollark: But ask for anything remotely rare - or *have* something rareish - and boom, unrelated offers.
gollark: Well, that's not that bad, and probably occurs because nebulae are pretty common.
gollark: I suspect its users are mostly illiterate.

See also
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.