chaps19&20-1 cse 4701 chapters 21 & 22 6e -19 & 20 5e: trans processing &...

Chaps19&20-1

CSE 4701

Chapters 21 & 22 6e -19 & 20 5e: Trans Processing & Concurrency Control

Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department

The University of Connecticut191 Auditorium Road, Box U-155

Storrs, CT [email protected]

http://www.engr.uconn.edu/~steve(860) 486 - 4818

A portion of these slides are being used with the permission of Dr. Ling Lui, Associate Professor, College of Computing, Georgia Tech.

Other slides have been included/modified from the PPTs provided by the Fundamentals of Database Systems 6e course materials.

Remaining slides represent new material.

Chaps19&20-2

CSE 4701

Overview of Material Key Background Topics:

Synchronization in Operating Systems Transaction and Deadlock Concepts Prevention, Avoidance, Detection

Chapter 19 5e; 21 6e - Transaction Processing Concurrency Control Data Consistency Problems Schedules and Serializability

Chapter 20 5e; 22 6e - Concurrency Control Different Locking-Based Algorithms 2 Phase Protocol Deadlock and Livelock Optimistic Concurrency Control

Chaps19&20-3

CSE 4701

What is Synchronization? Ability of Two or More Serial Processes to Interact

During Their Execution to Achieve Common Goal Recognition that “Today’s” Applications Require

Multiple Interacting Processes Client/Server and Multi-Tiered Architectures Inter-Process Communication via TCP/IP Mobile Applications Interacting with Cloud, Web,

or REST Services Fundamental Concern: Address Concurrency

Control Access to Shared Information Historically Supported in Database Systems Currently Available in Many Programming

Languages

Chaps19&20-4

CSE 4701

Thread Synchronization Suppose X and Y are Concurrently Executing in Same

Address Space What are Possibilities?

X Y

1

2

3

What Does Behavior at Left Represent?

Synchronous Execution! X Does First Part of Task Y Next Part Depends on X X Third Part Depends on Y Threads Must Coordinate

Execution of Their Effort

Chaps19&20-5

CSE 4701

Thread Synchronization

Will Second Part Still Finish After Third Part? Will Second Part Now Finish Before Third Part? What Happens if Variables are Shared?

This is the Database Concern - Concurrent Transactions Against Shared Tables!

X Y

1

23

Now, What Does Behavior at Left Represent?

Asynchronous Execution! X Does First Part of Task Y Does Second Part Concurrent

with X Doing Third Part What are Issues?

Chaps19&20-6

CSE 4701

Databases have Transactions A Transaction is

A Logic Unit of Database Processing Represents the Collection of Actions that Make

Consistent Transformations of System States while Preserving System Consistency

Interleaved (A and B) and Concurrent (C and D)

Chaps19&20-7

CSE 4701

Two Sample Transactions Transaction T1 Reads/Writes X/Y, Modifying X by

Subtracting N and Y by Adding N Transaction T2 Reads X and Modifies X by Adding M Transactions can Execute

Serially: T1 followed by T2 (or reverse) Interleaved: Operation by Operation

What Could Happen in Serial Case? What can go Wrong in Interleaved Case?

Chaps19&20-8

CSE 4701

Why Do we Need to Synchronize? Promote Sharing of Resources, Data, etc.

Cooperating Processes Norm Not Exception Difficult to Program Solutions

Handle Concurrent Behavior of Processes Multiple Processes Interacting via OS Resources Under Control of Process Manager/Scheduler

Performance, Parallel Algorithms & Computations Multi-Processor Architectures Different OS to Handle Multiple Processors

Client/Server and Multi-Tier Architectures Underlying Database Support

Concurrent Transactions Shared Databases

Chaps19&20-9

CSE 4701

Potential Problems without Synchronization? Data Inconsistency

Lost-Update Problem Impact on Correctness of Executing Software

Deadlock Two Processes (Transactions) Each Hold Unique Resource (Data Item) and Want

Resource (Date Item) of Other Process (Trans.) Processes Wait Forever

Non-Determinacy of Computations Behavior of Computation Different for Different

Executions Two Processes (Transactions) Produce Different

Results When Executed More than Once on Same Data

Chaps19&20-10

CSE 4701

Classic Synchronization Techniques Goal: Shared Variables and Resources Two Approaches:

Critical Sections Define a Segment of Code as Critical Section Once Execution Enters Code Segment it Cannot be

Interrupted by Scheduler Release Point for Critical Section for Interrupts We’ll Briefly Review

Semaphores Proposed in 1960s by E. Dijkstra Utilizes ADTs to Design and Implement Behavior that

Guarantees Consistency and Non-Deadlock Recall your OS Course (CSE4300)

Chaps19&20-11

CSE 4701

shared float balance;Code for p1 Code for p2

. . . . . .balance = balance + amount; balance = balance - amount; . . . . . .

p1 p2

balance

Critical Sections Two Processes Share “balance” Data Item Remember, Assignment is Not Atomic, but May

Correspond to Multiple Assembly Instructions

Chaps19&20-12

CSE 4701

shared double balance;

Code for p1 Code for p2 . . . . . .balance = balance + amount; balance = balance - amount; . . . . . .

Critical Sections Recall the Code Below

What Happens if Time Slice Expires at Arrow and an Interrupt is Generated?

Code for p1 Code for p2

load R1, balance load R1, balanceload R2, amount load R2, amountadd R1, R2 sub R1, R2store R1, balance store R1, balance

Chaps19&20-13

CSE 4701

Critical Sections (continued) There is a Race to Execute Critical Sections Sections May Be Different Code in Different

Processes: Cannot Detect With Static Analysis Results of Multiple Execution Are Not Determinate Need an OS Mechanism to Resolve Races If p1 Wins, R1 and R2 Added to Balance - Okay If p2 Wins, its Changed Balance Different from One

Held by p1 which Adds/Writes Wrong ValueCode for p1 Code for p2

load R1, balance load R1, balanceload R2, amount load R2, amountadd R1, R2 sub R1, R2store R1, balance store R1, balance

Chaps19&20-14

CSE 4701

Trans. 1Trans. 1 Trans. 2Trans. 2

Data Item AData Item A Data Item BData Item B

Trans. 3Trans. 3

Data Item CData Item C

General Problem: A Deadly Embrace T1 has A Wants B - Won’t Release A Until it Gets B T2 has B Wants A - Won’t Release B Until it Gets A T3 has C Wants A - Won’t Release C Until it Gets A What is the End Result?

Deadlock!

Chaps19&20-15

CSE 4701

Deadlock in Databases

Trans. 1Trans. 1 Trans. 2Trans. 2 Trans. 3Trans. 3

Shared Database

Shared Database

Databases Must Control Access to Information by Multiple Concurrent Transactions (Processes)

How do we Prevent Simultaneous Updates of Database by Concurrent Transactions (Processes)?

Data is the Resource in Database System

Chaps19&20-16

CSE 4701

Addressing Deadlock Deadlock is Global Condition! Need to Analyze All Processes that Need All

Resources Can’t Make Local Decision Based on Needs of One

Process Four Deadlock Approaches:

Prevention: Never Allow Deadlock to Occur Avoidance: System Makes Decision to Head Off

Future Deadlock State Detection & Recovery: Check for Deadlock

(Periodically or Sporadically), Then Recover Manual Intervention: Operator Reboot if System

Seems Too Slow

Chaps19&20-17

CSE 4701

Prevention: A First Look Design the System So that Deadlock is Impossible Deadlock Only Occurs If All Following TRUE!!

Mutual Exclusion: Allocated Data Items are Exclusive Property of Transaction

Hold and Wait: Transaction Can Hold Data Items While Waiting for Another Resource

Circular Waiting: T1 has A needs B, T2 has B needs C, … Tn has Z needs A

No Preemption: Only Transaction Can Release Data Items or Withdraw Data Items Request

All Four Necessary for Deadlock to Exist Prevention Requires Concurrency Control Manager to

Violate at Least One Condition at All Times!

Chaps19&20-18

CSE 4701

Avoidance: A First Look Construct a Formal Model of System States Via Model, Choose a Strategy that Will Not Allow the

System to Go to a Deadlock State Predictive Approach: Requires Transaction to Declare

Intent re. Data Items in Advance Transaction X Needs A, B, and D Represents “Maximum Claim” on Data Items Transaction X Won’t Proceed Until all Data Items

Available May Require “Long” Waits

Amenable to Formal Solution/Algorithm

Chaps19&20-19

CSE 4701

Detection and Recovery: A First Look When Deadlock Occurs, Can we Detect and Recover? Two Phases to Algorithm

Detection: Is there Deadlock? Recovery: Preempt Data Items from Transactions

Detection Algorithm When is it Executed? What is its Overhead? Too Often - Wastes Data Items Too Infrequent - Blocked Transactions Don’t Do

Enough Work Dominant Commercial Solution

Chaps19&20-20

CSE 4701

Deadlock in Databases Concurrent Access to Database Information Optimistic Concurrency Control

Assume Problems Infrequent (ATM Example) Maintain Transaction Log Detect and Correct Errors in System via Log

“Long-After” Their Occurrence Similar to What in OS? Deadlock Concepts?

Pessimistic Concurrency Control Assume Problems will Occur (Airline Example) Require Transactions to Lock Portions of Data for

Read and Write Requests Similar to What in OS? Deadlock Concepts?

Chaps19&20-21

CSE 4701

Prevention Necessary Conditions for Deadlock

Mutual Exclusion Hold and Wait Circular Waiting No Preemption

Ensure that at Least One of the Necessary Conditions is False at All Times Why Must Mutual Exclusion Hold at All Times?

Some Data Items (System Catalog) Must be Exclusively Held by a Transaction

How Can a Prevention Strategy be Designed to Guarantee Failure of One of Other Conditions?

Chaps19&20-22

CSE 4701

Hold and Wait Invalidate: Hold and Wait: Transaction Can Hold One

Data Item While Waiting for Another Data Item Approach 1: Targeted to Batch Systems

Transaction Must Request All Data Items it Needs Transaction Competes for All Data Items Even if

Needs Only One Data Item at Time Holds Data Items “Done” With

Approach 2: Targeted to Timesharing For Transaction to Acquire a Data Item

Must Release All Held Data Items Reacquire All (Released &New) Data Items Needed

Overhead to Reacquire Held Data Items Could Encourage Starvation

Chaps19&20-23

CSE 4701

Avoidance Requires a Multi-Phase Approach

Construct a Model of System States Choose a Strategy that Guarantees that the System

Will Not Go to a Deadlock State Service Transactions in Some Order, Not

Necessarily Order Received Requires Extra Information for Each Transaction

Maximum Claim - Every Data Item Each Transaction Will Ever Request

Concurrency Controller Sees the Worst Case and can Allow Transitions Based on that Knowledge

Goal: To Maintain “Safe” State

Chaps19&20-24

CSE 4701

Synopsis of Techniques Resource Allocation Policy:

Detection - Very Liberal - requested Resources (Data Items) are Granted Where Possible

Prevention - Conservative - Undercommits Resources (Data Items)

Avoidance - Moderate - Between Detection/Prev. Different Invocation Schemes

Detection - Periodically to Test for Deadlock Prevention - Request All Resources at Once,

Preempt, and Order Resources Avoidance - Manipulate Transactions to Find at

Least One Safe Execution Path

Chaps19&20-25

CSE 4701

Advantages Disadvantages Detection

Never Delays Transaction Initiation Facilitates On-Line Processing

Prevention Works Well for “Short” Transactions Enforceable Via Compile Time Checks Run-Time Computation Reduced

Avoidance No Preemption Needed

Detection Inherent Preemption Losses

Prevention Inefficient Preempts Too Often Disallows Incremental Transaction Requests

Avoidance Future Transaction Requirements Must be Known

in Advance Transactions can be Blocked for Long Periods

Chaps19&20-26

CSE 4701

Transaction Processing Concepts Basic Transaction Processing Concepts

What are Processing Types? What is a Transaction? Why do we need Concurrency Control in a Multi-

User Environment? Atomic Transactions and ACID Properties Serial execution and Serializability

Concurrency Control Techniques Locking, Timestamps, and Multiversion Optimistic Concurrency Control

Transactions Provide Atomic/Reliable Execution in the Presence of

Failures Correct Execution of Multiple User Accesses

Chaps19&20-27

CSE 4701

What are Processing Types? Single-User System:

At most one user at a time can use the system. Multiuser System:

Many users can access the system concurrently. Concurrency

Interleaved processing: Concurrent execution of processes is interleaved in a

single CPU Parallel processing:

Processes are concurrently executed in multiple CPUs.

Chaps19&20-28

CSE 4701

What is a Transaction? A Transaction:

Logical unit of database processing that includes one or more access operations

Read – always mean Retrieval Write – could be insert or update, delete).

A transaction (set of operations) may be stand-alone specified in a high level language like SQL submitted interactively, or may be embedded within a program.

Transaction boundaries: Begin and End transaction

An application program may contain several transactions separated by the Begin and End transaction boundaries

Chaps19&20-29

CSE 4701

What is a Transaction? A Transaction is

A Logic Unit of Database Processing Represents the Collection of Actions that Make

Consistent Transformations of System States while Preserving System Consistency

Database in aconsistentstate

Database in aconsistentstate

Database may betemporarily in aninconsistent stateduring execution

BeginTransaction

EndTransaction

Execution ofTransaction

Objectives: Concurrency TransparencyFailure Transparency

Chaps19&20-30

CSE 4701

SIMPLE MODEL OF A DATABASE A database is a collection of named data items Granularity of data - a field, a record , or a whole disk

block (Concepts are independent of granularity) Basic operations are read and write

read_item(X): Reads a database item named X into a program variable. To simplify our notation, we assume that the program variable is also named X.

write_item(X): Writes the value of program variable X into the database item named X.

Chaps19&20-31

CSE 4701

Read Operation Basic unit of data transfer from the disk to the

computer main memory is one block. In general, a data item (what is read or written) will be the field of some record in the database, although it may be a larger unit such as a record or even a whole block.

read_item(X) command includes the following steps: Find the address of the disk block that contains

item X. Copy that disk block into a buffer in main memory

(if that disk block is not already in some main memory buffer).

Copy item X from the buffer to the program variable named X.

Chaps19&20-32

CSE 4701

Write Operation write_item(X) command includes the following steps:

Find the address of the disk block that contains item X.

Copy that disk block into a buffer in main memory (if that disk block is not already in some main memory buffer).

Copy item X from the program variable named X into its correct location in the buffer.

Store the updated block from the buffer back to disk (either immediately or at some later point in time).

Chaps19&20-33

CSE 4701

Two Sample Transactions Transaction T1 Reads/Writes X/Y, Modifying X by

Subtracting N and Y by Adding N Transaction T2 Reads X and Modifies X by Adding M Their Interleaved Execution can Yield Dramatically

Different Results! What are the Possibilities?

Chaps19&20-34

CSE 4701

Example of Transaction for Query

Query: User Steve Reserves Seat on Flight 123 Transaction Comprised of Three Steps:

Update the Seats Available (CAP) for Flight 123 If Steve is a New Customer, Insert Information for

Customer “Steve” into the CUST Table Insert Information for the Reservation into the

Flight-Customer Table FC To Record the Flight What Order Must you do this in? What Happens if Something Fails?

Consider an Airline Reservation System:FLIGHT(FNO, DATE, SRC, DEST, STSOLD, CAP)CUST(CNAME, ADDR, BAL)FC(FNO, DATE, CNAME,SPECIAL)

Chaps19&20-35

