CS 440 Database Management Systems

Slides:



Advertisements
Similar presentations
Database Systems (資料庫系統)
Advertisements

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.
1 Lecture 11: Transactions: Concurrency. 2 Overview Transactions Concurrency Control Locking Transactions in SQL.
Transaction Management: Concurrency Control CS634 Class 17, Apr 7, 2014 Slides based on “Database Management Systems” 3 rd ed, Ramakrishnan and Gehrke.
Principles of Transaction Management. Outline Transaction concepts & protocols Performance impact of concurrency control Performance tuning.
Concurrency Control II
Concurrency Control Amol Deshpande CMSC424. Approach, Assumptions etc.. Approach  Guarantee conflict-serializability by allowing certain types of concurrency.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Concurrency Control Chapter 17 Sections
Concurrency Control II. General Overview Relational model - SQL  Formal & commercial query languages Functional Dependencies Normalization Physical Design.
Concurrency Control Part 2 R&G - Chapter 17 The sequel was far better than the original! -- Nobody.
Sekolah Tinggi Ilmu Statistik (STIS) 1 Dr. Said Mirza Pahlevi, M.Eng.
Quick Review of Apr 29 material
Concurrency Control and Recovery In real life: users access the database concurrently, and systems crash. Concurrent access to the database also improves.
©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 and Recovery Module 6, Lecture 1.
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.
Transaction Management
1 Transaction Management Database recovery Concurrency control.
Transactions Amol Deshpande CMSC424. Today Project stuff… Summer Internships 
Concurrency Control. General Overview Relational model - SQL  Formal & commercial query languages Functional Dependencies Normalization Transaction Processing.
Database Management Systems, 2 nd Edition. R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Lecture 21 Ramakrishnan - Chapter 18.
V. Megalooikonomou Concurrency control (based on slides by C. Faloutsos at CMU and on notes by Silberchatz,Korth, and Sudarshan) Temple University – CIS.
Carnegie Mellon Carnegie Mellon Univ. Dept. of Computer Science Database Applications C. Faloutsos Concurrency control.
TRANSACTION MANAGEMENT R.SARAVANAKUAMR. S.NAVEEN..
1 Transactions Chapter Transactions A transaction is: a logical unit of work a sequence of steps to accomplish a single task Can have multiple.
Concurrency Control in Database Operating Systems.
1 Concurrency Control II: Locking and Isolation Levels.
1 Concurrency Control Chapter Conflict Serializable Schedules  Two schedules are conflict equivalent if:  Involve the same actions of the same.
Chapter 15: Transactions Loc Hoang CS 157B. Definition n A transaction is a discrete unit of work that must be completely processed or not processed at.
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.
Lecture 9- Concurrency Control (continued) Advanced Databases Masood Niazi Torshiz Islamic Azad University- Mashhad Branch
Jinze Liu. ACID Atomicity: TX’s are either completely done or not done at all Consistency: TX’s should leave the database in a consistent state Isolation:
CS 440 Database Management Systems Concurrency Control 1.
1 Concurrency Control. 2 Why Have Concurrent Processes? v Better transaction throughput, response time v Done via better utilization of resources: –While.
CS 540 Database Management Systems Concurrency Control 1.
Transaction Management
Concurrency Control.
Lecture 3 Concurrency control techniques
Transactions and Concurrency Control
Concurrency Control Techniques
Database Management System
Concurrency Control More !
Part- A Transaction Management
Transaction Management
COS 418: Advanced Computer Systems Lecture 5 Michael Freedman
March 21st – Transactions
April 4, 2011 Ion Stoica CS162 Operating Systems and Systems Programming Lecture 18 Transactions April 4, 2011 Ion.
בקרת בו זמניות (concurrency control)
Anthony D. Joseph and Ion Stoica
Transaction Management
March 9th – Transactions
Transactions Sylvia Huang CS 157B.
Lecture#21: Concurrency Control – Part 1
CS162 Operating Systems and Systems Programming Review (II)
Ch 22: Databases Concurrency Control
Database Transactions
Atomic Commit and Concurrency Control
Transaction management
Concurrency Control E0 261 Prasad Deshpande, Jayant Haritsa
Transaction Management
Temple University – CIS Dept. CIS661 – Principles of Data Management
CPSC-608 Database Systems
CONCURRENCY Concurrency is the tendency for different tasks to happen at the same time in a system ( mostly interacting with each other ) .   Parallel.
UNIT -IV Transaction.
Database Systems (資料庫系統)
Lecture 18: Concurrency Control
Database Systems (資料庫系統)
Presentation transcript:

