Avoiding Cascading Rollbacks

Cascading rollbacks have the issues of breaking durability and they are also slow. As a result we want to avoid them.

Recoverable schedules still cascade.

Cascadeless Schedules

A schedule is cascadeless if each transaction in it reads only values that were written by transaction that have already committed.

No dirty reads = no cascading rollbacks.

Additionally, for recoverable schedules, the log records have to reach the disk in the right order.

Cascadeless schedules are recoverable but not serialisable.

A schedules is strict if each transaction in it reads and writes only values that were written by transaction that have already committed.

For example:

\[S_1:w_2(X);c_2;w_1(X);r_1(X);c_1;\]

This is the most popular variant of 2PL as it enforces:

The following constraints must be followed:

A transaction $T$ must not release any lock that allows $T$ to write data until:
- $T$ has committed or aborted, and
- The commit/abort log record has been written to disk.

This means that:

With simple locking no locks can be released until the conditions are met.
With shared/exclusive locks just exclusive locks can’t be released.

For examples of strict 2PL with simple and shared/exclusive locks see the lecture.

With this method there is still a risk of deadlocks we can fix this by:

Detecting deadlocks & fixing them.
Enforcing deadlock-free schedules. This is an issue as deadlock-free schedules aren’t (strict) 2PL.

Schedules can be categorised in the following hierarchy: