Download Transaction processing systems

Quick revision on
Transaction Processing
Concepts
By:
Dr. Yousry Taha
Copyright 2010
Intoduction
– The concept of transaction :
• provides a mechanism for describing logical units of
database processing.
– Transaction processing systems :
• systems with large databases and hundreds of
concurrent users that are executing database
transactions.
IS 533 - Transactions
2
Singile user Versus Multiuser Systems
• Single-User : at most one user at a time can use the system
•
Multiuser : many users can use the system concurrently.
• Multiprogramming : allows the computer to execute multiple
programs at the same time.
• Interleaving : keeps the CPU busy when a process requires an input
or output operation, the CPU switched to execute another process
rather than remaining idle during I/O time .
• Most of the theory concerning concurrency control in databases is
developed in terms of interleaved concurrency.
IS 533 - Transactions
3
Transactions, Read and Write Operations, and
DBMS Buffers
• A Transaction : is a logical unit of database processing that
includes one or more database access operation.
• All database access operations between Begin Transaction and
End Transaction statements are considered one logical
transaction.
• If the database operations in a transaction do not update the
database but only retrieve data , the transaction is called a readonly transaction.
• Basic database access operations :
– read_item(X) : reads a database item X into program variable.
– Write_item(X) : Writes the value of program variable X into the database item X.
IS 533 - Transactions
4
Why Concurrency Control is needed
•
Several problems can occur when concurrent
transactions execute in an uncontrolled
manner.
1. The Lost Update Problem :
T1
Read_item(X);
X=:X-N;
Time
Write_item(X);
Read_item(Y);
Y=:Y+N;
T2
Read_item(X);
X=:X+M;
Item X has
incorrect
value
Write_item(X);
Write_item(Y);
IS 533 - Transactions
5
Why Concurrency Control is needed (continued)
2. The temporary Update (or Dirty read) problem
T2
T1
Read_item(X);
X=:X-N;
write_item(X);
Read_item(X);
X=:X+M;
write_item(X);
Time
read_item(Y);
T1 fails and must rollback,
meanwhile T2 has read the
temporary value
IS 533 - Transactions
6
Why Concurrency Control is needed (continued)
3.
The Incorrect Summary Problem
T3
T1
Sum:=0;
Read_item(A);
sum:=sum+A;
Read_item(X);
X=:X-N;
write_item(X);
Time
.
.
.
Read_item(X);
sum:=sum+x;
read_item(Y);
sum:=sum+Y;
T3 reads X after N is
subtracted and reads Y
before N is added;
read_item(Y);
Y:=Y+N;
write_item(Y);
4. Unrepeatable Read problem: A transaction reads items twice with two
different values because it was changed by another transaction between the two reads.
IS 533 - Transactions
7
Why Recovery Is Needed
• There several possible reasons for a
transaction to fail
– A computer failure : A hardware, software, or network error
occurs in the computer system during transaction execution.
– A transaction or system error : Some operations in the
transaction may cause it to fail.
– Local errors or exception conditions detected by the
transaction.
IS 533 - Transactions
8
Why Recovery Is Needed (continued)
– Concurrency control enforcement : The concurrency control
method may decide to abort the transaction.
– Disk failure : all disk or some disk blocks may lose their data
– Physical problems : Disasters,theft, fire, etc.
• The system must keep sufficient information
to recover from the failure.
IS 533 - Transactions
9
Transaction states and additional operations
• 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.
• The recovery manager keeps track of the following
operations :
–
–
–
–
–
BEGIN_TRANSACTION
READ OR WRITE
END_TRANSACTION
COMMIT_TRANSACTION
ROLLBACK
IS 533 - Transactions
10
Transaction states and additional operations
(continued)
READ/
WRITE
END
TRANSACTION
BEGIN
TRANSACTION
COMMIT
PARTIALLY
COMMITTED
ACTIVE
ABORT
COMMITTED
ABORT
FAILD
TERMINATED
Figure 19.4 State transition diagram illustrating the states for transaction execution
IS 533 - Transactions
11
The System Log
• The system maintains a log to keep track of all
transaction operations that affect the values of
database items.
• This log may be needed to recover from failures.
• Types of log records :
– [start_transaction,T] : indicates that transaction T has started
execution.
– [write_item,T,X,old_value,new_value] : indicates that
transaction T has changed the value of database item X from
old_value to new_value.
(new_value may not be recorded)
IS 533 - Transactions
12
The System Log (continued)
– [read_item,T,X]: indicates that transaction T has read
the value of database item X.
(read_item may not be recorded)
– [commit,T]: transaction T has recorded permanently .
– [abort,T]: indicates that transaction T has been
aborted.
IS 533 - Transactions
13
Desirable Properties of transactions
• ACID should be enforced by the concurrency
control and recovery methods of the DBMS.
• ACID properties of transactions :
– Atomicity : a transaction is an atomic unit of processing; it is
either performed entirely or not performed at all.
(It is the responsibility of recovery)
– Consistency : transfer the database from one consistent state to
another consistent state
(It is the responsibility of the applications and DBMS to
maintain the constraints)
IS 533 - Transactions
14
Desirable Properties of transactions
(continued)
– Isolation : the execution of the transaction should be
isolated from other transactions (Locking)
(It is the responsibility of concurrency)
* Isolation level:
-Level 0 (no dirty read)
-Level 1 ( no lost update)
-Level 2 (no dirty+ no lost)
-Level 3 (level 2+repeatable reads)
– Durability : committed transactions must persist in the
database ,i.e. those changes must not be lost because of
any failure.
(It is the responsibility of recovery)
IS 533 - Transactions
15
Schedules of Transactions
• Schedule(or History) S of n transactions
T1,T2,..,Tn is an ordering of operations of the
transactions with the following conditions :
– for each transaction Ti that participate in S , the operations of Ti in S
must appear in the same order in which they occur in Ti
– the operations from other transactions Tj can be interleaved with the
operations of Ti in S.
• The symbols r,w,c, and a are used for the
operations read_item, write_item, commit, and
abort respectively.
IS 533 - Transactions
16
Schedules of Transactions (continued)
• Two operations are said to be conflict if:
– they belong to different tansactions
– they access the same item X
– at least one the operations is a write_item(X)
Ex:
S1: r1(x);r2(x);w1(x);r1(y);w2(x);w1(y);
conflicts: [r1(x);w2(x)] – [r2(x);w1(x)] – [w1(x); w2(x)]
IS 533 - Transactions
17
Schedules of Transactions (continued)
• A schedule S of n transactions T1,T2,..,Tn is said to be
a complete schedule if :
– The operations in S are exactly those operations in T1,T2,.., Tn ,
including a commit or abort operation as the last operation for
each transaction in the schedule.
– For any pair of operations from the same transaction Ti, their
order of appearance in S the same as their order of appearance
in Ti
– For any two conflicting operations, one of the two must occur
before the other in the schedule.
IS 533 - Transactions
18
Characterizing Schedules based on
Recoverability
• Type of schedules :
– recoverable scheduls : once a transaction T is
commited , it should never rollbacked.
• i.e. If no transaction T in S commits until all
transactions T’ that have written an item that T
reads have committed.
• It is possible for Cascading rollback to occur when
an uncommited transaction has to be rolled back.
IS 533 - Transactions
19
Examples
• 1- Sa: r1(x);r2(x);w1(x);r1(y);w2(x);c2;w1(y);c1;
Recoverable schedule, even it suffers from the lost
update problem [w1(x);w2(x)]
• 2- Sc: r1(x); w1(x); r2(x); r1(y);w2(x);c2;a1;
Nonrecoverable schedule. Why?
T2 reads x from T1, and then T2 commits before
T1 commits. If T1 aborts, then T2 must be aborted
after had been committed.
IS 533 - Transactions
20
Examples
• 3- To make Sc recoverable, c2 of Sc must be
postponed until after T1 commits as follows:
Sd: r1(x); w1(x); r2(x); r1(y);w2(x); w1(y);c1; c2;
• If T1 aborts, then T2 should also abort as follows:
Se: r1(x); w1(x); r2(x); r1(y);w2(x); w1(y);a1; a2;
IS 533 - Transactions
21
Characterizing Schedules based on
Recoverability (continued)
– Cascadeless schedule : if every transaction in
the schedule reads only items that were written
by committed transactions.
– Strict Schedule : transactions can neither read
nor write an item X until the last transaction
that wrote X has committed or aborted.
IS 533 - Transactions
22
Serializability of Schedules
Serial, Nonserial, and Conflict-Serializable schedules
• 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.
• No interleaving occurs in serial schedule
• if we consider transactions to be independant,
then every serial schedule is considered correct.
IS 533 - Transactions
23
Serializability of Schedules
Serial, Nonserial, and Conflict-Serializable schedules
(continued)
• the problems of serial schedules :
– they limit concurrency or interleaving of operations
• if a transaction waits for an I/O operation to
complete, we cannot switch the CPU Processor to
another transaction
• if some transaction T is long , the other
transactions must wait for T to complete all its
operations.
IS 533 - Transactions
24
Serial, Nonserial, and Conflict-Serializable schedules
(continued)
• A schedule S of n transactions is serializable if it is equivalent to
some serial schedule of the same n transactions.
• Two schedules are called result equivalent if they produce the
same final state of the database.
• Two schedules are said to be conflict equivalent if the order of
any two conflicting operations is the same in both schedules
• schedule S is conflict serializable if it is conflict equivalent to
some serial schedule S’.
IS 533 - Transactions
25
Testing for Conflict Serializability of a Schedule
(Precedence Graph)
• Algorithm for Testing conflict serializability of
schedule S
• For each transaction Ti participating in schedule S, create a
node labeled Ti in the percedence graph
• For each case in S where Tj executes a read_item(X) after Ti
executes a write_item(X),create an edge (TiTj)
• For each case in S where Tj executes a write_item(X) after Ti
executes a read_item(X) create an edge (TiTj)
• For each case in S where Tj executes a write_item(X) after Ti
executes a write_item(X) create an edge (TiTj)
• The schedule S is serializable if and only if the precedance
graph has no cycles.
IS 533 - Transactions
26
Examples (Precedence Graph)
Assume we have these three transactions:
• T1: r1(x);w1(x);r1(y);w1(y)
• T2: r2(z);r2(y);w2(y);r2(x);w2(x)
• T3: r3(y);r3(z);w3(y);w3(z)
Assume we have these schedule:
• S1: r2(z);r2(y);w2(y); r3(y);r3(z); r1(x);w1(x);
w3(y);w3(z);r2(x); r1(y);w1(y); w2(x)
T1
No equivalent serial schedule
(cycle x(T1T2),y(T2T1))
y
(cycle x(T1T2),yz(T2T3),y(T3T1))
y
T2
x
y,z
T3
IS 533 - Transactions
27
Examples (Precedence Graph)
Assume we have another schedule for the same transactions:
• S2: r3(y);r3(z);r1(x); w1(x);w3(y);w3(z);r2(z);
r1(y);w1(y);r2(y); w2(y);r2(x);w2(x)
Equivalent serial schedule
x,y
T3T1T2
T1
T2
y
y,z
T3
IS 533 - Transactions
28
Uses of serializability
• Note that: being Serializable is distinct from being
Serial.
• A Serial Schedule leads to inefficient utilization
of CPU because of no interleaving of operations
from different transactions.
• A Serializable Schedule gives the benefits of
concurrent execution without giving up any
correctness
IS 533 - Transactions
29
Uses of serializability (continued)
• Practically, it is difficult to test for the
serializability.
• Also, it is impractical to execute the schedule and
then test the result for serializability and cancel the
effect of the schedule if it is not serializable.
• The approach taken in most commercial DBMSs
is to design Protocols that will ensure
serializabilty of all schedules.
IS 533 - Transactions
30
View Equivalence and View Serializability
• Two schedules S and S’ are said to be view equivalent
when :
– The same set of transactions participates in S and S’, and S
and S’ include the same operations of those transactions.
– For any operation ri(X) of Ti in S, if the value of X read by the
operation has been written by an operation wj(X) of Tj, the same
condition must hold for the value of X read by operation ri(X) of Ti in
S’
– If the operation wk(Y) of Tk is the last operation to write item Y in
S,then wk(Y) of Tk must also be the last operation to write item Y in S’
• A schedule S is said to be view serializable if it is view
equivalent to a serial schedule .
IS 533 - Transactions
31
Transaction Support in SQL
• Transaction initiation is done implicitly when SQL
statement is executed.
• Every transaction must have explicit end statement,
which is either a commit or a rollback.
• Every transaction has certain characteristics :
– access mode : read only or read write.
– diagnostic area size : option specifies an integer value n,
indicating the number of conditions that can be held
simultaneously in the diagnostic area.
– The isolation level: option that can be read uncommitted, read
committed, repeatable read, serializable.
IS 533 - Transactions
32
Transaction Support in SQL (continued)
If a transaction executes at a lower isolation
level than serializable, then one or more of
the following three violations may occur:
• Dirty read
• Nonrepeatable read
• Phantom: A transaction T1 may read a set of rows from a
table, then another transaction T2 inserts new rows. If T1
repeated, then it will see a Phantom.
IS 533 - Transactions
33
Transaction Support in SQL (continued)
Possible Violations Based on Isolation Level:
Types of Violation
Isolation
Level
Dirty
read
Read uncommitted
Read committed
Repeatable read
Serializable
yes
no
no
no
Nonrepeatable
read
yes
yes
no
no
IS 533 - Transactions
Phantom
yes
yes
yes
no
34
Transaction Support in SQL (continued)
Example for SQL transaction:
EXEC SQL WHENEVER SQLERROR GOTO UNDO;
EXEC SQL SET TRANSACTION
READ WRITE
DIAGNOSTICS SIZE 5
ISOLATION LEVEL SERIALIZABLE;
EXEC SQL INSERT EMPLOYEE
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: ……..
IS 533 - Transactions
35