Transaction Management and Concurrency Control Advanced Database Dr. AlaaEddin Almabhouh

Learning outcomes At the end of this chapter, you will be able to: Define the terms: Transaction, Concurrency control, ACID, timestamp Explain briefly the properties of transaction Discuss the problems happen during the time concurrent access. Discuss the various database locking techniques.

Transaction ? Transactions a transaction is a logical unit of work an action or series of actions which access or change the contents of a database

Example BEGIN TRANSACTION; INSERT ({S#:’S5’, P#:’P1’, QTY:1000}) INTO SP; IF any error occurred THEN GO TO UNDO; UPDATE P WHERE P# # ‘P1’ TOTQTY:=TOTQTY + 1000; COMMIT TRANSACTION; GO TO FINISH; UNDO: ROLLBACK TRANSACTION; FINISH: RETURN;

Transaction The previous example (a logical unit of work) involves two updates The database can be deemed to be inconsistent during that transaction Both updates need to be executed or the database will be left in an inconsistent state A systems that supports Transaction Processing enables successful completion of transactions the entire transaction executes or is totally cancelled

ACID Properties ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee database transactions are processed reliably. In the context of databases, a single logical operation on the data is called a transaction. For example, a transfer of funds from one bank account to another, even though that might involve multiple changes (such as debiting one account and crediting another), is a single transaction.

Transaction Properties ATOMICITY ‘all or nothing’. A transaction is an indivisible unit CONSISTENCY Consistency is a very general term that demands the data meets all validation rules that the overall application expects ISOLATION To demonstrate isolation, we assume two transactions execute at the same time, each attempting to modify the same data. One of the two must wait until the other completes in order to maintain isolation. DURABILITY The effects of a successfully completed transaction must persist and not be lost because of subsequent failure. To satisfy the durability constraint, the database system must ensure the success message is delayed until the transaction is finalized.

Transaction manager The transaction manager provides atomicity COMMIT TRANSACTION (Commit) signals successful end of transaction the database should be (or is) in a consistent state all the updates can be made permanent ROLLBACK TRANSACTION (Rollback) signals unsuccessful end of transaction all updates made by the logical unit of work must be undone

Transaction logging Transactions are tracked by using logs Transaction records transaction ID type of log (start of transaction, insert, update..) identifier of the data item affected before image (value before change) after image (value after change) log management information (pointers) Logs can also be used for performance monitoring and auditing

Transaction logging

Systems Recovery System failure the contents of main memory are lost the exact status of transactions in progress is unknown these transactions have to be UNDONE (rolled back) on system start up transactions that do complete but do not manage to have the updates transferred to disk must be REDONE (rolled forward) Check points determine whether a rollback or roll forward is required Checkpoint the point of synchronisation between the database & transaction log file. All buffers are force written to secondary storage

Recovery - transaction categories Time tc tf T r a n s c t I o T1 T2 T3 T4 T5 At restart time, therefore, the system first goes through the following procedure in order to identify all transactions of types T2–T5: Start with two lists of transactions, the UNDO list and the REDO list. Set the UNDO list equal to the list of all transactions given in the most recent checkpoint record; set the REDO list to empty. Search forward through the log, starting from the checkpoint record. If a BEGIN TRANSACTION log entry is found for transaction T, add T to the UNDO list. If a COMMIT log entry is found for transaction T, move T from the UNDO list to the REDO list. When the end of the log is reached, the UNDO and REDO lists identify, respectively, transactions of types T3 and T5 and transactions of types T2 and T4. The system now works backward through the log, undoing the transactions in the UNDO list; then it works forward again, redoing the transactions in the REDO list. Note: Restoring the database to a consistent state by undoing work is sometimes called backward recovery. Similarly, restoring it to a consistent state by redoing work is sometimes called forward recovery. Finally, when all such recovery activity is complete, then (and only then) the system is ready to accept new work. Checkpoint (time tc) System failure (time tf)

Transaction recovery Start with 2 lists of transactions, the UNDO list and the REDO list set the UNDO list equal to the list of all transactions in the most recent checkpoint set the REDO list to empty Search forward through the log, starting from the checkpoint record If a BEGIN TRANSACTION entry is found for T, add T to the UNDO list If a COMMIT log entry is found for transaction T, move T from the UNDO list to the REDO list When the end of the log is reached, the 2 lists contain relevant transactions

Concurrency Control

Concurrency Control The process of managing simultaneous operations on the database without having them interfere with one another Enables multi-user and multi-program access without compromising database integrity Main features of a concurrency control protocol shared/exclusive locking granularity lock acquisition lock release

The lost update problem Transaction A time Transaction B - - RETRIEVE p t1 - - - t2 RETRIEVE p UPDATE p t3 - - t4 UPDATE p

The lost update problem Time Program 1 X Program 2 40 t1 read x 40 t2 40 read x t3 update x 40 x:=x+20 40 write x (commit) 60 t4 60 update x 60 x:=x+30 70 write x (commit) Every thing is ok until we reach t4 The update in t4 will take the value of x in t2 That means x = x + 30  x = 40 + 30 = 70 But the value of x has been updated by t3 in program1 That means x = x + 30  x = 60 + 30 = 90 this is the true value 90 not 70

Uncommitted dependency Arises if one transaction is allowed to retrieve or update a tuple that has been updated by another transaction but not yet committed Transaction A time Transaction B - - - t1 UPDATE p RETRIEVE p t2 - - t3 ROLLBACK - - Transaction A becomes dependent on an uncommitted change at t2

Uncommitted dependency Time Program 1 Program 2 bal t1 begin 100 t2 read(bal) 100 t3 bal:=bal+100 100 t4 begin write(bal) 200 t5 read(bal) : 200 t6 bal:=bal-10 rollback 100 t7 write(bal) 190 t8 commit 190 The problem here is that at t4 we read the bal updated on t3 But after that at t6 the program 2 rollback that means the update Has been removed from 200 to 100 go to t1 (rollback all the transactions). but program1 until now is working on 200 value

Locking Concurrency problems can be solved by locking A procedure to control concurrent access to data. When one transaction is accessing the database, a lock may deny access to other transactions Exclusive locks (X locks) if a transaction holds an exclusive lock on P then a request from some other transaction on P will be denied Shared locks (S locks) if a transaction holds a shared lock on P then a request from other transactions for an X lock will be denied a request from other transactions for a S lock on P will be granted

Locking S X true false False Tj Ti S , S true because we allow two shared locks on the tuple Locks must be held for a duration of access

A data access protocol A transaction that wishes to retrieve a tuple (row) must acquire an S lock on that tuple A transaction that wishes to update a tuple must acquire an X lock on that tuple A transaction will go into a wait state if a lock is denied X and S locks are normally held until the end of a commit or rollback is issued Note: Transaction requests for tuple locks are normally implicit; a "tuple retrieve" request is an implicit request for an S lock, and a "tuple update" request is an implicit request for an X lock, on the relevant tuple. Also, of course (as always), we take the term "update" to include INSERTs and DELETEs as well as UPDATEs per se, but the rules requires some minor refinement to take care of INSERTs and DELETEs. We omit the details here.

The lost update problem Transaction A time Transaction B - - RETRIEVE p t1 (acquire S lock on P) - - - t2 RETRIEVE p - (acquire S lock on P UPDATE p t3 - (acquire X lock on P) - wait t4 UPDATE p wait (acquire S lock on P) wait wait Fig. 15.06 is a modified version of Fig. 15.01, showing what would happen to the interleaved execution of that figure under the locking protocol described in Section 15.3. Transaction A's UPDATE at time t3 is not accepted, because it is an implicit request for an X lock on t, and such a request conflicts with the S lock already held by transaction B; so A goes into a wait state. For analogous reasons, B goes into a wait state at time t4. Now both transactions are unable to proceed, so there is no question of any update being lost. Locking thus solves the lost update problem by reducing it to another problem!—but at least it does solve the original problem. The new problem is called deadlock. It is discussed in Section 15.5.

Uncommitted dependency Transaction A time Transaction B - - - t1 UPDATE p - (acquire X lock on P) RETRIEVE p t2 - (request S lock on P) - wait t3 COMMIT/ROLLBACK wait (release X lock on P) wait resume: RETRIEVE P t4 (acquire S lock on P)

Q & A Slide 81 (of 82)