Chapter 21

Chapter 21 Recovery

Objectives

To study how the (A and D) properties of transactions may be ensured under concurrent execution and crashes.

Points to emphasise

C and I are the concern of concurrency control. Recovery procedures must ensure A and D.
We are not concerned here with creating a stable storage abstraction. We assume the system can make the probability of losing data in persistent store on a crash arbitrarily small.
As in Chapter 14 we assume a fail-stop model for a crash.
The effects of any committed transaction must persist.
The transaction is the unit of recovery. It is the unit which is meaningful to the application.
Theoretical models are based on the idea of an invocation history, starting from the creation of an object. Practical implementations are based on recording an object’s state. Section 20.2 justifies this.
A recovery log record must be written before an update in place is made.

Possible difficulties

The object model: holding a complete invocation history of an object allows ANY state to be recovered. In practice we have to record a limited amount of state.

The (write-ahead) log-based approach to recovery should be straightforward. Any difficulty may be associated with the switch from reasoning at an abstract level to practical implementation issues.

We are assuming that every operation can be undone and redone and that UNDO and REDO are idempotent in case of crashes during recovery. This is OK for the simple examples here but not so obvious in general. It is safe to assume that before and after state are available. Only prior state need be recorded in the (write ahead) log before the operation is performed.

Teaching hints

To follow through the recovery log approach focus on what is in volatile main memory and what is in persistent store. Recall from Chapter 7 that the unit of transfer to disk may be large. It is not realistic to write every update to disk synchronously.
Focus on the significance of commit; the transaction is the unit of recovery. You must be able to perform the invocations made by a committed transaction, even if this is from information in the log.