4. Concurrency control techniques Protocol = Set of rules that guarantee serializability of concurrent transactions, without having to check it. Example protocols: Locking Timestamping Multiversioning (skipped here) Optimistic concurrency control AdvDB-4 J. Teuhola 2015

4.1. Concurrency control based on locking Lock = variable associated with a database unit (‘item’, ‘granule’, e.g. page) Data for lock implementation: Identifier of data unit to be locked Identifier of holding transaction Queue of waiting transactions Lock manager: DBMS module that keeps track of locks and maintains queues AdvDB-4 J. Teuhola 2015

Binary locks Operation sequence: lock(X) ... read(X) … write(X) ... unlock(X) X is reserved for exclusive use of the locking transaction. If X is locked by transaction T1, then T2 (which also needs X) is forced to wait. AdvDB-4 J. Teuhola 2015

Rules for binary locks (1) Lock before the first read(X) / write(X). (2) Unlock after the last read(X) / write(X). (3) No lock(X) if X is already locked. (4) Unlock(X) allowed only for the holder of lock(X) Drawback of binary locks: They prevent concurrent reading. AdvDB-4 J. Teuhola 2015

Multiple-mode locks Read-lock = shared lock Any number of transactions may hold. Write-lock = exclusive lock Only a single write-lock(X) is allowed to hold at a time; even a simultaneous read_lock(X) is forbidden. AdvDB-4 J. Teuhola 2015

Order of lock/unlock attempts within a given transaction: (1) Read-lock(X) or write-lock(X) before read(X). (2) Write-lock(X) before write(X). (3) Unlock(X) after the last read(X) / write(X). (4) No read-lock(X) if the transaction already holds a read-lock(X) or write-lock(X). (5) No write-lock(X) if the transaction already holds a read-lock(X) or write-lock(X). (6) Unlock(X) only if the transaction holds a read- lock(X) or write-lock(X). AdvDB-4 J. Teuhola 2015

Relaxations for locking rules Upgrade: Read-lock(X) raised to write-lock(X) when updating starts. Downgrade: Write-lock(X) lowered to read-lock(X) after all the updates. AdvDB-4 J. Teuhola 2015

Locking vs. serializability Locking does not guarantee serializability as such; it must be applied properly. An additional protocol is needed. AdvDB-4 J. Teuhola 2015

Two-phase locking (2PL) protocol The most common in practice Basic 2PL: All locks before the first unlock Upgrading in the growing phase Downgrading in the shrinking phase But: 2PL reduces the degree of concurrency Theorem: 2PL guarantees serializability AdvDB-4 J. Teuhola 2015

Conservative (static) 2PL Lock all required items at the start, i.e. pre-declare the read/write sets. If any lock attempt fails, then all of them fail, and the transaction waits. Difficulty: How to know, before execution, the data units to be read/written? Advantage: Deadlock-free, because it makes no gradual reservation of locks. AdvDB-4 J. Teuhola 2015

Strict 2PL Releases all write locks only at commit time. Guarantees strict schedules, i.e. no cascading rollbacks. Not deadlock-free. Strict & conservative: Deadlock-free, no cascading rollback But: low concurrency Rigorous 2PL: Release all locks at commit time AdvDB-4 J. Teuhola 2015

Deadlock prevention/resolving schemes Conservative: not very practical. Abort some transaction: Lock-waiter Lock-holder Abortion can be based on timestamps of transaction starting times. AdvDB-4 J. Teuhola 2015

Resolving deadlocks (1) Wait-die: An older transaction is allowed to wait. If a younger transaction is blocked by an older, abort the younger and restart it with the same timestamp as before. Effect: The younger transaction gets older and older, until it is not aborted, anymore. AdvDB-4 J. Teuhola 2015

Resolving deadlocks (cont.) (2) Wound-wait: A younger transaction is allowed to wait for a lock to be released. If an older transaction is blocked by a younger, the younger is aborted and re-started with the same timestamp as before. Drawbacks of (1), (2): unnecessary aborts. AdvDB-4 J. Teuhola 2015

Resolving deadlocks (cont.) (3) No waiting: No timestamps Abort when blocked and restart Too many abortions (even more than in (1), (2)) (4) Cautious waiting: If Ti tries to lock X, locked by Tj, and Tj is not blocked, then Ti is allowed to wait; otherwise abort and restart Ti. No cycles of blockings can be created AdvDB-4 J. Teuhola 2015

Resolving deadlocks (cont.) (5) Timeout: Abort the transaction if the waiting time exceeds a threshold. Too many aborts may happen when the load is high. (Waiting times may grow exponentially with respect to the number of concurrent transactions.) AdvDB-4 J. Teuhola 2015

Resolving deadlocks (cont.) (6) Deadlock detection: Maintain a wait-for graph of transactions. A cycle in the graph means deadlock. Cyclicity tests at certain intervals. (Method: depth-first search in the wait-for graph and check for back-edges) Victim selection for abortion: E.g. the youngest, but prevent cyclic abort & restart (by increasing priority, or keeping the original starting time). AdvDB-4 J. Teuhola 2015

