H.Lu/HKUST L06: Concurrency Control & Locking

L06: Concurrency Control & Locking - 2 H.Lu/HKUST Transactions  Concurrent execution of user programs is essential for good DBMS performance.  Because disk accesses are frequent, and relatively slow, it is important to keep the CPU humming by working on several user programs concurrently.  A user’s program may carry out many operations on the data retrieved from the database, but the DBMS is only concerned about what data is read/written from/to the database.  A transaction is the DBMS’s abstract view of a user program: a sequence of reads and writes.

L06: Concurrency Control & Locking - 3 H.Lu/HKUST Transaction A transaction is a collection of actions that make consistent transformations of system states while preserving system consistency. Database in a consistent state Database may be temporarily in an inconsistent state during execution Database in a consistent state Begin Transaction End Transaction Execution of Transaction

L06: Concurrency Control & Locking - 4 H.Lu/HKUST An Example Transaction Begin_transaction Reservation begin input(flight_no, date, customer_name); EXEC SQL SELECT STSOLD,CAP INTO temp1,temp2 FROM FLIGHT WHERE FNO = flight_no AND DATE = date; if temp1 = temp2 then output(``no free seats''); Abort else EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date; EXEC SQL INSERT INTO FC(FNO, DATE, CNAME, SPECIAL); VALUES (flight_no, date, customer_name, null); Commit output(``reservation completed'') endif end. {Reservation}

L06: Concurrency Control & Locking - 5 H.Lu/HKUST Example Transaction -- Reads & Writes Begin_transaction Reservation begin input(flight_no, date, customer_name); temp  Read(flight_no(date).stsold); if temp = flight(date).cap then begin output(``no free seats''); Abort end else begin Write(flight(date).stsold, temp + 1); Write(flight(date).cname, customer_name); Write(flight(date).special, null); Commit; output(``reservation completed'') end end. {Reservation}

L06: Concurrency Control & Locking - 6 H.Lu/HKUST Transaction Execution Transaction Manager (TM) Scheduler (SC) Begin_transaction, Read, Write, Commit, Abort Results Recovery Manager (RM) Scheduled Operations User Application Results Read, Write, Commit, Abort User Application …...

L06: Concurrency Control & Locking - 7 H.Lu/HKUST Properties of Transactions -- ACID A TOMICITY all or nothing C ONSISTENCY no violation of integrity constraints I SOLATION concurrent changes invisible and serializable D URABILITY committed updates persist

L06: Concurrency Control & Locking - 8 H.Lu/HKUST Atomicity  Either all or none of the transaction's operations are performed.  Atomicity requires that if a transaction is interrupted by a failure, its partial results must be undone.  The activity of preserving the transaction's atomicity in presence of transaction aborts due to input errors, system overloads, or deadlocks is called transaction recovery.  The activity of ensuring atomicity in the presence of system crashes is called crash recovery.

L06: Concurrency Control & Locking - 9 H.Lu/HKUST Consistency  Internal consistency  A transaction which executes alone against a consistent database leaves it in a consistent state.  Transactions do not violate database integrity constraints.  Transactions are correct programs

L06: Concurrency Control & Locking - 10 H.Lu/HKUST Isolation  Serializability  If several transactions are executed concurrently, the results must be the same as if they were executed serially in some order.  Incomplete results  An incomplete transaction cannot reveal its results to other transactions before its commitment.  Necessary to avoid cascading aborts.

L06: Concurrency Control & Locking - 11 H.Lu/HKUST Durability  Once a transaction commits, the system must guarantee that the results of its operations will never be lost, in spite of subsequent failures.  Database recovery

L06: Concurrency Control & Locking - 12 H.Lu/HKUST Concurrency in a DBMS  Users submit transactions, and can think of each transaction as executing by itself.  Concurrency is achieved by the DBMS, which interleaves actions (reads/writes of DB objects) of various transactions.  Each transaction must leave the database in a consistent state if the DB is consistent when the transaction begins. DBMS will enforce some ICs, depending on the ICs declared in CREATE TABLE statements. Beyond this, the DBMS does not really understand the semantics of the data. (e.g., it does not understand how the interest on a bank account is computed).  Issues: Effect of interleaving transactions, and crashes.

L06: Concurrency Control & Locking - 13 H.Lu/HKUST Why Concurrency Control  Consider two transactions (Xacts): Intuitively, the first transaction is transferring $100 from B’s account to A’s account. The second is crediting both accounts with a 6% interest payment.  There is no guarantee that T1 will execute before T2 or vice- versa, if both are submitted together. However, the net effect must be equivalent to these two transactions running serially in some order.  Concurrency control: synchronizing concurrent transactions such that the consistency of the database is maintained while, at the same time, maximum degree of concurrency is achieved. T1:BEGIN A=A+100, B=B-100 END T2:BEGIN A=1.06*A, B=1.06*B END

