Transaction Management

Prepared by: Remedios de Dios Bulos

Transaction Management


Outline

• Introduction

• Basic Transaction Concepts

• Concurrency

• Recovery


Introduction

DBMS should ensure that a database:• Events:

– In the presence of hardware and software failures– When multiple users are accessing the database

• Properties:– Reliable– Remains in a consistent state

• Functions:– Transaction support– Concurrency– Recovery


Outline

• Introduction


• Concurrency Control


What is a transaction?

• a logical unit of work– Entire program, part of a program or a single

command

• Carried out by:– A single user or– An application program

• To:– Access the database or– Change the contents of the database

CB2000


What is a transaction?EN94

• A Transaction: logical unit of database processing that includes one or more access operations (read-retrieval, write-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.


What is a transaction?

• Transaction boundaries: – Begin transaction – End transaction


Example

Time T1 balx

t1 begin _transaction 100

t2 read(balx) 100

t3 balx=balx - 10 100

t4 write(balx) 90

t5 end_transaction 90

t5 commit 90

T1 :Withdrawal transaction


Simple Model of a Database

• A database :– is a collection of named data items– Permanently resides on a disk, but some portion

of it is temporarily residing in memory

• Granularity of data :– a field, a record, or a whole disk block


2 Basic Transaction Operations

• read (X): Reads a database item named X into a program variable (local buffer).

• write (X): Writes the value of program variable (local buffer) into the database item named X


• 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.

Data


Block Storage Operations

1 block

1 buffer block


Read Operation

read(X) command includes the following steps:

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

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

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


MAIN MEMORY

Work Area of T1

A

BBuffer

Work Area of T2

input(A)

T1:read (X)

XBuffer block A

X

X1


Write Operation

write (X) command includes the following steps:

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

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

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

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


MAIN MEMORY

Work Area of T1

A

BBuffer

Work Area of T2

T1:write (X)

XBuffer block A

X

X1

output(A)X

X


A

B

X

Y

Buffer

MAIN MEMORY

X1

Y1

Work Area of T1

X2

Work Area of T2

Buffer block B

read-item(X)

write-item(Y)

input(A)

output(B)

Example of Data Access

Buffer block A


Transaction Examples

Database Relations:

EMPLOYEE (Eno, Name, Address, Sex, CivilStatus, Bdate, Position, Salary, SuperEno, Dno)

PROJECT (Pno, Pname, Plocation, Dno)

WORKS_ON (Eno, Pno, Hours)


Transaction example (1)

• Problem: Update the salary (add 10% to present salary) of a particular employee with an Eno = x.




Read(Eno = x, salary) dbop

salary = salary * 1.1

Write(Eno = x, salary) dbop

Transaction: consists of 2 dbop and a non-dbop

Note: dbop means database operation



• Problem: – Delete the employee with Eno=x.

– Reassign the projects of the employee with Eno=x to another employee, say Eno=new_eno.


WORKS_ON (Eno, Pno, Hours)



Delete (Eno = x) dbopfor all Works_On records, pnobegin

read (Pno = pno, Eno) dbopif (Eno = x ) then

beginEno = new_eno,write (Pno = pno, Eno) dbop

endend


Transactions: Properties (ACID)

• Atomicity

• Consistency

• Isolation

• Durability



• Atomicity– The “all or nothing” property.

– A transaction is an indivisible unit that is either performed in its entirety or it is not performed at all.

• Consistency– A transaction must transform the database from one

consistent state to another consistent state.

– The database must reflect the real-word at all times.



• Isolation– Transactions execute independently of one another.

– The partial effects of incomplete transactions should not be visible to other transactions.

• Durability– The effects of a successfully completed (committed)

transactions are permanently recorded in the database.

– They must not be lost because of a subsequent failure.



• Problem: transfer $50 from account A to account B

read(A);

A:= A-50;

write(A);

read(B);

B:= B+50;

write(B).


Transaction Properties: Consistency

• the sum of A and B should be unchanged by the execution of the transaction.

• Ensuring consistency for an individual transaction is the responsibility of the application programmer.

A= $1000

B=$2000

read(A);

A:= A-50;

write(A);

read(B);

B:= B+50;

write(B).


Transaction Properties: Atomicity

• the database system keeps track (on disk) of the old values of any data on which a transaction performs a write, and

• if a transaction does not complete its execution, the database system restores the old values to make it appear as though the transaction never executed.

• Ensuring atomicity is the responsibility of the transaction-management component of the database system.

A= $1000

B=$2000

Ti : read(A);

A:= A-50;

write(A);

read(B);

B:= B+50;

Fail!

write(B).


Transaction Properties: Durability • Durability is guaranteed:

– Updates carried out by the transaction have been written to disk before the transaction completes;

– Information about updates carried out by the transaction and written to disk is sufficient to enable the database to reconstruct the updates when the database system is restarted after failure.

• Ensuring durability is the responsibility of the recovery-management component of the database system.


Transaction Properties: Isolation

• Isolation is guaranteed:– Execute transactions serially;

however performance is affected;

– Other solutions have been developed to allow multiple transactions to execute concurrently

• Ensuring isolation is the responsibility of the concurrency-control component of the database system.

A= $1000

B=$2000

Ti :

read(A);

A:= A-50;

write(A);

read(B);

B:= B+50;

T2:

read(A)

read(B)

sum=A+B

write(B).


Transaction States

• Active

• Partially committed

• Committed

• Failed

• Aborted


Transaction States

active

•A transaction starts in the active state.

•The transaction stays in the active state while it is executing.

•A transaction starts in the active state.

•The transaction stays in the active state while it is executing.


Example

Time T1 balx


t2 read(balx) 100


t4 write(balx) 90


t5 commit 90


Active State


Transaction State

active

partiallycommitted

•When the transaction finishes its final statement, it enters the partially committed state.

•The actual output may still be residing in memory; thus, a hardware failure may preclude its successful completion

•When the transaction finishes its final statement, it enters the partially committed state.

•The actual output may still be residing in memory; thus, a hardware failure may preclude its successful completion


Example

Time T1 balx


t2 read(balx) 100


t4 write(balx) 90


t5 commit 90


Partiallycommitted


Transaction State

active

committedpartiallycommitted

•When the last of the information is written out in the disk, the transaction enters the committed state.

•When the last of the information is written out in the disk, the transaction enters the committed state.


Example

Time T1 balx


t2 read(balx) 100


t4 write(balx) 90


t5 commit 90


committedstate


Transaction State

active

failed

•If a transaction can no longer proceed with its normal execution (because of some failure), it enters the failed state.

•If a transaction can no longer proceed with its normal execution (because of some failure), it enters the failed state.


Time T4 balx


t2 read(balx) 100

t3 balx=balx + 100 100

t4 write(balx) 200

t5 … (failure)

t6

t7

t8

Failed state


Transaction State

active

abortedfailed

•A failed transaction must be rolled back and the database should be restored to its state prior to the start of the transaction. Such a transaction is said to be aborted.

•A failed transaction must be rolled back and the database should be restored to its state prior to the start of the transaction. Such a transaction is said to be aborted.


Time T4 balx


t2 read(balx) 100


t4 write(balx) 200

t5 … (failure) 200

t6 rollback 100

t7

t8


Transaction State

active

committed

aborted

partiallycommitted

failed

2 Outcomes of a transaction




• committed – The transaction is successfully completed;– The database reaches a new consistent state

• aborted– The transaction does not execute successfully;– The database must be restored to the consistent

state it was in before the transaction started. (rolled back or undone).


Transactions: other processes

• A committed transaction cannot be aborted.• To reverse the effects of a committed

transaction, a compensating transaction must be executed.

• An aborted transaction that is rolled back:– can be restarted later– depending on the cause of failure, it may

successfully execute and then commit at that time.


Transactions in DBMS

• The DBMS does not know which updates are grouped together to form a single transaction.

• The user should indicate the boundaries of the transaction through DML commands (delimeters) provided for in SQL2:– BEGIN TRANSACTION

– COMMIT

• If delimeters are not used the entire program is considered as a single transaction.


DBMS Transaction SubsystemTransaction

managerScheduler

Recoverymanager

Buffermanager

Systemsmanager

Accessmanager

Filemanager

• Transaction manager coordinates transactions on behalf of application programs

• It communicates with the scheduler

• The scheduler handles concurrency control.

• Its objective is to maximize concurrency without allowing simultaneous transactions to interfere with one another

• The recovery manager ensures that the database is restored to the right state before a failure occurred.

• The buffer manager is responsible for the transfer of data between disk storage and main memory.


Outline

• Introduction


• Concurrency Control

• Recovery


Single-user vs Multiuser Systems

• Single-user DBMS – at most one user at a time can use the system

• Multiuser DBMS – many users can use the system concurrently


Multiprogramming in Multiuser Systems

• allows multiple users to use computer systems simultaneously.

• allows the computer to process multiple programs (transactions).

• multiprogramming operating systems execute some commands from one program, then suspend that program, and execute some commands from the next program, and so on.


Multiprogramming in Multiuser Systems

• A program is resumed at the point where it was suspended when it gets its turn to use the CPU again.

• Interleaving keeps the CPU busy when the executing program requires an I/O operation.

• The CPU is switched to execute another program rather than remaining idle during I/O time.


Interleaved Concurrency

t1

A

Memory

A B

CPU

AB

B

A

A

B

t2

B


Simultaneous Concurrency(for multiple processors)

t3t4

C

D

CPU1

CPU2


T T1 balx


t2 read(balx) 100


t4 write(balx) 90

t5 commit 90

• BEGIN_TRANSACTION: This marks the beginning of transaction execution.

• READ or WRITE: These specify the read or write operations on the database items that are executed as part of a transaction

Transaction Operations


(Other) Transaction Operations• END_TRANSACTION:

• This specifies that READ and WRITE transaction operations have ended and marks the end limit of transaction execution.

• However, at this point it may be necessary to check whether :the changes introduced by the transaction can

be permanently applied to the database (committed) or

the transaction has to be aborted because it violates concurrency control for some other reason.


T T1 balx


t2 read(balx) 100


t4 write(balx) 90

t5 end transaction

t6 commit 90

Transaction Operations


(Other) Transaction Operations• COMMIT

This 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.

T T1 balx


t2 read(balx) 100


t4 write(balx) 90

t5 end transaction

t6 commit 90


(Other) Transaction Operations

• ROLLBACK (or ABORT):

• This signals that the transaction has ended unsuccessfully, so that any changes or effects that the transaction may have applied to the database must be undone.

Time T4 balx


t2 read(balx) 100


t4 write(balx) 200

t5 … (failure) 200

t6 rollback 100

t7 190

t8 190


(Other) Transaction Operations

• UNDO: Similar to rollback except that it applies to a single operation rather than a whole transaction.

• REDO: This 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.


What is concurrency control?

• Concurrency control is the process of :– managing simultaneous operations on the

database– without having them interfere with one

another.


Why Concurrency Control?• There may be interference that can result in

inconsistencies when– two or more users access the DB

simultaneously and – at least one is updating data.

• Although two transactions may be perfectly correct in themselves, the interleaving of operations may produce incorrect results.


Why Concurrency Control?

• Concurrency control :– enables users to access shared data

concurrently.– Throughput, the amount of work that is

accomplished in a given time interval is improved – the CPU is executing other transactions instead of being in an idle state waiting for I/O operations to complete.


Concurrency Problems

• Lost update problem

• Uncommitted dependency problem (temporary update/dirty read problem)

• Inconsistent analysis problem (incorrect summary problem)


Serial Processing

Time T1 balx


t2 read(balx) 100


t4 write(balx) 90

t5 commit 90



Serial Processing

Time T2 balx


t7 read(balx) 90


t9 write(balx) 190

t10 commit 190

T2: Deposit transaction



Lost update problem

• A lost update problem occurs :– when an apparently successfully completed

update operation by one user can be overridden by another user.


Time T1:Withdrawal T2:Deposit balx



t3 read(balx) 100

t4 read(balx) 100



t7 write(balx) 200

t8 write(balx) 90

t9 commit

t10 commit 90

Update of T2Update of T2

Update of T1Update of T1

Solution: Prevent T1 from reading the value of balx until after T2‘s update has been completed.

Solution: Prevent T1 from reading the value of balx until after T2‘s update has been completed.

The successful update of transaction T2 was overridden by transaction T1

The successful update of transaction T2 was overridden by transaction T1

At the end of the 2 transactions, (if the transactions were to be executed sequentially) the value of balx should be 190.

At the end of the 2 transactions, (if the transactions were to be executed sequentially) the value of balx should be 190.



Uncommitted dependency problem

• It occurs when one transaction is allowed to see the intermediate results of another transaction before it has committed (and a transaction failure occurs)



Uncommitted dependency problemTime T3 T4 balx


t2 read(balx) 100


t4 write(balx) 200

t5 begin _transaction

t6 read(balx) … (failure) 200

t7 balx=balx - 10 rollback 200

t8 write(balx) 190

t8 commit 190Since T4 failed (treated as if it was never executed),

at the end of transaction T3 , the value of balx

should be 90.

Since T4 failed (treated as if it was never executed),

at the end of transaction T3 , the value of balx

should be 90.





t2 read(balx) 100


t4 begin _transaction write(balx) 200



t7 write(balx) 190

t8 commit 190dirty data

•The value of balx that is read by T3 is called a dirty data because it has been created by a transaction (T4) that has not completed and committed yet.

•The value of balx that is read by T3 is called a dirty data because it has been created by a transaction (T4) that has not completed and committed yet.





t2 read(balx) 100


t4 begin _transaction write(balx) 200



t7 write(balx) 190

t8 commit 190Solution: Prevent T3 from reading the value of balx until after the decision has been made to either commit or abort T4‘s effects

Solution: Prevent T3 from reading the value of balx until after the decision has been made to either commit or abort T4‘s effects



Inconsistent Analysis problem

• Transactions that read the database can also produce inaccurate results, if they are allowed to read partial results of incomplete transactions that are simultaneously updating the database .

• It occurs when:– A transaction reads several values from the database

– But a second transaction updates some of them during the execution of the first.



Inconsistent Analysis problem

Given:

• T5 and T6 are simultaneous transactions.

• T6 is a summary transaction which is totaling the balances

of account x, account y and account z.

• T5 transfers 10 dollars from account x to account z.



Inconsistent Analysis problemTime T5 T6 balx baly balz sum

t1 begin _transaction 100 50 25

t2 begin _transaction sum = 0 100 50 25 0

t3 read(balx) read(balx) 100 50 25 0

t4 balx=balx – 10 sum = sum + balx 100 50 25 100

t5 write(balx) read(baly) 90 50 25 100

t6 read(balz) sum = sum + baly 90 50 25 150

t7 balz=balz + 10 90 50 25 150

t8 write(balz) 90 50 35 150

t9 commit read(balz) 90 50 35 150

t10 sum = sum + balz 90 50 35 185

t11 commit 90 50 35 185

Solution: Prevent T6 from reading the values of balx and balz until after T5 has completed its updates.

Solution: Prevent T6 from reading the values of balx and balz until after T5 has completed its updates.


Objectives of concurrency control

• To schedule transactions in such a way to avoid interference among simultaneous transactions.

• To maximize (in a multi-user DBMS) the degree of concurrency or parallelism such that transactions that can execute without interfering with one another can run in parallel.


Summary

• Basic transaction concepts– What is a transaction?– Transaction operations– Outcomes of a transaction– Transaction properties

• Concurrency Control– What is concurrency control?– Why concurrency control?– Concurrency problem– Objectives of concurrency control


Outline

• Schedule– Serial schedule– Non-serial schedule

• Serializability– Conflict serializability– View serializability

• Recoverability


Schedule

• A transaction consists of a sequence of operations:– Read or write

actions to the database

– Followed by commit or abort action.

Time T1 balx

t1 begin _transaction

100

t2 read(balx) 100


t4 write(balx) 90


t5 commit 90


ScheduleProblem:

• Let T1 and T2 be two transactions that transfer funds from one account to another.

• Transaction T1 transfers $50 from account A to account B.

• Transaction T2 transfers 10 percent of the balance from account A to account B.

• Current value of A and B are $1000 and $2000, respectively


T1

begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

T2

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end


begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end

Final values:A= $855B = $2145Total =$3000

Database is consistentDatabase is consistent

The execution sequence (T1,T2) is called a schedule

The execution sequence (T1,T2) is called a schedule

1st:Execute T11st:Execute T1

next:Execute T2next:Execute T2


begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end


Database is consistentDatabase is consistent

The execution sequences (T2,T1) is called a schedule

The execution sequences (T2,T1) is called a schedule

1st:Execute T21st:Execute T2

next:Execute T1next:Execute T1


• Schedule(T1, T2)Final values:A= $855B = $2145Total =$3000

• Schedule(T2, T)A= $850B = $2150Total =$3000


Schedule: definition

• A schedule S :– consists of the sequence of the operations from

a set of n transactions (T1, T2, T3, … Tn );

– subject to the constraint that the order of operations for each transaction is preserved in the schedule;

– thus, for each transaction Ti ,in schedule S, the order of operations in Ti must be the same in schedule S.


begin

1 read(A);

2 A:=A - 50;

3 write(A);

4 read(B)

5 B:=B + 50

6 write(B)

end

begin

1 read(A);

2 temp:=A*0.1

3 A:=A - temp;

4 write(A);

5 read(B);

6 B:=B + temp;

7 write(B);

end

Schedule1: T1, T2

consists of the sequence of the operations from a set of n transactions (T1, T2, T3, … Tn );

consists of the sequence of the operations from a set of n transactions (T1, T2, T3, … Tn );

Sequence of operations of T1Sequence of operations of T1

Sequence of operations of T2Sequence of operations of T2


begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end

Schedule1: T1, T2•subject to the constraint that the order of operations for each transaction is preserved in the schedule;

•for each transaction Ti ,in schedule S, the order of operations in Ti must be the same in schedule S.

•subject to the constraint that the order of operations for each transaction is preserved in the schedule;

•for each transaction Ti ,in schedule S, the order of operations in Ti must be the same in schedule S.

begin

1 read(A);

2 A:=A - 50;

3 write(A);

4 read(B)

5 B:=B + 50

6 write(B)

end

begin

1 read(A);

2 temp:=A*0.1

3 A:=A - temp;

4 write(A);

5 read(B);

6 B:=B + temp;

7 write(B);

end


begin

1 read(A);

2 A:=A - 50;

3 write(A);

4 read(B)

5 B:=B + 50

6 write(B)

end

begin

1 read(A);

2 temp:=A*0.1

4 write(A);

3 A:=A - temp;

5 read(B);

6 B:=B + temp;

7 write(B);

end

begin

1 read(A);

2 A:=A - 50;

3 write(A);

4 read(B)

5 B:=B + 50

6 write(B)

end

begin

1 read(A);

2 temp:=A*0.1

3 A:=A - temp;

4 write(A);

5 read(B);

6 B:=B + temp;

7 write(B);

end

Is the order of operations preserved?

Is the order of operations preserved?

NoNo


T1 T2

read(A);

A:=A - 50;

write(A);

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B)

B:=B + 50

write(B)

read(B);

B:=B + temp;

write(B);

begin

1 read(A);

2 A:=A - 50;

3 write(A);

4 read(B)

5 B:=B + 50

6 write(B)

end

begin

1 read(A);

2 temp:=A*0.1

3 A:=A - temp;

4 write(A);

5 read(B);

6 B:=B + temp;

7 write(B);

end

Is the order of Operations preserved?

Is the order of Operations preserved?

YesYes


Serial schedule: definition

• A schedule is serial where :– the operations of each transaction are executed

consecutively

– without any interleaved operations from other transactions.

– for example: given T1, T2 the serial order would be T1 then T2 ; or T2 then T1;

– thus, there is no interference between transactions since only one is executing at any given time.

– however, there is no guarantee that the results of all serial executions of a given set of transactions will be identical.


Serial Schedule

t1

T1

t2

T2


• The execution sequences (T1,T2) and (T2,T1) are serial schedules.

begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end

begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end


begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end

Schedule1: T1, T2


the operations of each transaction are executed consecutively;

the operations of each transaction are executed consecutively;

–without any interleaved operations from other transactions.–thus, there is no interference between transactions since only one is executing at any given time.

–without any interleaved operations from other transactions.–thus, there is no interference between transactions since only one is executing at any given time.


however, there is no guarantee that the results of all serial executions of a given set of transactions will be identical.

however, there is no guarantee that the results of all serial executions of a given set of transactions will be identical.

T1,T2: Final values:A= $855B = $2145Total =$3000




begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end

begin

read(A);

A:=A - 50;

write(A);

read(B)

B:=B + 50

write(B)

end

begin

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

B:=B + temp;

write(B);

end


Nonserial schedule: definition

• In a nonserial schedule, the operations from a set of concurrent transactions are interleaved.


Interleaved Concurrency

t1

T1

T2

t2

T2

T1


Non-serial Schedule: 1 (concurrent)

T1 T2

read(A);

A:=A - 50;

write(A);

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B)

B:=B + 50

write(B)

read(B);

B:=B + temp;

write(B);


Results are the Same as: T1,T2


Results are the Same as: T1,T2

consistentconsistent

}}

}}


T1 T2

read(A);

A:=A - 50;

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

write(A);

read(B)

B:=B + 50

write(B)

B:=B + temp;

write(B);


Results Not Same as: T1,T2T2,T1


Results Not Same as: T1,T2T2,T1

Non-serial Schedule: 2 (concurrent)

inconsistentinconsistent

}

}}

}


T1 T2

read(A);

A:=A - 50;

write(A);

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B)

