Schedules: Recoverable, Cascadeless, Strict

In a database, a schedule is an ordered sequence of operations from a set of transactions. When transactions run concurrently, their operations can interleave in many ways. However, not all interleavings are safe. To ensure data consistency and system reliability, it’s important to define which types of schedules are acceptable in the presence of failures.

There are three important categories of schedules based on their recovery properties: Recoverable, Cascadeless, and Strict.

1. Recoverable Schedules

A schedule is recoverable if transactions commit only after all the transactions whose changes they have read have committed.

Why is this important?
If a transaction T2 reads a value written by T1 and T1 fails, T2 has read invalid data. Recoverable schedules ensure that this situation doesn’t lead to inconsistency because T2 will not commit until T1 does.

Example:

The schedule shown above is Recoverable since T1 commits before T2, which makes the value read by T2 correct.

2. Cascadeless Schedules

A schedule is cascadeless if transactions only read data written by committed transactions. This avoids the possibility of cascading rollbacks, where a failure in one transaction forces several others to roll back.

Why does this matter?
In recoverable schedules, a rollback in one transaction may still cause rollbacks in others. Cascadeless schedules prevent even that by ensuring no transaction reads uncommitted data.

Example:

Here, the updated value of X is read by transaction T2 only after the commit of transaction T1. Hence, the Schedule is a Cascadeless schedule.

3. Strict Schedules

A schedule is strict if a transaction can neither read nor write a data item until the last transaction that wrote it has committed or aborted.

Why is this the safest?
Strict schedules offer the strongest guarantees. If a failure occurs, only the failed transaction needs to be rolled back. No other transaction would have accessed any of its uncommitted writes.

Strict schedules are widely implemented in real systems because they are simple to recover from and ensure high consistency.

Example:

Here, transaction Tb reads/writes the written value of transaction Ta only after the transaction Ta commits. Hence, the Schedule is a strict Schedule.

Summary