5.0 Introduction The concept of transaction provides a mechanism for describing logical units of database processing. Transaction processing systems are systems with large databases and hundreds of concurrent users executing database transactions, Examples: + airline reservations = banking + credit card processing, * online retail purchasing, + Stock markets, supermarket checkouts, and many other applications These systems require high availability and fast response time for hundreds of concurrent users. A transaction is typically implemented by a computer program, which includes database commands such as retrievals, insertions, deletions, and updates. 5.1 Objectives 4 To study transaction properties © To study creation of schedule and maintaining schedule equivalence. 4 To check whether the given schedule is serailizable or not. 4 To study protocols used for locking objects + Differentiating between 2PL and Strict 2PL 5.2 Introduction to Transaction Processing 5.2.1 Single-User versus Multiuser Systems. = One criterion for classifying a database system is according to the number of users who can use the system concurrently Single-User versus Multiuser Systems "DBMS is + single-user at most one user at a time can use the system - Eg: Personal Computer System + multiuser - many users can use the system and hence access the database concurrently -Eg: Airline reservation database Kavitha D N, Asst. Prof., CS&E, VVCE Scanned with CamScannerConcurrent access is possible because of Multiprogramming. Multiprogramming can be achieved by: + interleaved execution + Parallel Processing Multiprogramming operating systems execute some commands from one process, then suspend that process and execute some commands from the next process, and so on A process is resumed at the point where it was suspended whenever it gets its turn to use the CPU again Hence, concurrent execution of processes is actually interleaved, as illustrated in Figure 21.1 Figure 21.1 Interteaved process- ing versus parallel processing of con- current transactons, Figure 21.1, shows two processes, A and B, executing concurrently in an interleaved fashion interleaving keeps the CPU busy when a process requires an input or output (I/O) operation, such as reading a block from disk The CPU is switched to execute another process rather than remaining idle during /O. time Interleaving also prevents a long process from delaying other processes. If the computer system has multiple hardware processors (CPUs), parallel processing of multiple processes is possible, as illustrated by processes C and D in Figure 21.1 ~ Most of the theory concerning concurrency control in databases is developed in terms of interleaved concurrency In a multiuser DBMS, the stored data items are the primary resources that may be accessed concurrently by interactive users or application programs, which are constantly retrieving information from and modifying the database. Kavitha DN, Asst. Prof., CS&E, VVCE Scanned with CamScannerfe Database Items, Read and Write Operations, and DBMS Buffers A Transaction’3n executing program that forms a logical unit of database processing It includes one or more DB access operations such as insertion, deletion, modification or tetrieval operation. |t can be either embedded within an application program using begin transaction and end transaction statements Or specified interactively via a high level query language such as SQL ‘Transaction which do not update database are known as read only transactions. Transaction which do update database are known as read write transactions. A database is basically represented as a collection of named data items. The size of a data item is called its granularity. A data item can be a database record, but it can also be a larger unit such as a whole disk block, or even a smaller unit such as an individual field (attribute) value of some record in the database Each data item has a unique name Basic DB access operations that a transaction can include are: * read_item(X): Reads a DB item named X into a program variable. + write_item(X): Writes the value of a program variable into the DB item named X Executing read_item(X) include the following steps: 1. Find the address of the disk block that contains item X 2. Copy the block into a buffer in main memory 3. Copy the item X from the buffer to program variable named X. Executing write_item(X) include the following steps: 1. Find the address of the disk block that contains item X 2. Copy the disk block into a buffer in main memory 3. Copy item X from program variable named X into its correct location in buffer. 4. Store the updated disk block from buffer back to disk (either immediately or later). Decision of when to store a modified disk block is handled by recovery manager of the DBMS in cooperation with operating system. A DB cache includes a number of data buffers. When the buffers are all occupied a buffer replacement policy is used to choose one of the buffers to be replaced. EG:LRU \ avitha D N, Asst. Prof, CS&E, VVCE Scanned with CamScanner‘Atransaction includes read_item and write_item operations to access and update Da. * The read-set of a transaction is the set of all items that the transaction reads * The write-set is the set of all items that the transaction writes "For example, the read-set of 71 in Figure 21.2 is {X, Y} and its write-set is also {X, Y}. savy concuany Control Is Needed ‘= Several problems can occur when concurrent transactions execute in an uncontrolled manner = Example: + We consider an Airline reservation DB + Each records is stored for an airline flight which includes Number of reserved seats among other information. Types of problems we may encounter: 1, The Lost Update Problem 2. The Temporary Update (or Dirty Read) Problem 3. The Incorrect Summary Problem “The Unrepestable Read Problem | itha DN, Asst. Prof, CS&E, VVCE Scanned with CamScanner= Transaction T1 + transfers N reservations from one flight whose number of reserved seats is stored in the database item named X to another flight whose number of reserved seats is stored in the database item named Y. = Transaction T2 + reserves M seats on the first flight (X) sefortarncad an Th. 41. The Lost Update Problem "occurs when two transactions that access the same DB items have their operations interleaved in a way that makes the value of some DB item incorrect = Suppose that transactions T1 and T2 are submitted at approximately the sar suppose that their operations are interleaved as shown in Figure below me time, and * Final value of item X is incorrect because T2 reads the value of X before T1 changes it in the database, and hence the updated value resulting from 71 is lost. = For example: X= 80 at the start (there were 80 reservations on the flight) N=5(T1 transfers 5 seat reservations from the flight corresponding to X to the flight corresponding to Y) M=4 (12 reserves 4 seats on X) The final result should be X = 79. * The interleaving of operations shown in Figure is X = 84 because the update in T1 that removed the five seats from Xwas lost. vitha D N, Asst. Prof., CS&E, VVCE Scanned with CamScanner2. The Temporary Update (or Dirty Read) Problem ‘occurs when one transaction updates a database item and then the transaction fails for some reason Meanwhile the updated item is accessed by another transaction before it is changed back to its original value X=HXaM write tt 4 mn Transaction T; faits and must change the value of X back to its old value; meanwhile T, fias read the temporary incorrect value of X. 3. The Incorrect Summary Problem + If one transaction is calculating an aggregate summary function on a number of db items while other transactions are updating some of these items, the aggregate function may calculate some values before they are updated and others after they are updated. | ead nen; X= X- Ny MMU: | oe aye ‘ ‘Tareads X after Nis subtracted and reads en = — Yoefore Nia added; a wrong summary ee Ws the result (of by WM). | read tem(ry; Levan, ‘waite_hem(Y); Kavitha DN, Asst. Prof., CS&E, VVCE Scanned with CamScanner4. The Unrepeatable Read Problem Transaction T reads the same item twice and gets different values on eat the item was modified by another transaction T! between the two reads. for example, if during an airline reservation transaction, a customer inquires about seat ch read, since availability on several flights When the customer decides on a particular flight, the transaction then reads the number of seats on that flight a second time before completing the reservation, and it may end up reading a different value for the item. 4 Why Recovery Is Needed Whenever a transaction is submitted to a DBMS for execution, the system is responsible for making sure that either 1. All the operations in the transaction are completed successfully and their effect is recorded permanently in the database or 2.The transaction does not have any effect on the database or any other transactions In the first case, the transaction is said to be committed, whereas in the second case, ‘the transaction is aborted If a transaction fails after executing some of its operations but before executing all of them, the operations already executed must be undone and have no lasting effect. Types of failures 4. Acomputer failure (system crash): + A hardware, software, or network error occurs in the computer system during transaction execution + Hardware crashes are usually media failures—for example, main memory failure. 2. Atransaction or system error: + Some operation in the transaction may cause it to fail, such as integer overflow or division by zero + Also occur because of erroneous parameter values 3. Local errors or exception conditions detected by the transaction: + During transaction execution, certain conditions may occur that necessitate cancellation of the transaction Kavitha D N, Asst. Prof. CS&E, VVCE Scanned with CamScanner+ Forexample, data for the transaction may not be found 4. Concurrency control enforcement: det «The concurrency control may serializability or several transactions are in a state of deadlock 5. Disk failure: ‘ + Some disk blocks may lose thei because of a disk readMwrite head crash. cide to abort a transaction because itviolates r data because of a read or write malfunction or 6. Physical problems and catastrophes: fe + tefers to an endless list of problems that includes power or air-conditioning failure, fire, theft, overwriting disks or tapes by mistake « Failures of types 1, 2, 3, and 4 are more common than those of types 5 or 6. = Whenever a failure of type 1 through 4 occurs, the system must keep sufficient information to quickly recover from the failure. * Disk failure or other catastrophic failures of type 5 or 6 do not happen frequently; if they do occur, recovery is a major task. 5.3 Jransaction and System Concepts 5,341 Transaction States and Additional Operations * A transaction is an atomic unit of work that should either be completed in its entirety or not done at all. For recovery purposes, the system keeps track of start of a transaction, termination, commit or aborts. + BEGIN_TRANSACTION: marks the beginning of transaction execution + READ or WRITE: specify read or write operations on the database items that are executed as part of a transaction + END_TRANSACTION: specifies that READ and WRITE transaction operations have ended and marks the end of transaction execution + COMMIT_TRANSACTION: signals a successful end of the transaction so that any changes (updates) executed by the transaction can be safely committed to the database and will not be undone « ROLLBACK: signals that the transaction has ended unsuccessfully, so that any changes or effects that the transaction may have applied to the database must be mn Kavitha DN, Asst. Prof., CS&E, VVCE Scanned with CamScannerFigure: State transition diagram illustrating the states for transaction execution A transaction goes into active state immediately after it starts execution and can execute read and write operations. When the transaction ends it moves to partially committed state. At this end additional checks are done to see if the transaction can be committed or not. If these checks are successful the transaction is said to have reached commit point and enters committed state. All the changes are recorded permanently in the db. A transaction can go to the failed state if one of the checks fails or if the transaction is aborted during its active state. The transaction may then have to be rolled back to undo the effect of its write operation. Terminated state corresponds to the transaction leaving the system. All the information -about the transaction is removed from system tables. Kavitha DN. Asst. Prof., CS&E, VVCE Scanned with CamScanner5,4 Desirable Properties of Transactions Transactions should possess several properties, often called the ACID properties A Atomicity: a transaction is an atomic unit of processing and it is either performed entirely or not at all. C Consistency Preservation: a transaction should be consistency preserving that is it must take the database from one consistent state to another. lsolation/Independence: A transaction should appear as though it is being executed in isolation from other transactions, even though many transactions are executed concurrently. D Durability (or Permanency): if a transaction changes the database and is committed, the changes must never be lost because of any failure. + The atomicity property requires that we execute a transaction to completion. It is the responsibility of the transaction recovery subsystem of a DBMS to ensure atomicity. = The preservation of consistency is generally considered to be the responsibility of the Programmers who write the database programs or of the DBMS module that enforces integrity constraints. * The isolation property is enforced by the concurrency control subsystem of the DBMS. If every transaction does not make its updates (write operations) visible to other transactions until it is committed, one form of isolation is enforced that solves the temporary update problem and eliminates cascading rollbacks * Durability is the responsibility of recovery subsystem. Scanned with CamScannerfs Characterizing Schedules Based on Serializability schedules that are always considered to be correct when concurrent transactions are executing are known as serializable schedules = Suppose that two users—for example, two airline reservations agents—submit to the DBMS transactions T1 and T2 at approximately the same time. If no interleaving of operations is permitted, there are only two possible outcomes: 1. Execute all the operations of transaction T1 (in sequence) followed by all the operations of transaction T2 (in sequence). 2. Execute all the operations of transaction 72 (in sequence) followed by all the operations of transaction T1 (in sequence). ing transactions Ty and To (@) ial schedule B: Ty follawed by T. ‘eth etencatng of ‘operations: 4 ae ere keh 1 Kavitha D N, Asst. Prof., CS&E, VVCE Scanned with CamScanner* Serial schedule: — 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 schedule, "Serializable schedule: - Aschedule S is serializable if it is equivalent to some serial schedule of the same ‘transactions. «© Result equivalent: — Two schedules are called'result equivalent if they produce the same final state of the database. * Conflict equivalent: ‘Two schedules are said to be conflict equivalent ifthe order of any two conflicting operations is the same in both schedules. * Conflict serializable: A schedule S is said to be conflict serializable if itis conflict equivalent to some serial schedule S', "Being serializable is not the same as being serial = Being serializable implies that the schedule is a correct schedule. — Itwill leave the database in a consistent state. = The interleaving is appropriate and will result in a state as if the transactions were serially executed, yet will achieve efficiency due to concurrent execution. 5.6.1 Tésting conflict serializability of a Schedule S {. For each transaction Ti participating in schedule S,create a node labeled Ti in the precedence graph. Aaprthen 2. For each case in $ where Tj executes a read_item(X) after Ti executes 2 write_item(X), create an edge (Ti>T]) in the precedence graph. B. 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. \U. For each case in § where Tj executes a write_item(X) after Ti executes a write_item(X), create an edge (Ti->T)) in the precedence graph. 5. The schedule S is serializable if and only if the precedence graph has no cycles. Kavitha DN, Asst. Prof., CS&E, VVCE Scanned with CamScannereS o x x Fig: Constructing the precedence graphs for schedules A and D from fig 21.5 to test for conflict serializability. (a) Precedence graph for serial schedule A. (b) Precedence graph for serial schedule B. (c) Precedence graph for schedule C (not serializable). (d) Precedence graph for schedule D (serializable, equivalent to schedule A). * Another example of serializability testing. (a) The READ and WRITE operations of three transactions T;, Tz, and Ts. (a) ion T, read_item (x); write_item (X); YY write_jtem (Y); Kavitha DN, Asst. Prof., CS&E, VVCE Scanned with CamScanner®) fead_ttem (X); Time | ite tem (X); wre fom (Y, (2); write_item (Y); Schedule E © wrile_Heri (Z); read item (2); read_item (VY); write_item (Y); read_itern (x); Wiite_item (x) ‘Schedle F Kavitha DN, Asst. Prof, CS&E, VVCE Scanned with CamScanner= Precedence graph for schedule E . heres gett a gabon MAT) = Precedence graph for schedule F Scanned with CamScannerie Introduction to Concurrency Control + Purpose of Concurrency Control — To enforce Isolation (through mutual exclusion) among conflicting transactions. — To preserve database consistency through consistency preserving execution of transactions, — To resolve read-write and write-write conflicts. * Example: — In concurrent execution environment if T1 conflicts with T2 over a data item A, then the existing concurrency contro! decides if T1 or T2 should get the A and if the other transaction is rolled-back or waits, Ys Two-Phase Locking Techniques for Concurrency Control = The concept of locking data items is one of the main techniques used for controlling the concurrent execution of transactions, A lock is a variable associated with a data item in the database, Generally there is a lock for each data item in the database. A lock describes the status of the data item with respect to possible operations that can be applied to that item. It is used for synchronizing the access ‘by concurrent transactions to the database items. A transaction locks an object before using it When an object is locked by another transaction, the requesting transaction must wait 5.9.1 Types of Locks and System Lock Tables 1. Binary Locks ® A binary lock can have two states or values: locked and unlocked (or 1 and 0). = If the value of the lock on X is 1, item X cannot be accessed by a database operation that requests the item Scanned with CamScannerIf the value of the lock on X is 0, the item can be accessed when requested, and the lock value is changed to 1 We refer to the current value (or state) of the lock associated with item X as lock(X). Two operations, lock_item and unlock_item, are used with binary locking. A transaction requests access to an item X by first issuing a lock_item(X) operation If LOCK(X) = 1, the transaction is forced to wait. If LOCK(X) = 0, it is set to 1 (the transaction locks the item) and the transaction is allowed to access item X When the transaction is through using the item, it issues an unlock_item(X) operation, which sets LOCK(X) back to 0 (unlocks the item) so that X may be accessed by other transactions Hence, a binary lock enforces mutual exclusion on the data item. lock_item(X): B: if LOCK(X) = 0 (* itemis unlocked *) then LOCK(X) —1 (* lock the item *) else begin wait (until LOCK(X) = 0 and the lock manager wakes up the transaction); gotoB end; unlock_item(X): LOCK(X) < 0; (* unlock the item *) if any transactions are waiting then wakeup one of the waiting transactions; Kavitha D N, Asst. Prof., CS&E, VVCE Fig: 2.1.1 Lock and unlock operations for binary ‘\peKn - Scanned with CamScannerbn The lock_item and unlock_item operations must be implemented as indivisible units that is, no interleaving should be allowed once a lock or unlock operation is started until the operation terminates or the transaction waits The wait command within the lock_item(X) operation is usually implemented by putting the transaction in a waiting queue for item X until X is unlocked and the transaction can be granted access to it Other transactions that also want to access X are placed in the same queue.Hence, the wait command is considered to be outside the lock_item operation. It is quite simple to implement a binary lock; all that is needed is a binary-valued variable, LOCK, associated with each data item X in the database In its simplest form, each lock can be a record with three fields: plus a queue for transactions that are waiting to access the item If the simple binary locking scheme described here is used, every transaction must obey the following rules: 4. A transaction T must issue the operation lock_item(X) before any tead_item(X) or write_item(X) operations are performed in T. 2. A transaction T must issue the operation unlock_item(X) after all tead_item(X) and write_item(X) operations are completed in T. 3. A transaction T will not issue a lock_item(X) operation if it already holds the lock on item X. 4. A transaction T will not issue an unlock_item(X) operation unless it already holds the lock on item X. Shared/Exclusive (or Read/Write) Locks binary locking scheme is too restrictive for database items because at most, one transaction can hold a lock on a given item should allow several transactions to access the same item X if they all access X for teading purposes only if a transaction is to write an item X, it must have exclusive access to X For this purpose, a different type of lock called a multiple-mode lock is used In this scheme—called shared/exclusive or read/write locks—there are three locking operations: read_lock(X), write_lock(X), and unlock(X). Kavitha D N, Asst. Prof., CS&E, VVCE Scanned with CamScanner* -A read-locked item is also called share-locked because other transactions are allowed to read the item, whereas a write-locked item is called exclusive-locked because a single transaction exclusively holds the lock on the item * Method to implement read/write lock is to - keep track of the number of transactions that hold a shared (read) lock on an item in the lock table - Each record in the lock table will have four fields: . If LOCK(X)=write-locked, the value of locking_transaction(s) is a single transaction that holds the exclusive (write) lock on X If LOCK(X)=read-locked, the value of locking transaction(s) is a list of one or more transactions that hold the shared (read) lock on X. read_lock(X): B: if LOGK(X) = “unlocked” thenbegin LOCK(X) <~ “read-locked"; no_of_reads(X) <1 end else if LOCK(X) = “read-locked” “ then no_of_reads(X) ¢~ no_of_feads(X) +1 else begin “ ; wait (untit LOCK(X) = “unlocked” and the’lock manager wakes up the transaction); goto end; write lock(X): B: if LOCK(X) = “unlocked” then LOCK(X) ~ “write-locked” else begin ‘wait: (until LOCK(X) = “unlocked” right ab atid the lock manager wakes: up the transaction); ga to.B end; Kavitha D N, Asst. Prof., CS&E, VVCE Scanned with CamScanner= When we use the shared/exclusive locking scheme, the system must enforce the following tules: 1. A transaction T must issue the operation read_lock(X) or write_lock(X) before any tead_item(X) operation is performed in T. A transaction T must issue the operation write_lock(X) before any write_item(X) Operation is performed in T. 2. 3 A transaction T must issue the Operation unlock(X) after all tead_item(X) and write_item(X) operations are completed in TS. 4. A transaction T will not issue a tead_lock(X) operation if it already holds a read (shared) lock or a write (exclusive) lock on item X. Conversion of Locks A transaction that already holds a lock on item Xs allowed under certain conditions to convert the lock from one locked state to another For example, it is possible for a transaction T to issue a tead_lock(X) and then later to upgrade the lock by issuing a write_lock(X) operation - If Tis the only transaction holding a read lock on X at the time it issues the write_lock(X) operation, the lock can be upgraded;otherwise, the transaction must wait 582 Guaranteeing Serializability by Two-Phase Locking SoU Kavitha DN, Asst. Prof, CS&E, VVCE Scanned with CamScannerA transaction Is said to follow the two-phase locking protocol if all locking operations (read_lock, write_lock) precede the first unlock operation in the transaction Such a transaction can be divided into two phases: = Expanding or growing (first) phase, during which new locks on items can be acquired but none can be released Shrinking (second) phase, during which existing locks can be released but no new locks can be acquired If lock conversion Is allowed, then upgrading of locks (from read-locked to write-locked) must be done during the expanding phase, and downgrading of locks (from write-locked to read-locked) must be done in the shrinking phase. Transactions T1 and 72 in Figure 24.3(a) do not follow the two-phase locking protocol because the write_lock(X) operation follows the unlock(Y) operation in 71, and similarly the write_lock(Y) operation follows the unlock(X) operation in T2. ‘followed by T,: X=70, Y=50 Figure 21.3 Transactions that do not obey two-phase locking (a) Two transactions T1 and T2 (b) Results of possible serial schedules of 71 and T2 (c) A nonserializable schedule S that uses locks Scanned with CamScanner= If we enforce two-phase locking, the transactions can be rewritten as T1' and T2' as shown in Figure 22.4. Now, the schedule shown in Figure 22.3(c) is not permitted for Ti 'and 72! (with their modified order of locking and unlocking operations) under the rules of locking because Te will issue its write_lock(X) before it unlocks item Y; consequently, when T2_ issues its read_lock(X), it is forced to wait until T1!_ releases the lock by issuing an unlock (x) in the schedule. Figuré 22.4 Transactions T;’ and T,', whitch are the same as T, and Tp’in Figure 22.3, but follow the two-phase locking protecal. Note that they can produce a deadlock. [acer | Te write_item(X); untook(X); read_Jock(X); read_item(X); write_lock(Y); untock(X) read_item(Y); Y +Y, write_item(¥); unlock(Y); If every transaction in a schedule follows the two-phase locking guaranteed to be serializable protocol, schedule Two-phase locking may limit the amount of concurrency that can occur ina schedule Some serializable schedules will be prohibited by two-phase lockin, Kavitha D N, Asst. protocol rof., CS&E, VVCE Scanned with CamScanner