Chapter 16 Concurrency Control CS157b Tom Mensch.

Slides:



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

CM20145 Concurrency Control
Concurrency Control III. General Overview Relational model - SQL Formal & commercial query languages Functional Dependencies Normalization Physical Design.
Database Systems Lecture 16 Natasha Alechina
1 Concurrency Control III Dead Lock Time Stamp Ordering Validation Scheme.
1 Shivnath Babu Concurrency Control (II) CS216: Data-Intensive Computing Systems.
Database Systems (資料庫系統)
Concurrency Control WXES 2103 Database. Content Concurrency Problems Concurrency Control Concurrency Control Approaches.
Accessing data Transactions. Agenda Questions from last class? Transactions concurrency Locking rollback.
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 2: Enforcing Serializable Schedules Professor Chen Li.
Concurrency Control Enforcing Serializability by Locks
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.
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.
CSC271 Database Systems Lecture # 32.
Lecture 11 Recoverability. 2 Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine.
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.
Transaction Management and Concurrency Control
Concurrency Control By Donavon Norwood Ankit Patel Aniket Mulye 1.
©Silberschatz, Korth and Sudarshan16.1Database System Concepts 3 rd Edition Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols.
Session - 13 CONCURRENCY CONTROL CONCURRENCY TECHNIQUE Matakuliah: M0184 / Pengolahan Data Distribusi Tahun: 2005 Versi:
1 Concurrency Control: 18.4 Locking Systems with Several Lock Modes CS257 Spring/2009 Professor: Tsau Lin Student: Suntorn Sae-Eung ID: 212.
Concurrency Control: 18.4 Locking Systems with Several Lock Modes CS257 Spring/2009 Professor: Tsau Lin Student: Suntorn Sae-Eung ID:
Transaction Management
Chapter 18 Concurrency control Section 18.4 CS 257 Dr. T.Y.Lin Abhishek Pandya ID
©Silberschatz, Korth and Sudarshan16.1Database System Concepts 3 rd Edition Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols.
Concurrency Control Chapter 18 Section 18.5 Presented by Khadke, Suvarna CS 257 (Section II) Id
© 1997 UW CSE 11/13/97N-1 Concurrency Control Chapter 18.1, 18.2, 18.5, 18.7.
Concurrency Control.
08_Transactions_LECTURE2 DBMSs should guarantee ACID properties (Atomicity, Consistency, Isolation, Durability). This is typically done by guaranteeing.
Databases Illuminated
Chapter 11 Concurrency Control. Lock-Based Protocols  A lock is a mechanism to control concurrent access to a data item  Data items can be locked in.
Transactions CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)
Concurrency Control Techniques Chapter 18
Concurrency control. Lock-based protocols One way to ensure serializability is to require the data items be accessed in a mutually exclusive manner One.
Chapter 15 Concurrency Control Yonsei University 1 st Semester, 2015 Sanghyun Park.
Concurrency Server accesses data on behalf of client – series of operations is a transaction – transactions are atomic Several clients may invoke transactions.
Concurrency Control Concurrency Control By Dr.S.Sridhar, Ph.D.(JNUD), RACI(Paris, NICE), RMR(USA), RZFM(Germany) DIRECTOR ARUNAI ENGINEERING COLLEGE TIRUVANNAMALAI.
Concurrency Control in Database Operating Systems.
Transactions and Concurrency Control. Concurrent Accesses to an Object Multiple threads Atomic operations Thread communication Fairness.
7c.1 Silberschatz, Galvin and Gagne ©2003 Operating System Concepts with Java Module 7c: Atomicity Atomic Transactions Log-based Recovery Checkpoints Concurrent.
Page 1 Concurrency Control Paul Krzyzanowski Distributed Systems Except as otherwise noted, the content of this presentation.
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.
©Bob Godfrey, 2002, 2005 Lecture 17: Transaction Integrity and Concurrency BSA206 Database Management Systems.
3 Database Systems: Design, Implementation, and Management CHAPTER 9 Transaction Management and Concurrency Control.
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 15 : Concurrency.
1 Concurrency Control By Ankit Patel. 2 INTRODUCTION Enforcing serializability by locks Locks Locking scheduler Two phase locking Locking systems with.
Concurrency control.
Transaction Management
Lecture 3 Concurrency control techniques
Concurrency Control Techniques
Concurrency Control.
Multiple Granularity Granularity is the size of data item  allowed to lock. Multiple Granularity is the hierarchically breaking up the database into portions.
Part- A Transaction Management
Advanced Operating Systems - Fall 2009 Lecture 8 – Wednesday February 4, 2009 Dan C. Marinescu Office: HEC 439 B. Office hours: M,
Chapter 16: Concurrency Control
CONCURRENCY CONTROL (CHAPTER 16)
Chapter 10 Transaction Management and Concurrency Control
Concurrency Control WXES 2103 Database.
Database Transactions
Chapter 15 : Concurrency Control
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.
Presentation transcript:

Chapter 16 Concurrency Control CS157b Tom Mensch

Motivation: Bank Example zOne bank account with $100 balance zTwo different ATMs both trying to withdraw $100 from the same account at exactly the same time zBoth ATMs check the balance of the account and see it’s $100

Bank Example Continued zSince the balance is enough, both ATMs give out $100 zAfter both transactions complete the balance is -$100 zOne of the transactions should have been denied

Concurrent Transactions zProblem: How can data be accessed by multiple transactions without compromising data integrity? zSolution: Only allow a transaction to access data if it holds a “lock” on it.

Transactions with Locking zBoth ATMs try to “lock” the account zOne succeeds and withdraws $100 zThe second ATM has to wait until the first ATM releases it’s lock before it can proceed z Now when the second ATM tries to withdraw the $100 it cannot because the balance is $0

Locks zShared - transaction wants read access to data. zExclusive - transaction wants both read and write access to data.

shared-mode lock zMultiple transactions can have shared- mode locks on the same data. zEx: Transaction T1 has shared-mode lock on data A. Transaction T2 requests a shared-mode lock on data A; the request is granted.

exclusive-mode lock zOnly one transaction can have an exclusive-mode lock on a data item. zEx: Transaction T1 has exclusive-mode lock on data A. Transaction T2 requests a exclusive-mode lock on data A; the request is denied.

Lock-compatibility zShared - other shared-mode lock requests granted. zExclusive - all other lock requests denied.

Unlocking data zTransaction must unlock data when done accessing it. zShared-mode locks wait for exclusive- mode locks to be released zExclusive-mode locks wait for all other locks be be released

Indefinite postponement? zCan an exclusive-mode lock be indefinitely postponed (starved) by an infinite number of shared-mode lock requests? zNo. Because the concurrency-control manager will make shared-mode requests wait if an exclusive-mode is already waiting for a shared-mode lock to be released.

Balance Transfer Example zBank account A has a $100 balance zBank account B has a $200 balance zTransaction T1 transfers $50 from account B to account A zT1 locks A, withdraws $50 and unlocks A zT1 then locks B, adds $50 and unlocks B

Bank Transfer Continued zTransaction T2 wants to find out the sum of the balances of accounts A and B zT2 asks for a lock on both accounts after T1 has released it’s lock on A but before T1 locks B zT1 must now wait for T2 to complete before adding the $50 to account A

Bank Transfer Continued zThe result of T2 is $250 which is incorrect zWhy? zT1 should have held it’s lock on A longer

Deadlocks zT1 requests exclusive lock on A. Granted zT2 requests exclusive lock on B. Granted zT1 requests exclusive lock on B. Wait zT2 requests exclusive lock on A. Wait

Deadlocks Continued zT2 will never release it’s lock on B until it gets a lock on A zT1 will never release it’s lock on A until it gets a lock on B zBoth transactions will wait forever zThis is bad

Two-Phase Locking Protocol z1. Growing phase - transactions may acquire new locks z2. Shrinking phase - transactions may release locks, but not acquire new ones

Two-Phase Locking Continued zStrict two-phase locking protocol - requires that all exclusive locks be held until the transaction commits zRigorous two-phase locking protocol - requires that all locks be held until the transaction commits

Timestamp-Based protocols zEach transaction gets a timestamp when it enters the system zTimestamp can be either the system time, or simply a logical counter zW-timestamp(Q) - largest timestamp of any transaction that did write(Q) successfully zR-timestamp(Q) - largest timestamp of any transaction that did read(Q) successfully

Timestamp-Ordering zTransaction Ti with timestamp TS(Ti) issues read(Q) zTS(Ti) < W-timestamp(Q) then read(Q) is rejected and Ti is rolled back zTS(Ti) >= W-timestamp(Q) then read(Q) executes successfully

Timestamp-Ordering Cont. zTransaction Ti with timestamp TS(Ti) issues write(Q) zTS(Ti) < R-timestamp(Q) then write(Q) is rejected and Ti is rolled back zTS(Ti) < W-timestamp(Q) then write(Q) is rejected and Ti is rolled back zOtherwise write(Q) executes successfully

Thomas’ Write Rule zTransaction Ti with timestamp TS(Ti) issues write(Q) zTS(Ti) < R-timestamp(Q) then write(Q) is rejected and Ti is rolled back zTS(Ti) < W-timestamp(Q) then write(Q) is ignored and Ti continues zOtherwise write(Q) executes successfully

Validation-Based Protocols zConcurrency-control schemes impose additional overhead on system and can cause delays zSolution: find conflicts before they happen

Three-phase execution zRead phase - transaction reads data zValidation phase - transaction makes sure none of it’s writes to it’s temporary variables conflict with other operations zWrite phase - apply actual changes to database

Validation timestamps zValidation requires three timestamps zStart - time the transaction began executing zValidation - time the Read phase competed and Validation phase began zFinish - time the transaction completed