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:

Slides:



Advertisements
Similar presentations
Cs4432concurrency control1 CS4432: Database Systems II Lecture #21 Concurrency Control : Theory Professor Elke A. Rundensteiner.
Advertisements

Database Systems (資料庫系統)
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.
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.
Concurrency Control II
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.
Lecture 11 Recoverability. 2 Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine.
CS4432: Database Systems II Lecture #26 Concurrency Control and Recovery Professor Elke A. Rundensteiner.
Jinze Liu. Have studied C.C. mechanisms used in practice - 2 PL - Multiple granularity - Tree (index) protocols - Validation.
Quick Review of Apr 29 material
Conflict-Serializability Bharath Kumar Manur Venkataramana Class ID No:- 110.
Concurrent Transactions Even when there is no “failure,” several transactions can interact to turn a consistent state into an inconsistent state.
ICS 421 Spring 2010 Transactions & Concurrency Control (i) Asst. Prof. Lipyeow Lim Information & Computer Science Department University of Hawaii at Manoa.
Concurrency Control and Recovery In real life: users access the database concurrently, and systems crash. Concurrent access to the database also improves.
Concurrency Control R&G - Chapter 17 Smile, it is the key that fits the lock of everybody's heart. Anthony J. D'Angelo, The College Blue Book.
Transactions Controlling Concurrent Behavior. Busy, busy, busy... In production environments, it is unlikely that we can limit our system to just one.
1 Concurrency Control and Recovery Module 6, Lecture 1.
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,
Database Management Systems I Alex Coman, Winter 2006
Concurrency Control 18.1 – 18.2 Chiu Luk CS257 Database Systems Principles Spring 2009.
CS4432transaction management1 CS4432: Database Systems II Lecture #23 Transaction Management Professor Elke A. Rundensteiner.
Transactions Controlling Concurrent Behavior. Why Transactions? Database systems are normally being accessed by many users or processes at the same time.
Cs4432concurrency control1 CS4432: Database Systems II Concurrency Control.
Concurrency Control. General Overview Relational model - SQL  Formal & commercial query languages Functional Dependencies Normalization Transaction Processing.
CS4432: Database Systems II Transaction Management Motivation 1.
1 IT420: Database Management and Organization Transactions 31 March 2006 Adina Crăiniceanu
Chapter 181 Chapter 18: Concurrency Control (Slides by Hector Garcia-Molina,
1 Transaction Management Overview Chapter Transactions  A transaction is the DBMS’s abstract view of a user program: a sequence of reads and writes.
08_Transactions_LECTURE2 DBMSs should guarantee ACID properties (Atomicity, Consistency, Isolation, Durability). This is typically done by guaranteeing.
Transactions Sylvia Huang CS 157B. Transaction A transaction is a unit of program execution that accesses and possibly updates various data items. A transaction.
TRANSACTIONS. Objectives Transaction Concept Transaction State Concurrent Executions Serializability Recoverability Implementation of Isolation Transaction.
Introduction to Data Management CSE 344 Lecture 23: Transactions CSE Winter
CS 405G: Introduction to Database Systems 20. Concurrent control, Storage.
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.
SCUJoAnne Holliday11–1 Schedule Today: u Transaction concepts. u Read Sections Next u Authorization and security.
 Concurrent execution of user programs is essential for good DBMS performance. Disk accesses are frequent, and relatively slow. Want to keep the CPU working.
TRANSACTION MANAGEMENT R.SARAVANAKUAMR. S.NAVEEN..
1 Concurrency Control II: Locking and Isolation Levels.
©Silberschatz, Korth and Sudarshan15.1Database System Concepts Chapter 15: Transactions Transaction Concept Transaction State Implementation of Atomicity.
Transactions. What is it? Transaction - a logical unit of database processing Motivation - want consistent change of state in data Transactions developed.
1 CS542 Concurrency Control: Theory and Protocol Professor Elke A. Rundensteiner.
1 Concurrency Control Lecture 22 Ramakrishnan - Chapter 19.
1 Concurrency control lock-base protocols timestamp-based protocols validation-based protocols Ioan Despi.
1 CSE 480: Database Systems Lecture 24: Concurrency Control.
1 Database Systems ( 資料庫系統 ) December 27, 2004 Chapter 17 By Hao-hua Chu ( 朱浩華 )
Transaction Management
Concurrency Control.
Transaction Management
Transactions.
March 21st – Transactions
Transactions B.Ramamurthy Ch.13 11/22/2018 B.Ramamurthy.
Transaction Management
March 9th – Transactions
Lecture 21: Concurrency & Locking
CS162 Operating Systems and Systems Programming Review (II)
6.830 Lecture 12 Transactions: Isolation
Lecture 22: Intro to Transactions & Logging IV
Transaction Management
CPSC-608 Database Systems
Database Systems (資料庫系統)
Lecture 18: Concurrency Control
Database Systems (資料庫系統)
Presentation transcript:

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: TX’s must behave as if they are executed in isolation Durability: Effects of committed TX’s are resilient against failures SQL transactions -- Begins implicitly SELECT …; UPDATE …; ROLLBACK | COMMIT;  3/9/2016

Goal: ensure the “I” (isolation) in ACID 33 A B C T 1 : read( A ); write( A ); read( B ); write( B ); commit; T 2 : read( A ); write( A ); read( C ); write( C ); commit;

44 T 1 T 2 r( A ) w( A ) r( B ) w( B ) r( A ) w( A ) r( C ) w( C ) T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) r( C ) w( B ) w( C ) T 1 T 2 r( A ) r( A ) w( A ) w( A ) r( B ) r( C ) w( B ) w( C ) Good! Good! (But why?)Bad! Read 400 Write 400 – 100 Write 400 – 50

