Concept Of Transaction Management

In simple SQL query, the SQL command (DML, DDL etc) sent to server and executed one after another In place of sending one by one SQL command to server we can combine multiple operations that are logically similar and send to server as a single logical unit. Eg. Transferring Rs 100 from one account to another Withdraw Rs. 100 from account_1 Deposit Rs. 100 from account_2 Collection of multiple operations that form a single logical unit is called as transaction A transaction is a sequence of one or more SQL statements that combined together to form a single logical unit of work Types of operations in transactions Read This operation transfers one data item from the database memory to a local buffer of the transaction that executed the read operation. Eg Data Selection/Retrieval Language SELECT * FROM STUDENTS Write This operation transfers one data item from the local buffer of the transaction that executed the write back to the database. Eg. Data Manipulation Language (DML) UPDATE STUDENT SET NAME= RAVI WHERE SID=102 Information processing in DBMS is divided into individual, indivisible operational logical units called transactions Transactions are one of the mechanisms for managing changes to the database A transaction is a series of small database operations that together form a single large operation Application programs use transactions to execute sequences of operations when it is important that all operations are successfully completed

Concept Of Transaction Management

During the money transfer between two bank accounts it is unacceptable for the operation that updates the second account to fail. This would lead to transferred money being lost as it would be withdrawn from one account but not inserted in the second account
BEGIN TRANSACTION transfer
UPDATE accounts SET balance=balance-100 WHERE account=A UPDATE accounts SET balance=balance+100 WHERE account=B If no errors then
COMMIT transaction

Else
ROLLBACK transaction

End If

END TRANSACTION transfer

Transaction Structure And Boundaries

The transactions consists of all SQL operations executed between the begin transaction and end transaction A transaction is started by issuing a BEGIN TRANSACTION command. Once this command is executed the DBMS starts monitoring the transaction. All operations are executed after a BEGIN TRANSACTION command and are treated as a single large operation When transaction is completed it must either be committed by executing a COMMIT command or rolled back by executing a ROLLBACK command Until a transaction commits or rolls back the database system remains unchanged to other users of the system. Therefore the transaction can make as many changes as it wishes but none of the updates are reflected in the database until the transaction completes or fails A transaction that is successful and has encountered no errors is committed that is all changes to the database are made permanent and become visible to other users of the database A transaction that is unsuccessful and has encountered some type of errors is rolled back that is all changes to the database are undone and the database remains unchanged by transaction The DBMS guarantees that all the operations in the transaction either complete or fail. When a transaction fails all its operations are undone and the database is returned to the state it was in before the transaction started

Need Of Transaction
A database management system (DBMS) should be able to survive in a system failure conditions that is if a DBMS is having a system failure then it should be possible to restart the system and the DBMS without losing any of information contained in the database Modern DBMS should not loose data because of system failure A DBMS must manage the data in the database so that as users change the data it does not become corrupt and unavailable Computer systems fail to work correctly for many of below reasons Software Errors Are normally the mistakes in the logic of the program code. Eg when the value of a variable is set to an incorrect value Hardware Errors They occur when a component of the computer fails for eg a disc drive Communication Errors In large systems programs may access data stored at numerous locations on a network. The communication links between sites on the network can fail to work Conflicting Programs When a system executes more than one program at the same time the program may access and change the same data for eg many users may have access to be one set of data Transaction processing is designed to maintain a database in a consistent state It ensures that any operations carried out on the system that is interdependent Transactions are either completed successfully or all aborted successfully Transaction processing is meant for concurrent execution and recovery from possible system failure in a DBMS

Fundamental Properties Of Transaction

To understand transaction properties we consider a transaction of transferring 100 rupees from account A to account B as below Let Ti be a transaction that transfers 100 from account A to account B. This transaction can be defined as Read balance of account A Withdraw 100 rupees from account A and write back result of balance update Read balance of account B Deposit 100 rupees from to account B and write back result of balance update
Read (A) A := A 100 Ti Write (A) Read (B) B := B +100 Write (B)

Atomicity
Transaction must be treated as single unit of operation That means when a sequence of operations is performed in a single transaction they are treated as a single large operation Examples
Withdrawing money from the account Making an airline reservation

The term atomic means things that cannot be divided into parts Similarly the execution of a transaction should either be complete or nothing should be executed at all No partial transaction executions are allowed Example : Money transfer in above example
Suppose some type of failure occurs after Write(A) but before Write(B) then system may loose 100 rupees in calculation which may cause error as sum of original balance(A+B) in accounts A and B is not preserved. In such case database should automatically restore original value of data items

Example : Making an airline reservation

Check availability of seats in desired flights. Airline confirms the reservation. Reduces number of available seats. Charges the credit card of the customer.

In above case either all above changes are made to database or nothing should be done as half done transaction may leave data as incomplete state If one part of transaction fails the entire transaction fails and the database state is left unchanged

Consistency
Consistent state is a state in which only valid data will be written to the database If due to some reasons a transaction is executed that violates the databases consistency rules, the entire transaction will e rolled back and the database will be restored to a state consistent with those rules On the other hand if a transaction is executed successfully it will take the database from one consistent state to another consistent state DBMS should handle an inconsistency rather than ensure the database is clean at the end of each transaction Consistency guarantees that a transaction will never leave your database in a half finished state Consistency means if one part of the transaction fails all of the pending changes are rolled back, leaving the database as it was before the transaction was initiated Example : Money Transfer in above example
Initially the total balance in account A is 1000 and B is 5000 so the sum of balance in both accounts is 6000 and while carrying out above transaction some type of failure occurs after Write (A) but before Write(B) then system may loose 100 rupees in calculation. As now sum of balance in both accounts is 5900 (which should be 6000) which is not a consistent result which introduces inconsistency in database

Example Student Database

When a student record is deleted his details from all the other associated records must get deleted . A properly configured database would not let delete the student record, leaving its associated records stranded

All the data involved in the operation must be left in consistent state upon completion or roll back of the transaction , database integrity cannot be compromised

Isolation
Isolation property ensures that each transaction must remain unaware of other concurrently executing transaction Isolation property keeps multiple transactions separated from each other until they are completed Operations occurring in a transaction are invisible to other transactions until the transaction commits or rolls back For example when a transaction changes a bank account balance other transactions cannot see the new balance until the transaction commits Different isolation levels can be set to modify this default behaviour Transaction isolation is generally configurable in a variety of modes. For example in one mode a transaction blocks until the other transaction finishes Even though many transactions may execute concurrently in the system. System must guarantee that for every transaction (Ti) other all transactions has finished before transaction (Ti) started or other transactions are started execution after transaction (Ti) finished That means each transaction is unaware of other transactions executing in the system simultaneously Example : Money transfer in above example
The database is temporarily inconsistent while above transaction is executing with the deducted total written to A and increased total is not written to account B. If some other concurrently running transaction reads balance of account A and B at this intermediate point and computes A+B it will observe an inconsistent value (Rs. 5900). If that other transaction wants to perform updates on accounts A and B based on inconsistent values (Rs. 5900) that it read, the database may be left in an inconsistent state even after both transactions have been completed.

A way to avoid the problem of concurrently executing transactions is to execute one transaction at a time

Durability
Durability property guarantees that the database will keep track of pending changes in such a way that the server can recover from an abnormal termination Even if the database server is unplugged in the middle of the transaction it will return to consistent state when its restarted The database handles this by storing uncommitted transactions in a transaction log. By virtue of consistency a partially completed transaction wont be written to the database in the event of an abnormal termination. However when the database is restarted after such a termination it examines the transaction log for completed transactions that had not been committed and applies them The results of a transaction that has been successfully committed to the database will remain unchanged even after database fails Changes made during the transaction are permanent once the transaction commits Example Once the execution of the transaction completes successfully and the user will be notified that the transfer of the amount has taken place if there is no system failure in this transfer of funds The durability property guarantees that once a transaction completes successfully all the changes made by transaction on the database persist even if there is a system failure after the transaction completes execution

Working Of Transaction Processing Transaction State Diagram If a transaction completes successfully it may be saved on to the database server called as committed transaction A committed transaction transfers database from one consistent state to other consistent state which must persist even if there is a system failure Transaction may not always complete its execution successfully and such transaction must be aborted An aborted transaction must not have any change that the aborted transaction made to the database. Such changes must be rolled back Once a transaction is committed we cannot undo its effects by aborting it A transaction must be in one of the following states

Working Of Transaction Processing Transaction State Diagram

Active
This is initial state of transaction execution As soon as transaction execution starts it is in active state Transaction remains in this state till transaction finishes

Partially Committed
As soon as last operation in transaction is executed transaction goes to partially committed state At this condition the transaction has completed its execution and ready to commit on database server, but it is possible that it may be aborted as the actual output may be there in main memory and thus a hardware failure may prohibit its successful completion

Failed
A transaction enters a failed state after the system determines that the transaction can no longer proceed with its normal execution Example In case of hardware or logical errors while execution

Aborted
Transaction has been rolled back restoring to prior state Failed transaction must be rolled back. Then it enters the aborted state. In this stage the system has two options
Restart the transaction A restarted transaction is considered to be a new transaction which may recover from possible failure Kill the transaction Because of the bad input or because the desired data were not present in the database an error can occur. In this case we can kill the transaction to recover from failure

Committed
When the last data item is written out, the transaction enters into committed state This state occurs after successful completion of transaction A transaction is said to have terminated if it has either committed or aborted

State Diagram Of A Transaction

Partially Committed Active

Committed

Failed

Aborted

Transactions Schedules
Schedule is a sequence of instructions that specify the sequential order in which instructions of transactions are executed A schedule for a set of transactions must consist of all instructions present in that transactions it must save the order in which the instructions appear in each individual transaction A transaction that successfully completes its execution will have to commit all instructions executed by it at the end of execution A transaction that fails to successfully complete its execution will have to abort all instructions executed by transaction at the end of execution We denote this transaction T as Rr(X) Denotes read operation performed by the transaction T on object X Wr(X) Denotes write operation performed by the transaction T on object X Each transaction must specify its final action as commit or abort

Serial Transactions / Schedules

This is simple model in which transactions executed in serial order that means after finishing first transaction second transaction starts its execution This approach specifies first my transaction then your transaction other transactions should not see preliminary results Example Consider below two transactions T1 and T2 Transaction T1 Deposits Rs. 100 to both accounts A and B Transaction T2 Doubles the balance of accounts A and B
T1
Read (A) A = A + 100 Write (A) Read (B) B = B + 100 Write (B) T2 Read (A) A=A*2 Write (A) Read (B) B=B*2 Write (B)

A Consistent Serial Schedule

T1 T2 A 25 Read (A) ; A = A + 100 Write (A) Read (B) ; B = B +100 Write (B) Read (A) ; A = A * 2 Write (A) Read (B) ; B = B * 2 Write (B) 250 250 250 Final Balance 250 125 125 B 25 Operation Initial Balance

Concurrent Transactions / Schedules

Transactions executed concurrently that means operating system executes one transaction for a while then context switches to second transaction and so on Transaction processing can allow multiple transactions to be executed simultaneously on database server Allowing multiple transactions to change data in database concurrently causes several complications with consistency of the data in the database It is very simple to maintain consistency in case of serial execution as compared to concurrent execution of transactions Advantages
Improved Throughput
Throughput of transaction is defined as the number of transactions in a given amount of time If we are executing multiple transactions simultaneously that may increase throughput considerably

