6 States of Transaction in DBMS

In database management systems (DBMS), a transaction is a logical unit of work that consists of one or more database operations. These operations can include read, write, update, and deletion. A transaction is considered to be an indivisible and atomic operation, meaning that it must be executed in its entirety or not at all. To ensure the consistency and reliability of the database, transactions go through several states during their execution.

States of Transaction in DBMS

A transaction is a series of operations that are executed as a single unit of work, ensuring that either all the operations are successfully completed or none of them are. Here are six states of transactions in DBMS, let’s discuss them one by one.

Active state

In DBMS, the term “active state of a transaction” refers to the period of time during which a transaction is being executed or processed. During this state, the transaction is not yet committed or rolled back, and it holds locks on the data items it has accessed or modified.

When a transaction is in the active state, it is typically performing operations such as reading data from the database, updating data, or inserting new data. It may also be holding locks on the data it has accessed to prevent other transactions from modifying that data until it is either committed or rolled back.

Once the transaction has completed its operations and is ready to commit, it enters the “commit state”. If an error occurs during the transaction or if the transaction is explicitly rolled back, it enters the “abort state”. These states mark the end of the transaction’s lifecycle and release any locks that were held on the data.

Partially committed state

The partially committed state is a state that a transaction can enter after it has executed its final operation but before it is fully committed. In this state, some of the changes made by the transaction have been written to the database, but the transaction has not been officially committed.

During the partially committed state, the changes made by the transaction are not visible to other transactions. This is because the DBMS holds locks on the affected data items to prevent other transactions from accessing or modifying them until the transaction is committed.

If a failure occurs during the partially committed state, such as a system crash or a network failure, the transaction is rolled back to undo the changes that were made. This ensures that the database remains in a consistent state, and that any changes made by the transaction are not permanently lost.

Once a transaction has been fully committed, all of its changes are made permanent and become visible to other transactions. At this point, the DBMS releases any locks held by the transaction, and the transaction is considered to be complete.

Committed state

In committed state, a transaction enters after it has successfully completed and all of its changes have been made permanent in the database. In this state, the transaction is considered to be complete, and all of its changes are visible to other transactions.

Once a transaction has been committed, the DBMS releases any locks held by the transaction, allowing other transactions to access and modify the data items that were previously locked. At this point, the changes made by the transaction become part of the database’s permanent record and are no longer subject to rollback.

Transactions that are in the committed state are usually recorded in a transaction log, which allows the DBMS to recover from failures or crashes. If a failure occurs before a transaction is committed, the DBMS can use the transaction log to undo any changes made by the transaction and return the database to its previous consistent state.

The committed state is an important part of maintaining the integrity and consistency of a database. By ensuring that all changes made by transactions are properly recorded and made permanent, the DBMS can provide a reliable and secure environment for storing and accessing data.

Failed state

The failed state is a state that a transaction enters when it cannot be completed due to a system or application error. In this state, the transaction is considered to have failed, and any changes made by the transaction are rolled back.

When a transaction enters the failed state, the DBMS typically records information about the failure in a transaction log. This information can be used later to help diagnose and correct the cause of the failure.

Once a transaction has failed, it cannot be committed, and any locks held by the transaction are released. This allows other transactions to access and modify the data items that were previously locked.

To recover from a failed transaction, the DBMS must undo any changes made by the transaction and return the database to its previous consistent state. This process is known as a rollback, and it ensures that the database remains in a valid and consistent state despite the failure.

In some cases, it may be possible to restart the failed transaction or to initiate a new transaction to complete the desired operations. However, this depends on the nature of the failure and the specific requirements of the application or system.

Aborted state

The aborted state is a state that a transaction enters when it is intentionally rolled back or when it cannot be completed due to an error. In this state, any changes made by the transaction are undone, and any locks held by the transaction are released. This allows other transactions to access and modify the data items that were previously locked.

The aborted state is different from the failed state, which occurs when a transaction cannot be completed due to a system or application error. In contrast, a transaction enters the aborted state when it is explicitly rolled back, either by the application or by the DBMS.

The aborted state is an important part of maintaining the consistency and integrity of a database. By allowing transactions to be rolled back when necessary, the DBMS can ensure that the database remains in a valid and consistent state, even in the event of errors or failures.

Transactions can also enter the aborted state automatically if they violate certain integrity constraints or other rules defined in the database schema. In these cases, the DBMS may automatically roll back the transaction to prevent it from making invalid changes to the database.

Terminated state

The terminated state of a transaction in a DBMS refers to the point at which the transaction is either committed or rolled back, effectively ending its execution.

When a transaction is committed, all the changes made to the database during the transaction are permanently saved, and the transaction is said to be in a terminated committed state. On the other hand, if any of the operations in the transaction fails, the entire transaction is rolled back, and the database is restored to its previous state before the transaction started. In this case, the transaction is said to be in a terminated rolled back state.

Once a transaction is in a terminated state, it cannot be modified or undone, and its effects on the database are final. The transaction is removed from the system’s active transaction list, and the resources it held, such as locks on database objects, are released. The termination of a transaction is a critical aspect of database management, as it ensures data consistency and integrity by maintaining the ACID (Atomicity, Consistency, Isolation, and Durability) properties of the DBMS.

Bottom Line

By managing transactions through these states, DBMS ensures that the database remains consistent and reliable, even when multiple transactions are executed simultaneously.

Further Reading

• What is DBMS? (Components, Features & Advantages)
• Types of DBMS
• DBMS Architecture
• Normalization in DBMS
• Types of Data Models in DBMS
• Hashing in DBMS
• Deadlock in DBMS
• Functional Dependency in DBMS
• Referential Integrity in DBMS
• Difference between DBMS and RDBMS
• ACID Properties DBMS (Atomicity, Consistency, Isolation, Durability)