Unit-5: Concurrency Control and Recovery
Transaction
A transaction can be defined as a logical unit of work on the database. It may engage in any number of database operations. In other words, a transaction is an action, or series of actions that are being performed by a single user or application program, which reads or updates the contents of the database.
Let’s take an example of a simple transaction. Suppose a bank employee transfers Rs 500 from A's account to B's account. This very simple and small transaction involves several low-level tasks.
A’s Account
Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)
B’s Account
Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)
Operations in Transaction
The main operations in a transaction are:
· Read Operation: Read operation reads the data from the database and then stores it in the buffer in main memory. For example- Read (A) instruction will read the value of A from the database and will store it in the buffer in main memory.
· Write Operation: Write operation writes the updated data value back to the database from the buffer. For example- Write(A) will write the updated value of A from the buffer to the database
Properties of transaction (ACID Properties)
There are properties that all transactions should follow and possess. A transaction in a database system must maintain Atomicity, Consistency, Isolation, and Durability − commonly known as ACID properties − in order to ensure accuracy, completeness, and data integrity.
· Atomicity: This property states that a transaction must be treated as an atomic unit, that is, either all of its operations are executed or none. There must be no state in a database where a transaction is left partially completed. That is why, it is also referred to as “All or nothing rule“.
· Consistency: This states that no transaction should have any adverse effect on the data residing in the database. If the database was in a consistent state before the execution of a transaction, it must remain consistent after the execution of the transaction as well.
· Durability: This property ensures that all the changes made by a transaction after its successful execution are written successfully to the disk. It also ensures that these changes exist permanently and are never lost even if there occurs a failure of any kind.
Durability in databases is the property that ensures transactions are saved permanently and do not accidentally disappear or get erased, even during a database crash.
· Isolation: In a database system where more than one transaction being executed simultaneously and in parallel, the property of isolation states that all the transactions will be carried out and executed as if it is the only transaction in the system. No transaction will affect the existence of any other transaction.
# Levels of Isolation:
· Read uncommitted
· Read Committed
· Repeatable Read
· Serializable
# Deadlock in DBMS: A deadlock is a condition where two or more transactions are waiting indefinitely for one another to give up locks. Deadlock is said to be one of the most feared complications in DBMS as no task ever gets finished and is in waiting state forever.
#Reasons for a transaction failure could be -
· Logical errors: If a transaction cannot complete due to some code error or an internal error condition, then the logical error occurs.
· Syntax error: It occurs where the DBMS itself terminates an active transaction because the database system is not able to execute it. For example, The system aborts an active transaction, in case of deadlock or resource unavailability.
States of Transaction
A transaction goes through many different states throughout its life cycle. These states are called as transaction states. A transaction in a database can be in one of the following states:
· Active: This is the initial state of every transaction. A transaction is called in an active state as long as its instructions are getting executed. All the changes made by the transaction now are stored in the buffer in main memory.
· Partially Committed State: After the last instruction of transaction has executed, the transaction enters into a partially committed state. It is not considered fully committed because all the changes made by the transaction are still stored in the buffer in main memory.
· Committed State: After all the changes made by the transaction have been successfully stored into the database, it enters into a committed state. Now, the transaction is considered to be fully committed. After a transaction has entered the committed state, it is not possible to roll back the transaction. This is because the system is updated into a new consistent state. The only way to undo the changes is by carrying out another transaction called as compensating transaction that performs the reverse operations.
· Failed State: When a transaction is getting executed in the active state or partially committed state and some failure occurs due to which it becomes impossible to continue the execution, it enters into a failed state.
· Aborted State: After the transaction has failed and entered into a failed state, all the changes made by it have to be undone. To undo the changes made by the transaction, it becomes necessary to roll back the transaction. After the transaction has rolled back completely, it enters into an aborted state.
· Terminated State: This is the last state in the life cycle of a transaction. After entering the committed state or aborted state, the transaction finally enters into a terminated state where its life cycle finally comes to an end.
Concurrency Control
Concurrency can simply be said to be executing multiple transactions at a time. It is required to increase time efficiency. Concurrency is a process to ensure that data is updated correctly and appropriately when multiple transactions are concurrently executed in DBMS. It is highly important to ensure atomicity, isolation, and serializability of concurrent transactions.
Recovery
Data recovery is the method of restoring the database to its correct state in the event of a failure at the time of the transaction or after the end of a process. If a failure occurs while a transaction is executing, and the transaction is unable to finish executing, then the recovery algorithm must wipe out the effects of the partially completed transaction. That is, it must ensure that the database does not reflect the results of such transactions. Moreover, it must ensure that the results of transactions that do execute are never lost. When a DBMS recovers from a crash, it should maintain the following:
· It should check the states of all the transactions, which were being executed.
· A transaction may be in the middle of some operation; the DBMS must ensure the atomicity of the transaction in this case.
· It should check whether the transaction can be completed now or it needs to be rolled back.
· No transactions would be allowed to leave the DBMS in an inconsistent state.
There are two types of techniques, which can help a DBMS in recovering as well as maintaining the atomicity of a transaction:
· Maintaining the logs of each transaction, and writing them onto some stable storage before actually modifying the database.
· Maintaining shadow paging, where the changes are done on a volatile memory, and later, the actual database is updated.
Causes of transaction failure:
· System failure
· Transaction error or system error
· Concurrency control enforcement
· Local errors or exceptions
Requirements for Recovery:
The different requirements for recovery are as follows.
· In case of media failure e.g. disc-head crash:
o Part of persistent store is lost - need to restore it.
o Transactions in progress may be using this area abort uncommitted transactions.
§ Requirement for system failure e.g. crash - main memory lost:
o Persistent store is not lost but may have been changed by uncommitted transactions.
o Also, committed transactions effects may not yet have reached persistent objects.
· Requirement for transaction abort:
o Need to undo any changes made by the aborted transaction.
0 Comments