Derived fragmentation: fragment ORDER based on the fragmentation of CUSTOMER .
P2 is uncertain (in “ready” state).
| Time | TX | TY | |------|----|----| | t1 | Lock stock at R1, R2 (write quorum) | | | t2 | Read stock: 100, 100 | | | t3 | Write stock: 90, 90 | | | t4 | Release locks | | | t5 | | Lock price at R2, R3 (write quorum) | | t6 | | Read price: $10, $10 | | t7 | | Write price: $10.50, $10.50 | | t8 | | Release locks | Serializable order: TX then TY
Stock = 90 (on R1,R2,R3 after propagation), Price = $10.50. Serializable order: TX then TY. Note: Read quorum not used here, but for read-only transactions, read any 2 replicas to ensure freshness. 5. Distributed Recovery – Two-Phase Commit (2PC) Exercise: Coordinator C, participants P1, P2. After all vote YES, C sends COMMIT to P1 but crashes before sending to P2. P1 receives commit, commits. P2 receives nothing. What happens? How does recovery solve this? For each fragment of CUSTOMER (e.g.
For each fragment of CUSTOMER (e.g., C_NYC = σ_city='NYC'(CUSTOMER) ), ORDER_NYC = ORDER ⋉ C_NYC (semijoin on cust_id). C_NYC = σ_city='NYC'(CUSTOMER) )