B:=B + 50

write(B)

read(B);

B:=B + temp;

write(B);

T1 T2

read(A);

A:=A - 50;

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

write(A);

read(B)

B:=B + 50

write(B)

B:=B + temp;

write(B);

New value of A is read

New value of A is read

New value of B is read

New value of B is read

inconsistentinconsistentconsistentconsistent


Serializability: definition

• Serial execution never leaves the database in an inconsistent state.

• Every serial execution is considered correct, although different results may be produced.

• Serializability aims to :– find nonserial schedules

• that allow transactions to execute concurrently

• without interfering with one another

– produce a database state (consistent) that could be produced by a serial execution.


Serializable schedule

• A (nonserial) schedule is serializable:– if a set of transactions executes concurrently– the nonserial schedule is correct if it produces

the same results as some serial execution.

• To prevent inconsistency of transactions interfering with one another, it is essential to guarantee serializability of concurrent transactions.


Serializable schedule

T1 T2

read(A);

A:=A - 50;

write(A);

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B)

B:=B + 50

write(B)

read(B);

B:=B + temp;

write(B);

Non-Serializable schedule

T1 T2

read(A);

A:=A - 50;

read(A);

temp:=A*0.1

A:=A - temp;

write(A);

read(B);

write(A);

read(B)

B:=B + 50