L06: Concurrency Control & Locking - 14 H.Lu/HKUST Lost Updates T1: T2: Read A A=A+100 Write A Read B B=B-100 Write B Read A A=1.06*A Write A Read B B=1.06*B Write B T1: T2: Read A A=A+100 Write A Read A A=1.06*A Write A Read B B=1.06*B Write B Read B B=B-100 Write B

L06: Concurrency Control & Locking - 15 H.Lu/HKUST Dirty Read  Program T2 credits interest rate based on a value that is not part of a consistent state.  Namely, T1 is aborted later on. StepT1T2 1Read(A,a1) 2a1 :=a Write(A,a1) 4Read(A, a2) 5a2:=a2*1.06 6Write(A, a2) 7Read(B,b1) 8… 9abort

L06: Concurrency Control & Locking - 16 H.Lu/HKUST Inconsistent Retrievals  T1 calculates the sum  T2 makes corrections to previously made data entrance error: C:=C+30 D:=D-30 T1 Read A100 T1Read B T2Read C 70 T2C:=C+30 T2Write C100 T1Read C T1Read D T2Read D 35 T2 D:=D-30 T2Write D 5 T2Commit T1Read E100455

L06: Concurrency Control & Locking - 17 H.Lu/HKUST Scheduling Transactions  Serial schedule: Schedule that does not interleave the actions of different transactions.  Equivalent schedules: For any database state, the effect (on the set of objects in the database) of executing the first schedule is identical to the effect of executing the second schedule.  Serializable schedule: A schedule that is equivalent to some serial execution of the transactions. (Note: If each transaction preserves consistency, every serializable schedule preserves consistency. )

L06: Concurrency Control & Locking - 18 H.Lu/HKUST Execution Schedule  An order in which the operations of a set of transactions are executed.  A schedule can be defined as a partial order over the operations of a set of transactions. T 1 : Read(x) T 2 : Write(x) T 3 : Read(x) Write(x) Write(y) Read(y) Commit Read(z) Read(z) Commit S 1 ={W 2 (x), R 1 (x), R 3 (x), W 1 (x), C 1,W 2 (y), R 3 (y), R 2 (z), C 2, R 3 (z), C 3 }

L06: Concurrency Control & Locking - 19 H.Lu/HKUST Serial Schedule  All the actions of a transaction occur consecutively.  No interleaving of transaction operations.  If each transaction is consistent (obeys integrity rules), then the database is guaranteed to be consistent at the end of executing a serial history.  T 1 : Read(x) T 2 : Write(x) T 3 : Read(x) Write(x) Write(y) Read(y) Commit Read(z) Read(z) Commit S ={W 2 (x), W 2 (y),R 2 (z),C 2,R 1 (x),W 1 (x), C 1, R 3 (x), R 3 (y), R 3 (z), C 3 }

L06: Concurrency Control & Locking - 20 H.Lu/HKUST Equivalence of Schedules  More than one definition  Conflict equivalence  View equivalence  Conflict equivalence  Schedules S and S’ are conflict equivalent if the relative order of execution of the conflicting operations belonging to unaborted transactions in two schedules are the same.

L06: Concurrency Control & Locking - 21 H.Lu/HKUST Serializable Schedule  Transactions execute concurrently, but the net effect of the resulting schedule upon the database is equivalent to some serial schedule. Example: T 1 : Read(x) T 2 : Write(x) T 3 : Read(x) Write(x) Write(y) Read(y) Commit Read(z) Read(z) Commit A serializable schedule. S = {W 2 (x), R 1 (x), W 1 (x), C 1, R 3 (x), W 2 (y), R 3 (y), R 2 (z), C 2, R 3 (z), C 3 }

L06: Concurrency Control & Locking - 22 H.Lu/HKUST Serializable Schedule T 1 : Read(x) T 2 : Write(x) T 3 : Read(x) Write(x) Write(y) Read(y) Commit Read(z) Read(z) Commit The following schedule is not serializable: S 1 = {W 2 (x), R 1 (x), R 3 (x),W 1 (x), C 1, R 3 (y), W 2 (y), R 2 (z), C 2, R 3 (z), C 3 } The following is serializable. S 2 ={W 2 (x), R 1 (x), W 1 (x), C 1, R 3 (x), W 2 (y), R 3 (y), R 2 (z), C 2, R 3 (z), C 3 }

