Concurrency Control II. General Overview Relational model - SQL  Formal & commercial query languages Functional Dependencies Normalization Physical Design.

Slides:



Advertisements
Similar presentations
CM20145 Concurrency Control
Advertisements

Concurrency Control III. General Overview Relational model - SQL Formal & commercial query languages Functional Dependencies Normalization Physical Design.
Optimistic Methods for Concurrency Control By : H.T. Kung & John T. Robinson Presenters: Munawer Saeed.
Database Systems (資料庫系統)
Transaction Management and Concurrency Control
1 Concurrency Control Chapter Conflict Serializable Schedules  Two actions are in conflict if  they operate on the same DB item,  they belong.
Principles of Transaction Management. Outline Transaction concepts & protocols Performance impact of concurrency control Performance tuning.
Concurrency Control II
1 ICS 214B: Transaction Processing and Distributed Data Management Lecture 4: More on Locks Professor Chen Li.
1 CS216 Advanced Database Systems Shivnath Babu Notes 12: Concurrency Control (II)
Concurrency Control Amol Deshpande CMSC424. Approach, Assumptions etc.. Approach  Guarantee conflict-serializability by allowing certain types of concurrency.
4/16/20151 PSU’s CS Concurrency Control and Recovery (only for DBs with updates…..!)- Review  Concurrency Control  Transaction  ACID  Isolation.
Concurrency Control Part 2 R&G - Chapter 17 The sequel was far better than the original! -- Nobody.
Lecture 11 Recoverability. 2 Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine.
1 Supplemental Notes: Practical Aspects of Transactions THIS MATERIAL IS OPTIONAL.
Database Management Systems, 2 nd Edition. R. Ramakrishnan and J. Gehrke1 Concurrency Control Chapter 19.
CMU SCS Carnegie Mellon Univ. Dept. of Computer Science /615 - DB Applications C. Faloutsos – A. Pavlo Lecture#22: Concurrency Control – Part 2 (R&G.
©Silberschatz, Korth and Sudarshan16.1Database System Concepts 3 rd Edition Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols.
Concurrency Control. Example Schedules Constraint: The sum of A+B must be the same Before: After: T1 read(A) A = A -50 write(A) read(B)
1 Concurrency Control. 2 Locking: A Technique for C. C. Concurrency control usually done via locking. Lock info maintained by a “lock manager”: –Stores.
Concurrency Control II R &G - Chapter 17 Lecture 20 Smile, it is the key that fits the lock of everybody's heart. Anthony J. D'Angelo, The College Blue.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Concurrency Control Chapter 17.
Concurrency Control II
Final Exam Review Last Lecture R&G - All Chapters Covered The end crowns all, And that old common arbitrator, Time, Will one day end it. William Shakespeare.
Concurrency Control II R &G - Chapter 19 Lecture 22 Smile, it is the key that fits the lock of everybody's heart. Anthony J. D'Angelo, The College Blue.
ICS (072)Concurrency Control1 Transaction Processing and Concurrency Control Dr. Muhammad Shafique Chapter March 2008.
Concurrency Control III R &G - Chapter 17 Lecture 24 Smile, it is the key that fits the lock of everybody's heart. Anthony J. D'Angelo, The College Blue.
Cs4432concurrency control1 CS4432: Database Systems II Concurrency Control with Recovery.
Alternative Concurrency Control Methods R&G - Chapter 17.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Concurrency Control Chapter 17 Modified by Donghui Zhang.
Concurrency Control.
V. Megalooikonomou Concurrency control (based on slides by C. Faloutsos at CMU and on notes by Silberchatz,Korth, and Sudarshan) Temple University – CIS.
ICS (072)Concurrency Control Techniques1 Concurrency Control Techniques Chapter 18 Dr. Muhammad Shafique.
Concurrency Control Techniques Chapter 18
1 Concurrency Control Chapter Conflict Serializable Schedules  Two schedules are conflict equivalent if:  Involve the same actions of the same.
Page 1 Concurrency Control Paul Krzyzanowski Distributed Systems Except as otherwise noted, the content of this presentation.
1 Concurrency Control Lecture 22 Ramakrishnan - Chapter 19.
Transaction Management Overview. Transactions Concurrent execution of user programs is essential for good DBMS performance. – Because disk accesses are.
Concurrency Control Introduction Lock-Based Protocols
1 Concurrency control lock-base protocols timestamp-based protocols validation-based protocols Ioan Despi.
Lecture 9- Concurrency Control (continued) Advanced Databases Masood Niazi Torshiz Islamic Azad University- Mashhad Branch
Em Spatiotemporal Database Laboratory Pusan National University File Processing : Concurrency Control 2004, Spring Pusan National University Ki-Joune Li.
1 Concurrency Control Chapter Conflict Serializable Schedules  Two schedules are conflict equivalent if:  Involve the same actions of the same.
CS 440 Database Management Systems
Transaction Management
Lec 10: Concurrency Control Techniques
Lecture 3 Concurrency control techniques
Concurrency Control Techniques
Extra slide #3.
Concurrency Control More !
Concurrency Control Chapter 17 Modified by Donghui Zhang
Chapter 16: Concurrency Control
Concurrency Control Part 2
Concurrency Control Chapter 17
Concurrency Control.
Chapter 16: Concurrency Control
Database Concurrency Control
Chapter 16: Concurrency Control
Chapter 16: Concurrency Control
Concurrency Control Chapter 17
Ch 22: Databases Concurrency Control
Module 16 : Concurrency Control
Concurrency Control Chapter 17
Chapter 16: Concurrency Control
Concurrency Control Chapter 17
Temple University – CIS Dept. CIS661 – Principles of Data Management
Concurrency Control Chapter 17
Database Management System
CONCURRENCY Concurrency is the tendency for different tasks to happen at the same time in a system ( mostly interacting with each other ) .   Parallel.
Chapter 16 : Concurrency Control
Presentation transcript:

Concurrency Control II

General Overview Relational model - SQL  Formal & commercial query languages Functional Dependencies Normalization Physical Design Indexing Query Processing and Optimization Transaction Processing and CC

Review: AC[I]D Isolation  Concurrent xctions unaware of each other How? We discussed locking protocols:  2PL protocol and its variants  Graph-based locking protocols

Multiple-Granularity Locks Hard to decide what granularity to lock (tuples vs. pages vs. tables). Shouldn’t have to decide! Data “containers” are nested: Tuples Tables Pages Database contains

Intention Lock Modes In addition to S and X lock modes, there are three additional lock modes with multiple granularity:  intention-shared (IS): indicates explicit locking at a lower level of the tree but only with shared locks.  intention-exclusive (IX): indicates explicit locking at a lower level with exclusive or shared locks  shared and intention-exclusive (SIX): the subtree rooted by that node is locked explicitly in shared mode and explicit locking is being done at a lower level with exclusive-mode locks.

MGL: multiple granularity locking v Before locking an item, Xact must set “intention locks” on all its ancestors. v For unlock, go from specific to general (i.e., bottom-up). v SIX mode: Like S & IX at the same time. -- ISIX -- IS IX      SX   S X      

ParentChild can belocked in IS IX S SIX X P C IS, S IS, S, IX, X, SIX [S, IS] not necessary X, IX, [SIX] none

Example R1 t1t1 t2t2 t3t3 t4t4 T 1 (IS) T 1 (S), T 2 (IX) T 2 (X)

Multiple Granularity Locking Scheme Transaction T i can lock a node Q, using the following rules: (1) Follow multiple granularity comp function (2) Lock root of tree first, any mode (3) Node Q can be locked by Ti in S or IS only if parent(Q) can be locked by Ti in IX or IS (4) Node Q can be locked by Ti in X,SIX,IX only if parent(Q) locked by Ti in IX,SIX (5) Ti uses 2PL (6) Ti can unlock node Q only if none of Q’s children are locked by Ti Observe that locks are acquired in root-to-leaf order, whereas they are released in leaf-to-root order.

Examples R t1 t3 t4 t2 f2.1 f2.2 f4.2 T1(IX) T1(X) R t1 t3 t4 t2 f2.1 f2.2 f4.2 T1(IS) T1(S) R t1 t3 t4 t2 f2.1 f2.2 f4.2 T1(SIX) T1(IX) T1(X) Can T2 access object f2.2 in X mode? What locks will T2 get?

Examples T1 scans R, and updates a few tuples:  T1 gets an SIX lock on R, then repeatedly gets an S lock on tuples of R, and occasionally upgrades to X on the tuples that needs to update. T2 uses an index to read only part of R:  T2 gets an IS lock on R, and repeatedly gets an S lock on tuples of R. T3 reads all of R:  T3 gets an S lock on R.  OR, T3 could behave like T2; can use lock escalation to decide which. -- ISIX -- IS IX      SX   S X      

B+-tree locking: A Hybrid Algorithm The likelihood that we really need an X lock decreases as we move up the tree. Hybrid approach: Set S locks Set SIX locks Set X locks

Optimistic CC Locking is a conservative approach in which conflicts are prevented. Disadvantages:  Lock management overhead.  Deadlock detection/resolution.  Lock contention for heavily used objects. If conflicts are rare, we might be able to gain concurrency by not locking, and instead checking for conflicts before Xacts commit.

Timestamp-Based Protocols Idea:  Decide in advance ordering of xctions  Ensure concurrent schedule serializes to serial order decided  Timestamps  TS(T i ) is time T i entered the system  Data item timestamps:  W-TS(Q): Largest timestamp of any xction that wrote Q  R-TS(Q): Largest timestamp of any xction that read Q  Timestamps -> serializability order

Timestamp CC Idea : If action p i of Xact T i conflicts with action q j of Xact T j, and TS(T i ) < TS(T j ), then p i must occur before q j. Otherwise, restart violating Xact.

When Xact T wants to read Object O If TS(T) < W-TS(O), this violates timestamp order of T w.r.t. writer of O.  So, abort T and restart it with a new, larger TS. (If restarted with same TS, T will fail again!) If TS(T) > W-TS(O):  Allow T to read O.  Reset R-TS(O) to max(R-TS(O), TS(T)) Change to R-TS(O) on reads must be written to disk (log)! This and restarts represent overheads. T startU start U writes O T reads O

When Xact T wants to Write Object O 1) If TS(T) < R-TS(Q), then the value of Q that T is producing was needed previously, and the system assumed that that value would never be produced. write rejected, T is rolled back and restarts. 2) If TS(T) < W-TS(Q), then T is attempting to write an obsolete value of Q. Hence, this write operation is rejected, and T is rolled back. 3) Otherwise, the write operation is executed, and W-TS(Q) is set to TS(T). T startU start U reads Q T writes Q Another approach in 2) is to ignore the write and continue!! Thomas Write Rule

Timestamp CC and Recoverability Timestamp CC can be modified to allow only recoverable schedules:  Buffer all writes until writer commits (but update WTS(O) when the write is allowed.)  Block readers T (where TS(T) > WTS(O)) until writer of O commits. Similar to writers holding X locks until commit, but still not quite 2PL. T1 T2 W(A) R(A) W(B) Commit v Unfortunately, unrecoverable schedules are allowed: