Published: 7 Dec 2025 | Reading Time: 8 min read
If you have ever wondered how a banking system ensures money doesn't disappear during a transfer or how e-commerce sites maintain accurate inventory even during peak sales, the answer lies in one core concept: Transaction in DBMS.
Today's applications are capable of dealing with millions of operations at the same time. Without proper transaction management, systems would face corrupted data, double payments, failed order updates, and inconsistent states—issues that can break trust and business reliability.
By going through this ultimate guide, one can understand all about a transaction in DBMS—starting from the role of ACID properties in ensuring correctness through the mechanism of concurrency control to recovery from crashes and the reason why serializability is considered the basis of consistency. The blog clarifies the whole theme in a very straightforward way, which is also suitable for exams, and it is enriched with up-to-date 2025 insights, examples, and best practices.
A transaction in Database Management System is a series of one or more database operations (like INSERT, UPDATE, DELETE, or SELECT) that together form a single, atomic unit of work. A transaction ensures that all the database operations are performed atomically, meaning that either all operations are successfully completed or none are. The primary goal of transactions is to maintain the database's consistency, even when errors or system failures occur.
Bank transfer:
Both of these operations must either succeed together or fail together to avoid inconsistencies in the database (e.g., money being deducted but not deposited).
Modern distributed systems manage transactions that go beyond microservices, cloud nodes, and clusters. ACID is still significant, but systems frequently use it together with BASE and event-driven recovery methods.
A Transaction in DBMS is defined by four key characteristics, often referred to as the ACID properties:
The ACID properties are fundamental to transaction management in DBMS:
Atomicity makes sure that a transaction is treated as a single unit of work. All operations within a transaction must be fully completed; otherwise, none of the changes are applied to the database.
Imagine that you are moving funds across bank accounts. Atomicity ensures that either the entire transfer (subtracting from one account and adding to the other) happens successfully, or if something goes wrong, none of the changes occur. If an error occurs halfway through, like a system crash, the database will be rolled back to its previous state, as if the transaction never happened.
Real-world Example: In an online shopping transaction, you may add items to your cart and proceed to checkout. Atomicity guarantees that no products are charged and that the inventory shows no change as if the transaction had never been undertaken in the event that the payment fails for any reason.
By following all database rules, constraints, and triggers, consistency ensures that a DBMS transaction will move the database from one legitimate state to another.
Every transaction should be a reflection of the database. For instance, in a system where certain rules are imposed (such as no less than zero in the account balance of a bank), a transaction has to follow those regulations. Any illegal operation that might breach such limitations is reversed, so the database is left in a stable condition at all times.
Real-world Example: A company's employee payroll system requires that an employee's salary should never be set to a negative amount. If an error causes this to happen during a transaction, the consistency property ensures the transaction is rejected, and the database remains in a valid state without any errors.
Isolation ensures that transaction in DBMS, even if executed concurrently, do not interfere with each other. Each transaction operates as if it is the only one running at that moment, without being affected by others.
This property prevents issues like dirty reads, non-repeatable reads, or phantom reads when multiple transactions are occurring simultaneously. It makes sure that the modifications from a single change are not exposed to other transactions until they are finalized, thus averting the situations of interference and inconsistencies.
Real-world Example: Let's say two customers are at the same moment attempting to purchase the very last seat on a plane. By using isolation, the system guarantees that although both operations are carried out concurrently, just one will succeed in making the booking, and the second user will get a message that the seat has already been taken. Therefore, the occurrence of conflicting or wrong transactions is avoided.
Durability ensures that, even in the case of a system failure or crash, a transaction's modifications are irreversible after it is committed.
After a transaction is completed and marked as "committed," its changes are stored permanently in the database. This ensures that if the system crashes after a transaction, the changes made by the transaction are not lost. The durability feature is typically made sure of by recording the transaction logs and using methods such as database checkpoints.
Real-world Example: After an online order is placed and payment is processed, durability ensures that even if the website crashes immediately after, the order remains in the system, and the payment is recorded correctly. The transaction's outcome is guaranteed to persist.
ACID ensures reliability, prevents data corruption, and maintains correctness under all conditions.
A transaction in DBMS is composed of a series of operations that manipulate and manage data in the database. Knowing these fundamental operations is necessary to understand how transactions work to keep the data they use intact, consistent, and reliable.
The read operation retrieves the value of a data item from the database. It is often the first step in a transaction, allowing the application to access current data for processing.
The write operation modifies the value of a data item in the database. This can include inserting new data, updating existing data, or deleting records.
A commit operation finalizes a transaction, making all changes performed by the transaction permanent in the database. Once committed, the effects of the transaction are visible to other transactions and persist even in the event of a system failure.
Using rollback, all changes that take place within the span of the current transaction are reversed; therefore, the database is returned to its last consistent state. The rollbacks are key to the error handling mechanism, which makes sure data integrity is not compromised due to the occurrence of partial or faulty transactions.
Consider a banking transaction where money is transferred from one account to another:
Transactions consist of key operations that ensure data is processed safely and consistently.
A transaction in DBMS goes through different stages in its lifecycle. These stages assist in understanding the progress as well as the success or failure of a transaction:
In the Active state, the transaction is in progress and executing its operations, such as reading, writing, updating, or deleting data. At this point, the changes made by the transaction are not yet permanent, and the transaction is still being processed.
Once all operations of the transaction have been executed, the system enters the Partially Committed state. Here, the transaction has finished its operations but has not yet finalized or made permanent in the database.
The Committed state indicates that the Transaction in DBMS has successfully completed, and all its changes have been permanently applied to the database. After this, the effects of the transaction are visible to other transactions, and no rollback is possible.
A transaction in the Failed state is essentially a failure or error that occurs during the execution of that transaction; hence, it cannot proceed any further. Such a transaction is stuck in the failure state, and no changes are made to the database.
The Aborted/Terminated state shows that the transaction has been rolled back due to an error or user intervention. The undoing of the transaction is complete; all changes made by the transaction are reversed, and the database is restored to its state before the transaction was initiated.
A transaction goes through various stages that show its advancement and result: Initially, it is Active, after the completion of operations, it becomes Partially Committed, if the transaction is successful, it will be Committed, otherwise, it moves to Failed and then Aborted in case of errors. These condition changes give the local management system the means to keep control, guarantee data consistency, and deal with the fallback situation if there is a malfunction.
In relational database management systems, a Transaction in DBMS is accomplished by using certain SQL commands that dictate how operations are grouped, carried out, committed, or reversed. These commands make sure that every stage of a transaction is in line with ACID properties and the data remains consistent.
1. BEGIN TRANSACTION / START TRANSACTION
This is the point where a transaction is marked to start. Any operations made after this point are considered part of the same transaction.
2. COMMIT
It records permanently all the modifications that have been made during the transaction. If a commit is made, the transaction will be irreversible.
3. ROLLBACK
Reverts every modification made to the active transaction. It is applied when a mistake happens or when processes need to be stopped in order to preserve consistency.
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
COMMIT;
Here, both updates succeed, so the transaction commits and changes become permanent.
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
-- Error occurs here
ROLLBACK;
If any step fails, the entire transaction is rolled back, ensuring no partial updates affect the database.
The transaction lifecycle in DBMS represents the different stages that a transaction goes through from the moment it is initiated until it is completed. The stages are the means by which the database keeps track of the progress, identifies the points of failure, and also makes sure that recovery and consistency are done correctly.
The transaction begins execution. It makes use of the database in operations such as read, write, update, or delete. Changes, if any, are not permanent at this point.
All operations have been executed successfully, but the final commit has not yet occurred. The database is prepared to make changes permanent.
The transaction completes successfully, and all its changes are permanently stored in the database. From this point on, there is no rollback.
As a result of an error or system issue, the transaction is unable to complete. The transaction cannot be continued in its current state.
The system rolls back the transaction due to a failure or manual cancellation. Any changes that were made during the aborted transaction are reverted, thus the database is restored to the previously consistent state.
The transaction comes to a formal end. It is after either a commit (successful completion) or a rollback (aborted completion) that this happens.
A transaction in DBMS can be divided into different categories based on the scope and complexity:
Local transactions in DBMS are operations that occur within a single database. They are relatively simple and typically involve straightforward tasks such as inserting, updating, or deleting records within that database. Since they involve just one system, the management of these transactions is less complex, and issues like coordination between multiple databases do not arise.
Distributed transactions involve multiple databases, often located on different servers or networks. These transactions require coordination between the databases to ensure that they all commit or roll back as a unified operation.
Distributed transactions frequently rely on protocols like the two-phase commit to guarantee that the transaction succeeds or fails across all participating databases simultaneously due to the difficulty of managing many systems and ensuring consistency.
Transactions are the core elements that help a database system to be accurate, reliable, and stable. They are the ones who make sure the data is consistent, even if several operations or users are running the system at the same time.
Transactions are the means through which data integrity is guaranteed. They do this by encapsulating the related changes in one unit; thus, they make sure that no partial updates occur and the data remains consistent, even in a situation of heavy user load.
In the case of a system crash, hardware failure, or an error, transactions are the means by which the system can be put back into a consistent state. The different stages of the log, checkpoint, undo, and redo ensure that the data that has been committed is saved, and the operations that were not completed are rolled back safely.
Transactions achieve concurrency control by isolating the operations that are going to be performed. By doing this, they avoid conflicts such as dirty reads, lost updates, or data inconsistency; hence, a large number of users can work simultaneously without the risk of these problems.
The sectors such as banking, e-commerce, finance, and healthcare, which are data-driven, can not do without accurate and fail-proof data. The correct handling of transactions is the thing that makes trust, reliability, and operations without interruption possible.
Always design transactions to be short, atomic, and well-controlled. This reduces lock contention, improves performance, and minimizes the risk of conflicts in high-traffic systems.
Concurrency control ensures that multiple transactions can execute simultaneously without causing data inconsistencies. There are several techniques used in concurrency control:
In the case of multiple transactions being carried out in a database system, the operations of these transactions can interleave in different ways. The sequence of these operations is known as a schedule. Knowledge of schedules and the idea of serializability is a must for keeping the data consistent in a database, in particular, in situations where transactions are run concurrently.
A schedule is a sequence that shows the chronological order in which concurrent transaction instructions are carried out. In general, schedules fall into:
Serializability is a key concept that ensures the outcome of a non-serial schedule is equivalent to some serial schedule. In other words, even though transactions are interleaved, the final state of the database is as if the transactions were executed one after another. This is essential for maintaining database consistency in the presence of concurrent transactions.
Serializability is the basis of the ACID properties, particularly isolation and consistency. By preventing concurrent transactions from interfering and thus producing wrong results, serializability keeps the database reliable and correct.
Although serial schedules always ensure safety, they limit the performance of the system. Non-serial schedules, along with suitable concurrency control and isolation levels, make a compromise between system throughput and database consistency.
Schedule equivalence ensures that concurrent execution is the same as sequential one, thus consistency and stability in multi-user environments are maintained.
In database systems, the interleaving of operations of concurrently executed transactions may differ, thus resulting in various schedules. To be sure that the system is working correctly, it is necessary to recognize if different schedules are equivalent, i.e. if they yield the same result and keep the database consistent. The most important ones are the three forms of schedule equivalence in DBMS:
Two schedules are result equivalent if the final state of the database after their execution is the same for the same initial data values. Nevertheless, this type of equivalence is seldom enough in theory, as it may not guarantee consistency for all possible data values or cases.
View equivalence considers the way data is read and written by transactions. Two schedules are viewed as equivalent if:
A schedule is view serializable if it is view equivalent to some serial schedule.
Conflict equivalence focuses on the order of conflicting operations, those that:
Two schedules are conflict equivalent if the order of all conflicting operation pairs is the same in both. If a schedule is in conflict with a serial schedule, it can be serialized.
Knowing schedule equivalence is the main way database systems can safely interleave transactions for improved performance, and at the same time be sure that the final outcome is the same as if transactions had been executed one after another. In multi-user setups, this is crucial for keeping consistency and stability.
Transaction management covers an array of operations that includes logging, commit protocols, and rollback mechanisms. These are the functions of each of them:
In distributed systems, the transaction coordinator is a component that handles the commit and rollback operations in different databases, thereby ensuring atomicity and consistency.
Transaction management and recovery are the mechanisms that make every database action reliable, traceable, and reversible if necessary. It is part of the same system that logging, commits, and rollbacks are, which is aimed at protecting the system from failures and keeping data consistent, even in distributed environments.
The transaction recovery methods that are implemented guarantee that the database will return to a consistent and correct state, even in the case of a system crash, power failure or software error. These methods cooperate with logs, checkpoints, undo/redo operations, and update strategies to uphold durability and consistency, which are the two pillars of the ACID properties.
A checkpoint is a snapshot of the current database state. During recovery, instead of scanning the entire log from the beginning, the DBMS starts recovery from the latest checkpoint.
Undo reverses the effects of uncommitted transactions.
Used when:
Example:
If a transaction of ₹5,000 withdrawal from an account had not been committed, then undo would make the balance the same as it was initially.
Redo essentially performs the same operations of the committed transactions again from the log to make them durable.
Used when:
Example:
In case a transaction transferred ₹2,000 and was successfully committed, but a crash occurred before writing to the disk, redo redoes the transfer.
In Deferred Update, all updates of a transaction are stored in logs but not applied to the database until the transaction commits.
Use Case: Systems where committing is infrequent or logging is cheap.
In Immediate Update, the data is changed in the database prior to the commit of the transaction.
Use Case: High-speed OLTP systems where early writing reduces bottlenecks.
Shadow paging avoids logs entirely.
A savepoint is a marker inside a transaction that allows partial rollback.
BEGIN;
UPDATE A;
SAVEPOINT sp1;
UPDATE B;
ROLLBACK TO sp1; -- Undo only update on B
COMMIT;
Useful in:
The log file is the heart of recovery.
A log records:
Logs must be written to disk before the actual data is updated.
This ensures:
Modern DBMS like PostgreSQL, Oracle, and MySQL are still very much dependent on WAL and checkpoints, but cloud-native systems have added:
This is what makes the recovery process not only faster but also more reliable, even when there are huge distributed workloads.
Recovery techniques ensure that the database never loses committed data and never applies invalid or partial transactions, regardless of failures. They safeguard the durability and consistency of every transaction.
By effectively handling transactions, you may also employ the following excellent tactics:
Transaction in DBMS are the lifeline of the DBMS, without which data integrity, consistency, and reliability would not be possible. These systems can still handle the complex, concurrent, and safe transactions efficiently by obeying the ACID principles, using appropriate concurrency control methods and recovery mechanisms.
Understanding transactions is quite essential for database administrators, developers, and anyone who is involved in the creation and management of data-driven applications.
A series of database activities carried out as a single unit of work is called a transaction in DBMS. It guarantees data consistency and integrity by ensuring that either all of the transaction's activities are correctly executed or none of them are.
Atomicity, Consistency, Isolation, and Durability are the four characteristics of ACID. These characteristics provide dependable transaction processing, preserve database integrity, and gracefully handle system faults.
The isolation property limits the intermediate state of a transaction from other transactions. By doing so, it prevents errors such as dirty reads, where a transaction reads changes that are not yet committed by another, thus ensuring that each transaction yields consistent results.
With the COMMIT command, the transaction is completed, and all changes are made permanent, whereas the ROLLBACK command cancels all modifications that were made during the transaction in case of an error or a failure, thereby allowing the database to regain its previous state.
The transaction states in the DBMS are: Active, Partially Committed, Committed, Failed, and Aborted. These states are used to monitor the transaction's progress as well as its completion, thus they enable correct error handling and recovery.
Local transactions are the ones that involve changes to a single database, while distributed transactions have to do with the changes that are made on several databases. Coordinating distributed transactions is necessary in order to be able to guarantee atomicity and consistency in all the databases that take part.
Transactions constitute the main source of data integrity; they enable concurrent access, and they also make up the system recovery in case of a failure. They go a long way towards keeping data accurate, consistent, and reliable, which is particularly important in the likes of banking applications, e-commerce, and inventory management.
Source: NxtWave - CCBP Blog
Original URL: https://www.ccbp.in/blog/articles/transaction-in-dbms
Contact: [email protected] | +919390111761 (WhatsApp only)