What is Transaction in DBMS?
Transactions are a set of operations that are used to perform some logical set of work. A transaction is made to change data in a database which can be done by inserting new data, updating the existing data, or by deleting the data that is no longer required. There are certain types of transaction states which tell the user about the current condition of that database transaction and what further steps to be followed for the processing.
You might have encountered a situation when your system got crashed due to some hardware or software issues and got rebooted to ensure that all the data is restored in a consistent state. This protection of user's data even in case of a system failure marks as one of the major advantages of database management system. Various transactions are done as a part of manipulating the data in a database, these transactions can be seen as a set of operations that are executed by the user program in DBMS. Execution of a similar transaction multiple times will lead to the generation of multiple transactions. For example, Withdrawing some amount of money from the ATM can be seen as a transaction that can be done multiple times also.
Operations in Transaction
A certain set of operations takes place when a transaction is done that is used to perform some logical set of operations. For example: When we go to withdraw money from ATM, we encounter the following set of operations:
- Transaction Initiated
- You have to insert an ATM card
- Select your choice of language
- Select whether savings or current account
- Enter the amount to withdraw
- Entering your ATM pin
- Transaction processes
- You collect the cash
- You press finish to end transaction
The above mentioned are the set of operations done by you. But in the case of a transaction in DBMS there are three major operations that are used for a transaction to get executed in an efficient manner. These are:
1. Read/ Access Data 2. Write/ Change Data 3. Commit
Let's understand the above three sets of operations in a transaction with a real-life example of transferring money from Account1 to Account2.
Initial balance in both the banks before the start of the transaction
Account1 - ₹ 5000 Account2 - ₹ 2000
This data before the start of the transaction is stored in the secondary memory (Hard disk) which once initiated is bought to the primary memory (RAM) of the system for faster and better access.
Now for a transfer of ₹ 500 from Account1 to Account2 to occur, the following set of operations will take place.
Read (Account1) --> 5000 Account1 = Account1 - 500 Write (Account1) --> 4500 Read (Account2) --> 2000 Account2 = Account2 + 500 Write (Account2) --> 2500 commit
The COMMIT statement permanently saves the changes made by the current transaction. When a transaction is successful, COMMIT is applied. If the system fails before a COMMIT is applied, the transaction reaches its previous state after ROLLBACK.
After commit operation the transaction ends and updated values of Account1 = ₹ 4500 and Account2 = ₹ 2500. Every single operation that occurs before the commit is said to be in a partially committed state and is stored in the primary memory (RAM). After the transaction is committed, the updated data is accepted and updated in the secondary memory (Hard Disk).
If in some case, the transaction failed anywhere before committing, then that transaction gets aborted and have to start from the beginning as it can’t be continued from the previous state of failure. This is known as Roll Back. :::
Transaction States in DBMS
During the lifetime of a transaction, there are a lot of states to go through. These states update the operating system about the current state of the transaction and also tell the user about how to plan further processing of the transaction. These states decide the regulations which decide the fate of a transaction whether it will commit or abort.
The ROLLBACK statement undo the changes made by the current transaction. A transaction cannot undo changes after COMMIT execution.
Following are the different types of transaction States :
Active State: When the operations of a transaction are running then the transaction is said to be active state. If all the read and write operations are performed without any error then it progresses to the partially committed state, if somehow any operation fails, then it goes to a state known as failed state.
Partially Committed: After all the read and write operations are completed, the changes which were previously made in the main memory are now made permanent in the database, after which the state will progress to committed state but in case of a failure it will go to the failed state.
Failed State: If any operation during the transaction fails due to some software or hardware issues, then it goes to the failed state . The occurrence of a failure during a transaction makes a permanent change to data in the database. The changes made into the local memory data are rolled back to the previous consistent state.
Aborted State: If the transaction fails during its execution, it goes from failed state to aborted state and because in the previous states all the changes were only made in the main memory, these uncommitted changes are either deleted or rolled back. The transaction at this point can restart and start afresh from the active state.
Committed State: If the transaction completes all sets of operations successfully, all the changes made during the partially committed state are permanently stored and the transaction is stated to be completed, thus the transaction can progress to finally get terminated in the terminated state.
Terminated State: If the transaction gets aborted after roll-back or the transaction comes from the committed state, then the database comes to a consistent state and is ready for further new transactions since the previous transaction is now terminated.
Properties of Transaction in DBMS
There are four major properties that are vital for a transaction to be successful. These are used to maintain state consistency in the database, both before and after the transaction. These are called ACID properties.
Atomicity: This property means that either the transaction takes place completely at once or doesn’t happen at all. There is no middle option, i.e., transactions do not occur partially. Each transaction is considered as one single step which either runs completely or is not executed at all. Click here, to learn more about Atomicity in DBMS.
Consistency: This property means that the integrity constraints of a database are maintained so that the database is consistent before and after the transaction. It refers to the correctness of a database.
Isolation: This property means that multiple transactions can occur concurrently without causing any inconsistency to the database state. These transactions occur independently without any external interference. Changes that occur in a particular transaction are not visible/ accessible to any other transaction until that particular change in that transaction has been committed.
Durability: This property ensures that once the transaction has completed execution, the updates and modifications to the database are stored in and written to disk and they remain intact even if a system failure occurs. These updates become permanent and are stored in the non-volatile memory.
For learning in-depth about these properties visit ACID properties in DBMS
- A Transaction can be seen as a set of operations that are used to perform some logical set of work. A transaction is used to make changes in data in a database which can be done by inserting new data, altering the existing data, or by deleting the already data.
- Lifetime of a transaction has multiple states, these states update the system about the current state of the transaction and also tell the user about how to plan further processing.
- ACID properties of a transaction provide a method of ensuring consistency of a database in a way such that each transaction is a set of operations that acts a one single step, produces consistent results, acts in isolation from other transactions, and provides durability that makes a database resistant to system failures.