L06: Concurrency Control & Locking - 23 H.Lu/HKUST Dependency Graph  Dependency graph:  One node per Xact;  edge from Ti to Tj if Tj reads/writes an object last written by Ti.  The cycle in the graph reveals the problem. The output of T1 depends on T2, and vice-versa.  Theorem: Schedule is conflict serializable if and only if its dependency graph is acyclic. T1T2 A B

L06: Concurrency Control & Locking - 24 H.Lu/HKUST Since there are two transactions, we have two nodes T 1 and T 2 T1 A cycle in Dependency Graph implies potential for database inconsistency T2 R 1 (X)  W 2 (X)  edge T 2  T 1 ; R 2 (X)  W 1 (x)  edge T 1  T2 1, W 2 (X)  W 1 (X)  edge T 1  T 2 T1T1 R 1 (X) W 1 (X) R 2 (X) W 2 (X) T2T2 Dependency Graph - An Example

L06: Concurrency Control & Locking - 25 H.Lu/HKUST Locking  Mechanism to ensure serializable execution of interleaving transactions accessing the same resources  Looking principle  Before accessing a data item, obtain a lock on the data item first  After accessing the data item, release the lock  Locks are either read lock (rl) [also called shared lock] or write lock (wl) [also called exclusive lock]  Read locks and write locks conflict (because Read and Write operations are incompatible)

L06: Concurrency Control & Locking - 26 H.Lu/HKUST Locking ­ Based Concurrency Control  Transactions indicate their intentions by requesting locks from the scheduler (called lock manager).  If the request data object is not exclusively locked by the others, the transaction is granted the lock. Otherwise, it will be blocked until other transactions release the lock.  However, simple locking does not guarantee the correctness

L06: Concurrency Control & Locking - 27 H.Lu/HKUST The Two-Phase Locking protocol  This is a protocol which ensures conflict-serializable schedules.  Phase 1: Growing Phase  transaction may obtain locks but is not allowed to release locks  Phase 2: Shrinking Phase  transaction may release locks but is not allowed to get new locks Acquire locksRelease locks time No of locks acquired

L06: Concurrency Control & Locking - 28 H.Lu/HKUST About 2PL  The protocol assures serializability. It can be proved that the transaction can be serialized in the order of their lock points (i.e. the point where a transaction acquired its final lock).  Does 2PL allow S 1 ? S 1 = {R 1 (x), W 1 (x), R 2 (x),W 2 (x), R 2 (y),W 2 (y),R 1 (y),W 1 (y) }  How about S 2 ? S 2 = {R 1 (x), W 1 (x), R 2 (x),W 2 (x), R 1 (y),W 1 (y), R 2 (y),W 2 (y)}

L06: Concurrency Control & Locking - 29 H.Lu/HKUST Strict Two-Phase Locking  Cascading roll-back is possible under two-phase locking  Strict two-phase locking: a transaction must hold all its exclusive locks till it commits/aborts.  Avoids cascade roll-back but reduces concurrency Acquire locks Keep all locks Release locks time Number of locks acquired

L06: Concurrency Control & Locking - 30 H.Lu/HKUST Deadlock  A transaction is deadlocked if it is blocked and will remain blocked until there is intervention.  Locking ­ based CC algorithms may cause deadlocks. Wait ­ for graph If transaction T i waits for another transaction T j to release a lock on an entity, then T i  T j in WFG.

L06: Concurrency Control & Locking - 31 H.Lu/HKUST Handling Deadlocks  Ignore  Let the application programmer deal with it, or restart the system  Prevention  Guaranteeing that deadlocks can never occur in the first place. Check transaction when it is initiated. Requires no run time support.  Avoidance  Detecting potential deadlocks in advance and taking action to insure that deadlock will not occur. Requires run time support.  Detection and Recovery  Allowing deadlocks to form and then finding and breaking them. As in the avoidance scheme, this requires run time support.

L06: Concurrency Control & Locking - 32 H.Lu/HKUST Summary  Concurrency control and recovery are among the most important functions provided by a DBMS.  Users need not worry about concurrency.  System automatically inserts lock/unlock requests and schedules actions of different Xacts in such a way as to ensure that the resulting execution is equivalent to executing the Xacts one after the other in some order.  There are several lock-based concurrency control schemes (Strict 2PL, 2PL). Conflicts between transactions can be detected in the dependency graph  The lock manager keeps track of the locks issued. Deadlocks can either be prevented or detected.