Phenomenon P4, or Lost Update, occurs when the effects of a committed transaction are effectively lost. Some or all effects may be lost. Effects may be temporarily visible to other transactions, then vanish.
In Berenson et al’s original definition, P4 occurs when transaction Ti reads version xi of object x, then writes a new version xk, presumably based on the version it read. Between Ti’s read and write, a second transaction Tj writes xj. Because Ti did not observe xj, Tj’s write is effectively lost.
Alternatively, one can formalize Lost Update in terms of dependency graphs. Tj rw-depends on Ti, since it overwrote the version Ti read. However, Ti’s write of x overwrites Tj’s, which means that Ti ww-depends on Tj. Lost Update is therefore a special case of G-single.
For example, consider two neighbors, Conredge and Irene, at a block party. Each intends to contribute a dessert to an empty dessert tray. Each reads the empty state of the tray. Irene writes back a version of the tray containing her snickerdoodles, and Conredge writes back a version with his peach cobbler. Conredge’s write supercedes Irene’s; it appears as if her snickerdoodles vanished into thin air.
Lost Update is allowed by Read Committed, but proscribed by Snapshot Isolation and Repeatable Read—although many implementations of Repeatable Read actually allow it. If the read uses a cursor, it is also proscribed by Cursor Stability—Berenson et al call this P4C.
When the exact sequence of micro-operations or the version order is unknown, there is an easy way to detect (some) kinds of Lost Update. If two transactions read the same version of some object x, and both write x, and neither observed the other’s write, then one of their writes must have been lost.
Literature
Berenson et al’s Snapshot Isolation paper defined P4 in these terms:
P4 (Lost Update): The lost update anomaly occurs when transaction T1 reads a data item and then T2 updates the data item (possibly based on a previous read), then T1 (based on its earlier read value) updates the data item and commmits. In terms of histories, this is:
P4: r1[x]…r2[x]…w1[x]…c1.
The problem … is that even if T2 commits, T2’s update will be lost.
Adya’s 1999 thesis uses Lost Update repeatedly—notably, as a motivating example for G2 and G-single. However, it does not define a specific phenomenon for it.