Transactions Practice Questions

Strict 2PL holds X locks until commit, ensuring no other transaction can read uncommitted data (preventing dirty reads). This makes schedules recoverable and avoids cascading aborts. Basic 2PL does not prevent dirty reads or cascading aborts. Rigorous 2PL also prevents dirty reads (holds all locks).

Trace option C: T2 read(X): TS=2 >= W-TS(X)=0 → proceed; R-TS(X)=2. T1 write(X): TS=1 < R-TS(X)=2 → ABORT T1. Schedule rejected. Verify others: A: T1 read(X): TS=1>=0 → R-TS=1. T2 write(X): TS=2>=R-TS=1, W-TS=0 → proceed. Allowed. B: T1 write(X): TS=1>=0 → W-TS=1. T2 read(X): TS=2>=W-TS=1 → proceed. Allowed. D: T1 write(X): TS=1>=0 → W-TS=1. T2 write(X): TS=2>=R-TS=0, W-TS=1 → proceed. Allowed. Only C is rejected.

Cascading rollback occurs when transaction $T_2$ reads a value written by $T_1$ (dirty read), and $T_1$ subsequently aborts. Since $T_2$'s read was based on $T_1$'s uncommitted write, $T_2$ must also be rolled back. Basic 2PL allows this; Strict 2PL prevents it by holding X locks until commit.

Phantom reads occur when a transaction re-executes a query and finds new tuples (phantoms) inserted by another committed transaction. Predicate (or range) locks lock all tuples satisfying a predicate - including future inserts - preventing phantoms. Index locking is a practical implementation.

2PL divides a transaction's locking activity into two phases: (1) Growing phase - locks are acquired, none released; (2) Shrinking phase - locks are released, none acquired. The lock point is the moment when the transaction holds its maximum number of locks. Once a lock is released, no new lock can be acquired.

Strict 2PL requires that all exclusive (X) locks be held until the transaction commits or aborts. This prevents dirty reads and cascading aborts. Rigorous 2PL additionally holds ALL locks (shared and exclusive) until commit/abort.

In 2PL, the transactions are serialized in the order of their lock points. $T_1$'s lock point (10) comes before $T_2$'s lock point (15), so the equivalent serial order is $T_1$ followed by $T_2$. This is a key property of 2PL: lock point order = serialization order.

Precedence graph edges: $r_2(X)$ before $w_1(X)$ → $T_2 \to T_1$. $w_1(X)$ before $w_2(X)$ → $T_1 \to T_2$. Cycle: $T_1 \to T_2 \to T_1$. Schedule is NOT conflict serializable. A 2PL schedule is always conflict serializable, so this schedule CANNOT be produced by 2PL transactions.

Conservative 2PL pre-declares and acquires all locks before execution, which prevents deadlocks but requires knowing all data items in advance (not always possible). It also reduces concurrency because transactions hold locks longer than necessary, causing others to wait even when they could proceed safely.

$T_1$ releases the lock on $A$ (unlock(A)) and then acquires a new lock on $B$ (lock-X(B)). This violates 2PL - once the shrinking phase begins (first unlock), no new locks can be acquired. $T_2$ only has one lock which it acquires and releases - that is a valid (trivial) 2PL schedule.

Every 2PL transaction has exactly 2 phases regardless of how many locks it holds: (1) Growing phase - all 6 locks acquired, (2) Shrinking phase - all 6 locks released after commit (Strict 2PL). The number of data items accessed does not change the number of phases. Answer: 2.

In MGL compatibility matrix, IS (Intention Shared) and X (Exclusive) are INCOMPATIBLE. An X lock means exclusive access to the entire table, which conflicts with any concurrent access - including those signaled by IS. Compatible pairs include: IS-IS, IS-S, IS-IX, S-S, S-IS only.

Sort by lock point: 1, 2, 4, 7, 9. The transaction with lock point 7 is at position 4 in the equivalent serial order.

Lock points: $T_2 = 3$, $T_1 = 5$, $T_3 = 8$. Serial order by lock point: $T_2$ (1st), $T_1$ (2nd), $T_3$ (3rd). So $T_1$ is in position 2.

The cycle in the wait-for graph is $T_1 \to T_2 \to T_3 \to T_1$ - involving $T_1$, $T_2$, and $T_3$. Transaction $T_4$ is waiting for $T_2$ but is not part of the cycle. So 3 transactions are in the deadlock.

(A) True - both guarantee conflict serializability. (B) True - 2PL uses locks and can deadlock; TO aborts instead of waiting. (C) True - Strict 2PL releases all locks only at commit, preventing dirty reads; basic TO allows dirty reads and cascading rollbacks. (D) False - the sets of schedules produced by TO and 2PL are incomparable; each allows some schedules the other rejects. (E) True - a transaction in TO that repeatedly gets aborted due to timestamp conflicts can starve.

The DAG has $T_1$ first, $T_4$ last. $T_2$ and $T_3$ can be ordered either way. Valid orderings: $T_1, T_2, T_3, T_4$ and $T_1, T_3, T_2, T_4$. So there are 2 distinct topological orderings.

Trace step by step: (1) T1 write(X): TS=1 >= R-TS(X)=0 and TS=1 >= W-TS(X)=0 → proceed; W-TS(X)=1. (2) T2 read(X): TS=2 >= W-TS(X)=1 → proceed; R-TS(X)=2. (3) T3 write(X): TS=3 >= R-TS(X)=2 and TS=3 >= W-TS(X)=1 → proceed; W-TS(X)=3. (4) T1 write(Y): TS=1 >= R-TS(Y)=0 and TS=1 >= W-TS(Y)=0 → proceed; W-TS(Y)=1. (5) T2 write(Y): TS=2 >= R-TS(Y)=0 and TS=2 >= W-TS(Y)=1 → proceed; W-TS(Y)=2. No transaction is aborted.