CS 440 Database Management Systems Lecture 8: Concurrency Control

Concurrent access to data Flight (fltNo, fltDate, seatNo, seatStatus) Database: seats 22A and 22B are available. John checks for availability and gets seat 22A John books seat 22A Mary checks for availability and gets seat 22B Mary books seat 22B Database: seats 22A and 22B are reserved.

Concurrent access to data: problems Database: seats 22A and 22B are available. John checks for availability and gets seat 22A Mary checks for availability and gets seat 22A John books seat 22A Mary books seat 22A Database: double booking on 22A!!! Database is not consistent. Solution: Run John’s before Mary’s (or vice versa) serial schedule

Serial schedules Database: seats 22A and 22B are available. Admin scans Flight to generate some reports. Mary checks the flights for tomorrow. Nobody can use the database until Admin is done!! How to run programs concurrently without them messing up each other’s results? It takes a long time!

Transaction a “program” of atomic database operations. atomic unit of database transformation. START TRANSACTION SQL-statement 1; SQL-statement 2; … SQL-statement n; COMMIT;

The ACID properties A tomicity: All actions in the Xact happen, or none happen. C onsistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent. I solation: Execution of one Xact is isolated from that of other Xacts. D urability: If a Xact commits, its effects persist.

Atomicity Balance transfer from Acct. 170 to Acct. 103: check if account #170 has at least $200. if #170 does not have enough fund => abort transaction reduce the balance of #170 by $200. check eligibility of #103, if not eligible => abort transaction increase the balance of #103 by $200. commit roll_back command to abort the transaction database system undoes all transaction’s modifications.

Atomicity Balance transfer from Acct. 170 to Acct. 103: check if account #170 has at least $200. reduce the balance of #170 by $200. increase the balance of #103 by $200. commit Power outage in before SQL statement #3 transaction aborts violates atomicity database system should automatically undo all transaction’s modifications.

Isolation Database: double booking on 22A!! Database: seats 22A and 22B are available. John checks for availability and gets seat 22A Mary checks for availability and gets seat 22A John books seat 22A Mary books seat 22A Database: double booking on 22A!! Concurrency control: ensures that transactions are interleaved correctly.

Durability Balance transfer from Acct. 170 to Acct. 103: check if account 170 has at least $200. reduce the balance of 170 by $200. increase the balance of 103 by $200. commit Database system says commit was successful, but the data is in buffer. Power outage right after commit modifications of the transaction are gone! violates Durability Database system must make sure that the effects of committed transactions persist.

The ACID properties A tomicity: All actions in the Xact happen, or none happen. C onsistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent. I solation: Execution of one Xact is isolated from that of other Xacts. D urability: If a Xact commits, its effects persist. Today’s topic

Transaction Interleaving Before: A = 0, B = 0, then? Correct schedule? Wrong schedule? Why? Xact T1 Xact T2 read(A) A = A + 1 write(A) A = A * 2 read(B) B = B + 1 write(B) read (B) B = B * 2 write (B) Xact T1 Xact T2 read(A) A = A + 1 write(A) A = A * 2 read(B) B = B * 2 write(B) read (B) B = B + 1 write (B) Xact T1 Xact T2 read(A) A = A + 1 write(A) read(B) B = B + 1 write(B) A = A * 2 B = B * 2 schedule 1 schedule 2 schedule 3

Transaction Interleaving Schedule 1 (interleaved, more concurrent) = Schedule 3 (serial) (A=0,B=0) --- T1 --> (A=1,B=1) -- T2 --> (A=2,B=2) Consistency and isolation: transform DB in serial Serializable schedule: a concurrent schedule that impacts DB like a serial schedule. How to check if a concurrent schedule is serializable? Xact T1 Xact T2 read(A) A = A + 1 write(A) A = A * 2 read(B) B = B + 1 write(B) read (B) B = B * 2 write (B) Xact T1 Xact T2 read(A) A = A + 1 write(A) read(B) B = B + 1 write(B) A = A * 2 B = B * 2 schedule 3 schedule 1

Use conflicting operations We denote operations of transaction i as writei or readi. Conflicting operations: operations from different transactions such that: two writes of the same data item: writei(A); witej(A). a read and a write on the same data item: readi(A); writej(A). Change the relative order of conflicting operators => change the final state of DB. A serializable schedule has the same order of conflicting operators as a serial schedule. they access the same data item and at least one of them is a write operation. No conflict between read operations.

Serialization graph Define dependencies between transactions with conflicting operations Serialization (precedence) graph: Ti --> Tj for a dependency from Ti to Tj Serializable if serialization graph does not have any cycle Xact T1 Xact T2 read(A) A = A + 1 write(A) A = A * 2 read(B) B = B + 1 write(B) read (B) B = B * 2 write (B) Xact T1 Xact T2 read(A) A = A + 1 write(A) A = A * 2 read(B) B = B * 2 write(B) read (B) B = B + 1 write (B) T1 T1 T2 T2 schedule 1 schedule 2

Guaranteeing isolation Scheduler guarantees serializability restricts the access of transactions on data items. enforces some order on conflicting operations. Two approaches: Pessimistic: There are many conflicting transactions. Optimistic: There are a few conflicting transactions.

Locking Protocol A “protocol” for accessing data well-formed transactions lock/unlock “access units” before/after using them lock manager grants/manages locks Goals of locking protocol ensure serializability preserve high concurrency Parameters of a locking protocol?

Locking Protocol: Parameters What “modes” of locks to provide? Compatibility? e.g., S for shared, X for exclusive How to “well-behave” to obtain and hold locks? in what sequence? how long to hold? What “units” to lock? database? table? tuple? what else? other units: attributes, range of attribute values (e.g., GPA > 3.0), predicate locking

Lock modes and compatibility Shared lock = read lock= S multiple transactions hold a shared lock over a data item. Exclusive lock = write lock = X at most one transaction holds an exclusive lock over a data item. Lock manager gives locks based on compatibility matrix: X S N Y

Motivation: a “simple” protocol Lock modes: S for shared and X for exclusive access compatibility: (S, S) = T, otherwise F Behavior: lock (the maximum mode) before access release lock immediately after Unit: a relation

Simple Protocol: what’s wrong? Xact T1 Xact T2 X.lock(A’s relation) read(A) A = A + 1 write(A) X.release-lock(A’s relation) read (A) A = A * 2 write (A) X.lock(B’s relation) read(B) B = B * 2 write(B) X. release-lock(B’s relation) B = B + 1 X.release-lock(B’s relation) fail to interleave dependencies in the right order

Solution: 2 Phase Locking (2PL) Each transaction has two phases: Getting locks (growing) acquire lock of the required mode (S or X) can only lock data items during this phase. may also upgrade the locks (from S-lock to X-lock). read/ write the locked data items. no release-lock in this phase Releasing locks (shrinking) can only release locks on the data items. may also downgrade the locks (from X-lock to S-lock). the phase starts with the first release-lock. no locking after the first release-lock. Rule: Transactions do not get any new lock after giving up one.

Simple protocol versus 2PL protocol Xact T1 Xact T2 X.lock(A) read(A) A = A + 1 write(A) X.release-lock(A) read (A) A = A * 2 write (A) X.lock(B) read(B) B = B * 2 write(B) X.release-lock(B) B = B + 1 Xact T1 Xact T2 S.lock(A) read(A) A = A + 1 X.lock(A) write(A) S.lock(B) read(B) B = B + 1 X.lock(B) write(B) X.release-lock(A) X.release-lock(B) read (A) A = A * 2 write (A) B = B * 2 write(B) X. release-lock(A) X. release-lock(B) 2PL is serializable

Transaction interleaving in 2PL schedules Xact T1 Xact T2 S.lock(A) read(A) A = A + 1 X.lock(A) write(A) S.lock(B) read(B) B = B + 1 X.lock(B) X.release-lock(A) read (A) A = A * 2 write (A) write(B) X.release-lock(B) B = B * 2 X. release-lock(A) X. release-lock(B) 2PL schedules are not generally serial.

Why 2PL schedule is serializable? Locks of conflicting operations are not compatible. 2PL does not allow the swap of conflicting operations. serial order between conflicting operations all conflicting operations of T1 before T2. It is possible to swap non-conflicting operations. provides concurrency

Locking Protocol: Granularity? Unit of locking: How to increase concurrency? coarse units? fine units? Granularity: concurrency vs. overhead hierarchical lockable units: Database, relations/ files, pages, tuples, attributes Correctness problem: T1 S.locks a tuple, T2 X.locks the file? Solution: create a collision path, so that different units would collide if they should

Granularity Locking Example Transaction T1 writes on a tuple in Student => X lock on tuple Transaction T2 wants to scan the whole DB => S lock on DB, allowed?? T1 has to implicitly notify other transactions puts “intentions locks” on the tuple’s parents in the lockable units hierarchy T1: I T2: Grant S? DB T1: I Relation Student Relation Enrollment T1: X Tuple Tuple Tuple Tuple

Granularity Locking Example, contd. T1 reads some tuples from Student => S on tuple, I on its parents T2 wants to scan the whole DB => S lock on DB, allowed?? We need different types of intention locks to increase concurrency IS and IX also SIX (intension to upgrade), why is it useful? T1: IS T2: Grant S? DB T1: IS Relation Student Relation Enrollment T1: S Tuple Tuple Tuple Tuple SIX: good for complete scan + occasional update. Without SIX, have to do S then IX separately (high locking overhead), or use an X (too strong).

Lock Compatibility Table X SIX IX S IS NL privilege ordering

Compatibility Example SIX Grant S? IS? IX? DB Questions: (SIX, S) = No? (SIX, IS) = Yes? (SIX, IX) = No? SIX SIX Relation Student Relation Enrollment X X Tuple Tuple Tuple Tuple

Granularity Locking Database: as hierarchy of lockable units Locking: to lock a unit, first lock all containing units with “intension” intension locks: IS, IX, SIX (intension to upgrade) Unlocking: release all relevant locks at once, or leaf to root why this order? DAG generalization: can’t do the other way around, since X not compatible with X (and they may take different path).

Granularity Locking: DAG Generalization: DAG of units: S locks at least one path to the node X locks all paths to the node DAG generalization: can’t do the other way around, since X not compatible with X (and they may take different path). Q: Why implicit S if one parent is X (or S, SIX)? A: Since that parent is in X maybe for other nodes, and not this one; otherwise all parent will be in X, in which case this node will be implicitly in X.

How “long” to hold a lock? 2PL requirement: only “shrink” after “growing” End of transaction: unlock (to make data accessible) at xact commit called strict 2PL why?

Problem with non-strict 2PL Cascading rollback we should never have let T1 commit T1 T2 write(B) read(A) commit read(A) write(A) T2 Aborts

Additional issues Deadlock? Optimistic concurrency control Assume rare unserializable behavior Timestamping followed by validation