CSE 4701 Begin_Transaction Reservation {

input(flight_no, date, customer_name);EXEC SQL SELECT STSOLD,CAP

INTO temp1,temp2FROM FLIGHTWHERE FNO = flight_no AND DATE = date;

if temp1 = temp2 then { output(“no free seats”); Abort }else { EXEC SQL UPDATE FLIGHT

SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date;

EXEC SQL INSERT INTO FC(FNO, DATE, CNAME, SPECIAL);

VALUES (flight_no, date, customer_name, null);Commitoutput(“Reservation Completed”) }end_Transaction Reservation;

Termination of Transactions Note: Checking to See if Steve Customer is Omitted

Chaps19&20-36

CSE 4701

What is Concurrency Control? Concurrency Control

Concurrent Execution of Transactions May Interfere with Each Other

May Produce an Incorrect Overall Result Even If Each Transaction is Correct When

Executed in Isolation Why is Concurrency Control Needed?

The Lost Update Problem The Dirty Read Problem The Incorrect Summary Problem The Unrepeatable Read Problem

Chaps19&20-37

CSE 4701

Why is Concurrency Control Needed? The Lost Update Problem

Two transactions access the same database items have their operations interleaved in a way that makes the value of some database item incorrect

The Temporary Update (or Dirty Read) Problem One transaction updates a database item and then

the transaction fails for some reason Updated item accessed by another transaction

before it is changed back to its original value. The Incorrect Summary Problem

One transaction calculating an aggregate summary function on a number of records

Other transaction(s) updating some of the records Aggregate Calculation on Inconsistent Data (some

before and some after updates)

Chaps19&20-38

CSE 4701

The Lost Update Problem Problem: Item X has an incorrect value Since its

Update by T1 is “lost” (Overwritten by T2)

T1T2

Read(X);X:=X;

Write(X);Read(Y);

Y = Y + 20;Write(Y);commit;

Read(X);X:=X;

Write(X);commit;

S1: R1(X), R2(X), W1(X), R1(Y), W2(X), c2, W1(Y), c1;

time

OSs use Mutual Exclusion. Short Operations on Simple

Data Low Cost Synchronization

In Databases, we Need to Do Better Long Operations on Large

Databases Data Contention in Important Long-Term Transactions

Chaps19&20-39

CSE 4701

T1 T2

Read(X);X:=X;Write(X);

Read(Y);...Accidentally abort


S2: R1(X), W1(X), R2(X), W2(X), c2, R1(Y), a1;

time

The Dirty Read Problem Problem: Item X read by T2 is “dirty” (incorrect) Since

Due to T1 Failing before Completion (Commit), System Must Undo the Update and Change X Back to Original Value

It is Created by a Trans. That Has Not Been Completed/Committed

Unfortunately T2 has Read the “temporary” value of X

Chaps19&20-40

CSE 4701

The Incorrect Summary Problem Problem: Inconsistent Values w.r.t. Time - X has been

Changed but Y has Not - X and Y are “Correct”

Chaps19&20-41

CSE 4701

Summary of the Problems Lost Update Problem

Two processes execute the programs that intend to update the same data item X concurrently

X may end up with just one update Dirty Data Read Problem

A process may write intermediate values into the database

Further writes invalidate that particular value Process rollback also invalidate that value

Chaps19&20-42

CSE 4701

Summary of the Problems Incorrect Summary Problem

Query: Calculate total checking deposits Update: Transfer $1 M from Acct 1 to Acct 2 If query reads account 1 before the update and

account 2 after the update, the result is off by $1M The Unrepeatable Read Problem

Consider at Transaction T T Reads Data Item X at Time t Another Transaction Y Modifies X at Time t+1 T then Read X again at Time t+2 T has Read Two Different values of X!

Chaps19&20-43

CSE 4701

A Brief Look at Role of Recovery What causes a Transaction to fail?

1. A computer failure (system crash): A hardware or software error occurs in the computer

system during transaction execution. If the hardware crashes, the contents of the computer’s

internal memory may be lost. 2. A transaction or system error:

Some operation in the transaction may cause it to fail, such as integer overflow or division by zero.

Transaction failure may also occur because of erroneous parameter values or because of a logical programming error. In addition, the user may interrupt the transaction during its execution.

Chaps19&20-44

CSE 4701


3. Local errors or exception conditions detected by the transaction: Certain conditions necessitate cancellation of the

transaction. For example, data for the transaction may not be found.

A condition, such as insufficient account balance in a banking database, may cause a transaction, such as a fund withdrawal from that account, to be canceled.

A programmed abort in the transaction causes it to fail. 4. Concurrency control enforcement:

The concurrency control method may decide to abort the transaction, to be restarted later, because it violates serializability or because several transactions are in a state of deadlock.

Chaps19&20-45

CSE 4701


5. Disk failure: Some disk blocks may lose their data because of a read

or write malfunction or because of a disk read/write head crash.

This may happen during a read or a write operation of the transaction.

6. Physical problems and catastrophes: This refers to an endless list of problems that includes

power or air-conditioning failure, fire, theft, sabotage, overwriting disks or tapes by mistake, and mounting of a wrong tape by the operator.

Chaps19&20-46

CSE 4701

Further Transaction and System Concepts A transaction is an atomic unit of work that is either

completed in its entirety or not done at all. For recovery purposes, the system needs to keep

track of when the transaction starts, terminates, and commits or aborts.

Transaction states: Active state Partially committed state Committed state Failed state Terminated State

Chaps19&20-47

CSE 4701

Further Transaction and System Concepts Recovery manager keeps track of the following

operations: begin_transaction: This marks the beginning of

transaction execution. read or write: These specify read or write

operations on the database items that are executed as part of a transaction.

end_transaction: This specifies that read and write transaction operations have ended and marks the end limit of transaction execution. Are changes permanently applied to the database or Is transaction has to be aborted because it violates

concurrency control or for some other reason

Chaps19&20-48

CSE 4701

Further Transaction and System Concepts Recovery manager keeps track of the following

operations (cont): commit_transaction:

Signals a successful end of the transaction so that any Changes (updates) executed by the transaction can be

safely committed to the database and will not be undone

rollback (or abort): Signals that the transaction has ended unsuccessfully any changes or effects that the transaction may have

applied to the database must be undone.

Chaps19&20-49

CSE 4701

Further Transaction and System Concepts Recovery techniques use the following operators:

undo: Similar to rollback except that it applies to a single

operation rather than to a whole transaction. redo:

Specifies that certain transaction operations must be redone to ensure that all the operations of a committed transaction have been applied successfully to the database.

Chaps19&20-50

CSE 4701

What can Go Wrong? Transaction Moves Through Many States from Begin

to End From System Issue, Key Concern are Potential Abort When Can Aborts Occur? What are Issues?

Chaps19&20-51

CSE 4701

What can Go Wrong? Aborting Active Transaction

Recovery Likely Not Needed Reads/Writes on “Local” Copies Permanent Copy Not Updated

Chaps19&20-52

CSE 4701

What can Go Wrong? Aborting Partially Committed Transaction

Transaction Commits by Writing Values to DB Suppose Write A, Write B, Write C If Failure After Write A/B and Before Write C,

Transaction Aborts and Corrective Action Needed Must “Undo” Effect of All Completed Writes

Chaps19&20-53

CSE 4701

What is Tracked for Transaction Processing? The System Log or Journal keeps track of all

transaction operations that affect the values of database items. This information may be needed to permit

recovery from transaction failures. The log is kept on disk, so it is not affected by any

type of failure except for disk or catastrophic failure.

In addition, the log is periodically backed up to archival storage to guard against such catastrophic failures.

Chaps19&20-54

CSE 4701

What is Tracked for Transaction Processing? The System Log: T is a unique transaction-id that is

generated automatically by the system: Types of log record:

[start_transaction,T]: Records that transaction T has started execution.

[write_item,T,X,old_value,new_value]: Records that transaction T has changed the value of database item X from old_value to new_value.

[read_item,T,X]: Records that transaction T has read the value of database item X.

[commit,T]: Records that transaction T has completed successfully, and affirms that its effect can be committed (recorded permanently) to the database.

[abort,T]: Records that transaction T has been aborted.

Chaps19&20-55

CSE 4701

What is Tracked for Transaction Processing? Recovery: If the system crashes, we can recover to a

consistent database state by examining the log Log contains a record of every write operation that

changes the value of some database item Possible to undo writes operations by tracing

backward through the log and resetting all items changed by a write operation of T to old_values.

Or, redo the effect of the write operations of a transaction T by tracing forward through the log

Set all items changed by a write operation of T to their new_values.

Chaps19&20-56

CSE 4701

What is Tracked for Transaction Processing? Commit Point of a Transaction:

A transaction T reaches its commit point when All its operations to access database have been executed

successfully AND Effect of all the transaction operations on the database

has been recorded in the log Beyond the commit point, the transaction is said to

be committed, and its effect is assumed to be permanently recorded in the database.

Transaction writes [commit,T] entry into the log. Roll Back of transactions:

Needed for transactions that have a [start_transaction,T] entry into the log but no commit entry [commit,T] into the log.

Chaps19&20-57

CSE 4701

ACID: Desirable Properties of Transactions Atomicity: A transaction is an atomic unit of

processing; it is either performed in its entirety or not performed at all.

Consistency preservation: A correct execution of the transaction must take the database from one consistent state to another.

Isolation: A transaction should not make its updates visible to other transactions until it is committed; this property, when enforced strictly, solves the temporary update problem and makes cascading rollbacks of transactions unnecessary.

Durability or permanency: Once a transaction changes the database and the changes are committed, these changes must never be lost because of subsequent failure.

Chaps19&20-58

CSE 4701

ACID in Terms of Operations Database Consists of Set of Data Items

Read(x) Gets Last Stored Value in X Write(x) Stores a New Value Into X

Atomicity: A Set of R/W Operations that Either Completes Entirely or Not at All

Consistency: R/W Operations take the Database from One Consistent State to Another Consistent State

Isolation: No Intermediate Values Produced by the R/W Operations will be Visible to Other Transactions

Durability: Once the Transaction is Completed, and All the Updates are Committed, then these Changes Must Never be Lost because of Subsequent Failure

Chaps19&20-59

CSE 4701

What is a Schedule? Transaction schedule or history:

When transactions are executing concurrently in an interleaved fashion, the order of execution of operations from the various transactions forms what is known as a transaction schedule

A schedule S of n transactions T1, T2, …, Tn is: Ordering of operations of transactions where, for

each transaction Ti that participates in S, the operations of T1 in S must appear in the same order in which they occur in T1.

Operations from other transactions Tj can be interleaved with the operations of Ti in S.

Chaps19&20-60

CSE 4701

What is a Schedule? A Schedule S is a Sequence of R/W Operations,

Which End with Commit or Abort Different Transactions Executing Concurrently in

an Interleaved Fashion with One Another Each Transaction a Sequence of R/W Operations

Two Schedules S1 and S2 are Equivalent, Denoted as S1 S2 , If and Only If S1 and S2 Execute the Same Set of Transactions Produce the Same Results (i.e., Both Take the DB

to the Same Final State)

Chaps19&20-61

CSE 4701

Transactions and a Schedule Below are Transactions T1 and T2 Note that the Their Interleaved Execution Shown

Below is an Example of One Possible Schedule There are Many Different Interleaves of T1 and T2

T1 T2


Read(Y);Y = Y + 20;Write(Y);commit;

Read(X);X:=X;Write(X);commit;

Schedule S: R1(X), W1(X), R2(X), W2(X), c2, R1(Y), W1(Y), c1;

Chaps19&20-62

CSE 4701

Transactions and a Schedule What Happens if the Schedule Changes to:

T1 T2




T1 T2

Read(X);X:=X;

Write(X);


Read(X);

X:=X;Write(X);commit;

Chaps19&20-63

CSE 4701

Equivalent Schedules Are the Two Schedules below Equivalent? S1 and S4 are Equivalent, since They have the Same Set

of Transactions and Produce the Same ResultsT1 T2

Read(X);X:=X;Write(X);Read(Y);Y = Y + 20;Write(Y);commit;


Schedule S1

T1 T2




Schedule S4

S4: R1(X), W1(X), R2(X), W2(X), c2, R1(Y), W1(Y), c1;

S1: R1(X),W1(X), R1(Y), W1(Y), c1, R2(X), W2(X), c2;

Chaps19&20-64

CSE 4701

What are Different Types of Schedules? Recoverable schedule:

One where no transaction needs to be rolled back. No transaction T in S commits until all transactions

T’ that write an item that T reads have committed. Cascadeless schedule:

One where every transaction reads only the items that are written by committed transactions.

Cascaded rollback: A schedule in which uncommitted transactions that

read an item from a failed transaction must be rolled back – Read value written by Failed Trans

Strict Schedules: A schedule in which a transaction can neither read

or write an item X until the last transaction that wrote X has committed.

Chaps19&20-65

CSE 4701

Serial and Serializable Schedules Serial schedule:

A schedule S is serial if, for every transaction T participating in the schedule, all the operations of T are executed consecutively in the schedule. Otherwise, the schedule is called nonserial schedule.

Serializable schedule: A schedule S is serializable if it is equivalent to

some serial schedule of the same n transactions. Being serializable implies that the schedule is a correct

schedule that: Leaves the database in a consistent state. The interleaving of operations results in a state as

if the transactions were serially executed, while achieving efficiency due to concurrent execution.

Chaps19&20-66

CSE 4701

Serializability of Schedules A Serial Execution of Transactions Runs One

Transaction at a Time (e.g., T1 and T2 or T2 and T1) All R/W Operations in Each Transaction Occur

Consecutively in S, No Interleaving Consistency: a Serial Schedule takes a Consistent

Initial DB State to a Consistent Final State A Schedule S is Called Serializable If there Exists an

Equivalent Serial Schedule A Serializable Schedule also takes a Consistent

Initial DB State to Another Consistent DB State An Interleaved Execution of a Set of Transactions

is Considered Correct if it Produces the Same Final Result as Some Serial Execution of the Same Set of Transactions

We Call such an Execution to be Serializable

Chaps19&20-67

CSE 4701

Example of Serializability Consider S1 and S2 for Transactions T1 and T2 If X = 10 and Y = 20

After S1 or S2 X = 7 and Y = 40 These are the two Possible Serial Schedules

T1 T2



Schedule S1 Schedule S2

T1 T2



Chaps19&20-68

CSE 4701


After S1 or S2 X = 7 and Y = 40 Is S3 a Serializable Schedule?

T1 T2




T1 T2



T1 T2

Read(X);X:=X;

Write(X);Read(Y);


Read(X);X:=X;

Write(X);commit;

Schedule S3

Chaps19&20-69

CSE 4701


After S1 or S2 X = 7 and Y = 40 Is S4 a Serializable Schedule?

T1 T2




T1 T2



T1 T2

Schedule S4




Chaps19&20-70

CSE 4701

Two Serial Schedules with Different Results Consider S1 and S2 for Transactions T1 and T2 If X = 10 and Y = 20

After S1 X = 7 and Y = 28 After S2 X = 7 and Y = 27

T1 T2

Read(X);X:=X;Write(X);Read(Y);Y = X + 20;Write(Y);commit;



T1 T2

Read(X);X:=X;Write(X);Read(Y);Y = X + 20;Write(Y);commit;


A Schedule is Serializableif it Matches Either S1 or S2 ,Even if S1 and S2 Produce Different Results!

Chaps19&20-71

CSE 4701

Thoughts on Serializability Serializability is hard to check

Interleaving of operations occurs in an operating system through some scheduler

Difficult to determine beforehand how the operations in a schedule will be interleaved

Need to Adopt a Practical Approach Come up with methods (protocols) to ensure

serializability. However, it is not possible to determine when a

schedule begins and when it ends. Hence, we reduce the problem of checking the

whole schedule to checking only a committed project of the schedule

Chaps19&20-72

CSE 4701

How do we Check for Conflicts? Testing for conflict serializability:

Look at only read_Item (X) and write_Item (X) operations

Constructs a precedence graph (serialization graph) with directed edges

An edge is created from Ti to Tj if one of the operations in Ti appears before a conflicting operation in Tj

The schedule is serializable if and only if the precedence graph has no cycles.

Chaps19&20-73

CSE 4701

The Serializability Theorem A Dependency Exists Between Two Transactions If:

They Access the Same Data Item Consecutively in the Schedule and One of the Accesses is a Write

Three Cases: T2 Depends on T1 , Denoted by T1 T2

T2 Executes a Read(x) after a Write(x) by T1

T2 Executes a Write(x) after a Read(x) by T1

T2 Executes a Write(x) after a Write(x) by T1 Don’t carE about Read(x) Read(x)

Transaction T1 Precedes Transaction T2 If:

There is a Dependency Between T1 and T2, and

The R/W Operation in T1 Precedes the Dependent T2 Operation in the Schedule

Chaps19&20-74

CSE 4701

The Serializability Theorem A Precedence Graph of a Schedule is a Graph

G = <TN, DE>, where Each Node is a Single Transaction;

i.e.,TN = {T1, ..., Tn} (n>1)

and Each Arc (Edge) Represents a Dependency Going

from the Preceding Transaction to the Other i.e., DE = {eij | eij = (Ti, Tj), Ti, Tj TN}

Use Dependency Cases on Prior Slide The Serializability Theorem

A Schedule is Serializable if and only of its Precedence Graph is Acyclic

Chaps19&20-75

CSE 4701

Serializability Theorem Example Consider S1 and S2 for Transactions T1 and T2

Consider the Two Precedence Graphs for S1 and S2 No Cycles in Either Graph!

T1 T2




T1 T2



T1 T2

X

Schedule S1

T1 T2

X

Schedule S2

Chaps19&20-76

CSE 4701

What are Precedence Graphs for S3 and S4? For S3

T1 T2 (T2 Write(X) After T1 Write(X)) T2 T1 (T1 Write(X) After T2 Read (X))

For S4 T1 T2 (T2 Read/Write(X) After T1 Write(X))

T1 T2

X

Schedule S4

T1 T2

Read(X);X:=X;

Write(X);Read(Y);


Read(X);X:=X;

Write(X);commit;

Schedule S3

T1 T2

Schedule S4




T1 T2

X

Schedule S3

X

Chaps19&20-77

CSE 4701

Four Schedules and their …

Chaps19&20-78

CSE 4701

… Precedence Graphs

Chaps19&20-79

CSE 4701

Serializability Facts Serializability Emphasizes Throughput Serializable Executions Allow us to Enjoy the Benefits

of Concurrency without Giving up Any Correctness However, we May NOT GET the Same Result

Testing for Serializability Difficult in Practice: Finding a Serializable Schedule for an Arbitrary

Set of Transactions is NP-hard Interleaving of Operations From Concurrent Transs

is Determined Dynamically at Run-time Practically Almost Impossible to Determine

Ordering of Operations Beforehand to Ensure Serializability

Chaps19&20-80

CSE 4701

Transaction Processing Issues Transaction Structure (Usually Called Transaction

Model) Flat (Simple), Nested

Internal Database Consistency Semantic Data Control (Integrity Enforcement)

Algorithms Reliability Protocols

Atomicity & Durability Local Recovery Protocols Global Commit Protocols

Concurrency Control Algorithms How to Synchronize Concurrent Transaction

Executions (Correctness Criterion) Intra-Transaction Consistency, Isolation

Chaps19&20-81

CSE 4701

Transaction Execution Who Participates in Transaction Execution?

Begin_Transaction, Read, Write, Abort, Commit,End_Transaction

ScheduledOperations Results

Results

…

Read, Write, Abort, EOT

UserApplication

UserApplication

TransactionManager

(TM)

Scheduler(SC)

RecoveryManager

(RM)

Chaps19&20-82

CSE 4701

Transaction Support in SQL2 A single SQL statement is always considered to be

atomic. Either the statement completes execution without

error or it fails and leaves the database unchanged. With SQL, there is no explicit Begin Transaction

statement. Transaction initiation is done implicitly when

particular SQL statements are encountered. Every transaction must have an explicit end statement,

which is either a COMMIT or ROLLBACK.

Chaps19&20-83

CSE 4701

Transaction Support in SQL2 Characteristics specified by a SET TRANSACTION

statement in SQL2: Access mode:

READ ONLY or READ WRITE. The default is READ WRITE unless the isolation level

of READ UNCOMITTED is specified, in which case READ ONLY is assumed.

Diagnostic size n, specifies an integer value n, indicating the number of conditions that can be held simultaneously in the diagnostic area.

Chaps19&20-84

CSE 4701

Transaction Support in SQL2 Characteristics specified by a SET TRANSACTION

statement in SQL2: Isolation level <isolation>, where <isolation> can be

READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ or SERIALIZABLE. The default is SERIALIZABLE. With SERIALIZABLE: the interleaved execution

of transactions will adhere to our notion of serializability.

However, if any transaction executes at a lower level, then serializability may be violated.

Chaps19&20-85

CSE 4701

Transaction Support in SQL2 Potential problem with lower isolation levels: Dirty Read:

Reading a value that was written by a transaction which failed.

Nonrepeatable Read: Allowing another transaction to write a new value

between multiple reads of one transaction. A transaction T1 may read a given value from a

table. If another transaction T2 later updates that value and T1 reads that value again, T1 will see a different value. Consider that T1 reads the employee salary for Smith.

Next, T2 updates the salary for Smith. If T1 reads Smith's salary again, then it will see a different value for Smith's salary.

Chaps19&20-86

CSE 4701

Transaction Support in SQL2 Potential problem with lower isolation levels (cont.):

What are Phantom Rows? New rows being read using the same read with a

condition A transaction T1 may read a set of rows from a table,

perhaps based on some condition specified in the SQL WHERE clause.

Now suppose that a transaction T2 inserts a new row that also satisfies the WHERE clause condition of T1, into the table used by T1.

If T1 is repeated, then T1 will see a row that previously did not exist, called a phantom.

Chaps19&20-87

CSE 4701

Transaction Support in SQL2 Sample SQL transaction:

EXEC SQL whenever sqlerror go to UNDO; EXEC SQL SET TRANSACTION READ WRITE DIAGNOSTICS SIZE 5 ISOLATION LEVEL SERIALIZABLE; EXEC SQL INSERT INTO EMPLOYEE (FNAME, LNAME, SSN, DNO, SALARY) VALUES ('Robert','Smith','991004321',2,35000); EXEC SQL UPDATE EMPLOYEE SET SALARY = SALARY * 1.1 WHERE DNO = 2; EXEC SQL COMMIT; GOTO THE_END; UNDO: EXEC SQL ROLLBACK; THE_END: ...

Chaps19&20-88

CSE 4701

Transaction Support in SQL2 Possible violation of serializabilty:

Type of Violation Isolation Dirty nonrepeatable level read read phantom

______________________________________________________

_READ UNCOMMITTED yes yes yes READ COMMITTED no yes yes REPEATABLE READ no no yes SERIALIZABLE no no no

Chaps19&20-89

CSE 4701

Summary of Transaction Processing Transaction and System Concepts Desirable Properties of Transactions Characterizing Schedules based on Recoverability Characterizing Schedules based on Serializability Transaction Support in SQL

Chaps19&20-90

CSE 4701

Database Concurrency Control Purpose of Concurrency Control

To enforce Isolation (through mutual exclusion) among conflicting transactions.

To preserve database consistency through consistency preserving execution of transactions.

To resolve read-write and write-write conflicts. Example:

In concurrent execution environment if T1 conflicts with T2 over a data item A, then the existing concurrency control decides if T1 or T2 should get the A and if the other transaction is rolled-back or waits.

Chaps19&20-91

CSE 4701

Concurrency Control Different Locking-Based Algorithms

Binary Locks (Lock and Unlock) Share Read Locks and Exclusive Write Locks Write Lock Does Not Imply Read

2 Phase Protocol All Locks Must Precede All Unlocks in Trans. True for All Transactions - Schedule Serializable

Concurrency Control Implementation Techniques Optimistic Concurrency Control

Time-Based Access to Information Consider “When” Information Read/Written to

Identify Potential or Prior Conflicts We’ll Deviate from Textbook Notation

Chaps19&20-92

CSE 4701

Summary of CC Techniques Two-Phase Locking

Most Important in Practice Used by a Majority of DBMSs Serializes in the Middle of Transactions Low Overhead Relatively Low Concurrency

Timestamp-Based Based on Multiple Versions of Data Items Serializes at the Beginning of Transactions Mostly Used in Distributed DBMSs

Optimistic Concurrency Control Methods Serializes at the End of Transactions Relatively High Concurrency

Chaps19&20-93

CSE 4701

Recalling Important Concepts Transaction: Sequence of Database Commands that

Must be Executed as a Single Unit (Program) Recall SQL Update Query

Equivalent to Multiple Operations Read from DB, Modify (Local Copy), Write to DB Modify Sometimes Delete and Insert

Granularity: Size of Data that is Locked for an Executing DB Transaction - Wide Range Database Relation (Tuple vs. Entire Table) Attribute (Column) Meta-Data (System Catalog)

Locking: Provides Means for Synchronization

Chaps19&20-94

CSE 4701

Transaction Example Two Possible Outcomes for T1 and T2 – Let A = 5

If T1 First, then A = 150 If T2 First, then A = 60

Is this a Problem?

T1 T2

LOCK AREAD AA=A+10WRITE AUNLOCK Acommit;

LOCK AREAD AA=A*10WRITE AUNLOCK Acommit;

T1 T2



Chaps19&20-95

CSE 4701

Transaction Example The Two Different Orderings of

T1 and T2 Represent Alternate Serial Schedules (Non-Interleaved)

Key Concept: Concurrent (Interleaved) Execution of Several DB Transactions is Correct if and only if its Effect is the Same as that Obtained by Running the Same Transactions in a Serial Order

If Result is Either 150 or 60 – it is OK! This is the Concept of Serializability!

T1 T2



Chaps19&20-96

CSE 4701

Recalling Key Definitions A Schedule for a Set of Transactions is the Order in

When the Elementary Steps (Read, Lock, Assign, Commit, etc.) are Performed

A Schedule is Serial if All Steps of Each Transaction Occur Consecutively

A Schedule is Serializable if it is Equivalent to “Some” Serial Schedule

If T1, T2 and T3 are Transactions - What are the Possible Serial Schedules? T1 T2 T3 T1 T3 T2 T2 T1 T3

Different Serial Schedules for 4 Transactions?

T2 T3 T1 T3 T1 T2 T3 T2 T1

Chaps19&20-97

CSE 4701

Another Example of Serializability Two Serial Schedules – Let A = 15, B = 25, C=5 What are Values of A, B, and C after Each?

T1 T2

Read(A);A:=A10;Write(A);Read(B);B = B + 10;Write(B);commit;

Read(B);B:=B20;Write(B);Read(C);C=C+20Write(C)commit;

T1 T2

Read(A);A:=A10;Write(A);Read(B);B = B + 10;Write(B);commit;

Read(B);B:=B20;Write(B);Read(C);C=C+20Write(C)commit;

S1 S2

A = 5, B = 15, C=25

Chaps19&20-98

CSE 4701

Another Example of Serializability Is S3 or S4 – Let A = 15, B = 25, C = 5 Serial Values:

T1 T2

Read(A);

A:=A10;

Write(A);

Read(B);

B = B + 10;

Write(B);

commit;

Read(B);

B:=B20;

Write(B);

Read(C);

C=C+20

Write(C)

commit;

T1 T2

Read(A);A:=A10;

Write(A);

Read(B);

B = B + 10;

Write(B);commit;

Read(B);

B:=B20;

Write(B);

Read(C);

C=C+20Write(C)commit;

A = 5, B = 15, C=25

A = 5B = 35C = 25

A = 5B = 15C = 25

Chaps19&20-99

CSE 4701

Locks Lock: Variable Associated with a Data Item in DB,

Describing the Status of that Item w.r.t. Possible Ops. A Means of Synchronizing the Access by

Concurrent Transactions to the Database Item Managed by Lock Manager

Binary Locks: Lock(x) and Unlock(x) A Transaction T Must Issue the Lock(x) before any

Read(x) or Write(x) A Transaction T Must use the Unlock(x) After all

Read(x)/Write(x) Operations are Completed in T System Catalog Maintains a Lock Table for All

Locked Items Lock(x)(or Unlock(x)) will not be Granted if there

Already Exists a Lock(x) (or Unlock(x))

Chaps19&20-100

CSE 4701

Database Transaction is a Sequence of Lock/Unlocks Item Locked must Eventually be Unlocked A Transaction Holds a Lock between Lock and Unlock

Statements Lock/Unlock Assumes that the Value of the Item

Changes (Always Assumes a Write)

For a Number of Transactions that Lock/Unlock A, we’d have: f1(f2(f3( … fn( a0))))

A Basic Lock/Unlock Model

a0 f(a0) a0 Lock AUnlock Af(a0)

Chaps19&20-101

CSE 4701

Example - Assessing Schedule Consider Three Transactions Below:

T1 has f1(a) and f2(b) T2 has f3(b) and f4(c) and f5(a) T3 has f6(a) and f7 (c)

Functions Represent actions that Modify Instances a, b, and c of Data Items A, B, and C, Respectively

T1 Lock ALock BUnlock AUnlock B

T2 Lock BLock CUnlock BLock AUnlock CUnlock A

T3 Lock ALock CUnlock CUnlock A

Chaps19&20-102

CSE 4701

Example - Assessing Schedule Consider the Schedule with Changes to a, b, and c

Is this Schedule Serializable?

A B C

T1 Lock A a b cT2 Lock B a b cT2 Lock C a b cT2 Unlock B a f3(b) c T1 Lock B a f3(b) c T1 Unlock A f1(a) f3(b) c T2 Lock A f1(a) f3(b) c T2 Unlock C f1(a) f3(b) f4( c ) T2 Unlock A f5 (f1(a)) f3(b) f4( c ) T3 Lock A f5 (f1(a)) f3(b) f4( c ) T3 Lock C f5 (f1(a)) f3(b) f4( c ) T1 Unlock B f5 (f1(a)) f2 (f3(b)) f4( c ) T3 Unlock C f5 (f1(a)) f2 (f3(b)) f7 (f4( c )) T3 Unlock A f6(f5 (f1(a))) f2 (f3(b)) f7 (f4( c ))

Chaps19&20-103

CSE 4701

Is this Schedule Serializable? Focus on the Final Line - It indicates the Effective

Order of Execution of Each Transaction for a, b, and c T1 has f1(a) and f2(b) T2 has f3(b) and f4(c) and f5(a) T3 has f6(a) and f7 (c)

For A - Order of Transactions is T1 T2 T3

For B - T2 Must Precede T1 For C - T2 Must Precede T3 Can All Three Conditions be True w.r.t. Order?

A B C

T3 Unlock A f6(f5 (f1(a))) f2 (f3(b)) f7 (f4( c ))

Chaps19&20-104

CSE 4701

Determining Serializability in this Model Examine Schedule Based on Order in Which Various

Transactions Obtain Locks Order must be Equivalent to Some Hypothetical Serial

Schedule of Transactions If Orders for Different Data Items Forces Two

Transactions to Appear in a Different Order(T2 Must Precede T1 and T1 Must Precede T2 )There is a Paradox!

This is Equivalent to Searching for Cycles in a Directed Graph

Chaps19&20-105

CSE 4701

Recall Topological Sort Graph is Acyclic Find a Node of Graph with ONLY Arrows Leaving (no

Entering) Delete Node and Arrows

Chaps19&20-106

CSE 4701

Algorithm 1: Binary Lock Model Input: Schedule S for Transactions T1, T2 , … Tk Output: Determination if S is Serializable, and If so,

an Equivalent Serial Schedule Method: Create a Directed Precedence Graph G:

Let S = a1 ; a2 ; … ; an where each ai is Tj :Lock Am or Tj : Unlock Am

For each ai = Tj : Unlock Am , find next ap = Ts : Lock Am (1 < p n) (Ts is next Trans. to lock Am), and if so, draw Arc in G from Tj to Ts

Repeat Until All Unlock/Lock are Checked Review the Resulting Precedence Graph

If G has Cycles - Non-Serializable If G is Acyclic - Topological Sort to Find an Equivalent

Serial Schedule

Chaps19&20-107

CSE 4701 T1 Lock A

T2 Lock BT2 Lock CT2 Unlock BT1 Lock B T1 Unlock AT2 Lock AT2 Unlock C T2 Unlock A T3 Lock A T3 Lock C T1 Unlock B T3 Unlock CT3 Unlock A

Precedence Graph for Prior Example Look for Unlock Lock Combos on the

Same Data Item T2 Unlock B and T1 Lock B T1 Unlock A and T2 Lock A T2 Unlock C and T3 Lock C T2 Unlock A and T3 Lock A

IS IT SERIALIZABLE?

T1 T2

B

A

T3

A, C

Chaps19&20-108

CSE 4701 T2 Lock A

T2 Unlock AT3 Lock A T3 Unlock AT1 Lock BT1 Unlock B T2 Lock B T2 Unlock B

Another Example Look for Unlock Lock Combos on the

Same Data Item T2 Unlock A and T3 Lock A T1 Unlock B and T2 Lock B

IS IT SERIALIZABE? IF SO WHAT IS THE SCHEDULE?

T1 T2

B

T3

A

Chaps19&20-109

CSE 4701

Two-Phase Protocol Two-Phase Protocol - All Locks Must Precede All

Unlocks in the Schedule for a Transaction Which of the Transactions Below are Two-Phase? Why or Why Not?

T1 Lock ALock BUnlock AUnlock B

T2 Lock BLock CUnlock BLock AUnlock CUnlock A

T3 Lock ALock CUnlock CUnlock A

Chaps19&20-110

CSE 4701

Theorems Regarding Serializability Theorem 1: Algorithm 1 Correctly Determines if a

Schedule S is Serializable (omit the proof). Theorem 2: If S is any Schedule of 2 Phase

Transactions (i.e., all of its Transactions are 2-Phase), then S is Serializable. Proof by Contradiction. Suppose Not - they by Theorem 1, S has a

Precedence Graph G with a Cycle T1 T2 T3 … Tp T1

UNL L UNL UNL L In T1 T2 , T1 is Unlock, so all Remaining Actions

must also be Unlock, since S is 2 Phase However, in Tp T1 , T1 is Lock, which is a

Contradiction to Fact that S is 2 Phase

Chaps19&20-111

CSE 4701

Problems of Binary Locks Only One Transaction Can Hold a Lock on a Given

Item No Shared Reading is Allowed - Too Restrictive For Example

T1 is Read Only on X - Yet Needs Full Lock T2 is Read Only on X and Y - Needs Full Locks

T1 T2

Read(X);

Read(Y) commit;

time

Read(X); Read(Y);

Y = Y + 20;Write(Y);

commit;

t1

t2

t3

t4

t5

Chaps19&20-112

CSE 4701

A Read/Write Lock Model Refines the Granularity of Locking to Differentiate

Between Read and Write Locks Improves Concurrent Access Rlock (Shared): If T has an Rlock A, then Any Other

Transaction can Also Rlock A, but All Transactions are Forbidden from Wlock A until All Transactions with Rlock A issue Ulock A (Multiple Reads)

Wlock (Exclusive): If T has Wlock A, then All Other Transactions are Forbidden to Rlock or Wlock A Until T Ulocks A (Write Implies Reading, Single Write)

Two Schedules are Equivalent if: Produce Same Value for Each Data Item Each Rlock on an Item Occurs in Both Schedules

at a Time When Locked Item has the Same Value

Chaps19&20-113

CSE 4701

Algorithm 2: Read/Write Lock Model Input: Schedule S for Transactions T1, T2 , … Tk Output: Is S Serializable? If so, Serial Schedule Method: Create a Directed Precedence Graph G:

Suppose in S, Ti :Rlock A. If Tj : Wlock A is the Next Transaction to Wlock A (if it

exists) then place an Arc from Ti to Tj.

Repeat for all Ti’s, all Rlocks before Wlock on A! Suppose in S, Ti :Wlock A.

If Tj : Wlock A is the Next Transaction to Wlock A (if it exists) then place an Arc from Ti to Tj.

If Also exists Tm :Rlock A after Ti :Wlock A but before Tj : Wlock A, then Draw an Arc from Ti to Tm.

Review the Resulting Precedence Graph If G has Cycles - Non-Serializable If G is Acyclic - Topological Sort for Serial Schedule

Chaps19&20-114

CSE 4701

Consider the Following Schedule What are the Dependencies Among Transactions?

T1 T2 T3 T4 (1) Wlock A(2) Rlock B(3) Unlock A(4) Rlock A(5) Unlock B(6) Wlock B(7) Rlock A(8) Unlock B(9) Wlock B(10) Unlock A(11) Unlock A(12) Wlock A(13) Unlock B(14) Rlock B(15) Unlock A(16) Unlock B

Chaps19&20-115

CSE 4701

Consider the Following Schedule What is the Precedence Graph G?

T1 T2 T3 T4 (1) Wlock A(2) Rlock B(3) Unlock A(4) Rlock A(5) Unlock B(6) Wlock B(7) Rlock A(8) Unlock B(9) Wlock B(10) Unlock A(11) Unlock A(12) Wlock A(13) Unlock B(14) Rlock B(15) Unlock A(16) Unlock B

Chaps19&20-116

CSE 4701

Precedence Graph What is the Resulting Precedence Graph? Is the Schedule Serializable? Why or Why Not?

T1 T2

T3T4

A:RW

A:RW

B:RW

A:WW

B:WWA:WR

Chaps19&20-117

CSE 4701

A Read-Only/Write-Only Lock Model Revision of the Read/Write Model for Algorithm 2 Refining Our Assumptions

Assume that a Wlock on an Item Does not Mean that the Transaction First Reads the ItemContrary to First Two Models

Example:Read A; Read B; C=A+B; A=A-1; Write A; Write CReads A, B and Writes A,C (No Read on C)

Reformulate Notion of Equivalent Schedules

Chaps19&20-118

CSE 4701

How Does This Model Differ from Alg. 2? Consider the Schedule Segment:

T1 : Wlock A T1 : Ulock A T2 : Wlock A T2 : Ulock A

In Algorithm 2 - T2 : Wlock A Assumes that T2 Reads the Value Written by T1

However, This Need Not be True in the New Model If Between T1 and T2, No Transaction Rlocks A, then

Value Written by is T1 Lost, and T1 Does not Have to Precede T2 in a Schedule w.r.t. A

Chaps19&20-119

CSE 4701

Redefine Serializability Conditions on Serializability Must be Redefined in

Support of the Write-Does-Not-Assume Read Model If in Schedule S, T2 Reads “A” Written by T1, then

T1 Must Precede T2 in any Serial Schedule Equivalent to S

Further, if there is a T3 that Writes “A”, then in any Serial Schedule Equivalent to S, T3 may either Precede T1 or Follow T2, but may not Appear Between T1 and T2

Graphically, we have:T3

A:WRT1

T2T3

T1 T2 T3 T1 T3 T2 T2 T1 T3

T2 T3 T1 T3 T1 T2 T3 T2 T1

Chaps19&20-120

CSE 4701

Augmentation of Precedence Graph In Support of the Write Does Not Imply Read Model,

we must Augment the Precedence Graph: Add an Initial Transaction To that Writes Every

Item, and a Final Transaction Tf that Reads Every Item

When a Transaction T’s Output is Invisible in Tf (I.e., the Value is Lost), Then T is Referred to as a Useless Transaction

Useless Transactions have no Paths from Transaction to Tf

Note: Maintain Same set of Locks (Rlock, Wlock, Ulock) with Different Interpretation on Wlock

Chaps19&20-121

CSE 4701

Intuitive View of Algorithm 3 If T2 Reads Value of “A” Written by T1 , then T2 Must

Precede in any Serial Schedule For WR Combo - Draw an Arc from T1 to T2

Now Consider a T3 that also Writes “A” T3 Must be either Before T1 or After T2 Add in a Pair of Arcs T3 to T1 and T2 to T3 of

Which one Must be Chosen in the Final Precedence Graph

Serializability Occurs if After Choices Made for each “T3” Pair, the Resulting Graph is Acyclic

G is Referred to as a “Polygraph” with Nodes, Arcs, and Alternate Arcs

Chaps19&20-122

CSE 4701

Algorithm 3 Example T1 T2 T3 T4

(1) Rlock A(2) Rlock A(3) Wlock C(4) Unlock C(5) Rlock C(6) Wlock B(7) Unlock B(8) Rlock B(9) Unlock A(10) Unlock A(11) Wlock A(12) Rlock C(13) Wlock D(14) Unlock B(15) Unlock C(16) Rlock B(17) Unlock A(18) Wlock A(19) Unlock B(20) Wlock B(21) Unlock B(22) Unlock D(23) Unlock C(24) Unlock A

Chaps19&20-123

CSE 4701

Algorithm 3 – Steps 1 to 4 Input: Schedule S for Transactions T1, T2 , … Tk Output: Is S Serializable? If so, Serial Schedule Method: Create a Directed Polygraph Graph P:

1. Augment S with Dummy To (Write Every Item) an Dummy Tf (Read Every Item)

2. Create Initial Polygraph P by Adding Nodes for To, Tf, and Each Ti Transaction , in S

3. Place an Arc from Ti to Tj Whenever Tj Reads A in Augmented S (with Dummy States) that was Last Written by Ti. Repeat this Step for all Arcs.Don’t Forget to Consider Dummy States!

4. Discover Useless Transactions - T is Useless if there is no Path from T to Tf

This is the “Initialization” Phase of Algorithm 3

Chaps19&20-124

CSE 4701

Resulting Polygraph - Steps 1 to 2

T4T3T2T1T0 Tf

1. Add To and Tf to S, 2. Add To , Tf , T1 , T2 , T3 , T4 to Polygraph P

Chaps19&20-125

CSE 4701

Alg 3 Step 3 - Init=T0 & Fin=Tf T1 T2 T3 T4

T0 Write A Write B Write C Write D(1) Rlock A(2) Rlock A(3) Wlock C(4) Unlock C(5) Rlock C(6) Wlock B(7) Unlock B(8) Rlock B(9) Unlock A(10) Unlock A(11) Wlock A(12) Rlock C(13) Wlock D(14) Unlock B(15) Unlock C(16) Rlock B(17) Unlock A(18) Wlock A(19) Unlock B(20) Wlock B(21) Unlock B(22) Unlock D(23) Unlock C(24) Unlock ATf Read A Read B Read C Read D

Who Reads A after T0 Writes A?

Who Reads A after T4 Writes A?

Who Reads B after T1 Writes B?

Who Reads B after T4 Writes B?

Who Reads C after T1 Writes C?

Who Reads D after T2 Writes D?

Chaps19&20-126

CSE 4701

Step 3 -Write to Reads on A

Chaps19&20-127

CSE 4701

Step 3 - Write to Reads on B

Chaps19&20-128

CSE 4701

Step 3 - Write to Reads on C

Chaps19&20-129

CSE 4701

Step 3 - Write to Reads on D

Chaps19&20-130

CSE 4701

Resulting Polygraph - Steps 1 to 3

T4T3T2T1T0 Tf

1. Add To and Tf to S, 2. Add To , Tf , T1 , T2 , T3 , T4 to Polygraph P 3. Look for Ti Write X to Tj Read X for all Items X 4. Look for Useless Transactions - No Paths from T to Tf

A:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WR

C:WRD:WR

Chaps19&20-131

CSE 4701

Resulting Polygraph - Steps 1-4 1. Add To and Tf to S, 2. Add To , Tf , T1 , T2 , T3 , T4 to Polygraph P 3. Look for Ti Write X to Tj Read X for all Items X 4. For - T3 Remove Arcs Into T3 – This Completes Step 4

T4T3T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

Chaps19&20-132

CSE 4701

Algorithm 3 – Steps 5 to 7 Method: Reassess the Initial Polygraph P:

5. For Each Remaining Arc Ti W to Tj R(meaning that Tj Reads Item A Written by Ti )Consider all T To and T Tf that also Writes A:I. If Ti = To and Tj = Tf then Add No Arcs

II. If Ti = To and Tj Tf then Add Arc from Tj to T

III. If Ti To and Tj = Tf then Add Arc from T to Ti

IV. If Ti To and Tj Tf then Add Arc Pair from T to Ti and Tj to T

6. Determine if P is Acyclic by “Choosing” One Transaction Arc for Each Pair - Make Choices Carefully

7. If Acyclic - Serializable - Perform Topological Sort without To , Tf for Equivalent Serial Schedule. Else - Not Serializable

Chaps19&20-133

CSE 4701

What are Four Cases of Step 5 Conceptually? 5. For Each Remaining Arc Ti W to Tj R

Consider all T To and T Tf that also Writes A:I. If Ti = To and Tj = Tf then Add No ArcsII. If Ti = To and Tj Tf then Add Arc from Tj to T III. If Ti To and Tj = Tf then Add Arc from T to Ti


Ti TjX:WR

T0 TfX:WR

General Case:

Case I: no new arc

T0 TjX:WR

Case II: Add Arc to from Ti to TT is after

TII X:RW

Chaps19&20-134

CSE 4701




Ti TjX:WR

Ti TfX:WR

General Case:

Case III: Add Arc from T to Ti – T is before

TIII X:RW

Chaps19&20-135

CSE 4701




Ti TjX:WR

Ti TjX:WR

General Case:

Case IV: Add in two Arcs T is after Tj or before Ti

TIV X:RW

IV X:RW

Chaps19&20-136

CSE 4701

T1 T2 T3 T4 To Write A Write B Write C Write D(1) Rlock A(2) Rlock A(3) Wlock C(4) Unlock C(5) Rlock C(6) Wlock B(7) Unlock B(8) Rlock B(9) Unlock A(10) Unlock A(11) Wlock A(12) Rlock C(13) Wlock D(14) Unlock B(15) Unlock C(16) Rlock B(17) Unlock A(18) Wlock A(19) Unlock B(20) Wlock B(21) Unlock B(22) Unlock D(23) Unlock C(24) Unlock ATf Read A Read B Read C Read D

Alg 3 Ex - Step 5 - Who Else Writes A?

For T0 to T1 Arc Who Else Writes A?For T0 to T2 Arc

Who Else Writes A?

For T4 to Tf Arc Who Else Writes A?

Chaps19&20-137

CSE 4701

Resulting Polygraph - Step 5 - A:WR

T4T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

T3

II A:RW

II A:RW

III A:RW

II A:RW

T4T3T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

II A:RW

Chaps19&20-138

CSE 4701

Resulting Polygraph - Step 5 - A:WR 5. For Each Arc Ti to Tj Consider All T’s that Write X

I. If Ti = To and Tj = Tf then Add No Arcs II. If Ti = To and Tj Tf then Add Arc from Tj to T III. If Ti To and Tj = Tf then Add Arc from T to Ti

IV. If Ti To and Tj Tf then Add Pair from T to Ti and Tj to T Check Items A (see new arcs/labels - case II and

III)

T4T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

T3

II A:RW

II A:RW

III A:RW

II A:RW

II A:RW

Chaps19&20-139

CSE 4701

Alg 3 Ex - Step 5 - Who Else Writes C/D? T1 T2 T3 T4

Init Write A Write B Write C Write D To(1) Rlock A(2) Rlock A(3) Wlock C(4) Unlock C(5) Rlock C(6) Wlock B(7) Unlock B(8) Rlock B(9) Unlock A(10) Unlock A(11) Wlock A(12) Rlock C(13) Wlock D(14) Unlock B(15) Unlock C(16) Rlock B(17) Unlock A(18) Wlock A(19) Unlock B(20) Wlock B(21) Unlock B(22) Unlock D(23) Unlock C(24) Unlock AFin Read A Read B Read C Read D Tf

For three T1 Arcs Does Anyone Else Write C?

For One T2 Arc Does Anyone Else Write D?

Chaps19&20-140

CSE 4701

Resulting Polygraph-Step 5- C:WR & D:WR 5. For Each Arc Ti to Tj Consider All T’s that Write X


IV. If Ti To and Tj Tf then Add Pair from T to Ti and Tj to T Do any Other Transactions Write C or Write D

for the arrows labeled C:WR and D:WR Respectively?

T4T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

T3

II A:RW

II A:RW

III A:RW

II A:RW

II A:RW

Chaps19&20-141

CSE 4701

Alg 3 Ex - Step 5 - Who Else Writes B? T1 T2 T3 T4

Init Write A Write B Write C Write D(1) Rlock A(2) Rlock A(3) Wlock C(4) Unlock C(5) Rlock C(6) Wlock B(7) Unlock B(8) Rlock B(9) Unlock A(10) Unlock A(11) Wlock A(12) Rlock C(13) Wlock D(14) Unlock B(15) Unlock C(16) Rlock B(17) Unlock A(18) Wlock A(19) Unlock B(20) Wlock B(21) Unlock B(22) Unlock D(23) Unlock C(24) Unlock AFin Read A Read B Read C Read D

For T4 to Tf Arc Who Else Writes B?T1 but already Arc from T1 to T4

For T1 to T4 Arc Who Else Writes B?Just T4 so no arc For T1 to T2 Arc Who Else Writes B?This is Case IV

T4 Writes B Two Arcs:

T4 after T2 and T4 before T1

Chaps19&20-142

CSE 4701

Two Added Arcs for Case IV and B

IV B:RW

IV B:RW

T4T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

T3

II A:RW

II A:RW

III A:RW

II A:RW

II A:RW

T4 Follows T2 and T4 Before T1

Chaps19&20-143

CSE 4701

Resulting Polygraph - Step 5 and 6 5. For Each Arc Ti to Tj Consider All T’s that Write X


IV. If Ti To and Tj Tf then Add Pair from T to Ti and Tj to T B (see new arcs - including alternates - dashed)

For T1 to T2, T4 writes - so add T2 to T4 and T4 to T1 – Case IV

Either T4 After T2 or Before T1 - no new arcs for other WRs.

IV B:RW

IV B:RW

T4T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

T3

II A:RW

II A:RW

III A:RW

II A:RW

II A:RW

Chaps19&20-144

CSE 4701

Resulting Polygraph - Step 5 and 6 6. Which Option of Pair of Arcs Should be Chosen? Why?

IV B:RW

IV B:RW

T4T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

T3

II A:RW

II A:RW

III A:RW

II A:RW

II A:RW

Chaps19&20-145

CSE 4701

Final Polygraph - Step 7 Final Graph with Are Removed Delete Dummy States below

Topological Sort Yields Order: T1 , T2 , T3 , T4

IV B:RW

T4T2T1T0 TfA:WR

A:WR

A:WR

B:WR

B:WR B:WR

C:WR

C:WRD:WR

T3

II A:RW

II A:RW

III A:RW

II A:RW

IV B:RW

T4T2T1

B:WR

B:WR

C:WR

T3

II A:RW

II A:RW

III A:RW

II A:RW

II A:RW

II A:RW

Chaps19&20-146

CSE 4701

Implementation Issues for CC Return to Earlier Diagram… Transaction Manager + Schedule Implement CC

Begin_Transaction, Read, Write, Abort, Commit,End_Transaction

ScheduledOperations Results

Results

…

Read, Write, Abort, EOT

UserApplication

UserApplication

TransactionManager

(TM)

Scheduler(SC)

RecoveryManager

(RM)

Chaps19&20-147

CSE 4701

Implementation Issues for CC To Implement Algorithms 1 to 3, Focus on

Software Infrastructure (TM and SC) Protocol (CC Model for Algorithms 1 to 3)

TM/SC: Arbitrates and Controls Transaction Execution

Protocol: Restrictions on the Elementary Steps of a Transaction in Order to Promote Serializability

TM/SC + Protocol Comprise the Requirements/Specification of the

Concurrency Control Mechanism Concurrency Control Mechanism Itself Can be

Modeled as a Lock Manager with Lock Tables

Chaps19&20-148

CSE 4701

Implementation Issues for CC Locking Modes - In Support of Algorithms 1-3, there

is Requirement to Establish Locking Modes For Binary, Read/Write, etc., a Table Lists the

Compatibility of the Locks w.r.t. Concurrent Behavior For Example, Tables Below Illustrates all Legal

Concurrent Actions of Two Transactions R/W Locks (on left) R/W/Increment Locks (on right) What are Increment Locks used for?

W

R

W

Yes

No

No

No

RW

R

W

Yes

No

No

No

WR I

R

W

I

Yes No No

No No No

No No Yes

Chaps19&20-149

CSE 4701

Implementation Issues for CC Locking Modes - Can be Extended and Refined Based

on the Level of Granularity that is Desired For Example: Retrieve-Delete-Update-Insert Questions:

How Can Two Deletes/Inserts be Compatible? Will Effect of a Delete/Insert be Lost?

W

R

W

Yes

No

No

No

Update

Retrieve

Delete

Delete

Insert

Insert Update Retrieve

Yes No No No

No Yes No No

No No No No

No No No Yes

Chaps19&20-150

CSE 4701

Implementation Issues for CC Answer:

Focus on Buffer Management Capability Smart Buffer Manager Tracks All Blocks at All

Times If T1 loaded Block 123 at Time t, when T2 Goes to

Access Block 123 at Time t+10, Buffer Manager Checks to See if Block Already in Memory

Buffer Manager also has Concurrency Control!

R

W

Yes

No

No

No

Update

Retrieve

Delete

Delete

Insert

Insert Update Retrieve

Yes No No No

No Yes No No

No No No No

No No No Yes

Chaps19&20-151

CSE 4701

Implementation Techniques for CC Algorithms 1 to 3 as Presented are Not Directly

Implementable! Don’t Integrate the CC Requirements (Protocol) with

the TM/SC Typical Implementation Techniques Utilize Queueing

Strategies to Impose an Ordering on Transactions: Queue for Each Transaction that Tracks the Data

Items Needed by the Transaction for its Execution Queue for Each Data Item that Tracks the Locks

Requested and Held by All Transactions Contain Inverse Data of One Another

Chaps19&20-152

CSE 4701

Examples of Queues

What is the State of Each Lock? What is the State of Each Transaction? What Happens when a Transaction, T1, Completes?

...ARlock

BWlockT1

...BRlock

CWlockT2

...ARlock

BRlockT3

...CRlock

AWlockT4

...T1

RlockT3

RlockA T4

Wlock

...T1

WlockT2

RlockB T3

Rlock

...T2

WlockT4

RlockC

Chaps19&20-153

CSE 4701

Examples of Queues Algorithms that Manage Queues Implement the CC

Strategy Lock State is Often Maintained within Queue

...A

RlockHeld

BWlockHeld

T1

...B

RlockHeld

CWlockWait

T2

...A

RlockHeld

BRlockWait

T3

...C

RlockWait

AWlockWait

T4

...T1

RlockHeld

T3

RlockHeld

AT4

WlockWait

...T1

WlockHeld

T2

RlockWait

BT3

RlockWait

...T2

WlockWait

T4

RlockWait

C

Chaps19&20-154

CSE 4701

A Sidetrack to Recovery Basics Transactions are Liable to Fail for Many Reasons

Hardware or Software Failure Deadlock Occurs Transaction Error (e.g., Divide by Zero) after

Partial Execution In Either Case

We May Need to Abort a Completed Transaction Due to Error in Another Transaction

We Must Recover the DB to “Correct” State What do OS’s Do?

Weekly Backups of File System Incremental Backups (To another Disk) Raid Arrays System and Editor Log Files

Chaps19&20-155

CSE 4701

Database Recovery Approaches Evolved from OS Techniques Backup Copies of Database

Tape Copies (early days) and CD Copies Online (Shadow Database System or FTP) Off Site Storage of DB (Daily/Weekly)

Maintenance of Journal or Log File Containing All Changes to DB Since Last “Backup” Each Journal Entry Contains

Transaction ID Old/New Values of Data Item(s) Beginning/Ending Point of Transaction

When Failure Occurs Redo Aborted Transactions/Rollback Completed

Transactions/Undo Partially Executed Trans.

Chaps19&20-156

CSE 4701

Two Phase Commit Policy All Actions for a Transaction are Performed in a

Workspace (in Memory) Rather than Directly on the DB Copy of the Data

These Actions are Written in Journal (Including the Commit Action)

Leads to Two-Phase Commit Policy Transaction Cannot Write to DB Until Committed Transaction Cannot Commit Until All Changes

have been Recorded First in the Jorunal Two Phases are:

Phase 1: Write Data in Journal Phase 2: Write Data in DB

Failure Can Occur Anytime!

Chaps19&20-157

CSE 4701

Why is Two Phase Commit Important? Suppose DB Writes Occur Before Commit Assume a Transaction Aborts in the Middle of

Processing Undo DB Changes Made to Actual Database Prior

to Failure Relatively Straightforward and Manageable

Undo Actions of Other Transactions that Read Information Written by Aborted Transaction Impossible! Undo May Require you to Propagate to

Many Other Transactions, Particularly if Aborted Transaction was Long-Duration (hours)

Basic Concepts of Recovery are Used to Non-Locking Optimistic CC Approach!

Chaps19&20-158

CSE 4701

Concurrency Control Locking Details Two-Phase Locking Techniques

Locking is an operation which secures (a) permission to Read (b) permission to Write a data item for a transaction.

Example: Lock (X). Data item X is locked in behalf of the

requesting transaction. Unlocking is an operation which removes these

permissions from the data item. Example:

Unlock (X): Data item X is made available to all other transactions.

Lock and Unlock are Atomic operations.

Chaps19&20-159

CSE 4701

Two-Phase Locking Techniques: Essential components

Two locks modes: (a) shared (read) (b) exclusive (write).

Shared mode: shared lock (X) More than one transaction can apply share lock on X

for reading its value but no write lock can be applied on X by any other transaction.

Exclusive mode: Write lock (X) Only one write lock on X can exist at any time and no

shared lock can be applied by any other transaction on X.

Conflict matrix Read Write

Read W

rite

N

NN

Y

Chaps19&20-160

CSE 4701


Lock Manager: Managing locks on data items.

Lock table: Lock manager uses it to store the identify of transaction

locking a data item, the data item, lock mode and pointer to the next data item locked. One simple way to implement a lock table is through linked list.

T1Transaction ID Data item id lock mode Ptr to next data item

NextX1 Read

Chaps19&20-161

CSE 4701


Database requires that all transactions should be well-formed. A transaction is well-formed if: It must lock the data item before it reads or writes to it. It must not lock an already locked data items and it

must not try to unlock a free data item.

Chaps19&20-162

CSE 4701

Two-Phase Locking Techniques:Essential components

The following code performs the lock operation:

B: if LOCK (X) = 0 (*item is unlocked*)then LOCK (X) 1 (*lock the item*)else begin

wait (until lock (X) = 0) andthe lock manager wakes up the transaction);

goto Bend;

Chaps19&20-163

CSE 4701

Two-Phase Locking Techniques:

Essential components The following code performs the unlock operation:

LOCK (X) 0 (*unlock the item*)if any transactions are waiting then

wake up one of the waiting the transactions;

Chaps19&20-164

CSE 4701


The following code performs the read operation:B: if LOCK (X) = “unlocked” then

begin LOCK (X) “read-locked”;no_of_reads (X) 1;

endelse if LOCK (X) “read-locked” then

no_of_reads (X) no_of_reads (X) +1 else begin wait (until LOCK (X) = “unlocked” and

the lock manager wakes up the transaction); go to Bend;

Chaps19&20-165

CSE 4701


The following code performs the unlock operation:

if LOCK (X) = “write-locked” then

begin LOCK (X) “unlocked”; wakes up one of the transactions, if any

endelse if LOCK (X) “read-locked” then

begin no_of_reads (X) no_of_reads (X) -1 if no_of_reads (X) = 0 then begin

LOCK (X) = “unlocked”;wake up one of the transactions, if any

endend;

Chaps19&20-166

CSE 4701

Two-Phase Locking Techniques: The algorithm Two Phases:

(a) Locking (Growing) (b) Unlocking (Shrinking).

Locking (Growing) Phase: A transaction applies locks (read or write) on

desired data items one at a time. Unlocking (Shrinking) Phase:

A transaction unlocks its locked data items one at a time.

Requirement: For a transaction these two phases must be

mutually exclusively, that is, during locking phase unlocking phase must not start and during unlocking phase locking phase must not begin.

Copyright © 2011 Ramez Elmasri and Shamkant Navathe


The algorithm

T1 T2 Result

read_lock (Y); read_lock (X); Initial values: X=20; Y=30read_item (Y); read_item (X); Result of serial executionunlock (Y); unlock (X); T1 followed by T2 write_lock (X); Write_lock (Y); X=50, Y=80.read_item (X); read_item (Y); Result of serial executionX:=X+Y; Y:=X+Y; T2 followed by T1 write_item (X); write_item (Y); X=70, Y=50unlock (X); unlock (Y);



The algorithm

T1 T2 Result

read_lock (Y); X=50; Y=50read_item (Y); Nonserializable because it.unlock (Y); violated two-phase policy.

read_lock (X); read_item (X); unlock (X); write_lock (Y);read_item (Y);Y:=X+Y;write_item (Y);unlock (Y);

write_lock (X);read_item (X);X:=X+Y;write_item (X);unlock (X);

Time



The algorithm

T’1 T’2

read_lock (Y); read_lock (X); T1 and T2 follow two-phaseread_item (Y); read_item (X); policy but they are subject towrite_lock (X); Write_lock (Y); deadlock, which must beunlock (Y); unlock (X); dealt with.read_item (X); read_item (Y);X:=X+Y; Y:=X+Y; write_item (X); write_item (Y);unlock (X); unlock (Y);

