UoL CS Notes
Menu

Recoverable Schedules

COMP207 Lectures

This lecture aims to fix the Concurrency & Partial Execution Example. We said that there a no good solutions to recover from this problem.

Dirty Reads

This is where the isolation property is not enforced in order to gain efficiency:

  • Spend less time preventing dirty reads.
  • Gain more parallelism by executing more transactions that would otherwise have to wait.

You can set this in the DBMS:

SET TRANSACTION READ WRITE
	ISOLATION LEVEL READ UNCOMMITTED;`

You can also set the first value to READ ONLY.

You can also set the second value to:

  • READ COMMITTED
  • REPEATABLE READ
  • SERIALIZABLE

Cascading Rollback

If a transaction $T$ aborts then we need to:

  • Find all transaction that have read items written by $T$.

    This is very slow and we wan to avoid this.

  • Recursively abort all transaction that have read items written by an aborted transaction.

    If we do not abort these then we break isolation. If we do abort them then we can break durability.

Recoverable Schedules

The problem for durability in regards to cascading rollbacks is that if a transaction $T_2$ reads data from some transaction $T_1$, then $T_2$ commits and afterwards $T_1$ aborts.

We can still do cascading rollback, but only active transaction can be forced to abort.

A schedule is recoverable if the following is true:

  • A transaction $T_1$ commits and has read an item $X$ that was written before by a different transaction $T_2$.
  • Then $T_2$ must commit before $T_1$ commits.

There is also the following additional requirement:

  • All log records have to reach disk in the order in which they are written.

    This avoids the issue where the commit statements can be swapped.

Example

This is an example of a recoverable schedule:

\[S_1: w_2(X);w_1(Y);w_1(X);\mathbf{r_2(Y)};w_2(Y);\mathbf{c_1};c_2;\]

This is however not serialisable.