Resource Utilization
It is defined as the processor and the disk performing useful work or not in idle state The processor and disk utilization increase as number of concurrent transaction increases

Reduced Waiting Time

There may be some small and some long transactions may be executing on a system If transactions are running serially a short transaction may have to wait for a earlier long transaction to complete which can lead to random delays in running a transaction

Concurrent Transaction Example

Example Consider below two transactions T1 and T2 Transaction T1 Deposits Rs. 100 to both accounts A and B Transaction T2 Doubles the balance of accounts A and B
T1
Read (A) A = A + 100 Write (A) Read (B) B = B + 100 Write (B) T2 Read (A) A=A*2 Write (A) Read (B) B=B*2 Write (B)

Above transactions cab executed concurrently as shown below obtained by interleaving the actions of T1 with those of T2

A Consistent Concurrent Schedule

T1 T2 A 25 Read (A) ; A = A + 100 Write (A) Read (A) ; A = A * 2 Write (A) Read (B) ; B = B +100 Write (B) Read (B) ; B = B * 2 Write (B) 250 250 250 Final Balance 125 250 125 B 25 Operation Initial Balance

Concurrency Control
In a single user database only one user is accessing the data at any times in multiuse This means that the DBMS does not have to concerned with how changes made to the database will affect other users In a multi user database many users may be accessing the data at the same time. The operations of one user may interfere with other users of the database The DBMS uses concurrency control to manage multiuser databases Concurrency control is concerned with preventing loss of data integrity due to interference between users in a multiuser environment Concurrency control should provide a mechanism for avoiding and managing conflict between various database users operating same data item at same time

Problems Caused By Concurrent Executions Lost Update Problem

Overwrite the update made by another transaction / user
Time T1 T2 T3 T4 T5 T6 Begin Transaction Read (Bal) Bal = Bal 10 Write (Bal) Commit X Y Begin Transaction Read (Bal) Bal = Bal + 100 Write (Bal) Commit Bal 100 100 100 200 90 90

Problems Caused By Concurrent Executions Lost Update Problem Contd

Example Transaction Y has read the value of bal at time T2 as 100 and transaction X has read the value of bal at time T3 as 100 At time T4 transaction X has subtracted 10 from its value of bal (200) to disc But at time T4 transaction X has subtracted 10 from its value of bal (100) to produce 90 Transaction X updates the value of bal on the disc at time T5 The result of this operation is that the update performed by transaction Y (bal + 100 = 200) has been lost Transaction X has overwritten the result of transaction Y This problem is avoided by not allowing transaction X to read bal until transaction Y has committed its update

Problems Caused By Concurrent Executions Uncommitted Dependency Problem

When user sees intermediate step of another transaction before it is committed

Time T1 T2 T3 T4 T5 T6 T7 T8 Begin Transaction Read (Bal) Bal = Bal -10 Write (Bal) Commit Rollback X Y Begin Transaction Read (Bal) Bal = Bal + 100 Write (Bal) Bal 100 100 100 200 200 100 190 190

Problems Caused By Concurrent Executions Uncommitted Dependency Problem - Contd Example Transaction Y reads and updates the value of bal (100 + 100 = 200) and writes the result at time T4 At time T5 transaction X reads the value of bal (200) written by transaction Y and updates it However at time T6 transaction Y has failed and rolled back This means that the update it made to bal is undone and value of bal is returned to100 Therefore transaction X is updating the incorrect value of bal (200) Transaction X should be updating bal = 100 because transaction Y has been rolled back and its changes undone Transaction X has used the result of transaction Y but this result was incorrect as transaction Y failed This problem is avoided by not allowing transaction X to read the value of bal until transaction Y either commits or rolls back

Problems Caused By Concurrent Executions Inconsistent Analysis Problem