write(B)

B:=B + temp;

write(B);consistentconsistent inconsistentinconsistent


Forms of Schedule Equivalence

• Conflict serializability

• View serializability


Conflict Serializability Order of operations: Read, Write

• If two consecutive instructions of two transactions either read or write completely different data items, – they do not conflict and – order is not important.

• If two consecutive instructions of two transactions either read or write the same data items– the operations may conflict– therefore, order of execution is important


Conflict Serializability Order of operations: Read, Write Different Data

• If two consecutive instructions of two transactions either read or write completely different data items, – they do not conflict and – order is not important.

T1 T2

begin _transaction

read(A)

begin _transaction

read(B)

write(B)

commit

write(A)

commit


Conflict Serializability Order of operations: Read Same Data

• If two consecutive instructions of two transactions only read the same data item,– they do not conflict

and – order is not

important.

T1 T2

begin _transaction

read(A)

begin _transaction

read(A)

commit

commit


Conflict Serializability Order of operations: Read, Write Same Data

• If two consecutive instructions of two transactions involve a read and write operations for the same data item, and

• If the read instruction of T1 comes before the write instruction of T2

• Then T1 does not read the value of the data item that is written by T2

• Thus, the order is important

T1 T2

begin _transaction

read(B) begin _transaction

read(A)

A:= A+10

read(A)

write(A)

commit

write(A)

commit

T1 does not read the value of A that is written by T2

T1 does not read the value of A that is written by T2



• If two consecutive instructions of two transactions involves a read and write operations for the same data item, and

• If the write instruction of T2 comes before the read instruction of T1

• Then T1 reads the value of the data item that is written by T2

• Thus, the order is important

T1 T2

begin _transaction

read(B) begin _transaction

read(A)

A:= A+10

write(A)

read(A)

commit

write(A)

commit

T1 reads the value of A that is written by T2

T1 reads the value of A that is written by T2


Conflict Serializability Order of operations: Write, Write Same Data

• If two consecutive instructions of two transactions involves both write operations for the same data item

• Then the order of these instructions does not affect either T1 and T2;

• However, the value obtained by the next read instruction of schedule S is affected since the result of only the latter of the two write instructions is preserved in the database.

• If there is no other write instruction after the two instructions, then the order of the write instructions of T1 and T2 affects the final value of the data item in the database



The order of two write instructions does not affect either T1 and T2;

T1 T2

begin _transaction

read(A) begin _transaction

read(A)

A:= A+10

write(A)

write(A)

commit

commit

T1 T2

begin _transaction


read(A)

A:= A+10

write(A)

write(A)

commit

commit

Schedule 1:

If initial value of A is 100, final value if A is 110 .

T1,T2: A= 110 (final value)

T2,T1: A =110 (final Value)

Schedule 1:

If initial value of A is 100, final value if A is 110 .



Schedule 2:

If initial value of A is 100, final value if A is 100.



Schedule 2:

If initial value of A is 100, final value if A is 100.



T1 has overwritten value written by T2

T1 has overwritten value written by T2



• However, the value obtained by the next read instruction of schedule S is affected since the result of only the latter of the two write instructions is preserved in the database.

T1 T2

begin _transaction


read(A)

A:= A+10

write(A)

write(A)

commit

read(A)

T1 T2

begin _transaction


read(A)

A:= A+10

write(A)

write(A)

commit

read(A)

The value obtained by the next read instruction will be the value written by T2, which is 110, if the initial value of A is 100






• If there is no other write instruction after the two instructions, then the order of the write instructions of T1 and T2 affects the final value of the data item in the database

T1 T2

begin _transaction


read(A)

A:= A+10

write(A)

write(A)

commit

commit

T1 T2

begin _transaction


read(A)

A:= A+10

write(A)

write(A)

commit

commit

If initial value of A is 100, then the final value of A in the database is 110





Serializability: Order of operations

• If two transactions either read or write completely separate data items, – they do not conflict and – order is not important.

• If two transactions only read a data item,– they do not conflict and – order is not important.

• If one transaction writes a data item and another either reads or writes the same data item, – the order of execution is important because conflict

occurs.


Nonserial scheduleT1 T2

begin _transaction

read(A)

write(A)

begin _transaction

read(A)

write(A)

read(B)

write(B)

commit

read(B)

write(B)

commit

These two instructions conflict because they involve same data item and at least one instruction is write

These two instructions conflict because they involve same data item and at least one instruction is write



begin _transaction

read(A)

write(A)

begin _transaction

read(A)

write(A)

read(B)

write(B)

commit

read(B)

write(B)

commit

These two instructions do not conflict because they refer to different data items.


