CS411 Database Systems Kazuhiro Minami 14: Concurrency Control.

Slides:



Advertisements
Similar presentations
1 Integrity Ioan Despi Transactions: transaction concept, transaction state implementation of atomicity and durability concurrent executions serializability,
Advertisements

TRANSACTION PROCESSING SYSTEM ROHIT KHOKHER. TRANSACTION RECOVERY TRANSACTION RECOVERY TRANSACTION STATES SERIALIZABILITY CONFLICT SERIALIZABILITY VIEW.
Transactions A process that reads or modifies the DB is called a transaction. It is a unit of execution of database operations. Basic JDBC transaction.
Recovery from Crashes. Transactions A process that reads or modifies the DB is called a transaction. It is a unit of execution of database operations.
1 Lecture 4: Transactions Wednesday, October 20, 2010 Dan Suciu -- CSEP544 Fall 2010.
Recovery from Crashes. ACID A transaction is atomic -- all or none property. If it executes partly, an invalid state is likely to result. A transaction,
ACID A transaction is atomic -- all or none property. If it executes partly, an invalid state is likely to result. A transaction, may change the DB from.
Concurrency Control 18.1: Schedules By Cancheevaram Kuppuswamy JaiSarvanan ID: 209.
1 Lecture 12: Transactions: Recovery. 2 Outline Recovery Undo Logging Redo Logging Undo/Redo Logging Book Section 15.1, 15.2, 23, 24, 25.
Quick Review of May 1 material Concurrent Execution and Serializability –inconsistent concurrent schedules –transaction conflicts serializable == conflict.
Chapter 7 Transactions 7.1 Transaction Concept 7.2 Transaction State 7.3 Implementation of Atomicity and Durability 7.4 Concurrent Executions 7.5 Serializability.
1 Concurrency Control and Recovery Module 6, Lecture 1.
Cs4432recovery1 CS4432: Database Systems II Database Consistency and Violations?
1 Transaction Management Overview Yanlei Diao UMass Amherst March 15, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
©Silberschatz, Korth and Sudarshan15.1Database System ConceptsTransactions Transaction Concept Transaction State Implementation of Atomicity and Durability.
Conflict-Serializability (section 18.2 of Concurrency Control) - Amith KC Student ID –
CONCURRENCY CONTROL 18.1 Serial and Serializable Schedule By: Nitin Mathur Id: 110 CS: 257.
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.
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)
Database Management Systems I Alex Coman, Winter 2006
1 Introduction to Transaction Processing (1)
Concurrency Control 18.1 – 18.2 Chiu Luk CS257 Database Systems Principles Spring 2009.
Transactions Amol Deshpande CMSC424. Today Project stuff… Summer Internships 
1 Recovery Control (Chapter 17) Redo Logging CS4432: Database Systems II.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 16.
1 Transaction Management Overview Chapter Transactions  Concurrent execution of user programs is essential for good DBMS performance.  Because.
Database Management Systems, 2 nd Edition. R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 18.
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.
Transaction Lectured by, Jesmin Akhter, Assistant professor, IIT, JU.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 15: Transactions.
1 Transaction Management. 2 Outline Transaction management –motivation & brief introduction –major issues recovery concurrency control Recovery.
HANDLING FAILURES. Warning This is a first draft I welcome your corrections.
Introduction to Data Management CSE 344 Lecture 23: Transactions CSE Winter
Database Systems/COMP4910/Spring05/Melikyan1 Transaction Management Overview Unit 2 Chapter 16.
©Silberschatz, Korth and Sudarshan15.1Database System Concepts Chapter 15: Transactions Transaction Concept Transaction State Implementation of Atomicity.
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.
Computing & Information Sciences Kansas State University Wednesday, 05 Nov 2008CIS 560: Database System Concepts Lecture 28 of 42 Wednesday, 05 November.
Chapter 14 Transactions Yonsei University 1 st Semester, 2015 Sanghyun Park.
15.1 Transaction Concept A transaction is a unit of program execution that accesses and possibly updates various data items. E.g. transaction to transfer.
©Silberschatz, Korth and Sudarshan14.1Database System Concepts - 6 th Edition Chapter 14: Transactions Transaction Concept Transaction State Concurrent.
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 14: Transactions.
Transaction Management and Recovery, 2 nd Edition. R. Ramakrishnan and J. Gehrke1 Transaction Management Overview Chapter 18.
1 CSE544 Transactions: Recovery Thursday, January 27, 2011 Dan Suciu , Winter 2011.
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 Lecture 28: Recovery Friday, December 5 th, 2003.
1 Lecture 15: Data Storage, Recovery Monday, February 13, 2006.
CS422 Principles of Database Systems Failure Recovery Chengyu Sun California State University, Los Angeles.
CS422 Principles of Database Systems Failure Recovery
Lecture 13: Recovery Wednesday, February 2, 2005.
Transaction Management and Concurrency
Chapter 14: Transactions
Transaction Management Overview
Database Management System
Transactions.
Transaction Management Overview
March 21st – Transactions
Transaction Management Overview
Transactions Sylvia Huang CS 157B.
Introduction to Database Systems CSE 444 Lectures 15-16: Recovery
CONCURRENCY CONTROL 18.1 Serial and Serializable Schedule
Transaction Management Overview
UNIT -IV Transaction.
Lecture 17: Data Storage and Recovery
Lecture 18: Concurrency Control
Lecture 16: Recovery Friday, November 4, 2005.
Transaction Management Overview
Presentation transcript:

CS411 Database Systems Kazuhiro Minami 14: Concurrency Control

Announcements No class next week No office hour next Friday (Nov. 26) Homework 5 due on Dec 1 Project stage 5 is due on Dec 3 Graduate project stage C is due on Dec 1

Undo/Redo Logging

Redo/undo logs save both before-images and after-images. –T has written element X; its old value was old_v, and its new value is new_v

Undo/Redo-Logging Rule UR1: If T modifies X, then must be written to disk before X is written to disk Note: we are free to OUTPUT early or late (I.e. before or after ) UndoRedoUndo/redo OUTPUT(A) OUTPUT(B) OUTPUT(A) OUTPUT(B) OUTPUT(A)

ActionTMem AMem BDisk ADisk BLog (memory)Log (disk) READ(A,t)8888 t := t* WRITE(A,t)16 88 READ(B,t) t := t* WRITE(B,t)16 88 FLUSH LOG OUTPUT(A ) 16 8 FLUSH LOG OUTPUT(B ) 16

Recovery is more complex with undo/redo logging. 1.Redo all committed transactions, starting at the beginning of the log 2.Undo all incomplete transactions, starting from the end of the log … REDOREDO UNDOUNDO

8 Algorithm for non-quiescent checkpoint for undo/redo 1.Write to log 2.Flush log to disk 3.Write to disk all dirty buffers, whether or not their transaction has committed (this implies some log records may need to be written to disk) 4.Write to log 5.Flush log to disk Flush dirty buffer pool pages … … … Active Tns Pointers are one of many tricks to speed up future undos

UNDOUNDO Algorithm for u ndo/redo recovery with nonq uiescent checkpoint 1.Backwards undo pass (end of log to start of last completed checkpoint) a.C = transactions that committed after the checkpoint started b.Undo actions of transactions that (are in A or started after the checkpoint started) and (are not in C) 2.Undo remaining actions by incomplete transactions a.Follow undo chains for transactions in (checkpoint active list) – C 3.Forward pass (start of last completed checkpoint to end of log) a.Redo actions of transactions in C Active Tns … … … REDO SREDO S

Examples what to do at recovery time? no  Undo T 1 (undo A, B, C) … T1 wrote A, … … checkpoint start (T1 active) … T1 wrote B, … … checkpoint end … T1 wrote C, … …

 Redo T1: (redo B, C) … T1 wrote A, … … checkpoint start (T1 active) … T1 wrote B, … … checkpoint end … T1 wrote C, … … T1 commit Examples what to do at recovery time?

Concurrency Control

A transaction is a sequence of operations that must be executed as a whole. Every DB action takes place inside a transaction. BUSEY SAVINGS Winslett $1000 BUSEY CHECKIN G Winslett $0 Either both (1) and (2) happen or neither! Transfer $500 1.Debit savings 2.Credit checking

We abstract away most of the application code when thinking about transactions. Read Balance1 Write Balance1 Read Balance2 Write Balance2 Transfer $500 1.Debit savings 2.Credit checking User’s point of view Code writer’s point of view Concurrency control ‘s & recovery’s point of view

Schedule: The order of execution of operations of two or more transactions. R(A) R(C) W(A) R(B) W(C) R(B) W(B) Transaction1Transaction2 Schedule S1 Time Read data item A (typically a tuple)

Why do we need transactions? R(A) W(A) Transaction 1: Add $100 to account A R(A) W(A) Time Transaction 2: Add $200 to account A

R(A) W(A) R(A) W(A) Time What will be the final account balance? Transaction 1: Add $100 to account A Transaction 2: Add $200 to account A The Lost Update Problem

R(A) W(A) F A I L R(A) W(A) Time What will be the final account balance? Transaction 1: Add $100 to account A Transaction 2: Add $200 to account A Dirty reads cause problems.

Abort or roll back are the official words for “fail”. Commit All your writes will definitely absolutely be recorded and will not be undone, and all the values you read are committed too. Abort/rollback Undo all of your writes!

The concurrent execution of transactions must be such that each transaction appears to execute in isolation.

Concurrency control is actually a scheduling problem Transaction Manager Scheduler Main Memory Buffers Reads and writes Read/Write request

Schedule Time-ordered sequence of the important actions taken by one or more transactions Consider only the READ and WRITE actions, and their orders; ignore the INPUT and OUTPUT actions –An element in a buffer is accessed by multiple transactions

Serial Schedule If any action of transaction T 1 precedes any action of T 2, then all action of T 1 precede all action of T 2 The correctness principle tells us that every serial schedule will preserve consistency of the database state Time T 1 ’s actionsT 2 ’s actions

Example 1: (T 1, T 2 ) READ(A, t) t := t WRITE(A, t) READ(B, t) t := t WRITE(B, t) READ(A, s) s := s * 2 WRITE(A, s) READ(B, s) s := s * 2 WRITE(B, s) T 1 T 2 A B

Example 2: (T 2, T 1 ) READ(A, t) t := t WRITE(A, t) READ(B, t) t := t WRITE(B, t) READ(A, s) s := s * 2 WRITE(A, s) READ(B, s) s := s * 2 WRITE(B, s) T 1 T 2 A B

Serial Schedule is Not Necessarily Desirable Improved throughput –I/O activity can be done in parallel with processing at CPU Reduced average waiting time –If transactions run serially, a short transaction may have to wait for a preceding long transaction to complete

A schedule is serializable if it is guaranteed to give the same final result as some serial schedule. Which of these are serializable? Read(A) Write(A) Read(B) Write(B) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B) Read(B) Write(B) Read(A) Write(A) Read(A) Write(A) Read(B) Write(B) Read(B) Write(B)

Notation for Transactions and Schedules We do not consider the details of local computation steps such as t := t Only the reads and writes matter Action: r i (X) or w i (X) Transaction Ti: a sequence of actions with subscript i Schedule S: a sequence of actions from a set of transactions T

Example: s := s*1 READ(A, t) t := t WRITE(A, t) READ(A, s) s := s * 1 WRITE(A, s) READ(B, s) s := s * 1 WRITE(B, s) T 1 T 2 A B READ(B, t) t := t WRITE(B, t)

Examples T1: r 1 (A); w 1 (A); r 1 (B); w 1 (B); T2: r 2 (A); w 2 (A); r 2 (B); w 2 (B); S: r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B);

Conflict-Serializability Commercial systems generally support conflict- serializability –Stronger notion than serializability Based on the idea of a conflict Turn a given schedule to a serial one by making as many nonconflicting swaps as we wish

Conflicts A pair of consecutive actions in a schedule such that, if their order is interchanged, then the behavior of at least one of the transactions involved can change

Conflicting Swaps Two actions of the same transaction - E.g., r i (X); w i (Y) Two writes of the same database element - E.g., w i (X); w j (X) A read and a write of the same database element - E.g., r i (X); w j (X)

Nonconflicting swaps Any two actions of different transactions may be swapped unless: –They involve the same database element, and –At least one is a write Examples: 1.r i (X); r j (Y) 2.r i (X); w j (Y) if X!= Y 3.w i (X); r j (Y) if X != Y 4.w i (X); w j (Y) if X != Y

Conflict-serializable Two schedules are conflict-equivalent if they can be turned one into the other by a sequence of nonconflicting swaps of adjacent actions A schedule is conflict-serializable if it is conflict- equivalent to a serial schedule Easy to check whether a schedule is conflict- serializable by examining a precedence graph

Example r 1 (A); w 1 (A); r 2 (A); w 2 (A); r 1 (B); w 1 (B); r 2 (B); w 2 (B); r 1 (A); w 1 (A); r 2 (A); r 1 (B); w 2 (A); w 1 (B); r 2 (B); w 2 (B); r 1 (A); w 1 (A); r 1 (B); r 2 (A); w 2 (A); w 1 (B); r 2 (B); w 2 (B); r 1 (A); w 1 (A); r 1 (B); r 2 (A); w 1 (B); w 2 (A); r 2 (B); w 2 (B); r 1 (A); w 1 (A); r 1 (B); w 1 (B); r 2 (A); w 2 (A); r 2 (B); w 2 (B);

Test for Conflict-Serializability Can decide whether or not a schedule S is conflict-serializable Ideas: –when there are conflicting actions that appear anywhere in S, the transactions performing those actions must appear in the same order in any conflict- equivalent serial schedule –Summarize those conflicting actions in a precedence graph

Precedence Graphs T 1 takes precedence over T 2 (T 1 < S T 2 ), if there are actions A 1 of T 1 and A 2 of T 2, s.t. –A 1 is ahead of A 2 in S –Both A 1 and A 2 involve the same database element –At least one of A 1 and A 2 is a written action Construct a precedence graph and ask if there are any cycles

Example S: r 2 (A); r 1 (B); w 2 (A); r 3 (A); w 1 (B); w 3 (A); r 2 (B); w 2 (B); 12 3 S’: r 1 (B); w 1 (B); r 2 (A); w 2 (A); r 2 (B); w 2 (B); r 3 (A); w 3 (A);

Example S 1 : r 2 (A); r 1 (B); w 2 (A); r 2 (B); r 3 (A); w 1 (B); w 3 (A); w 2 (B); 12 3