3.2.7 Transactions and Concurrency

1. • R_T(j), R_T(i), W_T(j), W_T(i), R_U(k), W_U(i), R_U(i), W_U(k)
   • R_U(k), W_U(i), R_U(i), W_U(k), R_T(j), R_T(i), W_T(j), W_T(i)
   • R_U(k), R_T(j), R_T(i), W_T(j), W_T(i), W_U(i), R_U(i), W_U(k)
2. An inconsistent retrieval occurs when a transaction reads values that another transaction has only partially updated, leaving the set of values in an inconsistent state. An example pattern is R_T(x), W_U(y), R_T(y), W_U(x).

3. 1. Impossible under strict locking or timestmping with TS_T > TS_U, possible under occ or timestamping with TS_T < TS_U.
   2. Possible under locking, occ, timestamping with TS_T < TS_U, impossible under timestmping with TS_T > TS_U.
   3. Possible under locking, occ,timestmping with TS_T > TS_U, impossible with timestamping with TS_T < TS_U
   4. Possible under timestamping with TS_T > TS_U, impossible otherwise
   5. Impossible under locking and timestamping. Possible under optimistic concurrency control. Why? Because the writes don't actually reveal their changed values till the transactions commit.

4. A transaction may do a lot of work without accessing data values before it accesses the shared data. Thus its timestamp may be very old before it even accesses the data, and thus may have a high probability of abortion. A better time to allocate the timestamp is when it first accesses data.