1. Quick revision on Transaction Processing Concepts By: Dr. Yousry Taha Copyright 2010

2. IS 533 - Transactions2 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.

3. IS 533 - Transactions3 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.

4. IS 533 - Transactions4 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.

5. IS 533 - Transactions5 Why Concurrency Control is needed Several problems can occur when concurrent transactions execute in an uncontrolled manner. 1.The Lost Update Problem : T1T2 Read_item(X); X=:X-N; Time Read_item(X); X=:X+M; Write_item(X); Read_item(Y); Y=:Y+N; Write_item(X); Item X has incorrect value Write_item(Y);

6. IS 533 - Transactions6 Why Concurrency Control is needed (continued) 2.The temporary Update (or Dirty read) problem T1 T2 Read_item(X); X=:X-N; write_item(X); Time Read_item(X); X=:X+M; write_item(X); read_item(Y); T1 fails and must rollback, meanwhile T2 has read the temporary value

7. IS 533 - Transactions7 Why Concurrency Control is needed (continued) 3.The Incorrect Summary Problem 4.Unrepeatable Read problem: A transaction reads items twice with two different values because it was changed by another transaction between the two reads. T1 T3 Read_item(X); X=:X-N; write_item(X); Time Read_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;......

8. IS 533 - Transactions8 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.

9. IS 533 - Transactions9 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.

10. IS 533 - Transactions10 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

11. IS 533 - Transactions11 Transaction states and additional operations (continued) ACTIVE PARTIALLY COMMITTED FAILD TERMINATED COMMITTED BEGIN TRANSACTION END TRANSACTION COMMIT ABORT Figure 19.4 State transition diagram illustrating the states for transaction execution READ / WRITE

12. IS 533 - Transactions12 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)

13. IS 533 - Transactions13 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.

14. IS 533 - Transactions14 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)

15. IS 533 - Transactions15 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)

16. IS 533 - Transactions16 Schedules of Transactions Schedule(or History) S of n transactions T 1,T 2,..,T n is an ordering of operations of the transactions with the following conditions : –for each transaction T i that participate in S, the operations of T i in S must appear in the same order in which they occur in T i –the operations from other transactions T j can be interleaved with the operations of T i in S. The symbols r,w,c, and a are used for the operations read_item, write_item, commit, and abort respectively.

17. IS 533 - Transactions17 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: r 1 (x);r 2 (x);w 1 (x);r 1 (y);w 2 (x);w 1 (y); conflicts: [r 1 (x);w 2 (x)] – [r 2 (x);w 1 (x)] – [w 1 (x); w 2 (x)]

18. IS 533 - Transactions18 Schedules of Transactions (continued) A schedule S of n transactions T 1,T 2,..,T n is said to be a complete schedule if : –The operations in S are exactly those operations in T 1,T 2,.., T n, 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 T i, their order of appearance in S the same as their order of appearance in T i –For any two conflicting operations, one of the two must occur before the other in the schedule.

19. IS 533 - Transactions19 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.

20. IS 533 - Transactions20 Examples 1- S a : r 1 (x);r 2 (x);w 1 (x);r 1 (y);w 2 (x);c 2 ;w 1 (y);c 1 ; Recoverable schedule, even it suffers from the lost update problem [w 1 (x);w 2 (x)] 2- S c : r 1 (x); w 1 (x); r 2 (x); r 1 (y);w 2 (x);c 2 ;a 1 ; 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.

21. IS 533 - Transactions21 Examples 3- To make S c recoverable, c 2 of Sc must be postponed until after T1 commits as follows: S d : r 1 (x); w 1 (x); r 2 (x); r 1 (y);w 2 (x); w 1 (y);c 1 ; c 2 ; If T1 aborts, then T2 should also abort as follows: S e : r 1 (x); w 1 (x); r 2 (x); r 1 (y);w 2 (x); w 1 (y);a 1 ; a 2 ;

22. IS 533 - Transactions22 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.

23. IS 533 - Transactions23 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.

24. IS 533 - Transactions24 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.

25. IS 533 - Transactions25 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’.

26. IS 533 - Transactions26 Testing for Conflict Serializability of a Schedule (Precedence Graph) Algorithm for Testing conflict serializability of schedule S For each transaction T i participating in schedule S, create a node labeled T i in the percedence graph For each case in S where T j executes a read_item(X) after T i executes a write_item(X),create an edge (T i  T j ) For each case in S where T j executes a write_item(X) after T i executes a read_item(X) create an edge (T i  T j ) For each case in S where T j executes a write_item(X) after T i executes a write_item(X) create an edge (T i  T j ) The schedule S is serializable if and only if the precedance graph has no cycles.

27. IS 533 - Transactions27 Examples (Precedence Graph) Assume we have these three transactions: T1: r 1 (x);w 1 (x);r 1 (y);w 1 (y) T2: r 2 (z);r 2 (y);w 2 (y);r 2 (x);w 2 (x) T3: r 3 (y);r 3 (z);w 3 (y);w 3 (z) Assume we have these schedule: S1: r 2 (z);r 2 (y);w 2 (y); r 3 (y);r 3 (z); r 1 (x);w 1 (x); w 3 (y);w 3 (z);r 2 (x); r 1 (y);w 1 (y); w 2 (x) No equivalent serial schedule (cycle x(T 1  T 2 ),y(T 2  T 1 )) (cycle x(T 1  T 2 ),yz(T 2  T 3 ),y(T 3  T 1 )) y x yy,z T1T1 T2T2 T3T3

28. IS 533 - Transactions28 Examples (Precedence Graph) Assume we have another schedule for the same transactions: S2: r 3 (y);r 3 (z);r 1 (x); w 1 (x);w 3 (y);w 3 (z);r 2 (z); r 1 (y);w 1 (y);r 2 (y); w 2 (y);r 2 (x);w 2 (x) Equivalent serial schedule T 3  T 1  T 2 x,y yy,z T1T1 T2T2 T3T3

29. IS 533 - Transactions29 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

30. IS 533 - Transactions30 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.

31. IS 533 - Transactions31 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 r i (X) of T i in S, if the value of X read by the operation has been written by an operation w j (X) of T j, the same condition must hold for the value of X read by operation r i (X) of T i in S’ –If the operation w k (Y) of T k is the last operation to write item Y in S,then w k (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.

32. IS 533 - Transactions32 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.

33. IS 533 - Transactions33 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 T 1 may read a set of rows from a table, then another transaction T 2 inserts new rows. If T 1 repeated, then it will see a Phantom.

34. IS 533 - Transactions34 Transaction Support in SQL (continued) Possible Violations Based on Isolation Level: Types of Violation IsolationDirtyNonrepeatablePhantom Levelread read Read uncommittedyes yes yes Read committedno yes yes Repeatable readno no yes Serializableno no no

35. IS 533 - Transactions35 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: ……..