Execute transactions in order, with no interleaving of operations T 1.r(A), T 1.w(A), T 1.r(B), T 1.w(B), T 2.r(A), T 2.w(A), T 2.r(C), T 2.w(C) T 2.r(A), T 2.w(A), T 2.r(C), T 2.w(C), T 1.r(A), T 1.w(A), T 1.r(B), T 1.w(B)  Isolation achieved by definition! Problem: no concurrency at all Question: how to reorder operations to allow more concurrency 55

Two operations on the same data item conflict if at least one of the operations is a write r(X) and w(X) conflict w(X) and r(X) conflict w(X) and w(X) conflict r(X) and r(X) do not r/w(X) and r/w(Y) do not Order of conflicting operations matters E.g., if T 1.r(A) precedes T 2.w(A), then conceptually, T 1 should precede T 2 66

A node for each transaction A directed edge from T i to T j if an operation of T i precedes and conflicts with an operation of T j in the schedule 77 T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) r( C ) w( B ) w( C ) T 1 T 2 r( A ) r( A ) w( A ) w( A ) r( B ) r( C ) w( B ) w( C ) T1T1 T2T2 Good: no cycle T1T1 T2T2 Bad: cycle

A schedule is conflict-serializable iff its precedence graph has no cycles A conflict-serializable schedule is equivalent to some serial schedule (and therefore is “good”) In that serial schedule, transactions are executed in the topological order of the precedence graph You can get to that serial schedule by repeatedly swapping adjacent, non-conflicting operations from different transactions 88

Rules If a transaction wants to read an object, it must first request a shared lock (S mode) on that object If a transaction wants to modify an object, it must first request an exclusive lock (X mode) on that object Allow one exclusive lock, or multiple shared locks 99 Mode of lock(s) currently held by other transactions Mode of the lock requested Grant the lock? Compatibility matrix

 10 T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) w( B ) r( B ) w( B ) lock-X( A ) lock-X( B ) unlock( B ) unlock( A ) lock-X( A ) unlock( A ) unlock( B ) lock-X( B ) Possible schedule under locking But still not conflict-serializable! T1T1 T2T2 Read 100 Write Read 101 Write 101*2 Read 100 Write 100*2 Read 200 Write Add 1 to both A and B (preserve A = B ) Multiply both A and B by 2 (preserves A = B ) A  B!A  B!

All lock requests precede all unlock requests Phase 1: obtain locks, phase 2: release locks  11 T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) w( B ) r( B ) w( B ) lock-X( A ) lock-X( B ) unlock( B ) unlock( A ) lock-X( A ) lock-X( B ) Cannot obtain the lock on B until T 1 unlocks T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) w( B ) r( B ) w( B ) 2PL guarantees a conflict-serializable schedule

T 2 has read uncommitted data written by T 1 If T 1 aborts, then T 2 must abort as well Cascading aborts possible if other transactions have read data written by T 2  12  Even worse, what if T 2 commits before T 1 ?  Schedule is not recoverable if the system crashes right after T 2 commits T 1 T 2 r( A ) w( A ) r( A ) w( A ) r( B ) w( B ) r( B ) w( B ) Abort!

Only release locks at commit/abort time A writer will block all other readers until the writer commits or aborts  Used in most commercial DBMS (except Oracle)  13

S 1, S 2 are conflict equivalent schedules if S 1 can be transformed into S 2 by a series of swaps on non-conflicting actions.

A schedule is conflict serializable if it is conflict equivalent to some serial schedule.

Nodes: transactions in S Arcs: T i -> T j whenever - p i (A), q j (A) are actions in S - p i (A) < S q j (A) - at least one of p i, q j is a write

What is P(S) for S = w 3 (A) w 2 (C) r 1 (A) w 1 (B) r 1 (C) w 2 (A) r 4 (A) w 4 (D) Is S serializable?

What is P(S) for S = w 1 (A) r 2 (A) r 3 (A) w 4 (A) ?

S 1, S 2 conflict equivalent  P(S 1 )=P(S 2 ) Proof: Assume P(S 1 )  P(S 2 )   T i : T i  T j in S 1 and not in S 2  S 1 = …p i (A)... q j (A)… p i, q j S 2 = …q j (A)…p i (A)... conflict  S 1, S 2 not conflict equivalent

Note: P(S 1 )=P(S 2 )  S 1, S 2 conflict equivalent Counter example: S 1 =w 1 (A) r 2 (A) w 2 (B) r 1 (B) S 2 =r 2 (A) w 1 (A) r 1 (B) w 2 (B)

P(S 1 ) acyclic  S 1 conflict serializable (  ) Assume S 1 is conflict serializable   S s : S s, S 1 conflict equivalent  P(S s ) = P(S 1 )  P(S 1 ) acyclic since P(S s ) is acyclic

(  ) Assume P(S 1 ) is acyclic Transform S 1 as follows: (1) Take T 1 to be transaction with no incident arcs (2) Move all T 1 actions to the front S 1 = ……. q j (A)……. p 1 (A)….. (3) we now have S 1 = (4) repeat above steps to serialize rest! T1 T2 T3 T4 P(S 1 ) acyclic  S 1 conflict serializable

Option 1: run system, recording P(S); at end of day, check for P(S) cycles and declare if execution was good