Transaction Processing

Quick revision on Transaction Processing Concepts

By:Dr. Yousry Taha

Copyright 2010

IS 533 - Transactions

IS 533 - Transactions*IntoductionThe 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*Singile user Versus Multiuser SystemsSingle-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*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 read-only 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*Why Concurrency Control is needed Several problems can occur when concurrent transactions execute in an uncontrolled manner.The Lost Update Problem :T1T2Read_item(X);X=:X-N;TimeRead_item(X);X=:X+M;Write_item(X); Read_item(Y);Y=:Y+N;Write_item(X);Item X has incorrect valueWrite_item(Y);


IS 533 - Transactions*Why Concurrency Control is needed (continued)

The temporary Update (or Dirty read) problemT1T2Read_item(X);X=:X-N;write_item(X);TimeRead_item(X);X=:X+M;write_item(X);read_item(Y);T1 fails and must rollback, meanwhile T2 has read the temporary value


IS 533 - Transactions*Why Concurrency Control is needed (continued)The Incorrect Summary Problem

Unrepeatable Read problem: A transaction reads items twice with two different values because it was changed by another transaction between the two reads.T1T3Read_item(X);X=:X-N;write_item(X);TimeRead_item(X);sum:=sum+x;read_item(Y);sum:=sum+Y;read_item(Y);Y:=Y+N;write_item(Y);T3 reads X after N is subtracted and reads Y before N is added; Sum:=0;Read_item(A);sum:=sum+A;...


IS 533 - Transactions*Why Recovery Is NeededThere several possible reasons for a transaction to failA 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*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*Transaction states and additional operationsA 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_TRANSACTIONREAD OR WRITEEND_TRANSACTIONCOMMIT_TRANSACTIONROLLBACK


IS 533 - Transactions*Transaction states and additional operations(continued)ACTIVEPARTIALLYCOMMITTEDFAILDTERMINATEDCOMMITTEDBEGINTRANSACTIONENDTRANSACTIONCOMMITABORTABORTFigure 19.4 State transition diagram illustrating the states for transaction executionREAD/WRITE


IS 533 - Transactions*The System LogThe 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*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*Desirable Properties of transactionsACID 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*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*Schedules of TransactionsSchedule(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 Tithe 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*Schedules of Transactions (continued)Two operations are said to be conflict if:they belong to different tansactions they access the same item Xat 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*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*Characterizing Schedules based on RecoverabilityType 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*Examples1- 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*Examples3- 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*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*Serializability of SchedulesSerial, Nonserial, and Conflict-Serializable schedulesA 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*Serializability of SchedulesSerial, 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*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*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 graphFor each case in S where Tj executes a read_item(X) after Ti executes a write_item(X),create an edge (TiTj) For each case in S where Tj executes a write_item(X) after Ti executes a read_item(X) create an edge (TiTj) For each case in S where Tj executes a write_item(X) after Ti executes a write_item(X) create an edge (TiTj) The schedule S is serializable if and only if the precedance graph has no cycles.


IS 533 - Transactions*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)

No equivalent serial schedule(cycle x(T1T2),y(T2T1))(cycle x(T1T2),yz(T2T3),y(T3T1))

yxyy,zT1T2T3


IS 533 - Transactions*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 T3T1T2

x,yyy,zT1T2T3


IS 533 - Transactions*Uses of serializabilityNote 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*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*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 SIf 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*Transaction Support in SQLTransaction 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*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 readNonrepeatable readPhantom: 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*Transaction Support in SQL (continued)Possible Violations Based on Isolation Level:

Types of Violation

IsolationDirtyNonrepeatablePhantomLevelread read

Read uncommittedyes yes yesRead committedno yes yesRepeatable readno no yesSerializableno no no


IS 533 - Transactions*Transaction Support in SQL (continued)Example for SQL transaction:

EXEC SQL WHENEVER SQLERROR GOTO UNDO;EXEC SQL SET TRANSACTIONREAD WRITEDIAGNOSTICS SIZE 5ISOLATION LEVEL SERIALIZABLE;EXEC SQL INSERT EMPLOYEEVALUES (Robert , Smith , 991004321 , 2 , 35000); EXEC SQL UPDATE EMPLOYEESET SALARY = SALARY * 1.1 WHERE DNO = 2;EXEC SQL COMMIT;GOTO THE_END;UNDO: EXEC SQL ROLLBACK;THE_END: ..


Documents

Transaction Processing