Cascading Rollback

Cascading rollback is formed using two different words, which are cascade and Rollback. The word cascade means “waterfall” and rollback means “ an act of making an action to change back to what it was before”. Due to the failure of a single transaction, a cascade of transaction rollbacks occurs.

Explanation:

• T1 writes value of A
• T2 reads A (before T1 commits)
• T3 reads A (value coming from T2)
• T1 aborts
• Since T2 and T3 used uncommitted data, both must roll back

Therefore, failure of T1 causes rollback of T2 and T3, resulting in cascading rollback.

Key Characteristics

• Occurs due to dirty reads (reading uncommitted data).
• Common in non-strict schedules.
• One transaction failure can affect multiple dependent transactions.
• Rollbacks propagate in a chain-like manner.
• Mainly seen in systems that allow read before commit.

How Cascading Rollback Occurs

• A transaction T1 writes a data item.
• Another transaction T2 reads that data item before T1 commits.
• If T1 aborts, the value read by T2 becomes invalid.
• T2 must also roll back.
• If a third transaction T3 depends on T2, it must also roll back.
• This creates a cascade of rollbacks.

Conditions Required for Cascading Rollback (Explanation)

• Transactions execute concurrently: Multiple transactions run at the same time, allowing them to access and modify shared data items.
• A transaction reads data written by another uncommitted transaction: One transaction uses a value that has been updated but not yet committed by another transaction (dirty read).
• The writing transaction aborts or fails: When the original transaction fails, its uncommitted changes are undone, making any dependent reads invalid.
• No strict locking: The DBMS allows reading data before the writing transaction commits, enabling cascading dependencies.

Problems Caused by Cascading Rollback

1. Wastes CPU Time and System Resources: Cascading rollback requires undoing the operations of multiple dependent transactions. This consumes extra CPU time, memory, and disk I/O, leading to inefficient use of system resources.

2. Increases Transaction Delay: Transactions that depend on failed transactions must be rolled back and re-executed. This increases their completion time and causes delays in overall transaction processing.

3. Reduces System Performance: Frequent rollbacks and re-execution shift system focus from normal processing to recovery tasks. As a result, database throughput decreases and performance is degraded.

4. Complicates Recovery Process: The system must identify and track all transactions that read uncommitted data. Rolling them back in the correct order makes the recovery process complex and error-prone.

How to Prevent Cascading Rollback

Cascading rollback can be avoided by using strict scheduling techniques:

• Processes only use committed data – No process reads data from another process until it is fully committed.
• Careful dependency management – Avoid unnecessary dependencies between processes.
• Checkpointing – Save process states periodically to limit rollback to the last safe point.
• Transaction protocols (like 2PC) – Ensure all nodes agree before committing updates.
• Message logging – Keep logs of communications to recover without rolling back dependent processes.