1. Concurrent Transactions Even when there is no “failure,” several transactions can interact to turn a consistent state into an inconsistent state.

2. Overview Scheduler manages read/write requests from transactions; allows execution in an order that is “serializable,” i.e., it “looks like” the transactions executed one­at­a­time(serial)

3. Example Assume A = B is required for consistency. Note that we omit OUTPUT steps for succinctness; they always come at the end. We deal only with Reads and Writes in the main memory buffers. T 1 and T 2 individually preserve DB consistency.

4. An Acceptable Schedule S 1 Assume initially A = B = 25. Here is one way to execute (S 1 = T 1 ; T 2 ) so they do not interfere.

5. Another Acceptable Schedule S 2 Here, transactions are executed as (S 2 =T 2 ; T 1 ). The result is different, but consistency is maintained.

6. Interleaving Doesn't Necessarily Hurt (S 3 )

7. But Then Again, It Might!

8. The Semantics of transactions is also important. Suppose T3 is identical to T2 but it multiplies by 1

9. We Need a Simpler Model Assume that whenever a transaction T writes X, it changes X in some unique way. – Arithmetic coincidence never happens Thus, we focus on the reads and writes only, assuming that whenever transaction T reads X and then writes it, X has changed in some unique way. – Notation: r T (X) denotes T reads the DB element X w T (X) denotes T writes X If transactions are T 1,…,T k, then we will simply use r i and w i, instead of r Ti and w Ti

10. Transactions and Schedules A transaction (model) is a sequence of r and w actions on database elements. A schedule is a sequence of reads/writes actions performed by a collection of transactions. Serial Schedule = All actions for each transaction are consecutive. r1(A); w1(A); r1(B); w1(B); r2(A); w2(A); r2(B); w2(B); …

11. Transactions and Schedules (Cont’d) Serializable Schedule : A schedule whose “effect” is equivalent to that of some serial schedule. We will introduce a sufficient condition for serializability.

12. Conflicts Suppose for fixed DB elements X & Y, r i (X); r j (Y) is part of a schedule, and we flip the order of these operations. – r i (X); r j (Y) ≡ r j (Y); r i (X) … In what sense? – This holds always (even when X=Y) We can flip r i (X); w j (Y), as long as X≠Y That is, r i (X); w j (X)  w j (X); r i (X) – In the RHS, T i reads the value of X written by T j, whereas it is not so in the LHS.

13. Conflicts (Cont’d) We can flip w i (X); w j (Y); provided X≠Y However, w i (X); w j (X) ≢ w j (X); w i (X); – The final value of X may be different depending on which write occurs last. There is a conflict if 2 conditions hold. A read and a write of the same X, or Two writes of X conflict in general and may not be swapped in order. All other events (reads/writes) may be swapped without changing the effect of the schedule (on the DB).

14. Precedence Graphs If by swapping pairs of non-conflicting actions in a schedule S, we end up in a serial schedule, then S is called a conflict-serializable schedule. S: r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B); Conflict-serializability is a sufficient condition for serializability but not necessary. Serializability/precedence graph for S Nodes: transactions {T1,…,Tk} Arcs: There is an arc from Ti to Tj if they have conflict access to the same database element X and Ti is first; in written Ti < S Tj.

16. If there is a cycle in the graph – Then, there is no serial schedule which is conflict­ equivalent to S. Each arc represents a requirement on the order of transactions in a conflict­ equivalent serial schedule. A cycle puts too many requirements on any linear order of transactions. If there is no cycle in the graph – Then any topological order of the graph suggests a conflict­equivalent schedule.

17. Why the Precedence-Graph Test Works? Idea: if the precedence graph is acyclic, then we can swap actions to form a serial schedule consistent with some topological order; Proof: By induction on n, number of transactions. Basis: n = 1. That is, S={T1}; then S is already serial. Induction: S={T1,T2,…,Tn}. Given that SG(S) is acyclic, then pick Ti in S such that no Tj in S is dependent on. – We swap all actions of Ti to the front (of S). – (Actions of Ti)(Actions of the other n-1 transactions) – The tail is a precedence graph that is the same as the original without Ti, i.e. it has n-1 nodes.  By the induction hyposthesis, we can reorder the actions of the other transactions to turn it into a serial schedule

18. Schedulers A scheduler takes requests from transactions for reads and writes, and decides if it is “OK” to allow them to operate on DB or defer them until it is safe to do so. Ideal: a scheduler forwards a request iff it cannot lead to inconsistency of DB – Too hard to decide this in real time. Real: it forwards a request if it cannot result in a violation of conflict­serializability. We thus need to develop schedulers which ensure conflict- serializablility.

