Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Clusterpoint wikipedia , lookup
Global serializability wikipedia , lookup
Consistency model wikipedia , lookup
Database model wikipedia , lookup
Object-relational impedance mismatch wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Commitment ordering wikipedia , lookup
Chapter 16 : Concurrency Control Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols Validation-Based Protocols Multiple Granularity Multiversion Schemes Insert and Delete Operations Concurrency in Index Structures Goal of Concurrency Control Transactions should be executed so that it is as though they executed in some serial order Also called Isolation or Serializability Transactional Concurrency Control Three ways to ensure a serial-equivalent order on conflicts: Option 1, execute transactions serially. Option 2, pessimistic concurrency control: block T until transactions with conflicting operations are done. Done using locks Option 3, optimistic concurrency control: proceed as if no conflicts will occur, and recover if constraints are violated. “single shot” transactions Repair the damage by rolling back (aborting) one of the conflicting transactions. Option 4, hybrid timestamp ordering using versions. Locking Locking is the most frequent technique used to control concurrent execution of database transactions Operating systems provide a binary locking system that is too restrictive for database transactions That's why DBMS contains its own lock manager A lock_value(X ) is variable associated with (each) database data item X The lock_value(X ) describes the status of the data item X, by telling which operations can be applied to X Concurrency Control using Locking The locking technique operates by preventing a transaction from improperly accessing data that is being used by another transaction. Before a transaction can perform a read or write operation, it must claim a read (shared) or write (exclusive) lock on the relevant data item. Once a read lock has been granted on a particular data item, other transactions may read the data, but not update it. A write lock prevents all access to the data by other transactions. Kinds of Locks Generally, the lock manager of a DBMS offers two kinds of locks: A shared (read) lock, and An exclusive (write) lock If a transaction T issues a read_lock(X ) command, it will be added to the list of transactions that share lock on item X, unless there is a transaction already holding write lock on X If a transaction T issues a write_lock(X ) command, it will be granted an exclusive lock on X, unless another transaction is already holding lock on X Accordingly, lock_value{read_lock, write_lock, unlocked } Lock Semantics Since read operations cannot conflict, it is acceptable for more than one transaction to hold read locks simultaneously on the same item. On the other hand, a write lock gives a transaction exclusive access to the data item Locks are used in the following way: A transaction needing access to a data item must first lock the item, requesting a read lock for read-only access or a write-lock for read-write access. If the item is not already locked by another transaction, the lock request will be granted. If the item is currently locked, the DBMS determines whether the request is compatible with the current lock. If a read lock is requested on an item that is already read locked, the request is granted, otherwise the transaction must wait until the existing write lock is released. A transaction holds a lock until it explicitly releases it, commits, or aborts. Basic Locking Rules The basic locking rules are: T must issue a read_lock(X ) or write_ lock(X ) command before any read_item(X ) operation T must issue a write_lock(X ) command before any write_item(X ) operation T must issue an unlock(X ) command when all read_item(X ) or write_item(X ) operations are completed Some DBMS lock managers perform automatic locking by granting an appropriate database item lock to a transaction when it attempts to read or write an item into database So, an item lock request can be either explicit, or implicit Locking Rules Lock manager- The part of DBMS that keeps track of locks issued to transactions is called lock manager. It maintains lock table Data items can be locked in two modes : 1. exclusive (X) mode. Data item can be both read as well as written. X-lock is requested using lock-X instruction. 2. shared (S) mode. Data item can only be read. S-lock is requested using lock-S instruction. Lock requests are made to concurrency-control manager. Transaction can proceed only after request is granted. Lock-Based Protocols Lock-compatibility matrix A transaction may be granted a lock on an item if the requested lock is compatible with locks already held on the item by other transactions Any number of transactions can hold shared locks on an item, but if any transaction holds an exclusive on the item no other transaction may hold any lock on the item. If a lock cannot be granted, the requesting transaction has to wait till all incompatible locks held by other transactions have been released. The lock is then granted. Lost Update Problem and Locking T1 T2 read_lock(X ) read_item ( X ) unlock(X ) write_lock(X ) read_item X X=X+M write_item(X ) unlock(X ) write_lock(X ) X=X–N write_item (X ) unlock(X ) t i m e T2's update to X is lost because T1 wrote over X, and it happened despite the fact that both transactions are issuing lock and unlock commands The problem is that T1 releases lock on X to early, allowing T2 to start updating X We need a protocol that will guarantee serializability A locking protocol is a set of rules followed by all transactions while requesting and releasing locks. Locking protocols restrict the set of possible schedules. The basic Two Phase Locking Protocol All lock operations must precede the first unlock operation Now, it can be considered as if a transaction has two phases: Growing (or expanding), when all locks are being acquired, and Shrinking, when locks are being downgraded and released, but non can be acquired or upgraded A theorem: If all transactions in a schedule obey locking rules and two phase locking protocol, the schedule is a conflict serializable one Consequently: A schedule that obeys to two phase locking protocol has not to be tested for conflict serializability Lost Update and Two Phase Locking T1 T2 read_lock(X ) read_item ( X ) X=X–N write_lock(X ) write_item (X ) unlock(X ) write_lock(X ) t //has to wait i write_lock(X ) read_item (X) X=X+M write_item(X ) unlock(X ) m e T2 can not obtain a write_lock on X since T1 holds a read lock on X and it has to wait When T1 releases lock on X, T2 acquires a lock on X and finishes successfully Two phase locking provides for a safe conflict serializable schedule The Two-Phase Locking Protocol Many database systems employ a two-phase locking protocol to control the manner in which locks are acquired and released. This is a protocol which ensures conflict-serializable schedules. Phase 1: Growing Phase Phase 2: Shrinking Phase transaction may release locks transaction may not obtain locks The rules of the protocol are as follows: transaction may obtain locks transaction may not release locks Once all locks have been acquired , transaction is in its locked point. A transaction must acquire a lock on an item before operating on the item. The lock may be read or write, depending on the type of access needed. Once the transaction releases a lock, it can never acquire any new locks. The protocol assures serializability. It can be proved that the transactions can be serialized in the order of their lock points (i.e. the point where a transaction acquired its final lock, end of growing phase). The Two-Phase Locking Protocol Two-phase locking is governed by following rules Two transaction can not have conflicting locks. No unlock operation can precede lock operation in the same transaction. The point in the schedule where the final lock is obtained is called the lock point. Phase 1 lock Phase 2 unlock Growing phase Lock phase Shrinking phase A Question for You T1 This slide describes the dirty read problem T2 The question: Does two phase locking solve The dirty read problem? read_item ( X ) X=X–N write_item (X ) read_item (X) X=X+M write_item (X) read_item ( Y ) T1 fails t i m e Answers: a) Yes b) No, because the dirty read problem is not a consequence of conflicting operations. Strict Two Phase Locking protocol solves the “dirty read” problem Two Phase Locking: Dirty Read T1 write_lock(X ) read_item ( X ) X=X–N write_item (X ) write_lock(Y ) unlock(X ) read_item ( Y ) T2 t i write_lock(X ) m read_item X e X=X+M write_item(X ) unlock(X ) Y=Y+Q write_item (Y ) unlock(Y ) //T1 fails before it commits If T1 gets exclusive lock on X first, T2 has to wait until T1 unlocks X Note that interleaving is still possible, only not within the transactions that access the same data items Two phase locking alone does not solve the dirty read problem, because T2 is allowed to read uncommitted database item X Strict Two Phase Locking A variant of the two phase locking protocol Protocol: A transaction T does not release any of exclusive locks until after it commits or aborts Hence, no other transaction can read or write an item X that is written by T unless T has committed The strict two phase locking protocol is safe for dirty read Rigorous two-phase locking is even stricter: here all locks are held till commit/abort. In this protocol transactions can be serialized in the order in which they commit. Most DBMS implement either strict or rigorous two phase locking Schedule for Strict 2PL with serial execution T1 T2 X(A) R(A) W(A) X(B) R(B) W(B) Commit X(A) R(A) W(A) X(B) R(B) W(B) Commit Disadvantages of Locking Pessimistic concurrency control has a number of key disadvantages, particularly in distributed systems: Overhead. Locks cost, and you pay even if no conflict occurs. Low concurrency. If locks are too coarse, they reduce concurrency unnecessarily. Need for strict 2PL to avoid cascading aborts makes it even worse. Low availability. Even readonly actions must acquire locks. High overhead forces careful choices about lock granularity. A client cannot make progress if the server or lock holder is temporarily unreachable. Deadlock. Two phase locking can introduce some undesirable effects. These are: waits, deadlocks, starvation Problems with Locking The use of locks and the 2PL protocol prevents many of the problems arising from concurrent access to the database. However, it does not solve all problems, and it can even introduce new ones. Firstly, there is the issue of cascading rollbacks: 2PL allows locks to be released before the final commit or rollback of a transaction. During this time, another transaction may acquire the locks released by the first transaction, and operate on the results of the first transaction. If the first transaction subsequently aborts, the second transaction must abort since it has used data now being rolled back by the first transaction. This problem can be avoided by preventing the release of locks until the final commit or abort action. Cascading roll-back is possible under two-phase locking. Cascade less schedule is not possible Dead Lock Dead lock is also called deadly embrace Deadlock occurs when two or more transactions reach an impasse because they are waiting to acquire locks held by each other. Typical sequence of operations is given on the following diagram T1 T2 •T2 acquired exclusive lock on Y write_lock(X ) write_lock(Y ) write_lock(Y ) //has to wait •T1 acquired exclusive lock on X t i m write_lock(X ) e //has to wait •No one can finish, because both are inthe waiting state •To handle a deadlock one of T3 or T4 must be rolled back and its locks released. Dead Lock (continued) Dead lock examples: a) T1 has locked X and waits to lock Y T2 has locked Y and waits to lock Z T3 has locked Z and waits to lock X b) BothT1 and T2 have acquired sharable locks on X and wait to lock X exclusively All that results in a cyclic wait for graph T2 waits for T1 T2 T1 T1 waits for T2 Starvation Starvation is also possible if concurrency control manager is badly designed. For example: A transaction may be waiting for an X-lock on an item, while a sequence of other transactions request and are granted an S-lock on the same item. If T2 has s-lock on data item and T1 request X-lock on same data item. So T1 has to wait for T2 to release S-lock. Meanwhile T3 request S-lock on same data item and lock request is compatible with lock granted to T2 so T3 may be granted S-lock. so now T2 release a lock but still T1 is not granted until T3 finish. Concurrency control manager can be designed to prevent starvation. T1 lock-S(A) T2 lock-X(A) wait T3 T4 T5 lock-S(A) lock-S(A) lock-S(A) Starvation Starvation is a problem that appears when using locks, or deadlock detection protocols Starvation occurs when a transaction can not make any progress for an indefinite period of time, while other transactions proceed Starvation can occur when: Waiting protocol for locked items is unfair (used stacks instead of queues) The same transaction is selected as `victim` repeatedly Lock Conversion A transaction T that already holds a lock on item X can convert it to another state Lock conversion rules are: T can upgrade a read_lock(X ) to a write_lock(X ) if it is the only one that holds a lock on the item X (otherwise, T has to wait) T can always downgrade a write_lock(X ) to a read_lock(X ) Lock Conversions Two-phase locking with lock conversions: For getting more concurrency we used 2PL with lock conversion. – First Phase: can acquire a lock-S on item can acquire a lock-X on item can convert a lock-S to a lock-X (upgrade) Upgrading possible only in growing phase. – Second Phase: can release a lock-S can release a lock-X can convert a lock-X to a lock-S (downgrade) Downgrading possible only in shrinking phase. Lock Conversions T1 T2 read_item ( a1 ) read_item ( a2 ) read_item ( a3 ) write_item ( a1 ) t read_item (a1) i read_item ( a2) m P=a1+a2 e 1. Normal 2PL would make T2 wait till the write_item (a1) is executed 2. Lock conversion would allow higher concurrency and allow shared lock to be acquired by T2 3. T1 could upgrade shared lock to exclusive just before the write instruction Lock Conversions Transactions attempting to upgrade may need to wait Lock conversions generate serializable schedules, serialized by their lock points If exclusive locks are held till the end of the transactions then schedules are cascadeless Automatic Acquisition of Locks A transaction Ti issues the standard read/write instruction, without explicit locking calls. The operation read(D) is processed as: if Ti has a lock on D then read(D) else begin if necessary wait until no other transaction has a lock-X on D grant Ti a lock-S on D; read(D) end Automatic Acquisition of Locks (Cont.) write(D) is processed as: if Ti has a lock-X on D then write(D) else begin if necessary wait until no other trans. has any lock on D, if Ti has a lock-S on D then upgrade lock on D to lock-X else grant Ti a lock-X on D write(D) end; All locks are released after commit or abort Implementation of Locking A lock manager can be implemented as a separate process to which transactions send lock and unlock requests The lock manager replies to a lock request by sending a lock grant messages (or a message asking the transaction to roll back, in case of a deadlock) The requesting transaction waits until its request is answered The lock manager maintains a data-structure called a lock table to record granted locks and pending requests The lock table is usually implemented as an in-memory hash table indexed on the name of the data item being locked Lock Management Lock table entry: Number of transactions currently holding a lock Type of lock held (shared or exclusive) Pointer to queue of lock requests Locking and unlocking have to be atomic operations Lock upgrade: transaction that holds a shared lock can be upgraded to hold an exclusive lock Lock Table Granted Waiting Black rectangles indicate granted locks, white ones indicate waiting requests Lock table also records the type of lock granted or requested New request is added to the end of the queue of requests for the data item, and granted if it is compatible with all earlier locks Unlock requests result in the request being deleted, and later requests are checked to see if they can now be granted If transaction aborts, all waiting or granted requests of the transaction are deleted lock manager may keep a list of locks held by each transaction, to implement this efficiently Other protocols than 2-PL – graphbased - - - Graph-based protocols are an alternative to twophase locking Assumption: we have prior knowledge about the order in which data items will be accessed (hierarchical) ordering on the data items, like, e.g., pages of a B-tree A B C Graph-Based Protocols Impose a partial ordering on the set D = {d1, d2 ,..., dh} of all data items. If di dj then any transaction accessing both di and dj must access di before accessing dj. Implies that the set D may now be viewed as a directed acyclic graph, called a database graph. The tree-protocol is a simple kind of graph protocol. Transactions access items from the root of this partial order Tree Protocol 1. 2. 3. 4. Only exclusive locks are allowed. The first lock by Ti may be on any data item. Subsequently, a data Q can be locked by Ti only if the parent of Q is currently locked by Ti. Data items may be unlocked at any time. A data item that has been locked and unlocked by Ti cannot subsequently be relocked by Ti Tree protocol - example T1 L(B) T2 -2PL? A -follows tree protocol? L(D) L(H) U(D) -‘correct’? B L(E) U(E) L(D) U(B) C D E F U(H) L(G) U(D) U(G) G H I Graph-Based Protocols (Cont.) The tree protocol ensures conflict serializability as well as freedom from deadlock. Advantages of tree protocol over 2 phase locking protocol shorter waiting times, unlocking may occur earlier and increase in concurrency protocol is deadlock-free, no rollbacks are required Drawbacks Protocol does not guarantee recoverability or cascade freedom Need to introduce commit dependencies to ensure recoverability Transactions may have to lock data items that they do not access. If Ti performs a read of uncommitted data item , we record a commit dependency of Ti on the transaction that performed the last write on the data item. increased locking overhead, and additional waiting time Without prior knowledge of what data items will be locked, transactions may lock the root of the tree reducing concurrency Schedules not possible under two-phase locking are possible under tree protocol, and vice versa. Main application used for locking in B+trees, to allow high-concurrency update access; otherwise, root page lock is a bottleneck Timestamp-Based Protocols BASIC TIMESTAMP ORDERING:- Timestamp is unique identifier created by DBMS to identify a transaction. Timestamp values are assigned in order in which transactions are submitted to the system. Each transaction is issued a timestamp when it enters the system. If an old transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned time-stamp TS(Tj) such that TS(Ti) <TS(Tj). The timestamp could use the value of the system clock or a logical counter The protocol manages concurrent execution such that the time-stamps determine the serializability order. In order to assure such behavior, the protocol maintains for each data item Q two timestamp values: W-timestamp(Q) is the largest time-stamp of any transaction that executed write(Q) successfully. R-timestamp(Q) is the largest time-stamp of any transaction that executed read(Q) successfully. Timestamp-Ordering Protocol The timestamp ordering protocol ensures that any conflicting read and write operations are executed in timestamp order. Suppose a transaction Ti issues a read(Q) 1. If TS(Ti) < W-timestamp(Q), then Ti needs to read a value of Q that was already overwritten. Hence, the read operation is rejected, and Ti is rolled back. 2. If TS(Ti) W-timestamp(Q), then the read operation is executed, and R-timestamp(Q) is set to max(Rtimestamp(Q), TS(Ti)). Timestamp Ordering Protocols (Cont.) Suppose that transaction Ti issues write(Q). 1. 2. If TS(Ti) < R-timestamp(Q), then abort and rollback T and reject the operation. This should be done because some younger transaction with timestamp greater than TS(T)after T in timestamp ordering-has already read or write the value of item Q before T had chance to write Q,thus violating the timestamp ordering. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete value of Q. Hence, this write operation is rejected, and Ti is rolled back. 3. Otherwise, the write operation is executed, and Wtimestamp(Q) is set to TS(Ti). (If TS(Ti) > W-timestamp(Q) and TS(Ti) > R-timestamp(Q)) Example of Timestamp Ordering Protocol T14 read(B) T15 read(B) B:= B-50 write(B) read(A) display (A+B) read (A) A := A+50 write (A) display (A+B) Timestamp Ordering Protocols (Cont.) The time stamp ordering protocol ensures conflict serializability as well as freedom from deadlock. However there is a possibility of starvation, if a sequence of conflicting transactions cause repeated restarts Consider two transactions T1 and T2 shown below. T1 Write(p) T2 Read(p) Read(q) Write(q) The write(q) of T1 fails and this rollsback T1 and in effect T2 as T2 is dependent on T1 This protocol can generate schedules that are non recoverable Recoverability and cascadelessness can be ensured by performing all writes at the end of the transaction and recoverability alone can be ensured by tracking uncommitted dependencies Strict Timestamp ordering Variation of basic TO called strict TO ensures schedules are both strict(recoverable) and (conflict)serializable. If transaction T issues read_item(X) or write_item(X) such that TS(T)>write_TS(X) has its read or write delayed until transaction T’(TS(T’)=write_TS(X) has commited or aborted. Thomas’ Write Rule Modified version of the timestamp-ordering protocol in which obsolete or outdated write operations may be ignored under certain circumstances. When Ti attempts to write data item Q, if TS(Ti) < Wtimestamp(Q), then Ti is attempting to write an obsolete or outdated value of {Q}. Rather than rolling back Ti as the timestamp ordering protocol would have done, this {write} operation can be ignored. Otherwise this protocol is the same as the timestamp ordering protocol. Thomas' Write Rule allows greater potential concurrency. Allows some view-serializable schedules that are not conflictserializable. T1 T2 R(A) W(A) commit W(A) Commit View Serializable schedule equivalent to serial schedule <T1,T2> Validation-Based Protocol (Optimistic method for concurrency control) Optimistic concurrency control techniques also known as validation or certification methods This techniques are called optimistic because they assume that conflicts of database operations are rare and hence that there is no need to do checking during transaction execution. Checking represent overhead during transaction execution, with effect of slowing down the transaction and checking needs to be done before commit Updates in transaction are not applied directly to d/b item until transaction reaches its end and are carried out in a temporary database file The three phases of concurrently executing transactions can be interleaved, but each transaction must go through the three phases in that order. Execution of transaction is done in three phases. Validation-Based Protocol (Optimistic method for concurrency control) Read and execution phase: Transaction Ti read values of committed items from database. Updates are applied only to temporary local copies of data items / temporary update file. Validation phase (Certification phase): Transaction Ti performs a ``validation test'‘ to determine if local copies can be written without violating serializability. If validation test positive then moves to write phase else transactions are discarded Write phase: If Ti is validated successfully , the updates are applied to the database; otherwise, Ti is rolled back and then restarted. This phase is performed only for Read-write transactions and not for Readonly transactions Optimistic concurrency control Each transaction T is given 3 timestamps: Start(T): when the transaction starts Validation(T): when the transaction enters the validation phase Finish(T) : when the transaction finishes Goal: to ensure the transaction following a serial schedule based on Validation(T) Optimistic concurrency control Given two transaction T1 and T2 and Validation(T1) < Validation(T2) Case 1 : Finish(T1) < Start(T2) Start(T1) T1 : Read Valid(T1) Valid Finish(T1) Write Read T2 : Start(T2) Here, no problem of serializability Valid Valid(T2) Write Finish(T2) Time Optimistic concurrency control Case 2 : Finish(T1) < Validation(T2) Start(T1) T1 : Read Valid(T1) Valid Finish(T1) Write Potential conflict Read T2 : Start(T2) Valid Valid(T2) Write Finish(T2) If T2 does not read anything T1 writes, then no problem Time Optimistic concurrency control Case 3 : Validation(T2) < Finish(T1) Valid(T1) Start(T1) T1 : Read Valid Finish(T1) Write Potential conflict Read T2 : Start(T2) Valid Valid(T2) Write Finish(T2) If T2 does not read or writes anything T1 writes, then no problem Time Optimistic concurrency control For any transaction T, check for all transaction T’ such that Validation(T’) < Validation(T) that 1. 2. 3. If Finish(T’) > Start(T) then if T reads any element that T’ writes, then abort If Finish(T’) > Validation(T) then if T writes any element that T’ writes, then abort Otherwise, commit Schedule Produced by Validation Example of schedule produced using validation T14 read(B) read(A) (validate) display (A+B) T15 read(B) B:= B-50 read(A) A:= A+50 (validate) write (B) write (A) Optimistic concurrency control Advantages: No blocking No overhead during execution Do have overhead for validation It is very efficient when conflicts are rare. Occasional conflicts result is transaction rollback. Rollback involves local copy of data, database is not involved so there will be no cascading rollback. Disadvantages: Potential starvation for long transaction Large amount of aborts if high concurrency Optimistic Concurrency Control Applications of Optimistic methods Suitable for environments where there are few conflicts and no long transactions Acceptable for mostly read or query database systems that require very few update transactions Granularity of Items Until now, we used the term `data item` without specifying its exact meaning In the context of the concurrency control, a data item can be: A field of a database record, A database record, A disk block, A whole file, A whole database Fine granularity refers to small item sizes and coarse granularity refers to larger item sizes The coarser the data item granularity is, the lower the degree of concurrency Granularity of Items (continued) Several trade-offs must be considered before choosing the size of the data-item As finer data granularity, as higher locking overhead of the DBMS lock manager (due to many locks and unlocks) If we lock large objects (e.g., Relations) Need few locks Get low concurrency If we lock small objects (e.g., tuples,fields) Need more locks (=> overhead higher) Get more concurrency The best item size depends on the type of a transaction: If a transaction accesses a small number of records, then data item = record If a transaction accesses a large number of records in the same file, then data item = file Some DBMS automatically change granularity level with regard to the number of records a transaction is accessing (attempting to lock) Multiple Granularity Granule is a unit of data individually controlled by concurrency control system. Granularity is lockable unit in a lock based concurrency control scheme. Example : If Ti needs to access the entire database and locking protocol is used, then Ti must lock each data item in database. If done individually it is time consuming. Better if Ti could issue a single lock request to lock the entire database. If Ti need to access only few data items then should not require to lock entire database but only lock that data item. Hence, mechanism is required to allow multiple levels of granularity. Allow data items to be of various sizes and define a hierarchy of data granularities, where the small granularities are nested within larger ones Can be represented graphically as a tree (but don't confuse with tree-locking protocol) Example of Granularity Hierarchy If transaction Ti gets an explicit lock on file Fc in exclusive mode, then it has an implicit lock in exclusive mode on all records belonging to this file Fc. .Does not need to lock individual records of Fc explictly. Multiple Granularity Database level Entire database Table Level Entire table Page level Entire disk block is locked. A page has fixed size as. 4K,8K,16K..Page contain several rows of one or more tables. Most suitable for multi user DBMS. Row level Lock exist for each row in each table of d/b. It improves availability of data. Management requires high overhead cost. Attribute level Allow concurrent transactions to access the same row but different attributes. Most flexible for multi user data access If any transaction wants to access entire database then has to lock entire database or root of the tree. Question is how does system determine if root node can be locked? One Solution is to search the entire tree which is time consuming which defeats the purpose of multiple granularity locking scheme. Multiple Granularity Locking (MGL) Protocol To make multiple granularity level locking practical, additional locks called intention locks are needed. Three types of intention locks : Intention Shared (IS) indicates shared locks will be requested on descendant node Intention Exclusive (IX) indicates exclusive locks will be requested on descendant node Shared Intention Exclusive (SIX) indicates current node is locked in Shared mode but exclusive locks will be requested on descendant nodes. Before locking an item, transaction must set “intention locks” on all its ancestors. Locking is done “top down” and unlock is done “bottom-up”. MGL Compatibility Matrix Requestor Holder Multiple Granularity Locking (MGL) Protocol Lock Compatibility matrix must be adhered The root of the tree must be locked first in any mode A node N can be locked by a transaction T in S or IS mode only if the parent of node N is already locked by transaction T in either IS or IX mode A node N can be locked by transaction T in X, IX or SIX mode only if the parent of node N is already locked by transaction T in either IX or SIX mode A transaction T can lock a node only if it has not unlocked any node (enforce 2PL) A transaction T can unlock a node N only if none of the children of node N are currently locked. Examples T1 reads record ra2 in File Fa T2 modifies record ra9 in file Fa Needs to lock database and area A1in IS mode Needs to lock Fa in S mode T4 reads the entire database Needs to lock database, area A1 and file Fa in IX mode Needs to lock ra9 in X mode. T3 reads all records in file Fa Needs to lock database, area A1 and Fa in IS mode Needs to lock ra2 in S mode Needs to lock the database in S mode. T1, T3 and T4 can access database concurrently T1 and T2 can access concurrently T2 cannot access concurrently with T3 or T4 Multiversion Schemes Multiversion schemes keep old versions of data item to increase concurrency. Multiversion Timestamp Ordering Multiversion Two-Phase Locking Each successful write results in the creation of a new version of the data item written. Use timestamps to label versions. When a read(Q) operation is issued, select an appropriate version of Q based on the timestamp of the transaction, and return the value of the selected version. reads never have to wait as an appropriate version is returned immediately. Multiversion Timestamp Ordering Each data item Q has a sequence of versions <Q1, Q2,...., Qm>. Each version Qk contains three data fields: Content -- the value of version Qk. W-timestamp(Qk) -- timestamp of the transaction that created (wrote) version Qk R-timestamp(Qk) -- largest timestamp of a transaction that successfully read version Qk when a transaction Ti creates a new version Qk of Q, Qk's Wtimestamp and R-timestamp are initialized to TS(Ti). R-timestamp of Qk is updated whenever a transaction Tj reads Qk, and TS(Tj) > R-timestamp(Qk). Multiversion Timestamp Ordering (Cont) Suppose that transaction Ti issues a read(Q) or write(Q) operation. Let Qk denote the version of Q whose write timestamp is the largest write timestamp less than or equal to TS(Ti). If transaction Ti issues a read(Q), then the value returned is the content of version Qk. If transaction Ti issues a write(Q) 1. 2. 1. 2. 3. if TS(Ti) < R-timestamp(Qk), then transaction Ti is rolled back. if TS(Ti) = W-timestamp(Qk), the contents of Qk are overwritten else a new version of Q is created. Observe that Reads always succeed Transaction is rejected if it is too late in doing write. Conflicts resolved thru rollbacks. Every Read also involves a write Does not ensure recoverability and cascadelessness Protocol guarantees serializability Multiversion Two-Phase Locking There are three locking modes for an item: In standard locking scheme, once transaction obtain write lock on an item, no other transactions can access that item. Idea behind multiversion 2PL is to allow other transaction T’ to read an item X while a single transaction T holds a write lock on X. Read, write and certify Accomplished by allowing two version for each item X. one version must be always written by some committed transaction. Second version X’ is created when transaction T acquires write lock on item. Other transaction can continue to read committed version of X while T holds write lock. When T is ready to commit ,must obtain certify lock on all items that is currently holds write locks on before it can commit. Certify lock is not compatible with read locks, so transaction may have to delay until all its write locks are released by reading transactions Once certify locks are acquired, the committed version X of data item is set to values of version X’ and version X’ is discarded and certify locks are released. Ensures schedules are recoverable and cascadeless Deadlock Handling Consider the following two transactions: T1: write (X) T2: write(Y) write(Y) write(X) Schedule with deadlock T1 lock-X on X write (X) wait for lock-X on Y T2 lock-X on Y write (Y) wait for lock-X on X Deadlock Handling Deadlock prevention protocols ensure that the system will never enter into a deadlock state. Some prevention strategies : Require that each transaction locks all its data items before it begins execution (pre-declaration). If any of the items can’t be obtained, none of the items are locked. In other words transaction requesting a new lock is aborted if possibility of deadlock can occur. Use preemption and transaction rollback. In preemption when T2 request a lock that T1 holds, lock granted to T1 may be preempted by rolling back, and granting of lock to T2. Allow system to enter into a Deadlock state and then Deadlock Detection and Deadlock Recovery schemes are applied Both deadlock prevention and Recovery involve rollbacks. Prevention protocols may be used when the probability of a system entering into deadlock is high otherwise Detection and Recovery scheme is more efficient. Dead Lock Prevention Techniques There are a number of deadlock prevention techniques These are: Conservative two phase lock protocol Timestamp techniques: Wait – Die protocol Wound – Wait protocol No – Wait protocol Conservative Two Phase Locking Protocol Conservative two phase locking A transaction has to lock all items it will access before it begins to execute (as in the ordinary two phase locking), If it cannot acquire any of its locks, it releases all items, aborts, and tries again, Deadlock can't occur because no hold - and wait Once it starts, a transaction is always in its shrinking phase Conservative Two Phase Locking Protocol Problems: What if a transaction cannot predetermine all items it is going to use? (e.g. a sequence of interactive SQL statements comprising one database transaction) What if a database item that is already locked by another transaction will be released very soon? (i.e. the transaction is aborted in vain) Low data-item utilization, i.e. data item may be locked and unused for a long duration Another variant of this approach Use a total order of data items. Once a particular data item is locked it cannot request locks on item that precede it This scheme is easy to implement as long as the set of data items accessed is known. Using Timestamps (Wait-Die) Timestamps are used together with two phase locking DBMS assigns a timestamp TS to each transaction T entering the system If Ti starts before Tj , then TS (Ti ) < TS (Tj) (*Ti is older than Tj ) Wait-die scheme — non-preemptive older transaction may wait for younger one to release data item. Younger transactions never wait for older ones; they are rolled back instead. a transaction may die several times before acquiring needed data item If Ti has higher priority ,allowed to wait, otherwise it is aborted. E.g. T22, T23, T24 have timestamps 5,10,15 If T22 request data item held by T23 then T22 will wait. If T24 requests the data item then it will be rolled back Using Timestamps (Wound-wait) wound-wait scheme — preemptive : If a transaction tries to lock an item held by another one, the older transaction wound the younger one (causes abort and restart with the same timestamp), But the younger one is allowed to wait So, the oldest transaction will be allowed to finish may be fewer rollbacks than wait-die scheme. If Ti has higher priority , abort Tj, otherwise Ti waits. E.g. T22, T23, T24 have timestamps 5,10,15 If T22 request data item held by T23 then data item will be preempted from T23 and T23 will be rolled back. If T24 requests the data item that T23 is holding then it will wait Deadlock Prevention Using Timestamps Both schemes avoid starvation, as transaction with smallest timestamp is not asked to rollback. Transactions that rollback are not assigned new timestamps, so at some point and time a transaction will acquire smallest timestamp value In wait-die the older transaction waits for the younger transaction to complete, so the older the transaction gets the more it tends to wait In wait-die if Ti is wounded and rolled back, the chances of it re-issuing the same commands and dying multiple times exist. In contrast such rollbacks may be fewer in wound-wait Deadlock Prevention (No-wait) Both in wait-die and in wound-wait schemes, a rolled back transactions is restarted with its original timestamp. Older transactions thus have precedence over newer ones, and starvation is hence avoided. Timeout-Based Schemes : a transaction waits for a lock only for a specified amount of time. After that, the wait times out and the transaction is rolled back. thus deadlocks are not possible simple to implement; but starvation is possible. Also difficult to determine good value of the timeout interval. Deadlock Detection Schemes Deadlock prevention is justified if transactions are long and use many items, or transaction load is very heavy In many practical situations it is advantageous to do no deadlock prevention but to detect dead locks and then abort at least one of the transactions involved An algorithm that examines the state of the system is invoked periodically to detect deadlocks If deadlocks are found then system must attempt to recover from the deadlock To do this system requires Knowledge of current data items requested by the transactions and the outstanding data item request An algorithm to determine deadlock condition A recovery process to recover from the deadlock Deadlock Detection Deadlock detection using wait-for-graph protocol: Construct a wait-for graph where each transaction has its node If Ti waits on Ti, construct a directed edge from Ti to Tj If there is a cycle detected, select a `victim` and abort it Victim selecting algorithm should select and abort transactions that made the least number of updates TIMEOUT protocol: If a transaction waits longer than a specified amount of time, it gets aborted Here, deadlock is only supposed, not proved Deadlock Detection (Wait-for graph) Deadlocks can be described as a wait-for graph, which consists of a pair G = (V,E), V is a set of vertices (all the transactions in the system) E is a set of edges; each element is an ordered pair Ti Tj. If Ti Tj is in E, then there is a directed edge from Ti to Tj, implying that Ti is waiting for Tj to release a data item. When Ti requests a data item currently being held by Tj, then the edge Ti Tj is inserted in the wait-for graph. This edge is removed only when Tj is no longer holding a data item needed by Ti. The system is in a deadlock state if and only if the wait-for graph has a cycle. Must invoke a deadlock-detection algorithm periodically to look for cycles. Deadlock Detection (Cont.) Wait-for graph without a cycle Wait-for graph with a cycle Deadlock Detection (Wait-for graph) When should we invoke deadlock detection algorithm? Depends on how often the deadlock occurs How many transactions will be affected by the deadlock If deadlock occurs frequently the invoke the algorithm more frequently. Data items allocated to deadlocked transactions are unavailable to other transactions till the deadlock is broken. In worst case invoke on every request that needs to wait Deadlock Recovery When deadlock is detected : Select a victim : Some transaction will have to be rolled back (made a victim) to break deadlock. Select that transaction as victim that will incur minimum cost. Factors that determine cost of rollback include How long the transaction has computed and how much longer will it compute before it completes the designated task How many data items have been used and how many more are required How many transactions will be involved in the rollback Deadlock Recovery When deadlock is detected (contd.): Rollback -- determine how far to roll back transaction Total rollback: Abort the transaction and then restart it. Partial rollback :More effective to roll back transaction only as far as necessary to break deadlock. This will require maintaining additional information about the state of all the transactions. The sequence of lock request granted and updates performed. Starvation happens if same transaction is always chosen as victim. Include the number of rollbacks in the cost factor to avoid starvation Other Concurrency Control Issues Till now we have restricted our attention to read and write. This limits transactions to data items already exisitng. But transaction can create and delete data items and can affect the concurrency control of the transaction We will now see concurrency issues related to Insert Delete Phantom Records Other Concurrency Control Issues Delete Operation Deletion of a data item conflicts with read and write operations as, if we read or write a deleted item, it will result in error Hence in 2PL an exclusive lock is required on a data item before it can be deleted In Timestamp ordering protocol, If TS(Ti) < R-timestamp(Q), then Ti is deleting a value that is already read by transaction Tj, where Ti< Tj. Hence delete is rejected and rolled back. If TS(Ti) < W-timestamp(Q), then Ti is deleting a value that is already written by transaction Tj, where Ti < Tj. Hence delete is rejected and rolled back Insert Operation Insertion of a data item conflicts with read and write operations as, no read or write can be performed before the item is inserted In 2PL, An insert operation may be performed only if the transaction inserting the tuple has an exclusive lock on the tuple to be inserted. In timestamp ordering protocol, after the insertion the R-timestamp and W-timestamp values of the data item are set to TS(Ti) Other Concurrency Control Issues Phantom Record A transaction locks database items that satisfy certain selection condition and updates them During that update, another transaction inserts a new item that satisfies the same selection condition After the update, but inside the same transaction, we suddenly discover the existence of a database item that has not been updated although it should have been (since it satisfies the selection condition) This database item, called a “phantom record”, appeared because it did not exist when locking has been done Other Concurrency Control Issues Phantom Record E.g. T1 : Select sum(salary) from emp where d_no = 5 T2 : insert (emp_id, d_no, emp_name, salary) into emp values (25,5,’xyz’,4500) Let S be a schedule involving T1, T2. Although the two transactions do not access any tuples in common, yet they conflict on a phantom tuple If concurrency control is done at tuple level, this conflict can go undetected and the system could fail to prevent a non-serializable schedule. This phenomenon is called “Phantom phenomenon” To prevent the phantom phenomenon T1 should prevent other transactions from creating new tuples in emp table where d_no=5 Hence it is not enough to lock tuples that are accessed, but we also need to lock the information used to find the tuples that are accesses To manage this index locking technique is used. Any transaction that inserts a tuple into a relation should insert information into each of the indices and locking is done on the indices as well. This eliminates the phantom phenomenon. + B -Tree For account File with n = 3. Insertion of “Clearview” Into the B+-Tree of Figure 16.21 Index Locking Protocol Index locking protocol: Every relation must have at least one index. A transaction can access tuples only after finding them through one or more indices on the relation A transaction Ti that performs a lookup must lock all the index leaf nodes that it accesses, in S-mode A transaction Ti that inserts, updates or deletes a tuple ti in a relation r Even if the leaf node does not contain any tuple satisfying the index lookup (e.g. for a range query, no tuple in a leaf is in the range) must update all indices to r must obtain exclusive locks on all index leaf nodes affected by the insert/update/delete The rules of the two-phase locking protocol must be observed Guarantees that phantom phenomenon won’t occur Concurrency Control in Indexes 2PL locking can be applied but would mean holding the locks till the shrinking phase and this would be expensive Crabbing Protocol Takes the advantage of B-tree structure of index Index search always traverses from the root to a leaf When searching acquire shared lock on the node. After acquiring a lock on the child node, release the lock on the parent as the parent node will not be required any further. When an insertion or deletion is being done, follow the same mechanism as search and obtain and release shared locks, except the parent. Acquire an exclusive lock on the leaf node to insert or delete key values. If node is not full no change is required. If node is full upgrade the parent lock to exclusive. B-Link Protocol Sibling nodes at each level are linked For Lookup / Search, shared locks are requested and before accessing the child node the lock on the parent is released For an insert or delete operation, proceed as in lookup and upgrade the shared lock to exclusive for the leaf node. If split relock parent in the exclusive mode. If split occurs with a search concurrently, locate thru the right sibling Transaction Support in SQL-92 Higher level of consistency allow programmers to ignore concurrency issues, whereas weaker levels of consistency places additional burden on the programmers to maintain consistency Isolation Level Dirty Read Unrepeatable Read Phantom Problem Read Uncommitted Maybe Maybe Maybe Read Committed No Maybe Maybe Repeatable Reads No No Maybe Serializable No No No Weak Levels of Consistency in SQL SQL allows non-serializable executions Serializable: is the default Repeatable read: allows only committed records to be read, and repeating a read should return the same value (so read locks should be retained) However, the phantom phenomenon need not be prevented T1 may see some records inserted by T2, but may not see others inserted by T2 Read committed: same as degree two consistency, but most systems implement it as cursor-stability Read uncommitted: allows even uncommitted data to be read In many database systems, read committed is the default consistency level has to be explicitly changed to serializable when required set isolation level serializable