DBMS MODULE-6

Introduction to Transaction Management

Transaction management is crucial for ensuring the integrity and reliability of databases, especially in multi-user environments where concurrent access is common. Understanding transactions, states, and recovery systems forms the foundation for managing these operations effectively.

Transaction Concept

A transaction is defined as a logical unit of database processing that may include various operations such as read, write, insert, update, or delete. It represents a sequence of operations that accomplish a specific task and can be part of a larger program or a high-level query. For example, transferring money between bank accounts involves multiple steps, including updating balances and ensuring all operations are completed successfully.

Example of a Banking Transaction

Consider a scenario where a bank employee transfers Rs 500 from Account A to Account B. The transaction involves several critical steps:

• Read the current balances of both accounts.

• Calculate the new balances for both accounts.

• Update the database with the new balances.

• Ensure that the operation is committed only if all steps succeed, and if any step fails, rollback to the previous state.

Transaction States

Transactions progress through several states:

• Active: The transaction is currently executing.

• Partially Committed: The transaction has completed its operations but not yet committed.

• Committed: The transaction has been permanently applied to the database.

• Failed: The transaction failed and needs to be aborted.

• Terminated: The transaction is completed and no further actions can be performed.

Transaction boundaries are marked by Begin and End operations, differentiating each transaction clearly within an application.

ACID Properties

Transactions are governed by the ACID properties, which are essential to ensure reliable processing:

• Atomicity: Ensures that a transaction is all-or-nothing. If any part of the transaction fails, the entire operation is rolled back.

• Consistency: Guarantees that a transaction takes the database from one valid state to another, preserving data integrity.

• Isolation: Transactions should operate independently of one another. Intermediate states may not be visible to other transactions until committed.

• Durability: Once a transaction is committed, its effects are permanent, even in the event of a system failure.

Recovery Management

Recovery management involves techniques to maintain the integrity of the database in case of failures. The primary goal is to ensure that once a transaction has been committed, it can be reliably recovered or that operations can be undone if necessary.

Types of Recovery Techniques

• Deferred Update: Changes made during the transaction are not applied until the transaction is committed. If a failure occurs, changes are not made.

• Immediate Update: Changes are applied to the database as operations execute. If a transaction fails, the system must undo any changes made.

• Shadow Paging: Involves maintaining a separate page for each transaction that allows for instantaneous rollback by switching back to the previous page in case of failure.

Example of Recovery Scenario

Suppose a transaction involves transferring funds between accounts. If the system crashes after the first account is updated but before the second account is updated, recovery processes must ensure that no funds are lost and the database remains consistent.

System Log

A log is maintained to track transactions, recording critical events such as when a transaction starts, reads or writes data, and when it is committed or aborted. This log is essential in recovery processes to restore the database to a consistent state after a failure.

Concurrency Control

In a multi-user environment, concurrency control methods ensure that multiple transactions can execute simultaneously without leading to data inconsistencies. Common methods include:

• Lock-Based Protocols: Control access to data resources using locks to prevent other transactions from accessing the same data concurrently.

• Timestamp-Based Protocols: Use timestamps to order transactions and ensure that conflicting operations respect the order of their timestamps.

Deadlock Situations

Deadlocks can occur in systems where two or more transactions are waiting for each other to release locks, creating a cycle of dependency that halts processing. Coffman conditions outline four necessary components for deadlocks to occur:

1. Mutual Exclusion: Resources cannot be shared.

2. Hold and Wait: Transactions holding resources may request additional resources.

3. No Pre-emption: Resources cannot be forcibly taken from transactions.

4. Circular Wait: A cycle of transactions waiting on each other exists.

For effective transaction management, it's vital to understand these concepts and implement strategies to handle transactions, ensuring consistency and recovery in a concurrent environment.