---

Implementing Transaction Processing using Redo Logs

---

• Deferred update/write and Redo log
  • The second way to implement transaction processing is

    The update/write operation is deferred and the log used is a REDO log

  ---

  ---

• Deferred write (update)

  • An deferred update operation will NOT make the updates immediately to the database

    The updates are made after the transaction has completed successfully

  • When transaction T₁ updates the data item X (deferred), but has yet not completed and in the mean time, a transaction T₂ reads the data item X , then T₂ will read the OLD value of X

  ---

• Redo log
  • A REDO log is a log file that contains information to REDO the effect of transactions

    ---

  • A effect of a transaction changing values in some records in the database

    To redo the effect of a transaction is to redo the updates made by the transaction

    ---

  • In order to redo the updates made by the transaction, we save the NEW value of every updated data item !!!

    ---

  • A REDO log contains the following types of log records

    [start, TID] : indicates that transaction TID has started [write, TID, X, new_value]: indicates that transaction TID has over-written data item X with the value was new_value [commit, TID] : indicates that transaction TID has completed successfully [abort, TID] : indicates that transaction TID has been aborted

    ---

  • Operation:

    When a new transaction begins , do: Assign a unique transaction ID T to the transaction Append [start, T] to the UNDO log When transaction T reads a data item X: Don't need to do anything... When transaction T writes a data item X: update X (with the new value) - the update is made to the copy in the transaction buffer (NOT to the data in the database) Append [write, T, X, new_value] to the REDO log When transaction T completes successfully: Append [commit, T] to the UNDO log When transaction T is aborted: Append [abort, T] to the UNDO log

  ---

  xxxx

  ---

• Example transaction processing using deferred write and REDO logs

  • Consider a simple transaction T that updates a value x :

    T: x := x - 1000 y := y + 1000

    (E.g., transfer $1000 from back account x to y )

    ---

  • Initially, the database state is as follows:

    ---

  • Transaction processing is as follows:

    When transaction T starts, the transaction processing system writes a start transaction to to log file: Transaction T must read the data item x from disk into its memory buffer To update data on disk , the transaction only update the data item x in its memory buffer After updating, transaction also write a REDO record to the log Notice that the old value of x is written to the log The log must be written before the transaction commits Transaction T then read y from disk into its memory buffer T only update the data item y in its memory buffer After updating, transaction also write a REDO record to the log Finally, transaction T completes: First: write commit record Only then update database:

  ---

  ---

• How deferred write + redo log ensures atomicity
  • Recall that the execution of a transaction is atomic :

    Either everything is done (i.e., both x and y are updated Or else nothing is done (i.e., both x and y are NOT updated

  • Question:

    What can cause partial execution ?

    Answer:

    System failure Access conflict (later)

    ---

  • Consider a system failure occurred at some step in the above execution:

    System failed any time before step 6 is complete: There is NO commit record ! x and y were unchanged no problem: discard log data of any uncomitted transactions System failed during step 6: There is a commit record ! Redo transaction using the redo log !