TRANSACTIONS MANAGEMENT AND CONCURRENCY AND RECOVERY CONTENT scion! Fon concept, State Diagram, ACID Si (oe sind View Properties, Transaction Control Commands, Concurrent Executions, acy Control ipased-prot0cols, Deadlock handling Timestamp-bosed protocols. seory System Concept, Log based recover. ing Tops: Sy he vriovedeoock sition wich may cau fora database destared in ModileV Jc approach of transaction is to provide a process for designing a logical schema of database processing on processing systems consist of huge databases along with numbers of users which are executing the ransactonsconcutrenty, In this chapter, we wl se the basic concepts of transaction processing. 1 units, formed by collections of operations are called transactions. A database system must confirm executes properly and pale logical ‘on of all the operations of transaction and ensure that the entire transaction to database. example, 2 user transfers an amount from one account to another account, this transaction seems like a aration in view of customer, but it consists of many operations. So, itis essential to perform all the le logical unit of work that should either execute er operations completely or not be ata A transaction isa piece of program fr execution that accesses and may be sometimes updates various om databases, Basically, a transaction is initiated by 2 user program written in a high-level programming ge such as C++ or Java and data-manipulation language like SQL. A transaction is enclosed into two ts (or function calls) begin transaction and end transaction. The transaction hoving all operations should be between the begin transaction and end transaction. transaction is a sing database model concepts, and itis very simple as compared to the other del or the object model. The various data items collectively represent a data item can be recorded in database and it can be in SVyolume such as smaller unit, ue in database of larger unit, e.g. whole disk block. Each data item is named uniquely, but the programmer will not use this name; itis just for identification of data ® Uniquely. For example, if the data item represents one disk block, then the address of the disk block can be Transaction model includes the els such as the relational mo base. The size of a data item is called its granularity. A eg.a particular attribute val 63)* Aborted: If transaction fails and it has been rolled back, the d: sement and Concurrency and Recoy, So DATABASE A 1 x MANAGEMENT SYSTEMS (DBMS) 6: for accessin the basic operations 19 data Used as name of the data item, Using this simplest database model a, ‘that a transaction can include are as follows: Hable snd: ee’ chat Fead_item(X): Data it 1d X reads from database into a program v2! that, t Litem(x): Data item names Program variable is also named X. * write item(0: Writes the value of program variable X into th .e database item named X. 7 Tt read): readX): =x+M; Xeexe 5m wrte_tor(X): cee { tem(X); Ye¥eNs wite_tern(yy: rm) ©) Fig. 6.1: Transaction T; for amount transfer s : Fig. 6.1 shows a transactionT1 that transfers N amount from one account whose total amount is stored in the ‘database item named X to another account whose amount is stored in the database item named Y. 6.1.3 Transaction Control Commands A transaction is a single unit of work that must either be completed entirely or not done at all. When we conside, the recovery processing, the system needs to keep track of all the execution of each transaction such as when . Stars terminates, and commits or aborts. Therefore, the recovery manager of the DBMS needs to keep track of ths following operations: * READ or WRITE: These read or write operations are executed on the database items as part of a transaction, * COMMIT_TRANSACTION: This signal shows that transaction is executed successfully and the updates done by the transaction can be reflected to the database and will not change. * ABORT of ROLLBACK: This signal shows thatthe transaction has ended unsuccessfully, therefore any changes or effects that the transaction may have done to the database must be undone. * State transition diagram of Transaction Fig. 62 shows a state transition diagram that shows movement of transaction through its execution states. 4 transaction must be in one of the following states: * Active state: This is the initial state; operations. Transaction enters into this state when it starts execution of READ or WRITE * Partially committed state: When the final statement has been executed and transaction ends, it goes to the Partially committed state. At this state, execution of the transaction has completed. There may be possibility that it may have to be aborted and the final result ofthe transaction is still in main memory. nger Proceed. During active state, a transaction failed state. all the effects of WRITE operations 'tabase will be at its prior to the start of the transaction. Then transaction enters into Aborted state, Committed state: Once the transaction is completed successfully, the transaction enters to committed state When a transaction is committed, allits changes must be recorded permanently in the database.inated state: A transaction iss, rp terminated state will leave the aid to hav, system, 4 N proces: He pote parlal erecution Processing should be executed entirely or do not execute it at all 7 After execution of any transacti rans. Tees once te transaction i mated echo eee the Database should remain in consistent state. This 2 i from one consistent state to another. 1, Sgolation: Multiple transactions are executi Be ithe sytem, fecution of each transaction is carried out as if itis the only + Durability: After the transaction is committed, the che bu , the changes mad si ust not be lost even if there are system failures ry le to the database must persist. These changes let Tbe a transaction that transfers 100 from account A to account B. This transaction can be defined as: Ti : read(X); Xi= X - 100; wite(X); read(¥) Yes ¥ + 100; write(v). Let us now consider each of the ACID properties. Consider the transaction Ti, accounts X and Y having the values 5000 and 7000 respectively after the complete execution of Transaction Ti the values of accounts X and Y reflected in the database are 4900 and 7000. Suppose that, during the execution of transaction Ti, a failure occurs that prevents Tifom completing its execution successfully. If failure occurs after the write(X) operation but before the write(Y) ‘peration. Now, accounts X and Y reflected in the database are 4900 and 7000, The system dropped 100 due to this fue. In particular, we note that the sum X + ¥ is no longer preserved. All actions of the transaction are reflected in tte database, or none are. If the transaction is aborted or failure occurs, the database system must restore the initial vals from the log. Database isin consistent state means the sum of X and Y should not change by the execution of any transaction. tout the consistency requirement, money could be added or removed by the transaction. If multiple transactions ‘ot interfere with each other. aie “tecuted concurrently, their operations may n all the changes that it has done on the database Once the execution of the transaction completes successfully, ¥en ifthe system failure occurs after it completes the execution of transaction:in Fig. 6.4. While execution of these sequences, consisten and the values of accounts X and Y are 3900 and 8100 respectively. say TL 10 another say 72, ge. $2.5 ConrurTent Execute ster money #70 gene acco on 71 transfers 100 from ac We will conser the transaction 12 rant om oanking 934 transactions that access and update X to account ¥. It is defined as: Ti:read(X); X20X-1005 write(x); read(Y); Ys=¥4100; oe yn ear fers 20 percent of the balance from account X account ¥. It is defined ‘Transaction T2 transfers T2:read(X); tr=xt0.25 xiexcts write(X)s read(¥)s vats write(Y). Suppose the current values of accounts X ant ively. Suppose two transactions 7) 10 and 7000, respectively. Suppost : ches ns xeuting before T2 as shown in Fig. 6.3. After execution a time in the order suct ofthe: silbcen di ours of accounts X and Y are 3920 and 8080 respectively. 1 2 read00i read); Xi=X-100; 9 | t=X10.2; write); read(); Y:e¥+ 100; | read(y); write; Yes¥4t Commit write; Fig. 6.3: Concurrent Execution (T1 then T2) Similarly, both of these transactions are executed one at time in order such as. T2 is executed before T1 as shown \¢y must be maintained. That is the sum X+Y is preserved. 11 12 read); read; X:=X-100; write; read(¥); Ys=¥+ 100; write); Commit Commit Fig. 6.4: Concurrent Execution (T2 then 72)AGEMENT SYSTEMS. pccution sequences described above are | he erations of transactions and must e called sched nsure the ord ctions is done are run mig trom one transaction, then perform a conten’ «: ules. A schedule for all the transactions must comprise ler in which the operations appear in each individual concurrently by database system, then related schedule ‘oncurrently, the operating system may execute some witch, execute some operations from second transaction ction, and so on, ine OP" when execution of multiple transa, a gon. i" (ot serial. When two transactions : c context 5 « time, and cc asain come back to the first transa o ill consider that the two i ¢ a i ener he So resections are executed concurrently, so their may be possible schedule is m ule, we got the same result as the transactions are executed serially TL seen m1 7 oe read(x); maa t=x02; writers; Keke writes) read(y); Ys=¥+ 100; writer; Commit Fig. 6.5: Concurrent execution Now we will consider the schedule shown in figure 6.6. After the execution of this schedule, we get the final vibes of accounts X and Y as 4000 and 8100, respectively. This final state is an inconsistent state, since we have ‘#éed 100 in the process of the concurrent execution, So, the sum A+B is not preserved by the schedule. TL m2 read(X); X:=X-100; write(X); read(Y); Y+ 100; write(V); Commit +t write); Commit sistent state Fig. 6.6: Schedule results in incon:rm When transactions are executing the effect of any schedule after the execut! execution, That is, the schedule should b schedules. fon mt fe same as a serial 6.1.6 Serializability - Conflict get to determine whether 2 schedule 1 Stang, When the mutiple wansacions ae terse, 4 * if to find which operation is executed ang ho, 0 i jider only ‘ not. As the transactions are set of operations #9 FBT ca hats why We will consi 'y 60 operate, le transact interactions between operations of multipl read and write We consider a read(X) instruction and a writeO) inst ‘two consecutive instructions of transactions Ti and Th, res ‘an interchange I and J and it will not affect the results 0 ‘common data item X, then the order of the operations "ay der “ ions, ther ible cases that we must consi yeaa ear oe oft is ead by both TH and Tso the order oF nd doen + Trread(x)J=read(w), Since the same value of it matter. i =read(\)J=write(X) If executed before the J, then Ti cannot read the value of X that is written by instruction of TIF) executed before I, then Ti reads the value of X which is written by Tj. Thus, the order of Land Js ate the result, =write(X)J=read(X). This case is also having the same effect as we discuss in case 2. © TewriteO9.JewriteQd), Since both instructions are write operations, the order of these instructions does not afec the transaction Ti or 7. We can say that operation I and J conflict if both the operations from different transactions are operated on same data item, and out of both at least one instruction is a write operation. item X and a schedule S having ang will access diferent data items they, the schedule. IFT and J refer oy ruction on a data i spectively. If and ) ¥f any instruction in matter, Since we are concentrating only on reag z, Th 12 read(X); write(X); read(X); wite(X); read(¥); warite(Y); read(); write yy; Fig. 6.7: Serializable Schedule Now we consider I and J are consecutive instructions of a schedule S. If and J are different transactions and and J do not conflict, then the order of I and J can interchange, and this will produce a new schedule S’. $# equivalent to S, since al instructions appear in the same order in schedules, only the order of I and J may s¥# because, their order does not matter. We can swap these instructions to oma a oe ne le, schedul 5, in Figure 6.8. squivalent schedule,yp nAGEMENT SYSTEMS (ODM) er Transactions Management and ¢ 4 Recovery Content 08 Management and Concurrency and Recovery COM at 7 read); write(X); read(X); read(¥); write(x); write(y); read(y); writecy Fig. 6.8: Schedule 5 er seies of interchanging of the non confcting operations, schedule S can be transformed into a schedule S’ mn we con 89 that S and S'areconfict equivalent otal! serial eee 2re conflict equivalent to each other. For example, Fig. 63 and Fig. 64 are not conflict aialett we my conclude whet if schedule S is conflict equivalent to a serial schedule, then it is conflict spaiable, Therefore igure 67's conflict serializable, because itis conflict equivalent to the serial schedule 1. 2 pew Svializability onfict equivalence depends on operations like read and write of transactions. There are other forms of ule equivalence which are purely dependent on the read and write operations, one is view equivalence which to concept of view serializabllty. Now we will take two schedules S and S', where both schedules have the ne st of transactions. If the schedules S and S' satisfy the following conditions then they are said to be view salent For each data item X. + Binitial value of X is read by transaction T; in schedule S, then also initial value of X must be read by transaction Tin schedule S' «+ fransaction T; executes the write(X) operations and produced the value, that value is read by executing read(X) cgertion of transaction 7; in schedule S, then similarly transaction T; executes the write(X) operations and produced the value, that value is read by executing read(X) operation of transaction Tin schedule S, «theres any final write operation on X of transaction in schedule S then there must be final write operation on X inschedule S, from the above conditions, first 2 conditions state that in both the schedules, each transaction reads the same vues, s0 they perform the same computation. Third condition combines with first 2 conditions, and checks that both schedules are in the same final system state. When schedule $ is view equivalent to a serial schedule then it will be called view serializable. That is view ‘alence leads to the concept of view serializability. Th 2 3 read(X); write); write); write(X): Fig. 6.9: View serializable salt schedule shown in Fig. 69 i view equivalent to the serial schedule , inital value of X read by “0 instuction in Transaction TL and the final write of X performed by transaction T3, =cement and Concurrency and Recovery Ce, DATABASE MANAGEMENT SYSTEMS (OBMS)_ 68 Teansactlons Manage Aer enteny the view-serializable schedules are not contig Every conflict-serializable schedule is view serializable, but all ns conflict, So interchanging gy serializable. In schedule shown in figure 68, every pair of consecutive instru instructions is not possible, so itis not conflict serializable. [6.2 CONCURRENCY CONTROL Concurrency control methods are used to maintain the isolation property of rene th thi Most of the methods of concurrency control also ensure the serializability of aa a mult the two-phase locking protocols, used to prevent access of data items concurrent sacle values are generated by locking data items. Another concurrency control protocols uses timestamps. Ti systems to identify each transaction uniquely. 6.2.1 Lock-Based Protocols ra fr When we consider the several transactions running concurrently, it may violate the isolation property. To ensure isolation, al the transactions access the data in mutually exclusive manner, ie, when one transaction is accessing a data item, then modification is not allowed for that data by any other transaction. This will be done if a transaction holding a lock on currently accesses data items. Data item may be locked in following two modes. 1. Shared-mode lock (5): Ifa transaction T; has got a shared-mode lock on data item Q, then Tian read item Q, but cannot write, for item Q. A transaction requests 2 shared lock on data item Q by executing the lock- S(Q) instruction. 2. Exclusive-mode lock (0: If 2 transaction T; has obtained an exclusive-mode lock on data item Q, then T; can both read and write item Q. A transaction requests an exclusive lock through the lock-X(Q) instruction, The transaction requests a lock on data item Q to the concurrency-control manager. Requested lock depends on the types of operations that it will perform on Q. When manager grants the lock to the requesting transaction, then only the transaction can proceed with the operation. By making use of these two modes of lock modes, multiple transactions can read a data item but allows only one transaction to write one data item at a time. Ifa transaction lock is requested for a data item, but that item is already locked by another transaction, which is in an incompatible mode, then concurrency control manager will not grant the lock, until the lock has been released by other transactions which held the lock. Thus, requesting transaction is kept waiting until all incompatible locks held by other transactions have been released. Transaction may unlock a data item that it had locked at some earlier Point. A transaction can unlock a data item Q by the unlock(Q) instruction. Consider the schedule shown by figure 6.10, suppose that the values of accounts A and & are S000 and 7000, respectively. If these two transactions are executed serially, in any order, then transaction T2 will display the value ns executing concurrent, is section, we will tiple transactions by 12000. TL 2 Concurrency-control manager lock-x(B) grant-X(B, T,) read(8) B:= B-100 write(®) unlock(8) lock-S(A) grant-S(a Ta)2; Concurrency-control manager readi(A) uniock(a) : lock-S(8) grant-s(8, 7) read(e) unlock(a) displayia + lockx(a) | 8) oe grant-X(A, Ti) A 100 write(A) unlock(A) Ad Fig. 6.10: Schedule 1. _ yes transactions are executed concurrently, then transaction T2 displays € 11800, which is incorrect. The Fever this mistake (s that the transaction Tl unlocked data item B too early, as a result of which 72 saw an coset tate “o ensure the Sevalzabilty, we must consider the positioning of locking and unlocking operations in evry scan. Tis willbe done by the Two Phase Locking (2-PL) which ensures srilizabliy. 22 The Two-Phase Locking Protocol ability. These protocols requires two phases for issuing ‘te two-phase locking protocol ensures the ser sand unlock requests: 1. Growing phase. A transaction may get locks, but may not release any lock. 2 Shrinking phase. A transaction may release locks, but may not get any new locks. italy transaction is in the growing phase. The transaction acquires locks as needed. Once the transaction desesalock, it enters the shrinking phase, and it can issue no more lock requests. Ttislocking protocol divides the execution of a transaction into three different steps. «en the executions of transaction begins, it requests for the locks for data items that it needed for execution. It enters into Growing Phase. + IfTransaction obtains all the locks for data as it needs for execution. If it releases any locks then it will enter into step 3 + The tansaction cannot request into any new locks. Instead, it only releases the granted locks. It enters into stinking phase, Growing Shrinking Growing a phase. Time Tes Tends. -Phase Locking (2PL) Protocol Fig. 6.11 a iement and Concurrency and Recover, Teansactlons Manager Set single transaction failure CaUSeS 2FOIDECK 03 sor, back is undesirable, because itis the Undoing 9: trict the transactions which lead the Cascading DATABASE MANAGEMENT SYSTEMS (OEMS) jen0) Now we will see the cascading rollback. In a schedule if a of transaction, it is called as cascading rollback. Cascading rol significant amount of work. It is necessary that schedules must rest rollbacks. Such schedules are called cascadeless schedules. Cascading rollback may occur under two-phase locking. Co follows the two-phase locking protocol, but the failure of T1 after sider the schedule in Fig. 6.12. Each trans the read (A) step of T3 Leads to cascading rly of T2 and T3, 1 2 ie lock-X(A) read(A) lock-s(8) read(8) write(A) unlock(A) lock-X(a) read(A) write(A) unlock(a) lock-S(A) read(A) Fig, 6.12: Cascading Rollback To avoid Cascading rollbacks, two-phase locking is modified and itis called the strict two-phase locking protoco, In this protocol, addition is that all exclusive-mode locks taken by a transaction be held until that transaction commits. This modification guarantees that any data written by an uncommitted transaction are locked in exclusive ‘mode till the transaction commits, which will prevent reading of data by any other transaction. 6.2.3 Deadlock Handling Unfortunately, lacking can lead to an undesirable situation. Suppose, a set of transactions Ty, Ts, Ts, Te Ts ate in waiting state shown in figure 6.13, such as T, is waiting for a data item that T2 holds, and T2 is waiting for a data item that T3 holds, and so on, and TS waiting for a data item that T1 holds. Now the schedule has reached the state where none of these transactions can ever proceed. This situation is called deadlock. O-® Fig. 6.13: Deadlock condition When deadlock occurs, two transactions must be rollbacked by the system, transaction are unlocked, then these data items are available to other transaction, There are two principal methods for handing deadlock problem. One that enter a deadlock state, is called deadlock prevention protocol. In the other deadlock state, and then it will recover by deadlack detection and deadlock then the data items locked by that ensures that the system will never method, system may be entering 2 Fecovery protocols.y veh SYSTEMS (Onn) yan avery Convent ack Prevention gre two approaches to deadlock prevention, One method contiims that schedule should not enter Into g, when ordering the lock requests, or requiting h in schedule fesults into deadlock, then mthod she oe 1 at metiod Is simplest 03 all the data required far 030 put there are Wo main dsady i ‘gavance before the transaction tod £0 FW dato utlzation, oe all ocks together. In the other approach, wating of ould perform transaction rollback instead of waiting for cutlon must got lock by transaction before It starts ‘mages to this protocol: tis lificult to predict what data items need to be " Stas execution, As data items may be locked anid may not be used for a ious deadlock prevention schemes are proposed that make a decison about what to do with a transaction, ir should be Blocked and kept on wait or aborted. Some ofthese schemes use the transaction timestamp concept, timestamp iS 9 unique identifier assigned to each transaction, These aro typically based on the order ign transactions start execution. This will define the timestamps; for example, f transaction T2 starts after seston TH then TS(TI) < TS(T2), Hence the transaction that sta schemes that Prevent deadlock using the timestamp are wait-ie and wound-wait, Suppose that transaction sts lock for data item X but the item X is locked conflicting lock by other transaction Tj. The techniques must ‘dowthe elow rules: «Wattle: TSCM) < TS(T), then Tis allowed to wait; otherwise Tis aborted (Le. die) and it restarts later with the same timestamp. + Wound-waits IF TS(TI) < TS(T, thervse Tiis allowed to wait, 80 Hts first has the smaller time-stamp value, then T} is aborted and it restarts later with the same timestamp (Ti wounds Tj); ‘The major problem with both of these schemes is that unnecessary rollbacks may occur, 415 Deadlock Detection and Recovery Ifa system does not have the protocol to prevent from deadlock, then it must use a detection and recovery ithods. An algorithm must check the system, to determine whether a deadlock has occurred. If deadlock occurs then the system needs to recover from the deadlock, 626 Deadlock Detection Inthe deadlock detection approach, system must check whether it entered in deadlock state, If the schedule is ‘ightweight or transactions are short, each transaction locks some data items, and then there may be possibility that, diferent transactions may access same data items at the same time. So, the deadlock detection approaches have the ironedge about the interference among the transactions Deadlocks can be described precisely in system construct and maintain a wait-for graph. This graph contains a ParG=(V,8), where V is a set of vertices and E is a set of ‘edges. The set of vertices indicates all the transactions in the ‘stem and the set E of edges in an ordered pair like Ti-vTj is a directed edge from transaction Ti to Tj, which ‘wate that transaction Ti is waiting forthe data items which is locked by transaction such as T2-sT3-sT4—9T2, eB Fig, 6.14: Walt-for graph} F ind Concurrency and Recove 632, Transactions Management and C os coe ; ired by transaction Ti then the ¢ When transaction Tj releases the lock or unlocks the data item i he ae shown ta ie ae is removed. If the wait-for graph contains a cycle, then a deadlock occurs in the sy’ The system must maintain the wait-for graph, to detect deadlocks, invoking the algorithms, + Recovery from Deadlock: it mu When dade detected by deteion algorithm inte syste thn it mut weaves fom He ea a solution to Fecover from deadlock is to roll back one or more transactions to bres to ‘DATABASE MANAGEMENT SYSTEMS (DBMS) and periodically searches for @ cycle inthe graph st recover from the deadlock. The deadlock. There are three actions to be carried out for recoveries, they are mentioned as follows: (@) Selection of a vieti When deadlock exists in sytem, we have to identify the transactions to be rollback for breaking the dedi, state, We should select only that transaction for rollback that will acquire the minimum cost. But we also consider ‘more factors to determine the cost of rollback. These factors are: * Total time for computing the transaction to complete its designated task. * Allthe data items used by transaction, * * Data items needed to complete the execution of transactions. * Total transactions that are involved in rollback. (©) Rollback: After we have identified and decided any particular transaction must be rollback. We can rollback transaction by ‘wo modes. The first is a total rollback, the simplest solution, we have to abort the transaction and then restart it However, to break the deadlock, rollback the transaction is the effective solution, Another solution is partial rollback, in this approach, system must record the additional information of the state of all the running transactions. This additional information may consist of requests and grants of locks, updates reflected by transactions. The deadlock detection mechanism should identity locks that should be released by selected transaction to break the deadlock We have to mark that point where the identified lock is obtained and undo all actions after that point. Transaction must resume from this point to execute after the partial rollback, (©) Starvation: When we are selecting any transaction as victim as stated above, there may be possibility that some of the transactions may not complete their execution successfully, then it leads to starvation, We have to mention the frumber of rollbacks in the cost factor. This will ensure that a transaction can be selected as a victim for a specific number of times as mentioned, 6.2.7 Timestamp-based Protocols The use of locks, combined with the 2PL protocol, guarantees serializablity of schedules. The serializable schedules produced by 2PL have their equivalent serial schedules based on the order in which executing transactions lock the items they acquire, fa transaction needs an item that is already lacked, it may be forced to war op the item is released. Some transactions may be aborted and restarted because of the deadlock problem safernt approach that guarantees serializability involves using transaction timestamps to order transaction execution for an equivalent serial schedule.ps nerated a unique identifi 11 yg nas 9° fier to id S fentify a transaction called a timestamp, its values are the or rd at system. SO, Itcan be consider yi red as the cd rene! control approach based on timestamp “ ransaction start time. TS(1) is the timestamp of transaction ordering do n (ot mestamp 10 the transacti : 19 do not use locks; hence, deadlocks cannot occur. We £ sont ion by two simple techniques, PP jockvalue is assigned as timestamp to the tra nsaction, when transaction enters into system. I counter, i 4 e the ogi , Le. we assign: 15 te oats the val ign the current value of counter and vihen new transaction enters into the 1 Wer itncements the value of counter and soon eee spe Timestamp Ordering Algorithm Oe h of this thm i sic approach of this algorithm is to or ; ae ‘ne a De ecnat es sae a the transaction, which depends on the timestamp of transaction noe vonflicting read and wi Use timestamps ofthe transactions. The timestamp-ordering protocol mast any \g read and write operations should not violate ti if transaction Ti enters before tran pete ce an. oe ‘qnus: i oevral schedule where Ti saction Tj then TS(Ti) < TS(Tj), so the system must ensure schedule is i Jent tO aie ;ppears before 1), There are two timestamp values related to data item Q= ‘ waimestamp(@): i jest timestamp of transaction which performed write(Q) successfully. ): Highest time . petimestamp(Q a ir eer, of transaction which performed read(Q) successfully. enever a new read() of write(Q) instruction is executed, timestamps of transactions are updated. The itm ust ensure that, order ofthe item to be accessed does not violate the timestamp order vihen each item sgaccessed BY conflicting operations in the schedule. The concurrency control algorithm must check following two ase isons that transaction Tissues read), y vetiestamp(@) > TS(T), then abort and roll back Ti and reject the operation Hence, in the timestamp aedring afte Ti has already written the value of item Q before it read item Q, fWetimestamp(Q) $ TS(Ti), then the read operation is executed to item Q, and set the R-timestamp(Q) to the raximum of TS(Ti) and current R-timestamp(Q). (h Suppose that transaction Tl issues write(Q). I Retimestamp(Q) > TS(Ti) or W-timestamp(Q) > ‘TS(Ti), then abort and roll back transaction operation, Hence in the timestamp ordering after Ti has already read or write the value of item Q before it write theitem Q, this will violate the timestamp ordering. If the above case (a) does not happen, then system executes the write operation and TS(Ti) sets to We-timestamp(Q). concurrency-control scheme rollback @ transaction Ti it may isst nd reject the ye either a read or write operation, new fnestamp is assigned and restarts it £29 Thomas’ Write Rule To improve the potential concurren' ts scheme, protocol for read operations are seme: Poa Thomas’ Write Rule. Jy than timestamp ordering protocol, some modifications are made in it. In only the rules for write operations are modified. This kation in write operations are called Suppose that transaction Tissues writel@)jement and Concurrency and R wactlons Man: DATABASE MANAGEMENT SYSTEMS (OBMS) 6.34 “Transact SH Coot ite operation and rollback Ti I R-timestamp(Q) > TS(Ti), then the system rejects the write see = eae gig to mre an obsolete value i If W-timestamp(Q) > TS(Ti, then write operation can be ignore : sets W-times * I above 2 cases di Ey then the system executes the write operation and tAMPIQ) tg ve 2 cases do not happen, the a T3(0 ; + wit the second rule, IF; ‘The difference between Timestamp ordering protocol and Thomas’ write rules ia el id be rolbaek wis Write(Q and TS(Ti) < W-timestamp(Q) then by the timestamp-ordering OO ot ‘Thomay write rule io cna an) = Rtimestamp() the obsolete write i ignored. By tnorng ¥ nedules confirm the definition of yer conflict serializable schedules that are but are nevertheless correct. Those scl ew lizable schedules [6.3 RECOVERY SYSTEM us causes such as power outage, di There may be possibilities that computer system may face failure from vé i fore, crash, software failure, or due to fire. If system failure occurs, information may be lost. Therefore, the database system must preserve the atomicity and durability properties of transactions by taking necessary actions even if the fallure occurs. Database system must have recovery mechanism which can ensure the consistent state of database by restoring database that exists before the failure occurs. Recovery time should be minimum ie. high availability must be provided by recovery scheme. 6.3.1 Fallure Clas: ‘There are various types of failure depending on the different causes that may occur in a system, each failure may be handled with different techniques. Following are types of failure: ication * System crash: If the software has some bugs in coding or malfunction of hardware or operating system that causes the loss of the content of volatile storage causes the transaction processing to halt. And the content Stores at nonvolatile storage are uncorrupted and remain unchanged. This is known as the fail-stop assumption * Transaction failure: There are two types of errors, logical and system error which may cause a transaction failure. * System error: The system has entered an undesirable state, such as systems enter into deadlock state, The transaction should not be execute further and rollback. The transaction will restart its execution, *. Logical error: Logical errors are internal conditions that are not satisfied such as data not found, data overflow, limits exceeded, and bad input. This wll not allow transactions to be executed normally. * Disk failure: Because of head crash during writing or failure during transfer of data, oss of data on disk blocks ¢ caused, To recover from failure, use other disks such as DVD or tapes or archival backups that saves a copy of takes backup of data. When system failure occurs, it should be recoverable, identify the type of failure of the device where data is due to failure, to do so we have to determine the recovery mechanism, stored and also check the contents of database affected To determine how the system should recover from failures, we need to identiy the failure modes of those devices used for storing data. Next. we must consider how these failure modes affect the contents of the database We have to maintain the database consistency and transaction atomicity even after the falure, we have to propot® algorithms known as recovery algorithms, which have the following two concerns:r pSASEMANAGEMENT SYSTEMS (opm) + orsecovery from failures ations Performed after a failure to recover 1 transaction atomicity, and durability after recove gaz Recovery Concepts he contents of database to maintain database consistency, y ‘he following things should be maintained while recover 19) Te states ofall the transactions must be noted which ing from a crash: were being executed tp ifthe execution state of any transaction is in the mid le of some operat roperti eer eee operation, the ACID properties of DBMS must (a ifthe transactions are not completed or completed, this state must be noted, And then the whole transaction must be rolled back, nese me ee @ Incase of inconsistent state, no transactions are allowed to leave the DBMS, ‘The following are two techniques which are used in recovering of data lly upd i (a) Before actually updating the physical database in persistent storage device, the logs of each transaction must be maintained. For example, MYSQL database keeps the log fle in LDF file. (LOF = Log Database File) and main database is kept in MDF file. (MDF - Master Database File) (p) Shadow paging technique is being used in volatile memory (RAM). After completion of the transaction, only the physical database is updated. : 63.3 Log based Recovery . Sequence of records is nothing but Logs, keeping all the activities in database. Log of each transaction is maintained in storage. Before updating the database by the execution of transaction, log should be updated, Log and log records are: + It contains information about when a transaction Ti initiates. + : It contains information about when a transaction Ti commits. * It contains information about when a transaction Ti aborts. The database can be modified using two approaches: * Deferred Update Technique: All the updation that will be done by transaction should be reflected to database, only after the transaction reaches to commit state. This technique is referred as deferred update technique. If transaction is aborted before it reach the commit state, it will not change the database in any way that will not UNDO operation. It may be required to REDO the operation effects from the committed transaction recorded into the log, Hence, deferred update is also known as the NO-UNDO/REDO algorithm. * Iimediate Modification Technique: If modification is done on database, while transaction is stil executing, it ication technique. 'SS2id to use immediate modi