Concurrency

Correctness Principle A transaction is atomic -- all or none property. If it executes partly, an invalid state is likely to result. A transaction, may change the DB from a consistent state to another consistent state. Otherwise it is rejected (aborted). Concurrent execution of transactions may lead to inconsistency – each transaction must appear to be executed in isolation The effect of a committed transaction is durable i.e. the effect on DB of a transaction must never be lost, once the transaction has completed. ACID: Properties of a transaction: Atomicity, Consistency, Isolation, and Durability

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

Example Assume A = B is required for consistency. T 1 and T 2 individually preserve DB consistency. We omit OUTPUT steps for succinctness

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.

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

Interleaving Doesn't Necessarily Hurt (S 3 )

But Then Again, It Might!

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

We Need a Simpler Model Assume that whenever a transaction T writes X, it changes X in some unique way. – i.e. 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

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); … Serializable Schedule: A schedule whose “effect” is equivalent to that of some serial schedule. We will introduce a sufficient condition for serializability.

Conflicts Suppose for DB elements X and 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) – 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.

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

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); Serializability/precedence graph for S 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.

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.

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={T 1 }; then S is already serial. Induction: S={T 1,T 2,…,T n }. Given that SG(S) is acyclic, then pick T i in S such that no T j in S is dependent on. – We swap all actions of T i 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 T i, 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

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

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”

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

Legal Schedule Doesn’t Mean Serializable

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

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.

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.

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

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.

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

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: