In context of database, let T1 and T2 are two concurrent transactions. Consider the following sequence of operations on data X:
T1: READ(X) T1: WRITE(X) T2: READ(X) T2: WRITE(X)
This is a _______ problem.

Question

In context of database, let T1 and T2 are two concurrent transactions. Consider the following sequence of operations on data X: 
T1: READ(X) T1: WRITE(X) T2: READ(X) T2: WRITE(X) 
This is a _______ problem.

Accepted Answer

The correct option is (2):
The given sequence T1: READ(X), T1: WRITE(X), T2: READ(X), T2: WRITE(X) perfectly illustrates the classic database concurrency anomaly known as the **Lost Update** problem. This situation arises because both concurrent transactions, T1 and T2, base their calculations on the original value of the data item X, which they read at the beginning. T1 writes its new value back to X, but before T1 can commit (or before its write is fully isolated), T2 writes its own new value back, calculated from the original, outdated read. When the second transaction commits, its write operation effectively overwrites the first transaction’s committed change, causing the update from the first transaction to be permanently lost. This common issue is a direct violation of transaction Isolation.

The incorrect option is (1):
**Dirty Read** is incorrect because it specifically occurs when one transaction reads data that has been modified by another transaction that *has not yet committed*. While T2 *could* be reading an uncommitted value written by T1 in this sequence, the most severe and characteristic problem of this R-W, R-W operation pattern is the loss of one of the updates. The Dirty Read anomaly is primarily about reading invalid, uncommitted data, whereas the Lost Update is about the failure to retain a legitimate update.

The incorrect option is (3):
**Incorrect Summary** is incorrect as this anomaly is related to aggregate functions. It occurs when a transaction is performing a summary calculation (like SUM) over a set of records, and a concurrent transaction updates some of those records mid-calculation. The resulting summary is inconsistent because it includes a mix of pre-update and post-update values for different rows. The scenario provided only involves simple READ and WRITE operations on a single data item X and does not show any aggregate calculation.

The incorrect option is (4):
**Unrepeatable Read** is incorrect because its definition requires a single transaction to perform the *same* read operation multiple times and retrieve *different* committed values. The sequence T1: READ(X), T1: WRITE(X), T2: READ(X), T2: WRITE(X) only shows T1 performing one READ operation on X. For an Unrepeatable Read to occur, the schedule would need to show T1 reading X, T2 updating and committing the change to X, and then T1 reading X again to see the newly committed value.