19. Lock Actions Before reading or writing an element X, a transaction Ti requests a lock on X from the scheduler. The scheduler can either grant the lock to Ti or make Ti wait for the lock. If granted, Ti should eventually unlock (release) the lock on X. Shorthands: – l i (X) = “transaction Ti requests a lock on X” – u i (X) = “Ti unlocks/releases the lock on X”

20. The use of lock must be proper in 2 senses: – Consistency of Transactions: Read or write X only when hold a lock on X. –r i (X) or w i (X) must be preceded by some l i (X) with no intervening u i (X). If Ti locks X, Ti must eventually unlock X. –Every l i (X) must be followed by u i (X). – Legality of Schedules: Two transactions may not have locked the same element X without one having first released the lock. –A schedule with l i (X) cannot have another l j (X) until u i (X) appears in between

21. Legal Schedule Doesn’t Mean Serializable

22. Two Phase Locking There is a simple condition, which guarantees confict-serializability: In every transaction, all lock requests (phase 1) precede all unlock requests (phase 2).

23. Why 2PL Works? Precisely: a legal schedule S of 2PL transactions is conflict­ serializable. Proof is an induction on n, the number of transactions. Remember, conflicts involve only read/write actions, not locks, but the legality of the transaction requires that the r/w's be consistent with the l/u's.

24. Why 2PL Works (Cont’d) Basis: if n=1, then S={T 1 }, and hence S is conflict-serializable. Induction: S={T 1,…,T n }. Find the first transaction, say T i, to perform an unlock action, say u i (X). Can we show that the r/w actions of T i can be moved to the front of the other transactions without conflict? Consider some action such as w i (Y). Can it be preceded by some conflicting action w j (Y) or r j (Y)? In such a case we cannot swap them. – If so, then u j (Y) and l i (Y) must intervene, as w j (Y)...u j (Y)...l i (Y)...w i (Y). – Since T i is the first to unlock, u i (X) appears before u j (Y). – But then l i (Y) appears after u i (X), contradicting 2PL. Conclusion: w i (Y) can slide forward in the schedule without conflict; similar argument for a r i (Y) action.

25. Shared/Exclusive Locks Problem: while simple locks + 2PL guarantee conflict­serializability, they do not allow two readers of DB element X at the same time. But having multiple readers is not a problem for conflict­serializability (since read actions commute).

26. Shared/Exclusive Locks (Cont’d) Solution: Two kinds of locks: 1. Shared lock sl i (X) allows T i to read, but not write X. – It prevents other transactions from writing X but not from reading X. 2. Exclusive lock xl i (X) allows T i to read and/or write X; no other transaction may read or write X.

27. Consistency of transaction conditions: – A read r i (X) must be preceded by sl i (X) or xl i (X), with no intervening u i (X). – A write w i (X) must be preceded by xl i (X), with no intervening u i (X). Legal schedules: – No two exclusive locks. If xl i (X) appears in a schedule, then there cannot be a xl j (X) until after a u i (X) appears. – No exclusive and shared locks. If xl i (X) appears, there can be no sl j (X) until after u i (X). If sl i (X) appears, there can be no wl j (X) until after u i (X). 2PL condition: – No transaction may have a sl(X) or xl(X) after a u(Y).

28. Scheduler Rules When there is more than one kind of lock, the scheduler needs a rule that says “if there is already a lock of type A on DB element X, can I grant a lock of type B on X?” The compatibility matrix answers the question. Compatibility Matrix for Shared/Exclusive Locks is:

29. Upgrading Locks Instead of taking an exclusive lock immediately, a transaction can take a shared lock on X, read X, and then upgrade the lock to exclusive so that it can write X.

30. Upgrading Locks (Cont.) Had T1 asked for an exclusive lock on B before reading B, the request would have been denied, because T2 already has a shared lock on B.

31. Deadlocks Problem: when we allow upgrades, it is easy to get into a deadlock situation. Example:T1 and T2 each reads X and later writes X.

32. Solution: Update Locks Update lock ul i (X) with asymetric compatibility matrix. – Only an update (not read) can be upgraded to write (If there are no shared locks anymore). – Legal schedules: read action permitted when there is either a shared or update lock. – An update can be granted while there is a shared­ lock, but the scheduler will not grant a shared­lock when there is an update.

33. Compatibility Matrix for Shared, Exclusive, and Update Locks

34. Example: T 1 and T 2 each read X and later write X.