Anomalies
Lost Update
A lost update overwrites an earlier write derived from a stale read.
Lost update
A lost update occurs when two transactions read the same item and both try a read-modify-write update. The later write overwrites the earlier intent. Note: the render shows the trace order, not just the final cell.
Both transactions read
The compiled trace has 2 reads before the writes finish. Note: both reads are stale bases for separate update intents.
these traces model specific anomalies under a read-latest-write execution model; isolation levels (RC/RR/SI/serializable) and MVCC mechanism are modelled later - no product claims.
Overwrite
Transaction T1 wrote 110; transaction T2 overwrote it. The lost write value is 110 and the final state has 1 item. Note: the final value appears in the render, not in prose.
these traces model specific anomalies under a read-latest-write execution model; isolation levels (RC/RR/SI/serializable) and MVCC mechanism are modelled later - no product claims.
Final state can look harmless
The interleaved final value is 120 and the serial baseline value is 120; the match flag is yes. Note: this is why the lesson reads the trace intent, not only the final table.
these traces model specific anomalies under a read-latest-write execution model; isolation levels (RC/RR/SI/serializable) and MVCC mechanism are modelled later - no product claims.
Summary
Lost update is an overwrite anomaly caused by interleaved read-modify-write work. The important point is intent, not only final state. This trace ends at a value that the serial baseline also produces, so the final state alone looks harmless. The anomaly is that one read-modify-write intent was silently discarded: two writes were derived from the same stale read, and only one derived update survives. Write skew is different: no write is lost; a cross-item constraint breaks instead. Note: isolation levels, serializable behavior, and MVCC mechanisms are deferred to later books.