Chaps19&20-170

CSE 4701


The algorithm Two-phase policy generates two locking algorithms

(a) Basic (b) Conservative

Conservative: Prevents deadlock by locking all desired data items

before transaction begins execution. Basic:

Transaction locks data items incrementally. This may cause deadlock which is dealt with.

Strict: A more stricter version of Basic algorithm where

unlocking is performed after a transaction terminates (commits or aborts and rolled-back). This is the most commonly used two-phase locking algorithm.


Dealing with Deadlock and Starvation

Deadlock

T’1 T’2

read_lock (Y); T1 and T2 did follow two-phaseread_item (Y); policy but they are deadlock

read_lock (X);read_item (Y);

write_lock (X);(waits for X) write_lock (Y);

(waits for Y)

Deadlock (T’1 and T’2)

Chaps19&20-172

CSE 4701

Dealing with Deadlock and Starvation Deadlock prevention

A transaction locks all data items it refers to before it begins execution.

This way of locking prevents deadlock since a transaction never waits for a data item.

The conservative two-phase locking uses this approach.

Chaps19&20-173

CSE 4701

Dealing with and Starvation Deadlock detection and resolution

In this approach, deadlocks are allowed to happen. The scheduler maintains a wait-for-graph for detecting cycle. If a cycle exists, then one transaction involved in the cycle is selected (victim) and rolled-back.

