Basic Two Phase Locking Protocol

Slides:



Advertisements
Similar presentations
Concurrency Control III. General Overview Relational model - SQL Formal & commercial query languages Functional Dependencies Normalization Physical Design.
Advertisements

Optimistic Methods for Concurrency Control By : H.T. Kung & John T. Robinson Presenters: Munawer Saeed.
1 Concurrency Control III Dead Lock Time Stamp Ordering Validation Scheme.
Database Systems (資料庫系統)
Unit 9 Concurrency Control. 9-2 Wei-Pang Yang, Information Management, NDHU Content  9.1 Introduction  9.2 Locking Technique  9.3 Optimistic Concurrency.
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.
Concurrency Control II
1 ICS 214B: Transaction Processing and Distributed Data Management Lecture 2: Enforcing Serializable Schedules Professor Chen Li.
Cs4432concurrency control1 CS4432: Database Systems II Lecture #23 Concurrency Control Professor Elke A. Rundensteiner.
Cs4432concurrency control1 CS4432: Database Systems II Lecture #22 Concurrency Control: Locking-based Protocols Professor Elke A. Rundensteiner.
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
Lecture 12 Transactions: Isolation. Transactions What’s hard? – ACID – Concurrency control – Recovery.
Lecture 11 Recoverability. 2 Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine.
1 ICS 214B: Transaction Processing and Distributed Data Management Lecture 6: Cascading Rollbacks, Deadlocks, and Long Transactions Professor Chen Li.
Quick Review of Apr 29 material
©Silberschatz, Korth and Sudarshan16.1Database System Concepts 3 rd Edition Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols.
©Silberschatz, Korth and Sudarshan16.1Database System Concepts 3 rd Edition Chapter 16: Concurrency Control Lock-Based Protocols Timestamp-Based Protocols.
Transaction Processing: Concurrency and Serializability 10/4/05.
Transaction Management
Concurrency Control John Ortiz.
CS4432transaction management1 CS4432: Database Systems II Lecture #23 Transaction Management Professor Elke A. Rundensteiner.
1 Concurrency Control. 2 Transactions A transaction is a list of actions. The actions are reads (written R T (O)) and writes (written W T (O)) of database.
1 Concurrency Control. 2 Transactions A transaction is a list of actions. The actions are reads (written R T (O)) and writes (written W T (O)) of database.
Concurrency Control In Dynamic Database Systems Laurel Jones.
Concurrency Control in Distributed Databases. By :- Rishikesh Mandvikar rmandvik[at]engr.smu.edu May 1, 2004.
Optimistic Concurrency Control Lecture Phase Locking Recap Phases – Growth – acquire all locks – Shrinking – release locks as done Strict 2PL –
Concurrency Control Lectured by, Jesmin Akhter, Assistant professor, IIT, JU.
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.
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.
TRANSACTION MANAGEMENT R.SARAVANAKUAMR. S.NAVEEN..
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.
1 CSE232A: Database System Principles More Concurrency Control and Transaction Processing.
6.830 Lecture 14 Two-phase Locking Recap Optimistic Concurrency Control 10/28/2015.
Em Spatiotemporal Database Laboratory Pusan National University File Processing : Concurrency Control 2004, Spring Pusan National University Ki-Joune Li.
Database Isolation Levels. Reading Database Isolation Levels, lecture notes by Dr. A. Fekete, resentation/AustralianComputer.
Distributed Transactions What is a transaction? (A sequence of server operations that must be carried out atomically ) ACID properties - what are these.
Transaction Management
CS422 Principles of Database Systems Concurrency Control
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
Concurrency Control via Validation
Database Concurrency Control
Chapter 16: Concurrency Control
4. Concurrency control techniques
בקרת בו זמניות (concurrency control)
CIS 720 Concurrency Control.
Concurrency Control via Timestamps
Distributed Transactions
Concurrency Control II (OCC, MVCC)
Database System Implementation CSE 507
Database Transactions
6.830 Lecture 12 Transactions: Isolation
6.830 Lecture 14 Two-phase Locking Recap Optimistic Concurrency Control 10/28/2015.
Chapter 15 : Concurrency Control
Distributed Database Management Systems
Distributed Transactions
Atomic Commit and Concurrency Control
Transaction management
Submitted to Dr. Badie Sartawi Submitted by Nizar Handal Course
Concurrency control (OCC and MVCC)
Database Systems (資料庫系統)
Lecture 18: Concurrency Control
Database Systems (資料庫系統)
Presentation transcript:

6.830 Lecture 13 Two-phase Locking Recap Optimistic Concurrency Control

Basic Two Phase Locking Protocol Before every read, acquire a shared lock Before every write, acquire an exclusive lock (or "upgrade") a shared to an exclusive lock Only release locks after all locks have been acquired Lock point = point when all locks are acquired Transaction can run to completion Will be serialized after any conflicting transactions that already completed, and before any other conflict transaction

Example ( 2 x RX WX RY WY ) T1 T2

Example ( 2 x RX WX RY WY ) T1 T2 Slock X

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X Xlock X

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X Xlock X Write X

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X Xlock X Write X Release X? If T1 releases X at this point, T2 could update X and Y before T1, resulting in a non-serial schedule.

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X Xlock X Write X Release X? Xlock Y

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X Xlock X Write X Release X? Xlock Y Release X

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X Xlock X Write X Release X? Xlock Y Release X

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X Xlock X Write X Release X? Xlock Y Release X Acq Y?

Example ( 2 x RX WX RY WY ) T1 T2 Slock X Read X Xlock X Write X Release X? Xlock Y Release X Acq Y? (Waits for T1)

Two Problems Cascading Aborts & Unrecoverability Deadlocks

Rigorous Two Phase Locking Protocol Before every read, acquire a shared lock Before every write, acquire an exclusive lock (or "upgrade") a shared to an exclusive lock Release locks only after the transaction commits Ensures recoverability/cascadeless, and that commit order = serialization order

Deadlock Detection & Prevention Detection techniques Look for a cycle in waits-for graph Or use a timeout Once a deadlock is found, kill one of the deadlock transactions Release its locks and “roll back” Why is deadlock avoidance not possible?

Why Does 2PC Work? If T1 never waits for a lock from T2, then either T2 acquired and released all its locks before T1 tried to acquire any conflicting locks, or T1 doesn’t conflict with T2 If T1 waits to get a lock from T2, then either: T2 will acquire all of the conflicting locks before T1, in which case the equivalent serial order will be T2-T1 or T1 and T2 will deadlock, in which case one will abort Proof by contradiction. Suppose T1 could have acquired a conflicting lock before T2, in addition to T2 waiting for T1. Two cases: 1) T1 is still holding that lock, in which case T1 and T2 will deadlock Or 2) T1 must have released that lock already. But that’s not possibly by the definition of 2PC, since T1 can’t release a lock until it has acquired all the locks it needs.

OCC Write twrite(object,value): if n not in write_set: // never written, make copy m = read(object) copies[object] = m write_set = write_set U {object} write(copies[object], value)

OCC Read tread(object): read_set = read_set U {object}; if object in write_set: return read(copies[object]); else: return read(object);

Validation Rules When Tj completes its read phase, require that for all Ti < Tj, one of the following conditions must be true for validation to succeed (Tj to commit): Ti completes its write phase before Tj starts its read phase W(Ti) does not intersect R(Tj), and Ti completes its write phase before Tj starts its write phase. W(Ti) does not intersect R(Tj) or W(Tj), and Ti completes its read phase before Tj completes its read phase. W(Ti) does not intersect R(Tj) or W(Tj), and W(Tj) does not intersect R(Ti) [no conflicts] These rules will ensure serializability, with Tj being ordered after Ti with respect to conflicts

Condition 1 Ti completes its write phase before Tj starts its read phase Read Validate Write Ti Read Validate Write Tj Time Don't overlap at all.

W(Ti) intersects W(Tj), i.e., Tj wrote something Ti wrote, or R(Ti) intersects W(Tj), i.e., Ti read something Tj wrote Condition 2 W(Ti) does not intersect R(Tj), and Ti completes its write phase before Tj starts its write phase. W(Ti) ∩ R(Tj) = { } R(Ti) ∩ W(Tj) ≠ { } W(Ti) ∩ W(Tj) ≠ { } Read Validate Write Ti Read Validate Write Tj Time Tj doesn’t read anything Ti wrote. Anything Tj wrote that Ti also wrote will be installed afterwards. Anything Ti read will not reflect Tjs writes

Condition 3 R(Ti) intersects W(Tj), i.e., Ti read something Tj wrote W(Ti) does not intersect R(Tj) or W(Tj), and Ti completes its read phase before Tj completes its read phase. W(Ti) ∩ R(Tj) = { } R(Ti) ∩ W(Tj) ≠ { } W(Ti) ∩ W(Tj) = { } Read Validate Write Ti Read Validate Write Tj Time Tj doesn’t read or write anything Ti wrote (but Ti may read something Tj writes). Ti definitely won’t see any of Tj’s writes, because it finishes reading before Tj starts validation, so Ti ordered before Tj. Ti will always complete its read phase before Tj b/c timestamps assigned after read phase