Livelock Indefinite waiting time for some transaction while others execute. Not deadlock. The reason is an unfair waiting scheme. Fair: FCFS = First-Come-First-Served. Priority system: Increase priority for waiting transactions (typical in operating systems). AdvDB-4 J. Teuhola 2015

Starvation Same victim repeatedly in deadlock detection. Wait-die and wound-wait avoid starvation because the starting time of the aborted transaction is not changed, and therefore the old transactions are favoured. AdvDB-4 J. Teuhola 2015

4.2. Concurrency control based on timestamp ordering Starting time of a transaction Identifies the transaction uniquely Timestamp order determines the corres-ponding serial schedule. For each active database unit X maintain: Read_TS(X) = Largest timestamp of readers Write_TS(X) = Largest timestamp of writers Conflicting operations must be in timestamp order of the related transactions. AdvDB-4 J. Teuhola 2015

Rules for timestamp ordering (1) Write(X) by T: If read_TS(X)>TS(T) or write_TS(X)>TS(T) then abort and roll back T, else write(X) and set write_TS(X)  TS(T) (2) Read(X) by T: If write_TS(X) > TS(T) then abort and roll back T, else read(X) and set read_TS(X)  max(read_TS(X),TS(T)) AdvDB-4 J. Teuhola 2015

Notes on timestamp ordering Interpretation: If two conflicting operations are in the wrong order, then reject the transaction related to the latter. Drawbacks: Does not prevent cascading rollback. Danger of starvation AdvDB-4 J. Teuhola 2015

Thomas’s write rule Write(X) by T: If read_TS(X) > TS(T) then abort T If write_TS(X) > TS(T) then do not write but continue, else write(X) and set write_TS(X)  TS(T) Idea: Value X written by T would be overwritten, anyway, without T reading it inbetween. (We know that T did not read X; otherwise T would have been aborted by the first rule) AdvDB-4 J. Teuhola 2015

Timestamp ordering (TO) compared to 2PL Neither is always better than the other. Neither allows all possible serializable schedules. No deadlock for TO, but starvation (cyclic restart) is possible. TO does not ensure recoverable schedules as such; additional control of commit order is required. TO allows dirty reads. AdvDB-4 J. Teuhola 2015

Strict timestamp ordering If T wants to read/write X and TS(T) > write_TS(X) then delay T until transaction T’ that wrote X has committed. Recoverable, no dirty reads, no cascading rollback. Resembles locking but does not cause deadlocks, because waitings occur in timestamp order. AdvDB-4 J. Teuhola 2015

4.3. Optimistic (= validation) concurrency control (OCC) During execution: No locks Transactions update their local copies of data items (in main memory or disk). After execution: Validation phase: Check if updates violate serializability. If not, update the database from local copies, otherwise abort & restart. AdvDB-4 J. Teuhola 2015

Phases of OCC Read phase: Read from the database, update local copies of items. Validation phase: Check serializability. Write phase: Apply updates to the database. Idea: All checks at once (in validation) Assumption: Little interference among transactions AdvDB-4 J. Teuhola 2015

Rules of OCC Maintain read_set and write_set of transactions. Maintain start and end times of phases. Validation for Ti : No interference with committed transactions No interference with transactions currently in validation phase. AdvDB-4 J. Teuhola 2015

Correctness in OCC When checking the correctness of transaction Ti , one of the following should hold for any Tj which is committed or being validated: (a) Tj completes its write phase before Ti starts its read phase. (b) Ti starts its write phase after Tj completes its write phase and read_set(Ti)  wr_set(Tj) =  (c) Tj completes its read phase before Ti completes its read phase and read_set(Ti)  wr_set(Tj) =  and wr_set(Ti)  wr_set(Tj) =  AdvDB-4 J. Teuhola 2015

4.4. Concurrency control for indexes Problem with 2-phase locking on B+-trees: An exclusive lock on the path from root to leaf blocks out all other users of the index. Conservative approach for insert: Lock a node exclusively at visit, but release it after noticing that its child is non-full. Optimistic approach for insert: Exclusive lock only at split propagation. AdvDB-4 J. Teuhola 2015

4.5. Other concurrency issues Phantom problem: A record to be inserted can create a conflict with the read/write set of another transaction, but it cannot be detected before the insert. Solutions: (a) Index locking: Lock all entries accessible from the index. (b) Predicate locking: Lock all records satisfying a given predicate. AdvDB-4 J. Teuhola 2015

Other concurrency issues (cont.) Interactivity problem: The dependence between two items may only exist in the head of the user: Uncommitted transaction writes upon the terminal The user types his input based on that value. Solution: Postpone output to the screen until commit; not very practical! AdvDB-4 J. Teuhola 2015