A wait-for-graph is created using the lock table. As soon as a transaction is blocked, it is added to the graph. When a chain like: Ti waits for Tj waits for Tk waits for Ti or Tj occurs, then this creates a cycle. One of the transaction o

Chaps19&20-174

CSE 4701

Dealing with Deadlock and Starvation Deadlock avoidance

There are many variations of two-phase locking algorithm.

Some avoid deadlock by not letting the cycle to complete.

That is as soon as the algorithm discovers that blocking a transaction is likely to create a cycle, it rolls back the transaction.

Wound-Wait and Wait-Die algorithms use timestamps to avoid deadlocks by rolling-back victim.

Chaps19&20-175

CSE 4701

Dealing with Deadlock and Starvation Starvation

Starvation occurs when a particular transaction consistently waits or restarted and never gets a chance to proceed further.

In a deadlock resolution it is possible that the same transaction may consistently be selected as victim and rolled-back.

This limitation is inherent in all priority based scheduling mechanisms.

In Wound-Wait scheme a younger transaction may always be wounded (aborted) by a long running older transaction which may create starvation.

Chaps19&20-176

CSE 4701

Why Optimistic Concurrency Control? Motivate by Disadvantages of Locking Techniques

Lock Maintenance Deadlock-Free Locking Protocols Limit