If two consecutive instructions of a schedule do not conflict, then the order of the two instructions can be swapped to produce a new schedule (S’)




begin _transaction

read(A)

write(A)

begin _transaction

read(A)

read(B)

write(A)

write(B)

commit

read(B)

write(B)

commit







begin _transaction

read(A)

write(A)

begin _transaction

read(A)

read(B)

write(A)

write(B)

commit

read(B)

write(B)

commit

These two instructions do not conflict because they are both read instructions.






begin _transaction

read(A)

write(A)

begin _transaction

read(B)

read(A)

write(A)

write(B)

commit

read(B)

write(B)

commit






Nonserial schedule





T1 T2

begin _transaction

read(A)

write(A)

begin _transaction

read(B)

read(A)

write(A)

write(B)

commit

read(B)

write(B)

commit


Nonserial schedule





T1 T2

begin _transaction

read(A)

write(A)

begin _transaction

read(B)

read(A)

write(B)

write(A)

commit

read(B)

write(B)

commit


Nonserial schedule:





T1 T2

begin _transaction

read(A)

write(A)

begin _transaction

read(B)

write(B)

read(A)

write(A)

commit

read(B)

write(B)

commit


Nonserial schedule: (2)

Final result of the swaps is a serial schedule: T1,T2

There is no longer interleaving of operations.

Final result of the swaps is a serial schedule: T1,T2

There is no longer interleaving of operations.

T1 T2

begin _transaction

read(A)

write(A)

begin _transaction

read(B)

write(B)

read(A)

write(A)

commit

read(B)

write(B)

commit

}}


T1 T2

begin _transaction

read(A)

write(A)

begin _transaction

read(B)

write(B)

read(A)

write(A)

commit

read(B)

write(B)

commit

Original schedule(S)Original schedule(S) Equivalent serial schedule(S’)Equivalent serial schedule(S’)

T1 T2

begin _transaction

read(A)

write(A)

begin _transaction

read(A)

write(A)

read(B)

write(B)

commit

read(B)

write(B)

commit

If a schedule S can be transformed into a schedule S’ by a series of swaps of non-conflicting instructions, we say that S and S’ are conflict equivalent

If a schedule S can be transformed into a schedule S’ by a series of swaps of non-conflicting instructions, we say that S and S’ are conflict equivalent

A schedule is conflict serializable if it is conflict equivalent to a serial schedule

A schedule is conflict serializable if it is conflict equivalent to a serial schedule


• It is possible to have two schedules that produce the same outcome, but that are not conflict equivalent

T1 T2

read(Q)

write(Q)

write(Q)

Can we swap? Can we swap? No No


• It is possible to have two schedules that produce the same outcome, but that are not conflict equivalent

T1 T2

read(Q)

write(Q)

write(Q)

Cannot swap instructions to obtain either the serial schedule

< T1, T2>, or the serial schedule < T2, T1>.

Cannot swap instructions to obtain either the serial schedule

< T1, T2>, or the serial schedule < T2, T1>.

Serial schedule T1,T2: if Q is initially 100, final value of Q is written by T2Non-serial Schedule: if Q is initially 100, final Q is 100


View Serializability• Let S and S´ be two schedules with the same set of

transactions. S and S´ are view equivalent if the following three conditions are met:1. For each data item Q, if transaction Ti reads the initial value of Q

in schedule S, then transaction Ti must, in schedule S´, also read the initial value of Q.

2. For each data item Q, if transaction Ti executes read(Q) in schedule S, and that value was produced by transaction Tj ( write(Q) if any), then transaction Ti must in schedule S´ also read the value of Q that was produced by transaction Tj .

3. For each data item Q, the transaction (if any) that performs the final write(Q) operation in schedule S must perform the final write(Q) operation in schedule S´.

As can be seen, view equivalence is also based purely on reads and writes alone.


Schedule S

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

Serial Schedule: S’

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

For each data item Q, if transaction Ti reads the initial value of Q in schedule S, then transaction Ti must, in schedule S´, also read the initial value of Q.

For each data item Q, if transaction Ti reads the initial value of Q in schedule S, then transaction Ti must, in schedule S´, also read the initial value of Q.

transaction T1 reads the initial value of Q in schedule S, and T1 in schedule S’, also reads the initial value of Q.

transaction T1 reads the initial value of Q in schedule S, and T1 in schedule S’, also reads the initial value of Q.

First read(Q) instruction





Schedule S

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

Serial Schedule S’

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

For each data item Q, if transaction Ti executes read(Q) in schedule S, and that value was produced by transaction Tj ( write(Q) if any), then transaction Ti must in schedule S´ also read the value of Q that was produced by transaction Tj .

For each data item Q, if transaction Ti executes read(Q) in schedule S, and that value was produced by transaction Tj ( write(Q) if any), then transaction Ti must in schedule S´ also read the value of Q that was produced by transaction Tj .

This condition does not exist for the given

schedules

This condition does not exist for the given

schedules


Schedule S

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)


T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

For each data item Q, the transaction (if any) that performs the final write(Q) operation in schedule S must perform the final write(Q) operation in schedule S´.

For each data item Q, the transaction (if any) that performs the final write(Q) operation in schedule S must perform the final write(Q) operation in schedule S´.

T3 performs the final write of Q in both schedules

T3 performs the final write of Q in both schedules


Schedule S

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)


T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

A schedule S is view serializable if it is view equivalent to a serial schedule.

A schedule S is view serializable if it is view equivalent to a serial schedule.

S and S’ are view equivalent. They meet all three conditions.

Therefore, S is view serializable.

S and S’ are view equivalent. They meet all three conditions.

Therefore, S is view serializable.


Schedule S

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)


T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

If Q is 100:

Schedule S: value of Q written by T3

Schedule S’: value of Q written by T3

If Q is 100:

Schedule S: value of Q written by T3

Schedule S’: value of Q written by T3


Schedule S

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)


T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

Blind writes – operations that perform write without having performed a read operation.

Blind writes – operations that perform write without having performed a read operation.


Schedule S

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)


T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

Cannot swap read(Q) of T1 and write(Q) of T2

Cannot swap read(Q) of T1 and write(Q) of T2

Cannot swap write(Q) of T2 and write(Q) of T1




Therefore, schedule S is not a conflict serializable schedule

Therefore, schedule S is not a conflict serializable schedule


Schedule S

T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)


T1 T2 T3

read(Q)

write(Q)

write(Q)

write(Q)

If the initial value of Q = 100

Schedules S and S’ final value for Q will be the same

If the initial value of Q = 100

Schedules S and S’ final value for Q will be the same


• A schedule S is view serializable if it is view equivalent to a serial schedule.

• Every conflict serializable schedule is also view serializable.

• a schedule which is view-serializable may not be conflict serializable.

• Every view serializable schedule that is not conflict serializable has blind writes.

View Serializability


Testing Conflict Serializability• A precedence graph consists of:

– A node for each transaction

1. A directed edge T1 T2’ if T1 executes write(Q) before T2 executes read(Q); that is, T2 reads the value of the item written by T1 ;

2. A directed edge T1 T2’ if T1 executes read(Q) before T2 executes write(Q); that is T2 writes a value into an item after it has been read by T1

3. A directed edge T1 T2’ if T1 executes write(Q) before T2 executes write(Q); that is, T2 writes a value into an item after it has been written by T1


Testing Conflict Serializability

1. A directed edge T1 T2’ if T1 executes write(Q) before T2 executes read(Q); that is, T2

reads the value of the item written by T1 ;

T1 T2

read(X)

write(X)

read(X)

write(X)

T1T2

Precedence graph



2. A directed edge T1 T2’ if T1 executes read(Q) before T2 executes write(Q); that is T2 writes a value into an item after it has been read by T1

T1 T2

read(X)

write(X)

read(Q) read(Q)

write(Q)

T1T2

Precedence graph



3. A directed edge T1 T2’ if T1 executes write(Q) before T2 executes write(Q); that is, T2 writes a value into an item after it has been written by T1

T1 T2

read(X)

read(X)

write(X)

write(X)

T1T2

Precedence graph



• A schedule is conflict serializable if and only if its precedence graph is acyclic.

T1T2

T3


Non-conflict Serializable Schedule

• If the precedence graph is a cycle, then the schedule is non-conflict serializable.

T1

T2

T3


Nonserial schedule: is conflict serializable

T1 T2

read(X)

write(X)

read(X)

write(X)

read(Y)

write(Y)

read(Y)

write(Y)

T1 executes write(X) before T2 executes read(x)

T1T2

Precedence graph

T1 executes write(Y) before T2 executes read(Y)


Non-conflict Serializable Schedule: exampleT1 T2

read(balx)

balx=balx + 100

write(balx)

read(balx)

balx=balx * 1.1

write(balx)

read(baly)

baly=baly * 1.1

write(baly)

read(baly)

baly=baly - 100

write(baly)

T1 is transferring 100 from one account with balx to another account with baly while T2 is increasing the balance of these two accounts by 10%

T1T2

x

y

Precedence graph






Example Schedule (Schedule A)T1 T2 T3 T4 T5

read(X)

read(Y)

read(Z)

read(V)

read(W)

write(W)

read(Y)

write(Y)

write(Z)

read(U)

read(Y)

write(Y)

read(Z)

write(Z)

read(U)

write(U)

T1 T2T1 T2

T3 T4T3 T4

T2 T4T2 T4

T1 T3T1 T3


Precedence Graph for Schedule

T1

T2T3

T4

T1 T2T1 T2T1 T3T1 T3

T2 T4T2 T4

T3 T4T3 T4


Test for View Serializability

• The precedence graph test for conflict serializability must be modified to apply to a test for view serializability.

• The problem of checking if a schedule is view serializable falls in the class of NP-complete problems. Thus existence of an efficient algorithm is unlikely.

• However practical algorithms that just check some sufficient conditions for view serializability can still be used.


Schedule S

T1 T2 T3

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)


T2 T1 T3

r(B)

w(A)

w(B)

r(A)

w(B)

r(A)

w(B)

Is S view- serializable?

Ref: Garcia, Molina, et. al


Polygraphs: Test for View- Serializability• Polygraph consists of:

1. A node for each transaction and additional nodes for the hypothetical T0 and Tf where • T0 is an hypothetical transaction that wrote the

initial values for each DB element read by any transaction in the schedules and

• Tf is an hypothetical transaction that reads every element written by one or more transactions after each schedule ends.

2. For each action ri(X) with source Tj, place an arc from Tj to Ti.



Polygraphs: Test for View- Serializability3. Suppose Tj is the source of a read ri(X), and Tk is another

writer of X. It is not allowed for Tk to intervene between Tj and Ti, so it must appear either before Tj or after Ti. We represent this condition by an arc pair (shown dashed) from Tk to Tj and from Ti to Tk. Intuitively, one or the other of an arc pair is “real” but we don’t care which, and when we try to make a polygraph acyclic, we can pick whichever of the pair helps to make it acyclic. However, there are cases where the arc becomes a single arc:

• If Tj is T0, then it is not possible for Tk to appear before Tj, so we use an arc Ti Tk in the place of the arc pair.

• If Ti is Tf, then Tk cannot follow Ti, so we can use an arc Tk Tj in pace of the arc pair.



Polygraphs: Test for View- Serializability

T0 T1TfT2

T3


B

T0 T1 T2 T3 Tf

w(A)

w(B)

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)

r(A)

r(B)




T0 T1TfT2

T3


B

A

T0 T1 T2 T3 Tf

w(A)

w(B)

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)

r(A)

r(B)




T0 T1TfT2

T3


B

A A

T0 T1 T2 T3 Tf

w(A)

w(B)

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)

r(A)

r(B)




T0 T1TfT2

T3


B

A A

A

B

T0 T1 T2 T3 Tf

w(A)

w(B)

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)

r(A)

r(B)




T0 T1TfT2

T3

B

A A

A

B

T0 T1 T2 T3 Tf

w(A)

w(B)

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)

r(A)

r(B)

Arcs (edges) based on A

Writers of A: T0 and T2

• T2 T1 based on A– since neither T0 nor T2 can get in the middle

of the arc T2 T1, no additional arcs are needed.

• T2 T3 based on A– since neither T0 nor T2 can get in the middle

of the arc T2 T3, no additional arcs are needed.

• T2 Tf based on A– since neither T0 nor T2 can get in the middle

of the arc T2 Tf, no additional arcs are needed.




T0 T1TfT2

T3

B

A A

A

B

T0 T1 T2 T3 Tf

w(A)

w(B)

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)

r(A)

r(B)

Arcs (edges) based on B: T0 T2 and T3 Tf

Writers of B: T0, T1, T2 and T3

• T0 T2 based on B– T1 (arc pairs): T1 T0 and T2 T1

• T1 T0: not possible since T1 cannot come before T0; nothing can precede T0

• T2 T1: OK but it is already present in the graph because of A.

– T3 (arc pairs): T3 T0 and T2 T3• T3 T0: not possible since T3 cannot come

before T0; nothing can precede T0





T0 T1TfT2

T3

B

A A

A

B

T0 T1 T2 T3 Tf

w(A)

w(B)

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)

r(A)

r(B)

Arcs (edges) based on B: T0 T2 and T3 Tf

Writers of B: T0, T1, T2 and T3

• T3 Tf based on B

– T0 (arc pairs): T0 T3 and Tf T0

• T0 T3: not possible to move T0

• Tf T0: not possible to move T0


• T1 T3: not present, so draw an arv

• Tf T1: T1 cannot appear after Tf



• Tf T2: T2 cannot appear after Tf


B



T0 T1TfT2

T3

B

A A

A

B

T0 T1 T2 T3 Tf

w(A)

w(B)

r(B)

w(A)

r(A)

r(A)

w(B)

w(B)

w(B)

r(A)

r(B)

Acyclic graph: T2 T1 T3


B


Concurrency Control vs. Serializability Tests

• Testing a schedule for serializability after it has executed is a little too late!

• Goal – to develop concurrency control protocols that will assure serializability. They will generally not examine the precedence graph as it is being created; instead a protocol will impose a discipline that avoids nonseralizable schedules.

• Tests for serializability help understand why a concurrency control protocol is correct.


Outline

• Schedule– Serial schedule– Non-serial schedule

• Serializability– Conflict serializability– View serializability

• Recoverability


Recoverability• Serializability identifies schedules that

maintain the consistency of the database, assuming that none of the transactions in the schedule fail.

• Recoverability may be applied when transactions fail bearing in mind that:– The atomicity property requires that the effects

of the transaction (failed) are undone.– The durability property states that once a

transaction commits, its changes cannot be undone.


Recoverability

• Why a recoverable schedule is desired?

– Need to address the effect of transaction failures on concurrently running transactions.

• What is a recoverable schedule?– if a transaction Tj reads a data item previously

written by a transaction Ti , the commit operation of Ti appears before the commit operation of Tj (that is, Ti must commit first before Tj commits)


Recoverability

If T8 should abort, T9 would have to be aborted also

• The following schedule is recoverable if T8 commits before T9 commits

commitcommit

commitcommit


Recoverability

If T8 should abort, T9 would have read (and possibly shown to the user) an inconsistent database state. Hence database must ensure that schedules are recoverable.

• The following schedule is not recoverable if T9 commits immediately after the read

commitcommit

commitcommit


T9 T10

begin _transaction

read(balx)

balx=balx + 100

write(balx) begin _transaction

read(balx)

balx=balx * 1.1

write(balx)

read(baly)

baly=baly * 1.1

write(baly)

read(baly) commit

baly=baly - 100

write(baly)

• T10 cannot be undone because it has already committed; the durability property does not allow this.

• Thus, this schedule is nonrecoverable.

instead of a commit operation, T9 decides to rollback

failfail


Recoverability• What is a cascading rollback?

– a single transaction failure leads to a series of transaction rollbacks. Consider the following schedule where none of the transactions has yet committed (so the schedule is recoverable)

• T10 writes a value of A

• If T10 fails, T11 and T12 must also be rolled back.

• Can lead to the undoing of a significant amount of work

failfail


Recoverability

• Cascadeless schedules — cascading rollbacks cannot occur; for each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti, the commit operation of Ti appears before the read operation of Tj.

• Every cascadeless schedule is also recoverable• It is desirable to restrict the schedules to those that

are cascadeless.


Cascadeless

If T1 should abort, T2 has not yet read the value of A.

T1 T2

read(A)

write (A)

commit

read(A)

the commit operation of T1 appears before the read operation of T2.

the commit operation of T1 appears before the read operation of T2.


END

Transaction Management

Documents

Transcript of Transaction Management