Transaction reads partial results of incomplete transaction update made by other transaction
Time T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 Begin Transaction Read (Bal(X)) BaL (X) = Bal (X) -10 Write (Bal(X)) Read (Bal(Z)) Bal(Z) = Bal(Z) + 10 Write (Bal(Z)) Commit Read (Bal(Z)) Sum = Sum + Bal (Z) Commit X Y Begin Transaction Sum = 0 Read (Bal(Y)) Sum = Sum + Bal Write (Bal(Y)) Sum = Sum + Bal(Y) Bal (X) Bal (Y) Bal (Z) Sum 100 100 100 100 90 90 90 90 90 90 90 50 50 50 50 50 50 50 50 50 50 50 25 25 25 25 25 25 25 35 35 35 35 0 0 100 100 150 150 150 150 185 185

Problems Caused By Concurrent Executions Uncommitted Dependency Problem - Contd

Example Transaction Y is summing the values of Bal (X), Bal (Y), Bal (Z). However at the same time transaction X is transferring 10 pounds between Bal (X) and Bal (Z) As transaction Y has used the old balances of Bal (X) and Bal (Z) its final result is incorrect This problem would be solved by preventing transaction X from transferring the money between accounts before transaction Y has committed

Concurrency Control Schemes

Fundamental property of transaction is Isolation Isolation property ensures that each transaction must remain unaware of other concurrently executing transactions When several transactions are executing simultaneously on a database it may not preserve isolation property for a long time To implement concurrent system there must be interaction among various concurrent transactions This can be done by using one of the concurrency control schemes All the following schemes are based on serializability of schedules

Lock Based Protocols

Introduction In concurrent environment many users can access same data in DBMS simultaneously, each has a feeling of exclusive access to the database To achieve this system we must have interaction amongst those concurrent transactions Whenever one transaction is accessing data second transaction should not change data Transaction can access data if it is locked by that transaction Locking is necessary in a concurrent environment to assure that one process should not retrieve or update a record which another process is updating. Failure to this would result in inconsistent and corrupted data Types Of Locks There are two types of locking to control concurrent access Shared Locks This type of locking is used by the DBMS when a transaction wants to read data without performing modification to it from the database Another concurrent transaction can also acquire a shared lock on the same data allowing the other transaction to read the data Shared locks are represented by S If a transaction T1 has obtained a shared lock on data item X then transaction T1 can only read data item X but cannot write on data item X SQL implementation LOCK TABLE Customer IN SHARED MODE Exclusive Locks This type of locking is used by the DBMS when a transaction wants to read or write data in the database When a transaction has an exclusive lock on some data other transaction cannot acquire any type of lock on the data Exclusive locks are represented by X If a transaction T1 has obtained a exclusive lock on data item X then transaction T1 can read data item X and also can write on data item X SQL implementation LOCK TABLE Customer IN EXCLUSIVE MODE

Deadlock
A system is said to be in state of deadlock if there exists a set of transactions such that every transaction in the set is waiting for another transaction to complete its execution Example Consider two transactions given below T1 : This transaction first reads and then writes data on data item X then after that performs read and write on data item Y T2 : This transaction first reads and then writes data on data item Y then after that performs read and write on data item X
T1 Read (X) Write (X) Read (Y) Write (Y) T2 Read (Y) Write (Y) Read (X) Write (X)

Deadlock Contd
Consider above two transactions are executing using locking protocol as below
T1 Lock-X (X) Read (X) Write (X) Lock-X (Y) Read (Y) Write (Y) Lock-X (Y) Read (Y) Write (Y) Lock-X (X) Read (X) Write (X) Wait for transaction T1 to unlock Lock-X on X Wait for transaction T2 to unlock Lock-X on Y T2

So in above schedule transaction T1 is waiting for transaction T2 to unlock data item Y and transaction T2 is waiting for transaction T1 to unlock data item X. So system is in a deadlock state as there are set of transactions T1 and T2 such that both are waiting for each others transaction to complete. This state is called as Deadlock state