Concurrency Secondary Memory Access Causes Locks to be

Held for a Long Duration Locks Typically Held Until Transaction

Completes, Which Reduces Concurrency Often Needed in “Worst” Case Only Overhead - Locking + Deadlock Detection

Key Concept Write Collisions in Large Databases for “Many”

Applications are Rare OCC: “Don’t Worry be Happy” Approach

Chaps19&20-177

CSE 4701

Basic Ideas of OCC Interference Between Transactions is Rare and

Locking Incurs too Much Overhead Instead, Allow Each Transaction to Execute Freely,

and Check Serializability at the end of the Transaction Win (Allow to Commit) If No Interference Occurs or

There have been No Conflicts

Pessimistic execution

Optimistic execution

Validate Read(and Compute)

Write

ValidateRead Write(and Compute)

Chaps19&20-178

CSE 4701

How Does OCC Work? Execute Transactions Ad-Hoc - Let them Go

Uncontrolled Maintain Information of “Relevant” Actions Against

DB (Often in Conjunction with Recovery/Journal) When Transactions Finish - Check to see if Everything

Proceeded Satisfactorily Assumes that Probability of Transaction Interference

is Quite Small Two Questions re. OCC:

How Do We know Everything Went OK? How do we Recover if it Didn’t?

Chaps19&20-179

CSE 4701

What is a Timestamp? Timestamp

A monotonically increasing variable (integer) indicating the age of an operation or a transaction.

A larger timestamp value indicates a more recent event or operation.

Timestamp based algorithm uses timestamp to serialize the execution of concurrent transactions.

Chaps19&20-180

CSE 4701

OCC Utilizes Timestamps Timestamps are Clock Ticks used to Record the Major

Milestones in the Execution of a Transaction Examples Include:

Start Time of Transaction Read/Write Times for DB Items Finish Time of Transaction Commit Time of Transaction

Two Important Definitions are: Read Time of an Item: Highest Time Stamp

Possessed by Any Transaction that Reads the Item Write Time of an Item: Highest Time Stamp

Possessed by Any Transaction that Wrote the Item A Transaction has a Fixed Time when it Started that is

Constant Throughout its Execution

Chaps19&20-181

CSE 4701

How are Timestamps Used? Focus on “When” Reads and Writes Occur Transaction Cannot Read an Item if its Value was Not

Written Until After the Transaction Finished its Execution Transaction T with Timestamp t1 Cannot Read an

Item with a Write Time of t2 if t2 > t1 If this is the Case, T Must Abort and be Restarted Can’t Read Item if it hasn’t been Written

Transaction Cannot Write an Item if that Item has its Old Value Read at a Later Time Transaction T with Timestamp t1 Cannot Write an

Item with a Read Time of t2 if t2 > t1 If this is the Case, T Must Abort and be Restarted Can’t Write Item Being Read at a Later Time

Chaps19&20-182

CSE 4701

Algorithm 4: Optimistic CC Let T be a Transaction with Timestamp t Attempting to

Perform Operation X on a Data Item I with Readtime tR and Writetime tW If (X = Read and t tW ) or

(X = Write and t tR ) then Perform Operation If t > tR then set tR = t for Data Item I (read after write)

If t > tW then set tW = t for Data Item I (write after read) If (X = Write and tR t < tW ) then Do Nothing since

Later Write will Cancel out the Write of T If (X = Read and t < tW ) or

(X = Write and t < tR ) then Abort the Operation 1st - T trying to Read Item Before it was Written 2nd - T trying to Write an Item Before it was Read

Chaps19&20-183

CSE 4701

T1 T2 T3 A B C

200 150 175 RT=0 RT=0 RT=0 WT=0 WT=0 WT=0

(1) Read B

(2) Read A

(3) Read C

(4) Write B

(5) Write A

Example of OCC

What Happens at Each Step w.r.t. RT/WT?

RT=0 RT=200 RT=0WT=0 WT=0 WT=0

RT=150 RT=200 RT=0WT=0 WT=0 WT=0

RT=150 RT=200 RT=175WT=0 WT=0 WT=0

RT=150 RT=200 RT=175WT=0 WT=200 WT=0

RT=150 RT=200 RT=175WT=200 WT=200 WT=0

Chaps19&20-184

CSE 4701

T1 T2 T3 A B C

200 150 175 RT=0 RT=0 RT=0 WT=0 WT=0 WT=0

(1) Read B RT=0 RT=200 RT=0 WT=0 WT=0 WT=0

(2) RT=150 RT=200 RT=0 Read A WT=0 WT=0 WT=0

(3) RT=150 RT=200 RT=175 Read C WT=0 WT=0 WT=0

(4) RT=150 RT=200 RT=175 Write B WT=0 WT=200 WT=0

(5) RT=150 RT=200 RT=175 Write A WT=200 WT=200 WT=0

(6) Write C

Example of OCC

What Happens at Step 6? WT(C) =150 < RT(C)=175 Trying to write C after its Read - Consequence - Abort T2

RT=150 RT=200 RT=175WT=200 WT=200 WT=0

Chaps19&20-185

CSE 4701

T1 T2 T3 A B C

200 150 175 RT=0 RT=0 RT=0 WT=0 WT=0 WT=0






(6) RT=150 RT=200 RT=175 Write C WT=200 WT=200 WT=0


Example of OCC

Step (7) T3 can Finish, but No Effect Since 175 < 200 - Discard

Chaps19&20-186

CSE 4701

T1T2 T3 A B C

200 150 175 RT=0 RT=0 RT=0 WT=0 WT=0 WT=0






(6) RT=150 RT=200 RT=175 Write C WT=200 WT=200 WT=0


Summary of Example T1 Completes Successfully; T2 Aborts;

T3 Completes but Doesn’t Write A

Chaps19&20-187

CSE 4701

Recovery Consideration Actual Write Operations of Previous Example are

Phase 1 of Two-Phase Commit (Write to Journal) Commit - Phase 2 - Writes to DB Between Write to Log and Write to DB, No Other

Transaction is Allowed to Read Items being Written OCC Reduces Work as Follows:

One Step for Read, Two for Writes (write/commit) In Locking, we had Four Steps for R or W:

Lock, Read or Write, Unlock, Commit

Chaps19&20-188

CSE 4701

Viewing OCC vs. Phases of Execution Read Phase:

Database Information Read from Secondary Storage into Primary Memory

All Writes are to Local Workspace Validate Phase:

Check to see if Integrity of Data has not been Violated

Write Phase: Update the DB (Secondary Storage) from Local

Copies

Optimistic execution

ValidateRead Write(and Compute)

Chaps19&20-189

CSE 4701

Contrasting PCC and OCC Transaction Control

PCC: Control by Having Transactions Wait OCC: Control by Having Transactions Backed up

Serializability PCC: Ordering of Data Items OCC: Ordering of Transactions

Biggest Potential Problem PCC: Deadlock, rather Preventing it OCC: Starvation

Different Applications Suited to Different Approaches Some DBMS Support Both DBA Can Configure on Application-by-

Application Basis

Chaps19&20-190

CSE 4701

Concluding Remarks Background

OS Concepts of Sharing and Synchronization Deadlock Detection, Prevention, Avoidance

Chapter 19 Transaction Processing Concepts Different Problems re. Concurrency Control

Deadlock, Livelock, Starvation Lost Update, Dirty Read, etc. Serial Schedule and Serializability

Chapter 20 Deviated from Textbook Notation 3 Pessimistic Locking Based CC Algorithms 1 Optimistic Timestamp Based CC Algorithm Role of Recovery in CC

chaps19&20-1 cse 4701 chapters 21 & 22 6e -19 & 20 5e: trans processing &...

Documents

d slide

effort slide

n transaction t

task y

programming languages

operating systems transaction

e course materials

thread synchronization