It so happens that the transaction fails to execute until completion owing to software issues, hardware problems, or system crash. In such a situation, the failed transaction is rolled back by the rollback operation. However, another transaction may have utilized the value yielded by the failed transaction. Then that transaction will have to be rolled back as well to maintain consistency in the database.
Explanation of recoverability
This table represents a schedule with two transactions. The first transaction T1 reads the value of A and writes it, and this value is read by another transaction T2 which writes it as well. T2 performs the commit operation, but T1 does not execute until completion. It is now necessary to perform the rollback operation on T1. Although T2 needs to be rolled back as well, the process of rollback does not work on T2 as it has already performed the commit operation. This type is the irrecoverable schedule.
A schedule is irrecoverable if Ta read the updated data of Tb, and Ta gets committed before Tb.
This table represents a schedule that has two transactions. T1 reads the value of A and writes it, and the same is read by T2 who writes it as well. T1 fails to execute and is rolled back. It is necessary to rollback T2 as it has read the results of T1. No commit operation had been performed on T2 before committing T1, and so the rollback operation can be successfully performed on T2. This type is recoverability with cascade rollback.
Recoverability with cascade rollback: Such a recoverability is possible if Ta reads the result of Tb and the commit operation of Ta does not occur before the commit operation of Tb.
This table represents a schedule that has two transactions. T1 reads the value of A, writes it, and performs the commit operation. The result is read by T2, who writes it as well. Hence, this schedule is cascade-less recoverable.