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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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: ..
IS 533 - Transactions
Top Related