Scribd
Upload
35 views

Implementing Transaction Processing Using Redo Logs

1. Transaction processing can use deferred writes and a redo log. This involves deferring updates until transaction commit and logging changes to allow redo if needed. 2. A redo log records start, write, commit, and abort records to track transaction changes. It allows redoing writes if needed to ensure atomicity. 3. If a failure occurs after commit, the redo log is used to apply all writes. This guarantees the transaction executes fully or not at all, ensuring atomicity.

Uploaded by

dawodyimer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
35 views

Implementing Transaction Processing Using Redo Logs

1. Transaction processing can use deferred writes and a redo log. This involves deferring updates until transaction commit and logging changes to allow redo if needed. 2. A redo log records start, write, commit, and abort records to track transaction changes. It allows redoing writes if needed to ensure atomicity. 3. If a failure occurs after commit, the redo log is used to apply all writes. This guarantees the transaction executes fully or not at all, ensuring atomicity.

Uploaded by

dawodyimer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Implementing Transaction Processing using Redo Logs

Deferred update/write and Redo log

The second way to implement transaction processing is

1. The update/write operation is deferred and

2. 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 T1 updates the data item X (deferred), but has yet not completed and in the mean time, a transaction T2 reads the
data item X , then T2 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

1. [start, TID] : indicates that transaction TID has started

2. [write, TID, X, new_value]: indicates that transaction TID has over-written data item X with the value was
new_value

3. [commit, TID] : indicates that transaction TID has completed successfully

4. [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:

1. When transaction T starts, the transaction processing system writes a start transaction to to log file:

2. Transaction T must read the data item x from disk into its memory buffer
3. 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

4. Transaction T then read y from disk into its memory buffer


5. T only update the data item y in its memory buffer

After updating, transaction also write a REDO record to the log

6. 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 !

You might also like