Transaction Properties in DBMS

Transaction Properties in DBMS

When we talk about transactions in a database, it’s important to remember that a single transaction is not just one action—it can consist of multiple operations executed internally. Once a transaction is submitted, it must complete all the operations included within it. After completion, it should notify the user about success or failure along with the changes applied to the database.

However, when multiple users submit transactions concurrently (at the same time), the database might enter an inconsistent state due to overlapping executions. To avoid such situations and ensure data integrity even in the case of concurrent access or system failures, transactions are required to follow four fundamental properties: Atomicity, Consistency, Isolation, and Durability. Together, these are known as the ACID properties.

Machine Learning Tutorial:–Click Here
Data Science Tutorial:-Click Here
Complete Advance AI topics:- CLICK HERE
Deep Learning Tutorial:- Click Here

What is a Transaction?

A transaction is a collection of operations that represent a single logical unit of work in a database. Its purpose is to maintain data integrity and consistency before and after execution. Operations that form a transaction may include:

• Adding new data
• Modifying existing data
• Accessing existing data
• Or a combination of these

A transaction must adhere to the four ACID properties in order to be considered correct:

• Atomicity
• Consistency
• Isolation
• Durability

Let’s understand each property in detail.

1. Atomicity

The term “all or nothing” best describes atomicity. It guarantees that either no operations are applied at all or that every operation in a transaction is carried out successfully. Partial execution does not exist.

Key Features of Atomicity:

• The transaction’s operations must all be finished, or none at all.
• Maintained despite failures (disk, CPU, software, or deadlocks).
• The DBMS is in charge of ensuring atomicity.

Atomicity relies on two fundamental operations:

• Abort: If the transaction fails, all changes are rolled back, leaving the database unchanged.
• Commit: If the transaction succeeds, all changes become permanent.

Example:

Suppose we transfer ₹100 from account A (₹600) to account B (₹300).

• After successful execution, balances will be:
  • A = ₹500
  • B = ₹400

However, the database becomes inconsistent if the transaction fails in the middle, for example, if the amount is taken out of A but not added to B. To prevent this, DBMS maintains old values and restores them if execution is incomplete.

2. Consistency

The phrase “no violation of integrity constraints” defines consistency. It guarantees that a transaction moves the database between legitimate states.

• Before and after a transaction, the database must always abide by its rules, or constraints.
• A transaction is rejected by the database if it breaks any rules.

Example:

The total balance before and after the transaction should stay the same if the preceding scenario is used:

• Before transaction: 600 + 300 = ₹900
• After transaction: 500 + 400 = ₹900

Thus, consistency is maintained. There would be inconsistency if the transaction failed in the middle since the total would not match.

Maintaining consistency is mainly the responsibility of the application programmers, who must enforce constraints during transaction coding.

3. Isolation

Isolation guarantees that one transaction’s operations continue to be separate from another until it is finished. To put it another way, T2 cannot access a data item while T1 is still using it.

This prevents interference between concurrent transactions and is enforced by the Concurrency Control subsystem of the DBMS.

Why Isolation Matters:

Even if atomicity and consistency are preserved individually, concurrent execution may cause issues due to overlapping operations.

Example:

Consider two transactions:

• T1: Transfer ₹750 from Account A to B
• T2: Transfer 20% of A’s balance to B

If executed concurrently without isolation, results may vary.

• In a consistent schedule, total funds remain correct (₹13,000).
• In an inconsistent schedule, incorrect totals may arise (₹13,250), leading to errors.

Thus, isolation ensures correctness by preventing conflicts between transactions.

4. Durability

Durability guarantees that once a transaction is committed, its results are permanent, even if the system crashes immediately afterward.

• Changes made by committed transactions survive system failures.
• The Recovery subsystem of DBMS ensures this property.

DBMS maintains a log file to track all write operations. If the system crashes before writing changes to disk, the log helps restore committed transactions once the system restarts.

Complete Python Course with Advance topics:-Click Here
SQL Tutorial :-Click Here
Download New Real Time Projects :–Click here

Conclusion

Reliable database transactions are built on the foundation of the ACID properties: atomicity, consistency, isolation, and durability. Even in the event of failures or concurrent access, they guarantee that data is accurate, consistent, and recoverable.

In short:

• Atomicity = All or nothing
• Consistency = No rule violations
• Isolation = Independent execution
• Durability = Changes are permanent

Together, these properties make transactions robust and safeguard databases from inconsistencies, ensuring smooth operations in multi-user and fault-prone environments.

For more insights on databases and system design, stay connected with UpdateGadh.

transaction properties in dbms with examples
transaction in dbms
acid properties in dbms
transaction states in dbms
transaction properties in dbms pdf
transaction properties in dbms geeksforgeeks
transaction properties in dbms w3schools
transaction management in dbms
transaction properties in dbms
explain transaction properties in dbms
define transaction properties in dbms
list out the transaction properties in dbms
transaction properties in dbms with examples
transaction properties in dbms in hindi
transaction properties in dbms pdf
transaction properties in dbms with example
transaction properties in ddb
transaction properties in sql