Concept:
In a database system, concurrency control is essential to prevent "Race Conditions" when multiple transactions access and modify the same data simultaneously. The "Lost Update Problem" is a classic concurrency anomaly that occurs when two transactions read the same old value of a data item and then update it, effectively overwriting each other's changes.
Step 1: Analyzing the Execution Sequence.
Consider a scenario where the initial value of $X = 100$.
• $T_1$ reads $X$ (sees 100).
• $T_2$ reads $X$ (also sees 100).
• $T_1$ calculates $X = X + 50$ and writes $X = 150$.
• $T_2$ calculates $X = X + 20$ and writes $X = 120$.
Step 2: Identifying the "Lost" Update.
In the sequence above, the final value of $X$ in the database is 120. However, mathematically, if both transactions were applied, the value should have been $100 + 50 + 20 = 170$. The update performed by $T_1$ (adding 50) was completely overwritten by $T_2$'s write operation because $T_2$ was unaware that $T_1$ had modified the data in the meantime.
Step 3: The Solution.
To prevent this, DBMS implementations use locking mechanisms (like 2-Phase Locking). If $T_1$ holds an "Exclusive Lock" on $X$, $T_2$ cannot read or write $X$ until $T_1$ commits. This ensures that $T_2$ reads the new value (150) rather than the old value (100).