Transaction Management in DBMS: States, Types & ACID

By : Fiona Brown Fiona Brown
Hours Updated

⚡ Smart Summary

Database Transaction Management treats one or more database operations as a single logical unit that moves the database from one consistent state to another. It relies on ACID properties, defined transaction states, and schedules to keep concurrent access correct.

  • 🔁 Core Unit: A transaction groups related read and write operations so they succeed or fail together, never halfway.
  • 🧪 ACID Properties: Atomicity, consistency, isolation, and durability guarantee correct results even under failure or concurrency.
  • 🚦 Transaction States: Active, partially committed, committed, failed, and terminated describe a transaction’s lifecycle.
  • 👥 Why Concurrency: A database is shared, so many transactions run at once and must not corrupt each other’s data.
  • 📋 Schedules: A schedule orders the operations of parallel transactions while preserving each transaction’s internal sequence.
  • 🔗 Serializability: A concurrent schedule is correct when its result equals some serial execution, judged by conflict or view equivalence.
  • ↩️ Recovery: A failed transaction is rolled back so its partial writes never reach the committed database.
Read More

Transaction Management in DBMS

What is a Database Transaction?

A Database Transaction is a logical unit of processing in a DBMS which entails one or more database access operations. In a nutshell, database transactions represent real-world events of any enterprise.

All types of database access operations that are held between the beginning and end transaction statements are considered a single logical transaction in DBMS. During the transaction the database is inconsistent. Only once the transaction is committed is the state changed from one consistent state to another.

Database Transaction moving between consistent states
Database Transaction

Facts About Database Transactions

  • A transaction is a program unit whose execution may or may not change the contents of a database.
  • The transaction concept in DBMS is executed as a single unit.
  • If the database operations do not update the database but only retrieve data, this type of transaction is called a read-only transaction.
  • A successful transaction can change the database from one CONSISTENT STATE to another.
  • DBMS transactions must be atomic, consistent, isolated, and durable.
  • If the database were in an inconsistent state before a transaction, it would remain in the inconsistent state after the transaction.

Why Do You Need Concurrency in Transactions?

A database is a shared resource. It is used by many users and processes concurrently. Examples include banking systems, railway and air reservation systems, stock market monitoring, and supermarket inventory and checkouts.

Not managing concurrent access may create issues like:

  • Hardware failure and system crashes.
  • Concurrent execution of the same transaction, deadlock, or slow performance.

Controlling this shared access is the job of concurrency control, which uses locking and timestamps to interleave transactions safely. Before that, it helps to know the states a transaction passes through.

States of Transactions

The various states of a transaction concept in DBMS are listed below:

State Description
Active State A transaction enters the active state when the execution process begins. During this state, read or write operations can be performed.
Partially Committed A transaction goes into the partially committed state after the end of the transaction.
Committed State When the transaction reaches the committed state, it has completed its execution successfully, and all of its changes are recorded to the database permanently.
Failed State A transaction is considered failed when any one of the checks fails, or if the transaction is aborted while it is in the active state.
Terminated State The state of a transaction reaches the terminated state when the transaction leaves the system and cannot be restarted.

State transition diagram for a database transaction

Let us study a state transition diagram that highlights how a transaction moves between these various states.

  1. Once a transaction starts execution, it becomes active. It can issue a READ or WRITE operation.
  2. Once the READ and WRITE operations complete, the transaction reaches the partially committed state.
  3. Next, some recovery protocols need to ensure that a system failure will not result in an inability to record the transaction’s changes permanently. If this check succeeds, the transaction commits and enters the committed state.
  4. If the check fails, the transaction goes to the failed state.
  5. If the transaction is aborted while in the active state, it goes to the failed state. The transaction should be rolled back to undo the effect of its write operations on the database.
  6. The terminated state refers to the transaction leaving the system.

RELATED ARTICLES

What Are ACID Properties?

