CSCI Transaction Processing Concepts 1 TRANSACTION PROCESSING CONCEPTS Dr. Awad Khalil Computer Science Department AUC

CSCI Transaction Processing Concepts 2 Content  Types of Processing  The Concept of Transaction  Concurrency & Recovery Controls  The System Log  Schedules  Serializability of Schedules

CSCI Transaction Processing Concepts 3 Types of Processing: Single-User versus Multiuser Systems  A DBMS is single-user if at most one user at time can use the system.  A DBMS is multiuser if many users can use the system concurrently - that is at the same time.

CSCI Transaction Processing Concepts 4 Types of Processing: Interleaved versus simultaneous concurrency

CSCI Transaction Processing Concepts 5 Transaction  In multiuser DBMSs, the stored data items are the primary resources that may be accessed concurrently by user programs, which are constantly retrieving information from and modifying the database.  The execution of a program that accesses or changes the contents of the database is called transaction.

CSCI Transaction Processing Concepts 6 Transaction (Cont’d)  The database access operations that a transaction can include are:  read_item ( X ): Reads a database item named X into a program variable named also X.  write_item ( X ): Writes the value of program variable X into the database item named X.

CSCI Transaction Processing Concepts 7 Transaction – read_item(X) 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 named X.

CSCI Transaction Processing Concepts 8 Transaction – write_item(X) 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 named X into its correct location in the buffer. 4. Store the updated block from the buffer back to disk.

CSCI Transaction Processing Concepts 9 Transaction – An Example Transaction T1 Transaction T2 Transaction T1 Transaction T read_item (X); read_item (X); read_item (X); read_item (X); X := X - N; X := X + M; write_item(X); write_item(X); read_item(Y); Y := Y + N; write_item(Y);

CSCI Transaction Processing Concepts 10 Concurrency & Recovery Controls  Concurrency and Recovery controls are mainly concerned with the database access commands in a transaction.  Transactions submitted by the various users may execute concurrently and may access and update the same database items. If this concurrent execution is uncontrolled, it may lead to problems such as inconsistent database.

CSCI Transaction Processing Concepts 11 Why Concurrency Control ?  Several problems can occur when concurrent transactions execute in an uncontrolled manner.  We assume a simple airline reservation database in which a record is stored for each airline flight. Each record includes the number of reserved seats on that flight as a named data item, among other information.  The same program can be used to execute many transactions, each with different flights and number of seats to be booked.  For concurrency control purpose, a transaction is a particular execution of a program on a specific date, flight, and number of seats.

CSCI Transaction Processing Concepts 12 Transaction – An Example Transaction T1 Transaction T2 Transaction T1 Transaction T read_item (X); read_item (X); read_item (X); read_item (X); X := X - N; X := X + M; write_item(X); write_item(X); read_item(Y); Y := Y + N; write_item(Y);

CSCI Transaction Processing Concepts 13 Problems: The Lost Update  This occurs when two transactions that access the same database items have their operations interleaved in a way that makes the value of some database item incorrect.

CSCI Transaction Processing Concepts 14 Problems: The Temporary Update “Dirty Read”  This occurs when one transaction updates a database item and then the transaction fails for some reason. The updated item is accessed by another transaction before it is changed back to its original value.

CSCI Transaction Processing Concepts 15 Problems: The Incorrect Summary  This occurs when one transaction is calculating an aggregate summary function on a number of records while other transactions are updating some of these records. In this situation, the aggregate function may calculate some values before they are updated and others after they are updated.

CSCI Transaction Processing Concepts 16 Why Recovery Control?  Whenever a transaction is submitted to a DBMS for execution, the system is responsible for making sure that either:  all the operations in the transaction are completed successfully and their effect is recorded permanently in the database, OR  The transaction has no effect whatsoever on the database or on any other transactions.  The DBMS must not permit some operations of a transaction T to be applied to the database while other operations of T are not.  This may happen if a transaction fails after executing some of its operations but before executing all of them.

CSCI Transaction Processing Concepts 17 Types of Failures 1. A computer failure (system crash): A hardware or software error occurs in the computer system during transaction execution. 2. A transaction or system error : Some operation in the transaction may cause it to fail, such as integer overflow or division by zero. 3. Local errors or exception conditions: During transaction execution, certain conditions may occur that necessitate cancellation of the transaction. For example, data for the transaction may not be found, or insufficient account balance in a banking database. 4. Concurrency control enforcement: The concurrency control method may decide to abort the transaction, to be restarted later, because it violates serializability or because several transactions are in a state of deadlock. 5. Disk failure: Some disk blocks may lose their data because of a read or write malfunction or because of a disk read/write head crash. 6. Physical problems and catastrophes: Such as power or air- conditioning failure, fire, theft, sabotage, overwriting disks by mistake, … etc.

