Chapter17
- 2. Introduction to Transaction Processing Concepts and Theory Chapter 17
- 3. Introduction to Transaction Processing Transaction and System Concepts Desirable Properties of Transactions Characterizing Schedules Based on Recoverability Characterizing Schedules based on Serializability Transaction Support in SQL Chapter Outline
- 4. Database systems are classified as: Single-user: at most one user at a time can use the system Multi-user: many users –simultaneously-- can use the system Multi-user systems work in one of the following modes: Interleaved concurrency, Parallel processing Transaction processing systems are systems with large number of users that are executing database transactions on large databases (e.g., reservation systems, banking, credit card processing, supermarket checkout, and etc.). Introduction to Transaction Processing
- 5. FIGURE 17.1 Interleaved processing versus parallel processing of concurrent transactions. Introduction to Transaction Processing
- 6. A transaction is a logical unit of database processing that includes one or more database access operations (e.g., insertion, deletion, modification, or retrieval operations). A read-only transaction only retrieves data and thus do not change the state of the database. The basic database access operations are: Read-item(X): reads a database item X into a program variable X Write-item(X): writes the value of program variable X into the database item named X Introduction to Transaction Processing
- 7. FIGURE 17.2 Two sample transactions. Transaction T 1 . Transaction T 2 . Introduction to Transaction Processing
- 8. Problems occur when concurrent transactions execute in an uncontrolled manner: The Lost Update Problem The Temporary Update (or Dirty Read) Problem The Incorrect Summary Problem Why Concurrency Control is Needed
- 9. FIGURE 17.3 The lost update problem. Why Concurrency Control is Needed
- 10. FIGURE 17.3 (continued) (b) The temporary update problem. Why Concurrency Control is Needed
- 11. FIGURE 17.3 (continued) (c) The incorrect summary problem. Why Concurrency Control is Needed
- 12. A DBMS must make sure that either: All operations in the transaction are completed, or The transaction has no effect whatsoever on the database or on any other transactions. Transaction failure in the middle of execution: A computer failure –e.g., main memory failure A transaction or system error –e.g., division by zero Local errors or exception conditions detected by the transaction –e.g., data may not be found Concurrency control enforcement –e.g., abort the transaction, and start it later Disk failure –e.g., read/write head crash Physical problems and catastrophes –e.g., fire, sabotage Why Recovery is Needed
- 13. A transaction is an atomic unit of work. For recovery purpose, the system needs to keep track of when the transaction starts, terminates, and commits/aborts. The recovery manager keeps track of the following operations: BEGIN_TRANSACTION READ OR WRITE END_TRANSACTION COMMIT_TRANSACTION –ended successfully ROLLBACK (OR ABORT) --ended unsuccessfully Transactions and System Concepts
- 14. A transaction goes into an active state immediately after it starts execution. When the transaction ends, it moves to the partially committed state . If the transaction passes recovery protocol checks, then it enters the committed state, otherwise it goes to the failed state. The terminated state corresponds to the transaction leaving the system. Transactions and System Concepts
- 15. FIGURE 17.4 State transition diagram illustrating the states for transaction execution . Transactions and System Concepts
- 16. For recovery purpose, the system maintains a log to keep track of all transaction operations that affect the value of database items. Log records contains of the following information START_TRANSACTION, T WRITE_ITEM, T, X, OLD_VALUE, NEW_VALUE READ_ITEM, T, X COMMIT, T ABORT, T Where T refers to a unique transaction-id that is generated automatically by the system. Log records enables undo/redoing Transactions and System Concepts
- 17. Transactions should posses ACID properties: A tomicity: it is either performed in its entirety or not performed at all. C onsistency preservation: its complete execution take(s) the database from one consistent state to another. I solation: its execution should not be interfered with by any other transaction executing concurrently. D urability or Permanency: the changes applied to the database by a committed transaction must persist in the database. Desirable Properties of Transactions
- 18. A schedule (or history ) S of n transactions T 1 , T 2 , …, T n is an ordering of the operations of the transactions, such that operations of T i in S must appear in the same order in which they occur in T i . For example, the schedule of Figure 17.3(a) is S a : r 1 (X); r 2 (X); w 1 (X); r 1 (Y); w 2 (X); w 1 (Y); and the schedule for Figure 17.3(b) is S b : r 1 (X); w 1 (X); r 2 (X); w 2 (X); r 1 (Y); a 1 ; Two operations in a schedule are conflict if: They belong to different transactions, They access the same item X, and At least one them is a WRITE_ITEM(X) operation. Characterizing Schedules Based on Recoverability
- 19. 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. The order of operations in S is the same as their occurrence in T i . For any two conflict operations, one of the two must occur before the other in the schedule. Characterizing Schedules Based on Recoverability
- 20. For some schedule it is easy to recover from transaction failures. We would like that, once a transaction T is committed, it should never be necessary to roll back T. The schedules that meet this criterion are called recoverable schedules . Therefore: A schedule S is recoverable if no transaction T in S commits until all transactions T’ that have written an item that T reads have committed. For example S’ a : r 1 (X); r 2 (X); w 1 (X); r 1 (Y); w 2 (X); c 2 ; w 1 (Y); c 1 ; is recoverable, even though it suffers from the lost update problem. Characterizing Schedules Based on Recoverability
- 21. Example -- Consider the following schedules: S c : r 1 (X); w 1 (X); r 2 (X); r 1 (Y); w 2 (X); c 2 ; a 1 ; S d : r 1 (X); w 1 (X); r 2 (X); r 1 (Y); w 2 (X); w 1 (Y); c 1 ; c 2 ; S e : r 1 (X); w 1 (X); r 2 (X); r 1 (Y); w 2 (X); w 1 (Y); a 1 ; a 2 ; S c is not recoverable , because T 2 reads item X written by T 1 , and then T 2 commits before T 1 commits. S d is recoverable , because T 2 reads item X written by T 1 , and then T 2 commits after T 1 commits and no other conflict operations exists in the schedule. S e is similar to S d , but T 1 is aborted (instead of commit). In this situation T 2 should also abort, because the value of X it read is no longer valid (this phenomenon known as cascading rollback or cascading abort ). Characterizing Schedules Based on Recoverability
- 22. Because cascading rollback can be quite time-consuming, we perform cascadeless schedules. A schedule is said to be cascadeless or to avoid cascading rollback if every transaction in the schedule reads only items that were written by committed transactions. A more restrictive type of schedule is called strict schedule, in which transactions can neither read nor write an item X until the last transaction that wrote X has committed (or aborted) Characterizing Schedules Based on Recoverability
- 23. If no interleaving of operations is permitted, there are only two possible arrangements for executing transactions T 1 and T 2 : Execute (in sequence) all the operations of transaction T 1 , followed by all the operations of transaction T 2 . Execute (in sequence) all the operations of transaction T 2 , followed by all the operations of transaction T 1 . If interleaving of operations is allowed there will be many possible schedules. The concept of serializability of schedules is used to identify which schedules are correct. Characterizing Schedules Based on Serializability
- 24. FIGURE 17.5 Examples of serial and nonserial schedules involving transactions T 1 and T 2 . Serial schedule A: T 1 followed by T 2 . Serial schedules B: T 2 followed by T 1 . Characterizing Schedules Based on Serializability
- 25. FIGURE 17.5 (continued) Examples of serial and nonserial schedules involving transactions T 1 and T 2 . (c) Two nonserial schedules C and D with interleaving of operations. Characterizing Schedules Based on Serializability
- 26. 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. The drawback of serial schedules is that they limit concurrency of interleaving of operations. Two schedules are called result equivalent if they produce the same final state of the database. Characterizing Schedules Based on Serializability
- 27. FIGURE 17.6 Two schedules that are result equivalent for the initial value of X = 100, but are not result equivalent in general. Characterizing Schedules Based on Serializability
- 28. Two schedules are called conflict equivalent if the order of any two conflicting operations is the same in both schedules. A schedule S of n transactions is serializable if it is equivalent to some serial schedule of the same n transactions. A schedule S to be conflict serializable if it is conflict equivalent to some serial schedule S’. Characterizing Schedules Based on Serializability
- 29. Algorithm for testing conflict serializability of S: For each transaction T i in schedule S, create a node, If T j executes a READ_ITEM(X) after T i executes a WRITE_ITEM(X), create an edge T i T j If T j executes a WRITE_ITEM(X) after T i executes a READ_ITEM(X), create an edge T i T j If 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 precedence graph has no cycle. Characterizing Schedules Based on Serializability
- 30. FIGURE 17.7 Constructing the precedence graphs for schedules A, B, C, and D from Figure 17.5 to test for conflict serializability Precedence graph for serial schedule A. Precedence graph for serial schedule B. Precedence graph for schedule C (not serializable). Precedence graph for schedule D (serializable, equivalent to schedule A) Characterizing Schedules Based on Serializability
- 31. Every transaction has certain characteristics attributed to it, which is specified by a SET TRANSACTION statement in SQL. The characteristics are: Access mode: can be READ ONLY or READ WRITE Diagnostic area size: specifies an integer value n, indicating the number of conditions that can be held simultaneously (supplies feedback information). Isolation level: is specified using the statement ISOLATION LEVEL <isolation> Where the value for <isolation> can be READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, or SERIALIZABLE Transaction Support in SQL
- 32. The default isolation level is SERIALIZABLE (not allowing violations that cause dirty read, unrepeatable read, and phantoms). If a transaction executes at a lower level than SERIALIZABLE, then one or more of the following violations may occur: Dirty read: a transaction T 1 may read the update of a transaction T 2 , which is not committed yet, Nonrepeatable read: T 1 may read a value, and after T 2 updates it, T 1 reads and will see a different value, Phantoms: T1 reads a set of rows from a table, a transaction inserts a row; if T1 is repeated it will see a phantom (a row that previously did not exist). Transaction Support in SQL
- 33. A sample SQL transaction: EXEC SQL WHENEVER SQLERROR GOTO UNDO; EXEC SQL SET TRANSACRTION READ WRITE DIAGNOSTIC SIZE 5 ISOLATION LEVEL SERIALIZABLE; EXEC SQL INSERT INTO EMPLOYEE (FNAME, LNAME, SSN, DNO, SALARY) 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: …; Transaction Support in SQL