Presentation is loading. Please wait.

Presentation is loading. Please wait.

Database System Concepts 5 th Ed. © Silberschatz, Korth and Sudarshan, 2005 See www.db-book.com for conditions on re-usewww.db-book.com Chapter 16 : Concurrency.

Similar presentations


Presentation on theme: "Database System Concepts 5 th Ed. © Silberschatz, Korth and Sudarshan, 2005 See www.db-book.com for conditions on re-usewww.db-book.com Chapter 16 : Concurrency."— Presentation transcript:

1 Database System Concepts 5 th Ed. © Silberschatz, Korth and Sudarshan, 2005 See for conditions on re-usewww.db-book.com Chapter 16 : Concurrency Control

2 ©Silberschatz, Korth and Sudarshan16.2Database System Concepts - 5 th Edition, Sep 12, 2005 Chapter 16: Concurrency Control Lock-Based Protocols

3 ©Silberschatz, Korth and Sudarshan16.3Database System Concepts - 5 th Edition, Sep 12, 2005 Lock-Based Protocols A lock is a mechanism to control concurrent access to a data item 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. 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.

4 ©Silberschatz, Korth and Sudarshan16.4Database System Concepts - 5 th Edition, Sep 12, 2005 Lock-Based Protocols (Cont.) 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 is made to wait till all incompatible locks held by other transactions have been released. The lock is then granted.

5 ©Silberschatz, Korth and Sudarshan16.5Database System Concepts - 5 th Edition, Sep 12, 2005 Lock-Based Protocols (Cont.) Consider that T 1 transfers $50 from account B to account A, and T 2 displays the total amount in A and B. Suppose that the values of A and B are $100 and $200, respectively. T 1 : lock-X(B); T 2 : lock-S(A); read(B); read(A); B := B - 50; unlock(A); write(B); lock-S(B); unlock(B); read(B); lock-X(A); unlock(B); read(A); display(A + B); A := A + 50; write(A); unlock(A); Executed serially, then T 2 displays $300. But executed concurrently(see Schedule 1), then T 2 display $250, which is incorrect. The reason is that T 1 unlocked data item B too early.

6 ©Silberschatz, Korth and Sudarshan16.6Database System Concepts - 5 th Edition, Sep 12, 2005 Lock-Based Protocols (Cont.) T1 T2 lock-X(B) read(B) B := B – 50 write(B) unlock(B) lock-S(A) read(A) unlock(A) lock-S(B) read(B) unlock(B) display(A + B) lock-X(A) read(A) A := A + 50 write(A) unlock(A) Schedule 1.

7 ©Silberschatz, Korth and Sudarshan16.7Database System Concepts - 5 th Edition, Sep 12, 2005 Lock-Based Protocols (Cont.) Suppose now that unlocking is delayed to the end of the transaction. T 3 and T 4 correspond to T 1 and T 2 with unlocking delayed, respectively: T3: lock-X(B); T4: lock-S(A); read(B); read(A); B := B - 50; lock-S(B); write(B); read(B); lock-X(A); display(A + B); read(A); unlock(A); A := A + 50; unlock(B); write(A); unlock(B); unlock(A);

8 ©Silberschatz, Korth and Sudarshan16.8Database System Concepts - 5 th Edition, Sep 12, 2005 Pitfalls of Lock-Based Protocols Consider the partial schedule Neither T 3 nor T 4 can make progress executing lock-S(B) causes T 4 to wait for T 3 to release its lock on B, while executing lock-X(A) causes T 3 to wait for T 4 to release its lock on A. Such a situation is called a deadlock. To handle a deadlock one of T 3 or T 4 must be rolled back and its locks released.

9 ©Silberschatz, Korth and Sudarshan16.9Database System Concepts - 5 th Edition, Sep 12, 2005 The Two-Phase Locking Protocol This is a protocol which ensures conflict-serializable schedules. Phase 1: Growing Phase transaction may obtain locks transaction may not release locks Phase 2: Shrinking Phase transaction may release locks transaction may not obtain locks The protocol assures serializability.

10 ©Silberschatz, Korth and Sudarshan16.10Database System Concepts - 5 th Edition, Sep 12, 2005 The Two-Phase Locking Protocol (Cont.) Two-phase locking does not ensure freedom from deadlocks Cascading roll-back is possible under two-phase locking. To avoid this, follow a modified protocol called strict two-phase locking. Here a transaction must hold all its exclusive locks till it commits/aborts. 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.

11 ©Silberschatz, Korth and Sudarshan16.11Database System Concepts - 5 th Edition, Sep 12, 2005 Partial Schedule Under Two-Phase Locking Cascading rollback may occur under two-phase locking: Each transaction observes the two-phase locking protocol, but the failure of T 5 after the read(A) step of T 7 leads to cascading rollback of T 6 and T 7. Partial schedule under two-phase locking

12 ©Silberschatz, Korth and Sudarshan16.12Database System Concepts - 5 th Edition, Sep 12, 2005 Lock Conversions Two-phase locking with lock conversions: – 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) – Second Phase: can release a lock-S can release a lock-X can convert a lock-X to a lock-S (downgrade) This protocol assures serializability.

13 ©Silberschatz, Korth and Sudarshan16.13Database System Concepts - 5 th Edition, Sep 12, 2005 Lock Conversions Rigorous two-phase locking protocol: requires all locks to be held until the transaction commits. Consider T 8 : read(a 1 ); T 9 : read(a 1 ); read(a 2 ); read(a 2 );... display(a 1 + a 2 ). read(a n ); write(a 1 ). Two-phase locking protocol ==> serial

14 ©Silberschatz, Korth and Sudarshan16.14Database System Concepts - 5 th Edition, Sep 12, 2005 Lock Conversions If we employ the two-phase locking protocol, then T 8 must lock a 1 in exclusive mode. Therefore, any concurrent execution of both transactions amounts to a serial execution. Notice, however, that T 8 needs an exclusive lock on a 1 only at the end of its execution, when it writes a 1. Thus, if T 8 could initially lock a1 in shared mode, and then could later change the lock to exclusive mode, we could get more concurrency, since T 8 and T 9 could access a 1 and a 2 simultaneously. lock conversion: - upgrade: shared exclusive modes in growing phase. - downgrade: exclusive shared mode in shrinking phase.

15 ©Silberschatz, Korth and Sudarshan16.15Database System Concepts - 5 th Edition, Sep 12, 2005 Incomplete Schedule With a Lock Conversion See the incomplete schedule with a lock conversion. Strict two-phase locking and rigorous two-phase locking (with lock conversions) are used extensively in commercial database systems.

16 Database System Concepts 5 th Ed. © Silberschatz, Korth and Sudarshan, 2005 See for conditions on re-usewww.db-book.com End of Chapter 16


Download ppt "Database System Concepts 5 th Ed. © Silberschatz, Korth and Sudarshan, 2005 See www.db-book.com for conditions on re-usewww.db-book.com Chapter 16 : Concurrency."

Similar presentations


Ads by Google