CSCI Transaction Processing Concepts 18 Transaction Concepts  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:  BEGIN_TRANSACTION.  READ or WRITE.  END_TRANSACTION.  COMMIT_TRANSACTION.  ROLLBACK (or ABORT).  UNDO.  REDO.

CSCI Transaction Processing Concepts 19 Transaction States

CSCI Transaction Processing Concepts 20 The System Log  To be able to recover from transaction failures, the system maintains a log ( journal ).  The log keeps track of all transactions that affect the values of database items. The log is kept on disk and includes the following entries:  [ start_transaction, T ]  [ write_item, T, X,old_value,new_value]  [ read_item, T, X ]  [ commit, T ]  [ abort, T ]

CSCI Transaction Processing Concepts 21 The System Log (Cont’d)  If the system crashes, we can recover a consistent database state by examining the log and using one of the recovery techniques.  The Recovery manager can undo the effect of each WRITE operation of a transaction T by tracing backward through the log and resetting all items changed by the WRITE operation of T to their old_values.  The Recovery manager can also redo the effect of the WRITE operations of a transaction T by tracing forward through the log and setting all items changed by a WRITE operation of T to their new_values.

CSCI Transaction Processing Concepts 22 Commit Point of a Transaction  A transaction T reaches its commit point when all its operations that access the database have been executed successfully and the effect of all the transaction operations on the database has been recorded in the log.  Beyond the commit point, the transaction is said to be committed, and its effect is assumed to be permanently recorded in the database.  The transaction then writes an entry [ commit, T ] into the log.

CSCI Transaction Processing Concepts 23 Checkpoints  A [ checkpoint ] record is written into the log periodically at the point when the system writes out to the database on disk the effect of all WRITE operations of committed transactions  All transactions that have their [ commit, T ] entries in the log before a [ checkpoint ] entry do not need to have their WRITE operations redone in case of system crash.  Taking a checkpoint consists of the following actions: 1. Suspend execution of transactions temporarily. 2. Force-write all update operations of committed transactions from main memory buffers to disk. 3. Write a [ checkpoint ] record to the log, and force-write the log to disk. 4. Resume executing transactions.

CSCI Transaction Processing Concepts 24 Desirable Properties of Transaction  Atomic transactions should possess several properties. These are often called the ACID properties: 1. Atomicity: A transaction is an atomic unit of processing; it is either performed in its entirety or not performed at all. 2. Consistency preservation: A correct execution of the transaction must take the database from one consistent state to another. 3. Isolation: A transaction should not make its updates visible to other transactions until it is committed. 4. Durability or permanency: Once a transaction changes the database and changes are committed, these changes must never be lost because of subsequent failure.

CSCI Transaction Processing Concepts 25 Schedules & Recoverability  A schedule (or history ) S of n transactions T1, T2,..., Tn is an ordering of the operations of the transactions subject to the constraint that, for each transaction Ti that participates in S, the operations of Ti in S must appear in the same order in which they occur in Ti. S a : r1(X); r2(X); w1(X); r1(Y); w2(X); c2;w1(Y); c1; S b : r1(X); w1(X); r2(X); w2(X); c2; r1(Y); a1;  Two operations in a schedule are said to conflict if they belong to different transactions, if they access the same item X, and if one of the two operations is a write_item(X).

CSCI Transaction Processing Concepts 26 Schedules (Cont’d)  A schedule S of n transactions T1, T2,..., Tn, is said to be a complete schedule if the following conditions hold:  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 is 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.

CSCI Transaction Processing Concepts 27 Characterizing Schedules based on Recoverability 1- recoverable Schedule A schedule S is said to be recoverable if no transaction T in S commits until all transactions T’ that have written an item that T reads have committed. A schedule S is said to be recoverable if no transaction T in S commits until all transactions T’ that have written an item that T reads have committed. T is said to read from transaction T’ in a schedule S if some item X is first written by T’ and later read by T. T is said to read from transaction T’ in a schedule S if some item X is first written by T’ and later read by T. Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1;is recoverable ! Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1; is not recoverable ! Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;is recoverable !

CSCI Transaction Processing Concepts 28 Characterizing Schedules based on Recoverability 2- Avoiding Cascading Rollback Schedule In a recoverable schedule, no committed transaction ever needs to be rolled back. However, it is still possible for a phenomenon known as cascading rollback to occur, where an uncommitted transaction has to be rolled back because it read an item from a transaction that failed. In a recoverable schedule, no committed transaction ever needs to be rolled back. However, it is still possible for a phenomenon known as cascading rollback to occur, where an uncommitted transaction has to be rolled back because it read an item from a transaction that failed. Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1;T2 has to be rolled back ! A schedule is said to avoid cascading rollback if every transaction in the schedule only reads items that were written by committed transactions. In this case, all items read will be committed, so no cascading rollback will occur. A schedule is said to avoid cascading rollback if every transaction in the schedule only reads items that were written by committed transactions. In this case, all items read will be committed, so no cascading rollback will occur.

