A transaction does not happen in an instant; it moves through several states from the moment it starts until it finishes. These states describe what the transaction is doing at any point in time and how the DBMS is managing it.
Understanding transaction states helps you see how a transaction evolves, how failures are handled, and how the system decides whether changes are saved permanently or completely undone. We will cover the main states in simple, beginner‑friendly terms here; the deeper details of transaction lifecycle and recovery will be explained in a separate article.
The Main Transaction States
1. Active
The transaction is executing its operations.
Reads and writes are being performed on the database.
The transaction is in progress but no final decision (commit or abort) has been made yet.
This is the working phase of the transaction, where the DBMS is carrying out the SQL statements inside it.
2. Partially Committed
The transaction has completed all its operations successfully.
The DBMS has recorded all changes in its transaction log but has not yet made the final decision to permanently write them to the main database.
At this stage, the transaction is waiting for the “final stamp” of approval before the changes become visible to other users.
3. Committed
The transaction is successfully completed.
All changes are permanently written to the database.
The changes are now visible to other transactions.
Once a transaction reaches Committed state, it cannot be rolled back; its effects are durable.
4. Failed
During execution, the transaction encounters an error (for example, constraint violation, deadlock, or system problem) and cannot be completed as planned.
At this point the transaction is marked as failed, and the DBMS prepares to undo its partial changes.
Reasons for failure may include:
Primary key or foreign key violation.
Not enough disk space.
System crash or network issue.
5. Aborted (Rolled Back)
The transaction is cancelled and all its effects are reversed using the log or undo mechanisms.
The database returns to the state it was in before the transaction started.
After abort:
The transaction may be restarted if the cause of failure is temporary.
Or it may be permanently terminated, depending on the situation and application logic.
How the States Are Connected
A normal, successful transaction typically follows this path:
Active → Partially Committed → Committed
If something goes wrong during execution:
Active → Failed → Aborted
Some advanced systems may introduce internal states (like “waiting” or “in‑doubt”), but for beginners, these five states are enough to understand how a transaction moves from start through work and decision to either commit or abort.
Example in a Bank Transfer
Imagine a bank‑transfer transaction that deducts money from Account A and adds it to Account B:
Active:
The DBMS is executing the twoUPDATEstatements.Partially Committed:
Both updates are recorded in the log, but final write‑to‑disk is pending.Committed:
The transfer is complete; both account balances are permanently updated.
If a constraint is violated (for example, Account A does not have enough balance):
Failed → Aborted:
The system undoes both updates, leaving both accounts unchanged.
Why Transaction States Matter?
They show what a transaction is doing at any moment (working, waiting to commit, or being undone).
They help the DBMS perform recovery after failures using logs and state information.
They lay the foundation for understanding transaction lifecycle, concurrency, and recovery in later topics.
Summary
Transaction states in DBMS describe the journey of a transaction from start to finish. A transaction begins in the Active state, may move to Partially Committed, then to Committed if successful, or to Failed and finally Aborted if it cannot be completed. These states capture the logical flow of a transaction and are essential for ensuring data consistency, recovery, and reliability in database systems.