Types of Schedules based Recoverability in DBMS

In this article, we are going to deal with the types of Schedules based on the Recoverability in Database Management Systems (DBMS). Generally, there are three types of schedules given as follows:

Schedules Based on Recoverability

• Recoverable Schedule: A schedule is recoverable if it allows for the recovery of the database to a consistent state after a transaction failure. In a recoverable schedule, a transaction that has updated the database must commit before any other transaction reads or writes the same data. If a transaction fails before committing, its updates must be rolled back, and any transactions that have read its uncommitted data must also be rolled back.
• Cascadeless Schedule: A schedule is cascaded less if it does not result in a cascading rollback of transactions after a failure. In a cascade-less schedule, a transaction that has read uncommitted data from another transaction cannot commit before that transaction commits. If a transaction fails before committing, its updates must be rolled back, but any transactions that have read its uncommitted data need not be rolled back.
• Strict Schedule: A schedule is strict if it is both recoverable and cascades. In a strict schedule, a transaction that has read uncommitted data from another transaction cannot commit before that transaction commits, and a transaction that has updated the database must commit before any other transaction reads or writes the same data. If a transaction fails before committing, its updates must be rolled back, and any transactions that have read its uncommitted data must also be rolled back.

These types of schedules are important because they affect the consistency and reliability of the database system. It is essential to ensure that schedules are recoverable, cascaded, or strict to avoid inconsistencies and data loss in the database.

Recoverability

Recoverable Schedule

A schedule is said to be recoverable if it is recoverable as the name suggests. Only reads are allowed before write operations on the same data. Only reads (Ti->Tj) are permissible. 

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. 

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. 

Example:

Dirty Read Problem

Cascadeless Schedule

When no read or write-write occurs before the execution of the transaction then the corresponding schedule is called a cascadeless schedule. 

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. 

Cascadeless Schedule

Strict Schedule

If the schedule contains no read or write before commit then it is known as a strict schedule. A strict schedule is strict in nature. 

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: 

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:

Cascading Abort

Co-Relation between Strict, Cascadeless, and Recoverable schedules

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

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. 

FAQs on Types of Schedules based Recoverability in DBMS

Q.1: Does data loss happens with the non-recoverable schedule?

Answer:

The answer is ‘Yes’. Non-recoverable Schedules can lead to data loss. It happens when a transaction reads data from another transaction which is rolled back later, changes made by reading the transaction becomes permanent, which might lead to loss of data integrity.

Q.2: What is Cascading Rollback?

Answer:

Cascading Rollback is simply termed as a situation where failure happens in one transaction and leads to a series of rollback on the dependent transaction.