Transaction Properties

Definition

Transaction properties are the characteristics that define how a database transaction must behave to guarantee correctness, reliability, and data integrity. In particular, the ACID properties ensure that a transaction is executed as an indivisible unit, preserves database rules, does not interfere improperly with other transactions, and remains permanently saved once committed.

A transaction property is not just a theoretical idea; it is a practical requirement used by database systems to control how operations are processed. For example, in a bank transfer, if money is deducted from one account but not credited to another due to failure, transaction properties prevent the database from remaining in an inconsistent state.

Main Content

1. Atomicity

Meaning and core idea

Atomicity means a transaction is treated as a single unit of work. Either all operations inside the transaction are completed successfully, or none of them are applied at all. There is no middle state where only part of the transaction is saved.

Why it matters

This property prevents partial updates. If a transaction contains several steps and one step fails, the entire transaction must be rolled back so that the database returns to its previous stable state.

Atomicity is often described using the phrase “all or nothing.”
For example, consider a money transfer from Account A to Account B:

Debit Account A.
Credit Account B.

If the debit is completed but the credit fails due to a system crash, atomicity ensures the debit is undone. This prevents money from disappearing.

Example:

A student registration transaction may include:
inserting student details,
assigning a course,
generating a fee record.

If the third step fails, atomicity makes sure the first two steps are also undone, so the system does not contain incomplete registration data.

2. Consistency

Meaning and core idea

Consistency means a transaction must take the database from one valid state to another valid state. The transaction must obey all database rules, constraints, triggers, relationships, and integrity conditions.

Why it matters

It ensures the database never violates its own logic. If a transaction would break a rule, it should not be allowed to commit.

Consistency is about preserving correctness of data according to defined constraints such as:

primary key constraints,
foreign key constraints,
unique constraints,
check constraints,
business rules.

Example:

Suppose a database rule says an account balance cannot become negative.
If a withdrawal transaction tries to reduce balance below zero, the transaction violates consistency and must be rejected or rolled back.

Another example:

In a university database, a course enrollment record must refer to an existing student and an existing course.
If either reference is missing, the transaction is inconsistent and cannot be committed.

A simple view of consistency:

Valid State --Transaction--> Valid State

If the transaction would produce an invalid state, the system should stop it.

3. Isolation

Meaning and core idea

Isolation means that concurrent transactions should not interfere with each other in a way that causes incorrect results. Each transaction should appear to execute independently, even if many transactions are running at the same time.

Why it matters

In real systems, many users access the database simultaneously. Isolation prevents problems like lost updates, dirty reads, non-repeatable reads, and phantom reads.

Isolation is necessary because without it, one transaction might read temporary data written by another transaction that is not yet committed. That could lead to wrong decisions and data corruption.

Example:

Transaction T1 is updating the price of a product.
At the same time, Transaction T2 reads the product price.
If T2 sees the partially updated value before T1 commits, the result may be wrong.

Isolation levels help control how much one transaction can see of another transaction’s work. Higher isolation gives better correctness, but lower concurrency. Lower isolation gives better speed, but more risk of anomalies.

Common isolation problems:

Dirty read

reading uncommitted data

Non-repeatable read

reading different values for the same row in one transaction

Phantom read

new rows appearing during repeated queries

A simple visual idea:

T1: Read -> Update -> Commit T2: Read -> Update -> Commit

Proper isolation ensures the outcomes are as if transactions happened one by one.

4. Durability

Meaning and core idea

Durability means that once a transaction has been committed, its changes are permanent and will not be lost, even if the system crashes immediately afterward.

Why it matters

Users need confidence that once the database confirms success, the data will remain safe. Durability protects committed data from power failure, software crash, or hardware issues.

Durability is usually supported by mechanisms such as:

transaction logs,
checkpoints,
backup and recovery systems,
write-ahead logging,
stable storage.

Example:

A customer places an online order and the system shows “Order Confirmed.”
If the server crashes right after confirmation, durability ensures the order details remain stored and are recovered after restart.

Without durability, a committed transaction could vanish, causing major trust and business losses.

Working / Process

1. Start the transaction

The database begins a transaction when a user or application requests a group of operations to be processed together.
The system marks the transaction as active and prepares to track all changes.
At this stage, changes are usually not final and may still be undone if something goes wrong.

2. Execute operations while maintaining ACID behavior

The database performs the required reads and writes.
Atomicity ensures the group works as one unit.
Consistency checks validate that constraints are not broken.
Isolation controls interaction with other simultaneous transactions.
If any operation fails, the system may use rollback to cancel the transaction.

3. Commit or rollback the transaction

If every operation succeeds and the database remains valid, the transaction is committed.
Once committed, durability guarantees the changes are permanent.
If any error, crash, or rule violation occurs, the transaction is rolled back so that the database returns to its earlier correct state.

A simple process diagram for a transaction:

Start
  |
  v
Execute operations
  |
  v
Check rules and conflicts
  |
  +-----> Error? -----> Rollback -----> End
  |
  v
Commit
  |
  v
Permanent change

This process ensures that data remains accurate, stable, and recoverable.

Advantages / Applications

Data integrity and reliability

Transaction properties ensure the database remains correct even when failures occur.
They prevent partial writes, invalid states, and inconsistent records.
This is essential for systems that cannot afford data errors, such as banking, healthcare, and inventory management.

Safe concurrent processing

Isolation allows many users to work at the same time without damaging each other’s transactions.
This improves system usability in multi-user environments such as online shopping platforms, airline booking systems, and university registration portals.
It helps avoid common concurrency errors like dirty reads and lost updates.

Recovery and trust in critical systems

Durability ensures committed data survives crashes and restarts.
Users can trust that once a transaction is confirmed, it will not disappear.
This is crucial for payment systems, order processing, reservation systems, and financial applications.

Summary

Transaction properties make database transactions reliable and correct.
ACID stands for Atomicity, Consistency, Isolation, and Durability.
These properties ensure safe execution, valid data, and permanent committed changes.
Important terms to remember: transaction, commit, rollback, ACID, atomicity, consistency, isolation, durability, concurrency, recovery.