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.
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.
