Types of Schedules Based on Recoverability in DBMS

In a Database Management System (DBMS), multiple transactions often run at the same time, and their execution order is called a schedule. It is important to ensure that these schedules do not cause data loss or inconsistencies, especially if a failure occurs.

A recoverable schedule allows the system to undo changes safely if needed, while some schedules may lead to unwanted rollbacks, causing issues like cascading failures. To prevent such problems, schedules are categorized based on their recoverability, such as recoverable schedules, cascaded schedules, cascade-less schedules and strict schedules.

Schedules Based on Recoverability

Recoverable Schedule

A recoverable schedule ensures that the database can return to a consistent state after a transaction failure.

In this type of schedule:

1. A transaction cannot use (read) data updated by another transaction until that transaction commits.
2. If a transaction fails before committing, all its changes must be rolled back, and any other transactions that have used its uncommitted data must also be rolled back.

Recoverable Schedule prevents data inconsistencies and ensures that no transaction commits based on unverified changes, making recovery easier and safer.

Example:

S1: R1(x), W1(x), R2(x), R1(y), R2(y), W2(x), W1(y), C1, C2; 

The given schedule follows the order of Ti->Tj => C1->C2. Transaction T1 is executed before T2 hence there is no chance of conflict occurring. R1(x) appears before W1(x) and transaction T1 is committed before T2 i.e. completion of the first transaction performed the first update on data item x, hence given schedule is recoverable. 

Let us see an example of an unrecoverable schedule to clear the concept more.

S2: R1(x), R2(x), R1(z), R3(x), R3(y), W1(x), W3(y), R2(y), W2(z), W2(y), C1, C2, C3; 

Ti->Tj => C2->C3 but W3(y) executed before W2(y) which leads to conflicts thus it must be committed before the T2 transaction. So given schedule is unrecoverable. if Ti->Tj => C3->C2 is given in the schedule then it will become a recoverable schedule. 

Example:

Note: A committed transaction should never be rollback. It means that reading value from uncommitted transaction and commit it will enter the current transaction into inconsistent or unrecoverable state this is called Dirty Read problem. 

Cascadeless Schedule

A cascade-less schedule ensures that if one transaction fails, it does not cause multiple other transactions to roll back.
In this type of schedule, a transaction is not allowed to use (read) uncommitted data from another transaction until that transaction is fully committed. This prevents cascading rollbacks, where a failure in one transaction forces many others to undo their changes. If a transaction fails before committing, only its own changes are undone, but other transactions that have read its data do not need to roll back, making the recovery process simpler and more efficient.

Example:

S3: R1(x), R2(z), R3(x), R1(z), R2(y), R3(y), W1(x), C1, W2(z), W3(y), W2(y), C3, C2; 

In this schedule W3(y) and W2(y) overwrite conflicts and there is no read, therefore given schedule is cascade less schedule. 

Special Case: A committed transaction desired to abort. As given below all the transactions are reading committed data hence it's cascadeless schedule. 

Strict Schedule

A schedule is strict if it is both recoverable and cascadeless.

A strict schedule ensures strong data consistency by following two key rules:

1. A transaction cannot use (read) uncommitted data from another transaction until that transaction commits.
2. A transaction cannot update (write) the same data modified by another transaction until the first one commits.

This means that if a transaction fails before committing, all its changes must be undone (rolled back), and any other transactions that used its uncommitted data must also be rolled back.

Strict schedule helps in maintaining a reliable and consistent database by preventing data conflicts and minimizing errors.

Example:

S4: R1(x), R2(x), R1(z), R3(x), R3(y), W1(x), C1, W3(y), C3, R2(y), W2(z), W2(y), C2; 

In this schedule, no read-write or write-write conflict arises before committing hence its strict schedule: 

Cascading Abort: Cascading Abort can also be rollback. If transaction T1 aborts as T2 read data that is written by T1 it is not committed. Hence its cascading rollback. 

Example: 

Relation Between Strict, Cascadeless and Recoverable schedules

Below is the picture showing the correlation between Strict Schedules, Cascadeless Schedules, and Recoverable Schedules.

 From the above figure, we can conclude that:

1. Strict schedules are all recoverable and cascade schedules.
2. All cascade-less schedules are recoverable.

In Database Management Systems (DBMS), the schedules can be categorized based on their recoverability. Recoverability refers to the ability to recover the database to a consistent state after a transaction failure.