CSCI Transaction Processing Concepts 29 Characterizing Schedules based on Recoverability 3- Strict Schedule Strict schedule is a third type of schedule in which transactions can neither read nor write an item X until the last transaction that wrote X has committed (or aborted). Strict schedules simplify the process of recovering write operations to a matter of restoring the before image of a data item X, which is the value that X had prior to the aborted write operation. Strict schedule is a third type of schedule in which transactions can neither read nor write an item X until the last transaction that wrote X has committed (or aborted). Strict schedules simplify the process of recovering write operations to a matter of restoring the before image of a data item X, which is the value that X had prior to the aborted write operation. Sf: w1(X, 5); w2(X, 8); a1; !

CSCI Transaction Processing Concepts 30 Serializability of Schedules  An important aspect of concurrency control, called serializability theory, attempts to determine which schedules are “correct” and which are not to develop techniques that allow only correct schedules. Transaction T1 Transaction T read_item (X); read_item (X); read_item (X); read_item (X); X := X - N; X := X + M; write_item(X); write_item(X); read_item(Y); Y := Y + N; write_item(Y);

CSCI Transaction Processing Concepts 31 Serial Schedules & Nonserial Schedules

CSCI Transaction Processing Concepts 32 Serial Schedules & Nonserial 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; otherwise, the schedule is called nonserial.  If we consider the transactions to be independent, then every serial schedule is considered correct !!  The problem with serial schedules is that they limit concurrency or interleaving of operations. Hence, serial schedules are considered, in general, unacceptable.

CSCI Transaction Processing Concepts 33 Serializable Schedules  A schedule S is serializable if it is equivalent to some serial schedule of the same n transactions.  Saying that a nonserial schedule S is serializable is equivalent to saying that it is correct, because it is equivalent to a serial schedule, which is considered correct.

CSCI Transaction Processing Concepts 34 Schedules Equivalence 1. Result Equivalency:  Two schedules are called result equivalent if they produce the same final state of the database.  However, two different schedules may accidentally produce the same final state. S1S2 S1S2 read_item(X); read_item(X); X:=X+10; X:=X*1.1; write_item(X); write_item(X);  Hence, result equivalence is not used to define equivalence of schedules. 2. Conflict Equivalency:  Two schedules are called 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’. In such a case, we can reorder the nonconflicting operations in S until we form the equivalent serial schedule S’.

CSCI Transaction Processing Concepts 35 Testing Algorithm for Conflict Equivalence of Schedules  The algorithm looks at only the read_item and write_item operations in the schedule to construct a precedence graph (or serialization graph).  A precedence graph is a directed graph G = (N,E) that consists of a set of nodes N = {T1, T2,..., Tn} and a set of directed edges E = {e1, e2,..., em}.  There is one node in the graph for each transaction Ti in the schedule.  Each edge ei in the graph is of the form (Tj  Tk), 1  j  n, where Tj is called the starting node of ei and Tk is called the ending node of ei such that one of the operations in Tj appears in the schedule before some conflicting operation in Tk.

CSCI Transaction Processing Concepts 36 Testing Algorithm for Conflict Equivalence of Schedules 1. for each transaction Ti participating in schedule S create a node labeled Ti in the precedence graph; 2. for each case in S where Tj executes a read_item(X) after a write_item(X) command executed by Ti create an edge (Ti  Tj) in the precedence graph; 3. for each case in S where Tj executes a write_item(X) after Ti executes a read_item(X) create an edge (Ti  Tj) in the precedence graph; 4. for each case in S where Tj executes a write_item(X) command after Ti executes a write_item(X) command create an edge (Ti  Tj) in the precedence graph; 5. the schedule S is serializable if and only if the precedence graph has no cycles;

CSCI Transaction Processing Concepts 37 Testing Conflict Equivalence of Schedules  Constructing the precedence graphs for schedules A to D to test for conflict serializability.  (a) Precedence graph for schedule A.  (b) Precedence graph for schedule B.  (c) Precedence graph for schedule C (not serializable).  (d) Precedence graph for schedule D (serializable, equivalent to schedule A).

CSCI Transaction Processing Concepts 38 Testing Conflict Equivalence of Schedules

CSCI Transaction Processing Concepts 39 Testing Conflict Equivalence of Schedules

CSCI Transaction Processing Concepts 40 Thank you