Jinze Liu

ACID Atomicity: TX’s are either completely done or not done at all Consistency: TX’s should leave the database in a consistent state Isolation: TX’s must behave as if they are executed in isolation Durability: Effects of committed TX’s are resilient against failures SQL transactions -- Begins implicitly SELECT …; UPDATE …; ROLLBACK | COMMIT;  3/9/2016

Goal: ensure the “I” (isolation) in ACID 33 A B C T 1 : read( A ); write( A ); read( B ); write( B ); commit; T 2 : read( A ); write( A ); read( C ); write( C ); commit;

44 T 1 T 2 r( A ) w( A ) r( B ) w( B ) r( A ) w( A ) r( C ) w( C ) T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) r( C ) w( B ) w( C ) T 1 T 2 r( A ) r( A ) w( A ) w( A ) r( B ) r( C ) w( B ) w( C ) Good! Good! (But why?)Bad! Read 400 Write 400 – 100 Write 400 – 50

Execute transactions in order, with no interleaving of operations T 1.r(A), T 1.w(A), T 1.r(B), T 1.w(B), T 2.r(A), T 2.w(A), T 2.r(C), T 2.w(C) T 2.r(A), T 2.w(A), T 2.r(C), T 2.w(C), T 1.r(A), T 1.w(A), T 1.r(B), T 1.w(B)  Isolation achieved by definition! Problem: no concurrency at all Question: how to reorder operations to allow more concurrency 55

Two operations on the same data item conflict if at least one of the operations is a write r(X) and w(X) conflict w(X) and r(X) conflict w(X) and w(X) conflict r(X) and r(X) do not r/w(X) and r/w(Y) do not Order of conflicting operations matters E.g., if T 1.r(A) precedes T 2.w(A), then conceptually, T 1 should precede T 2 66

A node for each transaction A directed edge from T i to T j if an operation of T i precedes and conflicts with an operation of T j in the schedule 77 T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) r( C ) w( B ) w( C ) T 1 T 2 r( A ) r( A ) w( A ) w( A ) r( B ) r( C ) w( B ) w( C ) T1T1 T2T2 Good: no cycle T1T1 T2T2 Bad: cycle

A schedule is conflict-serializable iff its precedence graph has no cycles A conflict-serializable schedule is equivalent to some serial schedule (and therefore is “good”) In that serial schedule, transactions are executed in the topological order of the precedence graph You can get to that serial schedule by repeatedly swapping adjacent, non-conflicting operations from different transactions 88

Rules If a transaction wants to read an object, it must first request a shared lock (S mode) on that object If a transaction wants to modify an object, it must first request an exclusive lock (X mode) on that object Allow one exclusive lock, or multiple shared locks 99 Mode of lock(s) currently held by other transactions Mode of the lock requested Grant the lock? Compatibility matrix

 10 T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) w( B ) r( B ) w( B ) lock-X( A ) lock-X( B ) unlock( B ) unlock( A ) lock-X( A ) unlock( A ) unlock( B ) lock-X( B ) Possible schedule under locking But still not conflict-serializable! T1T1 T2T2 Read 100 Write Read 101 Write 101*2 Read 100 Write 100*2 Read 200 Write Add 1 to both A and B (preserve A = B ) Multiply both A and B by 2 (preserves A = B ) A  B!A  B!

All lock requests precede all unlock requests Phase 1: obtain locks, phase 2: release locks  11 T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) w( B ) r( B ) w( B ) lock-X( A ) lock-X( B ) unlock( B ) unlock( A ) lock-X( A ) lock-X( B ) Cannot obtain the lock on B until T 1 unlocks T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) w( B ) r( B ) w( B ) 2PL guarantees a conflict-serializable schedule

T 2 has read uncommitted data written by T 1 If T 1 aborts, then T 2 must abort as well Cascading aborts possible if other transactions have read data written by T 2  12  Even worse, what if T 2 commits before T 1 ?  Schedule is not recoverable if the system crashes right after T 2 commits T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) w( B ) r( B ) w( B ) Abort!

Only release locks at commit/abort time A writer will block all other readers until the writer commits or aborts  Used in most commercial DBMS (except Oracle)  13

S 1, S 2 are conflict equivalent schedules if S 1 can be transformed into S 2 by a series of swaps on non-conflicting actions.

A schedule is conflict serializable if it is conflict equivalent to some serial schedule.

Nodes: transactions in S Arcs: T i -> T j whenever - p i (A), q j (A) are actions in S - p i (A) < S q j (A) - at least one of p i, q j is a write

What is P(S) for S = w 3 (A) w 2 (C) r 1 (A) w 1 (B) r 1 (C) w 2 (A) r 4 (A) w 4 (D) Is S serializable?

What is P(S) for S = w 1 (A) r 2 (A) r 3 (A) w 4 (A) ?

S 1, S 2 conflict equivalent  P(S 1 )=P(S 2 ) Proof: Assume P(S 1 )  P(S 2 )   T i : T i  T j in S 1 and not in S 2  S 1 = …p i (A)... q j (A)… p i, q j S 2 = …q j (A)…p i (A)... conflict  S 1, S 2 not conflict equivalent

Note: P(S 1 )=P(S 2 )  S 1, S 2 conflict equivalent Counter example: S 1 =w 1 (A) r 2 (A) w 2 (B) r 1 (B) S 2 =r 2 (A) w 1 (A) r 1 (B) w 2 (B)

P(S 1 ) acyclic  S 1 conflict serializable (  ) Assume S 1 is conflict serializable   S s : S s, S 1 conflict equivalent  P(S s ) = P(S 1 )  P(S 1 ) acyclic since P(S s ) is acyclic

(  ) Assume P(S 1 ) is acyclic Transform S 1 as follows: (1) Take T 1 to be transaction with no incident arcs (2) Move all T 1 actions to the front S 1 = ……. q j (A)……. p 1 (A)….. (3) we now have S 1 = (4) repeat above steps to serialize rest! T1 T2 T3 T4 P(S 1 ) acyclic  S 1 conflict serializable

Option 1: run system, recording P(S); at end of day, check for P(S) cycles and declare if execution was good