ACID Properties are used for maintaining the integrity of the database during transaction processing. ACID in DBMS stands for Atomicity, Consistency, Isolation, and Durability.

  • Atomicity: A transaction is a single unit of operation. You either execute it entirely or do not execute it at all. There cannot be partial execution.
  • Consistency: Once the transaction is executed, it should move from one consistent state to another.
  • Isolation: A transaction should be executed in isolation from other transactions. During concurrent execution, intermediate results from simultaneously executed transactions should not be made available to each other.
  • Durability: After successful completion of a transaction, the changes in the database should persist, even in the case of system failures.

ACID Property in DBMS With Example

Below is an example of the ACID property in DBMS:

Transaction 1: Begin X=X+50, Y = Y-50 END
Transaction 2: Begin X=1.1*X, Y=1.1*Y END

Transaction 1 is transferring $50 from account X to account Y.

Transaction 2 is crediting each account with a 10% interest payment.

If both transactions are submitted together, there is no guarantee that Transaction 1 will execute before Transaction 2 or vice versa. Irrespective of the order, the result must be as if the transactions take place serially, one after the other.

Types of Transactions

Based on application areas:

  • Non-distributed vs. distributed.
  • Compensating transactions.
  • Transaction timing.
  • On-line vs. batch.

Based on actions:

  • Two-step.
  • Restricted.
  • Action model.

Based on structure:

  • Flat or simple transactions: consist of a sequence of primitive operations executed between a begin and end operation.
  • Nested transactions: a transaction that contains other transactions.
  • Workflow.

What is a Schedule?

A schedule is a process of creating a single group of multiple parallel transactions and executing them one by one. It should preserve the order in which the instructions appear in each transaction. If two transactions are executed at the same time, the result of one transaction may affect the output of the other.

Example

Initial Product Quantity is 10
Transaction 1: Update Product Quantity to 50
Transaction 2: Read Product Quantity

If Transaction 2 is executed before Transaction 1, outdated information about the product quantity will be read. Hence, schedules are required.

Parallel execution in a database is inevitable. But parallel execution is permitted when there is an equivalence relation among the simultaneously executing transactions. This equivalence is of three types.

Result Equivalence: If two schedules display the same result after execution, it is called a result equivalent schedule. They may offer the same result for some values and different results for another set of values. For example, one transaction updates the product quantity while another updates customer details.

View Equivalence: View equivalence occurs when the transactions in both schedules perform a similar action. For example, one transaction inserts product details into the product table, while another transaction inserts product details into the archive table. The transaction is the same, but the tables are different.

Conflict Equivalence: In this case, two transactions update or view the same set of data. There is a conflict among the transactions, as the order of execution will affect the output.

What is Serializability?

Serializability is the process of searching for a concurrent schedule whose output is equal to a serial schedule where transactions are executed one after the other. Depending on the type of schedule, there are two types of serializability:

  • Conflict serializability.
  • View serializability.

The two differ in how strictly they judge equivalence, as summarised below.

Aspect Conflict Serializability View Serializability
Basis Order of conflicting operations Read-from and final-write relationships
Test Precedence graph must be acyclic View equivalence to a serial schedule
Strictness Stricter, a subset Broader, includes blind writes
Cost to check Efficient Computationally hard

Every conflict serializable schedule is also view serializable, but not the reverse, which is why conflict serializability is the practical test a DBMS applies.

FAQs

Commit makes a transaction’s changes permanent in the database. Rollback undoes every change since the transaction began, returning the database to the consistent state that existed before it started.

Atomicity. If a crash occurs partway through, atomicity ensures the partial work is discarded, so the transaction is treated as if it never ran. Durability then protects committed work after recovery.

AI analyses lock waits and deadlock graphs to spot the transactions that block others, then recommends an isolation level or index change that reduces contention without weakening correctness.

To a degree. By learning the lock-request patterns that preceded past deadlocks, a model can flag a risky transaction mix early, letting the scheduler delay or reorder before a cycle forms.

A serial schedule runs one transaction fully before the next starts, so no interleaving can corrupt data. It is slow, which is why the goal is a concurrent schedule serializable to it.

Summarize this post with: