Enforcing Serializability by Locks

Slides:



Advertisements
Similar presentations
Optimistic Methods for Concurrency Control By : H.T. Kung & John T. Robinson Presenters: Munawer Saeed.
Advertisements

1 Shivnath Babu Concurrency Control (II) CS216: Data-Intensive Computing Systems.
Cs4432concurrency control1 CS4432: Database Systems II Lecture #21 Concurrency Control : Theory Professor Elke A. Rundensteiner.
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.
Conflict Serializability Example Murat Kantarcioglu.
1 Concurrency Control Chapter Conflict Serializable Schedules  Two actions are in conflict if  they operate on the same DB item,  they belong.
Concurrency II. Shared/Exclusive Locks Problem: while simple locks + 2PL guarantee conflict­serializability, they do not allow two readers of DB element.
TRANSACTION PROCESSING SYSTEM ROHIT KHOKHER. TRANSACTION RECOVERY TRANSACTION RECOVERY TRANSACTION STATES SERIALIZABILITY CONFLICT SERIALIZABILITY VIEW.
Cs4432concurrency control1 CS4432: Database Systems II Lecture #22 Concurrency Control Professor Elke A. Rundensteiner.
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.
Concurrency Control Enforcing Serializability by Locks
Cs4432concurrency control1 CS4432: Database Systems II Lecture #22 Concurrency Control: Locking-based Protocols Professor Elke A. Rundensteiner.
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.
Kyoung-Hwan Yun (#110). Conflicts Precedence Graphs and a Test for Conflict- Serializability.
Quick Review of Apr 29 material
Conflict-Serializability Bharath Kumar Manur Venkataramana Class ID No:- 110.
Prepared by: Mudra Patel (113) Locking Scheduler & Managing Hierarchies of Database Elements.
Concurrent Transactions Even when there is no “failure,” several transactions can interact to turn a consistent state into an inconsistent state.
Enforcing Serializability By LOCKS
Concurrency Control A.Sri Harsha Enforcing Serializability of Locks.
CONCURRENCY CONTROL SECTION 18.7 THE TREE PROTOCOL By : Saloni Tamotia (215)
Concurrency. Busy, busy, busy... In production environments, it is unlikely that we can limit our system to just one user at a time. – Consequently, it.
Transaction Processing: Concurrency and Serializability 10/4/05.
Transaction Management
Transactions or Concurrency Control. Introduction A program which operates on a DB performs 2 kinds of operations: –Access to the Database (Read/Write)
Transactions. Definitions Transaction (program): A series of Read/Write operations on items in a Database. Example: Transaction 1 Read(C) Read(A) Write(A)
Concurrency. Correctness Principle A transaction is atomic -- all or none property. If it executes partly, an invalid state is likely to result. A transaction,
Presentation Topic 18.7 of Book Tree Protocol Submitted to: Prof. Dr. T.Y.LIN Submitted By :Saurabh Vishal.
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.
Chapter 18.5 An Architecture For A Locking Scheduler Steve Ikeoka ID: 113 CS 257 – Spring 2008.
Concurrency control In production environments, it is unlikely that we can limit our system to just one user at a time. – Consequently, it is possible.
Module Coordinator Tan Szu Tak School of Information and Communication Technology, Politeknik Brunei Semester
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:
1 Concurrency Control By Ankit Patel. 2 INTRODUCTION Enforcing serializability by locks Locks Locking scheduler Two phase locking Locking systems with.
Transaction Management and Concurrency Control
1 Introduction to Transaction Processing (1)
CS216: Data-Intensive Computing Systems
CS 257: Principles of Database System
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
18.5 An Architecture for a Locking Scheduler
Transaction Properties
Outline Introduction Background Distributed DBMS Architecture
By Donavon Norwood Ankit Patel 112 Aniket Mulye 111
18.5 An Architecture for Locking Scheduler
Concurrency Control via Timestamps
March 9th – Transactions
Concurrency.
Chapter 10 Transaction Management and Concurrency Control
Section 18.8 : Concurrency Control – Timestamps -CS 257, Rahul Dalal - SJSUID: Edited by: Sri Alluri (313)
Locks and Locking Mode ( )
Lecture 21: Concurrency & Locking
Conflict-Serializability (section 18.2 of Concurrency Control)
6.830 Lecture 12 Transactions: Isolation
Conflicts.
ENFORCING SERIALIZABILITY BY LOCKS
Lecture 22: Intro to Transactions & Logging IV
Transaction management
CPSC-608 Database Systems
SQL – Shared and Exclusive Locks
Transaction Management
CPSC-608 Database Systems
Introduction to Database Systems CSE 444 Lectures 17-18: Concurrency Control November 5-7, 2007.
Locks.
Database Systems (資料庫系統)
Lecture 18: Concurrency Control
Database Systems (資料庫系統)
Presentation transcript:

Enforcing Serializability by Locks Database Systems Ch. 18.3 Michael Symonds

First, Recall… The responsibility of the scheduler is to take requests from transactions and either: Allow them to operate on the database or Block the transaction until such time as it is safe to allow the transaction to execute.

? Locks - How Do They Work? A request is sent from a transaction The Scheduler now consults the lock table to guide it decision Generates a serializable schedule of actions ?

A locking scheduler enforces Conflict-Serializability, (which is a more stringent condition than correctness or even serializability.) But the use of locks must be proper in 2 senses: Consistency of Transactions Legality of Schedules

Consistency of Transactions Transactions can only read or write an element if has been granted a lock and has not yet released the lock. If a transaction locks an element, it must later unlock that element.

In other words… “Whenever transaction Ti has an action ri(X) or wi(X), then there is a previous action, li(X) with no intervening action ui(X), and there is a subsequent ui(X).”

Legality of schedules No two transactions may have locked the same element without one having first released the lock. In other words “If there is an action li(X) followed by lj(X) in a schedule, then somewhere between those actions there must be an action ui(X)”

How these concepts work together:

Locks(element, transaction) or (X,T) Locking Scheduler Grant requests if and only if the request results in a legal schedule Scheduler consults the lock table which tells, for each database element, whether a transactions holds a lock for that element The locking table, when there is only one kind of lock, is a table of relations: Locks(element, transaction) or (X,T)

Two-Phase Locking (2PL) In every transaction, ALL lock actions precede ALL unlock actions Two-Phase Locking is a condition, like consistency, on the order of actions in a transaction A transaction that obeys the 2PL condition is said to be a two-phase-locked transaction or 2PL transaction

Same transactions, one minor difference…

Conflict-Serializability The locking scheduler now enforces Conflict-Serializability

Why does Two-Phase Locking work? Each 2PL transaction may be thought to execute in its entirety at the instant it issues its first unlock request. So there is always at least one conflict-equivalent serial schedule for any schedule of 2PL transactions: the one in which the transactions appear in the same order as their first unlocks.

Proof: Converting any legal schedule S of consistent, two-phase locking transactions to a conflict-equivalent serial schedule: N = the number of transactions in our schedule, S Basis: n = 1, nothing to do, it’s already a serial schedule Otherwise, S involves transactions T1, T2, …, Tn. Ti is the transaction with the first unlock action in the entire schedule of S We’ll call that action Ui(X) Claim: it’s possible to move all read and write actions forward to the beginning of the schedule without passing any conflicting reads or writes.

Consider some action of Ti, say Wi(Y). Keep in mind: The issue of conflict-equivalence refers to the read and write actions only. As we swap read and/or write actions, lock and unlock actions are ignored. Once all the read and write actions have been ordered serially, the lock and unlock actions are placed around them as the various transactions require. Consider some action of Ti, say Wi(Y). Could it be preceded in S by some conflicting action, say Wj(Y)? If so, then in schedule S, the actions Uj(Y) and Li(Y) must intervene: …; Wj(Y); …; Uj(Y); …; Li(Y);…; Wi(Y); … But since we said Ti is the first to unlock, then Ui(X) must be shown to precede Uj(Y) in S, so S must look like: …; Wj(Y); …; Ui(X); …; Uj(Y); …; Li(Y); ..; Wi(Y); …

Ui(X) now appears before Li(Y), which violates the condition of Two-Phase Locking, therefore Ti is NOT a 2PL Transaction – a contradiction! Therefore this argument of the non-existence of pairs of conflicting actions allows us to conclude that it is indeed possible to move all actions of Ti forward to the beginning of S, using non-conflicting swaps, followed by the restoration of the lock and unlock actions of Ti. Furthermore, this proof extends to every subsequent Transaction in S, allowing us to convert all of S to be shown as conflict-serializable.

A Risk of Deadlock