1. Concurrency

2. Busy, busy, busy... In production environments, it is unlikely that we can limit our system to just one user at a time. – Consequently, it is possible for multiple queries or transactions to be submitted at approximately the same time. If all of the queries were very small (i.e., in terms of time), we could probably just execute them on a first-come-first-served basis. However, many queries are both complex and time consuming. – Executing these queries would make other queries wait a long time for a chance to execute. So, in practice, the DBMS may be running many different transactions at about the same time.

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

4. Example Assume A = B is a constraint 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.

5. 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.

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

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

8. But Then Again, It Might!

9. Semantics of transactions is also important.

10. We Need a Simpler Model Coincidence never happens Focus on reads and writes only. – r T (X) denotes T reads X – w T (X) denotes T writes X – Transaction is a sequence of r and w actions on database elements. – If transactions are T 1,…,T k, then we use r i and w i, instead of r Ti and w Ti Schedule is a sequence of r and w 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);… – Serializable Schedule: A schedule whose “effect” is equivalent to that of some serial schedule.

11. Conflicts Suppose for fixed DB elements X and Y, r i (X); r j (Y) is part of a schedule, and we flip the order of these operations. Then r i (X); r j (Y) ≡ r j (Y); r i (X) This holds always (even when X=Y) We can flip r i (X); w j (Y) as long as X≠Y However, 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. 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.

12. Conflicts (Cont’d) There is a conflict if one of these two conditions hold. 1.A read and a write of the same X, or 2.Two writes of the same X Such actions 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). Definitions Two scheduless are conflict-equivalent if they can be converted into the other by a series of non-conflicting swaps of adjacent elements A schedule is conflict-serializable if it can be converted into a serializable schedule in the same way

13. Example r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 2 (A); r 1 (B); w 2 (A); w 1 (B); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 1 (B); r 2 (A); w 2 (A); w 1 (B); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 1 (B); r 2 (A); w 1 (B); w 2 (A); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 1 (B); w 1 (B); r 2 (A)w 2 (A); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 2 (A); r 1 (B); w 2 (A); w 1 (B); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 1 (B); r 2 (A); w 2 (A); w 1 (B); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 1 (B); r 2 (A); w 1 (B); w 2 (A); r 2 (B); w 2 (B) r 1 (A); w 1 (A); r 1 (B); w 1 (B); r 2 (A)w 2 (A); r 2 (B); w 2 (B)

14. Conflict-serializability Sufficient condition for serializability but not necessary. Example S1: w 1 (Y); w 1 (X); w 2 (Y); w 2 (X); w 3 (X); -- This is serial S2: w 1 (Y); w 2 (Y); w 2 (X); w 1 (X); w 3 (X); S2 isn’t conflict serializable, but it is serializable. It has the same effect as S1. – Intuitively, the values of X written by T1 and T2 have no effect, since T3 overwrites them.

15. Serializability/precedence Graphs Non-swappable pairs of actions represent potential conflicts between transactions. The existence of non-swappable actions enforces an ordering on the transactions that house these actions. Nodes: transactions {T 1,…,T k } Arcs: There is an arc from T i to T j if they have conflict access to the same database element X and T i is first; in written T i < S T j.

16. Precedence graphs 16 r 2 (A); r 1 (B); w 2 (A); r 3 (A); w 1 (B); w 3 (A); r 2 (B); w 2 (B) r 2 (A); r 1 (B); w 2 (A); r 2 (B); r 3 (A); w 1 (B); w 3 (A); w 2 (B) Note the following:  w 1 (B) < S r 2 (B)  r 2 (A) < S w 3 (A)  These are conflicts since they contain a read/write on the same element  They cannot be swapped. Therefore T 1 < T 2 < T 3 Note the following:  w 1 (B) < S r 2 (B)  r 2 (A) < S w 3 (A)  These are conflicts since they contain a read/write on the same element  They cannot be swapped. Therefore T 1 < T 2 < T 3 Note the following:  r 1 (B) < S w 2 (B)  w 2 (A) < S w 3 (A)  r 2 (B) < S w 1 (B)  Here, we have T 1 < T 2 < T 3, but we also have T 2 < T 1 Note the following:  r 1 (B) < S w 2 (B)  w 2 (A) < S w 3 (A)  r 2 (B) < S w 1 (B)  Here, we have T 1 < T 2 < T 3, but we also have T 2 < T 1

17. 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.

18. Why the Precedence-Graph Test Works? Idea: if the precedence graph is acyclic, then we can swap actions to form a serial schedule. Proof: By induction on n, number of transactions. Basis: n = 1. That is, S={T 1 }; then S is already serial. Induction: S={T 1,T 2,…,T n }. Given that the precedence graph is acyclic, there exists T i in S such that there is no T j in S that T i depends on. – We swap all actions of T i to the front (of S). – (Actions of T i )(Actions of the other n-1 transactions) – The tail is a precedence graph that is the same as the original without T i, i.e. it has n-1 nodes.  By the induction hypothesis, we can reorder the actions of the other transactions to turn it into a serial schedule

19. 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 result in a violation of serializability. – Too hard to decide this in real time. Real: a scheduler forwards a request if it cannot result in a violation of conflict­serializability.

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

21. The use of locks 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 T i locks X, T i 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. Validity of Locks

22. Legal Schedule Doesn’t Mean Serializable Consistency constraint required for this example: A=B

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

24. 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.

25. 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). 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.