Deadlock Contd
There are two principal methods to handle deadlock in a system Deadlock prevention We can use deadlock prevention technique to ensure that the system will never enter a deadlock state We can allow the system to enter a deadlock state and then we can detect such state by deadlock detection techniques and try to recover from deadlock state by using and deadlock recovery scheme Both of the above methods may result in transaction rollback Deadlock prevention is commonly used if the probability that the deadlock occurs in the system is high else detection and recovery are more efficient if probability of deadlock occurrence is less

Approaches For Deadlock Prevention

Approach 1
A simplest form in which a transaction acquires lock on all data items which will be required by transaction at the start of execution. It is effective as other transactions cannot hold lock on those data items till first unlocks data item Disadvantages
It is difficult to know in advance which data items need to be locked Data utilization is very low as many unused data items may be locked by transaction

Approaches For Deadlock Prevention Contd

Approach 2 - This approach uses time stamp ordering of data items. It is something like tree protocol and every transaction has to access data item in given sequence only. The variation of this approach with two phase protocol assures deadlock prevention. Order of data items must be known to every transaction
To have concurrency control two phase locking protocol is used which will ensure locks are requested in right order Timestamp ordering is determined by validation (Ti) that is TS (Ti) = validation (Ti) to achieve serializability The validation test for transaction Tj requires that for all transaction Ti with TS (Ti) < TS (Tj) then one of the following conditions must hold
Finish (Ti) < start (Tj) as Ti finishes before Tj starts the serializability should be maintained Ti completes its write phase before Tj starts its validation phase (Start (Tj) < Finish (Ti) < Validation (Tj))

This ensures writes of both transaction do not take place at the same time Read of Tj not affected by writes of Tj and Tj cannot affect read of Ti so serializability is maintained

Deadlock Detection And Recovery

When a system is having deadlock detection and recovery techniques the detection is done periodically to check whether the system is in deadlock, if yes then the recovery techniques are used to resolve this deadlock This can be done with the help some deadlock algorithms To achieve this the system must do the following System should maintain information about current data items allocation to transactions and requests to be satisfied Algorithm that uses this information to detect deadlock Recovery techniques to be applied after detection of deadlock Deadlock Detection Deadlock can be detected using directed graph called as wait-for-graph The graph G = (V,E) can be seen as V is of vertices that is set of transaction in execution concurrently and E is set of edges. Such that edge Ti -> Tj if Ti-> Tj is present in graph it shows that transaction Tj is waiting for transaction Ti to release a data item it needs If cycle is present in wait-for-graph then deadlock is present and transactions in cycle are deadlock To detect deadlock system must maintain wait-for-graph and periodically invoke an algorithm that searches cycle in the graph. If no cycle is present it means no deadlock is present in the system If deadlock occurs frequently then detection algorithm should be involved more frequently problem in this scenario is that data items locked by deadlock. Transaction will be available until the deadlock is problem This may tend to more cycles in graph degrading capacity of granting lock requests

Recovery From Deadlock

When deadlock is detected in the system, then the system should be recovered from deadlock using recovery schemes A most common solution is rollback one or more transaction to break the deadlock Methods to recover from deadlock
Section of victim
If deadlock is detected then one or transactions are selected to break the deadlock Transactions with minimum cost should be selected for rollbacks Cost can be detected by following factors
For how much time transaction has computed and how much time it needs to do How many data items it has locked How many data items it may need ahead Number of transaction to be rollback

Recovery From Deadlock Contd

Rollback
Once victims are decided then there are two ways to do
Total Rollback The transaction is aborted and then it is restarted Partial Rollback Rollback the only transaction which is needed to break the deadlock

But this approach needs to record some more information like state of running transactions, locks on data item held by them, and deadlock detection algorithm specifies points up to which transactions to be rollbacked and recovery method has to rollback After sometime transaction resumes; partial transaction

Starvation
It may happen every time same transaction is selected as victim and this may lead to starvation of that transaction System should take care that every time same transaction should not be selected as victim. So it will not be starved