Hands-on 8: Write Ahead Log System

Intro to Trans

This hands-on assignment will give you some experience using a Write Ahead Log (WAL) system (as described in Chapter 8 of the course notes). You can do this hands-on on any computer that has a Perl language interpreter, but we will be able to answer your questions more easily if you run this on an Athena workstation. You can download the WAL system from here (if your browser displays the file in a window instead of saving it, use "File -> Save As" to save the file). The downloaded file is a Perl script named trans. Before trying to run it, change its permissions to make it executable, for example by typing:

athena% chmod +x trans

The trans command can be run as follows:

trans [-reset]

Trans is a simple WAL system that models a bank's central database. Trans implements intention logging for error-recovery (without shadow files) as presented in the System R paper and the class notes. Trans creates and uses two files, named LOG and DB, in the current working directory. The "LOG" file contains the log entries, and the "DB" file contains the last state of the database. All the updates to the "LOG" file are forced to the disk. In contrast, all the updates to the "DB" are buffered in RAM, you can use the flush command (described below) to force the current committed updates of "DB" to the disk.

After you run ./trans you can enter commands to manage transactions and accounts. There are also commands to simulate a system crash and to force file updates to the disk. All the commands to trans are case sensitive. Since trans uses the standard input stream, you can use the system in batch mode. To do this, place your commands in a file ("cmd.in" for example) and redirect the file to trans's standard input:

athena% ./trans -reset < cmd.in.

When using batch mode, make sure that each command is followed by a newline character (including the last one).

Commands interpreted by Trans

• begin tid
  Begin a transaction denoted by the transaction id tid. The tid is a positive integer that uniquely identifies a given transaction.

• init tid account_name starting_balance
  Create a new account with the given account_name and starting_balance. The first argument specifies that this operation is part of transaction tid. The account_name can be any character string with no white spaces

• write tid account_number new_value
  Update the account to the new_value

• commit tid
  Commit the transaction

• checkpoint
  Write a checkpoint

Following commands help us understand the dynamics of the WAL system:

• flush
  Force the current committed updates to the database file from buffer memory. A typical transaction based application does not use a command like flush; the transaction system itself takes care of flushing buffers appropriately

• print
  Print out the current state of the database

• crash
  Crash the transaction system (this is the only way to exit the program properly)

Using Trans

./trans -reset

begin 1
init 1 studentA 1000
commit 1
begin 2
init 2 studentB 2000
begin 3
flush
init 3 studentC 3000
write 3 studentC 3001
write 2 studentB 2001
commit 3
print
crash

Use a text editor to examine the "DB" file and answer the following questions:

1) When the database recovers, which accounts should be active, and what values should they contain?

2) Trans prints out the database contents after you type print. Why doesn't the database show studentB?

3) Can you explain why "DB" file does not contain a record for studentC?

4) What differences would you see if the flush command was not there?

Recovering the database

./trans
print
crash

5)Run trans again to recover the database. Examine the "DB" file. Did trans recover the database correctly?

6)Explain the "Losers" and "Winners" reported during the recovery.

Checkpoints

./trans -reset

begin 1
init 1 studentA 1000
commit 1
begin 2
init 2 studentB 2000
checkpoint
begin 3
init 3 studentC 3000
write 3 studentC 3001
write 2 studentB 2001
commit 3
print
crash

Examine the "LOG" output file. Note that the CHECKPOINT entry lists the uncommitted TID's at that point in time.

7) What is the advantage of using checkpoints?

8) Run trans again to recover the database and use the print command to look at the recovered database. Note down the list of "Losers". Does "DB" recover correctly? The checkpoint command does a flush command internally. Why is this important for the correct execution of the checkpoint?

9) Using a text editor, manually edit the "LOG" file and replace the line "CHECKPOINT 2" with "CHECKPOINT 2 1 ". Run trans again by typing the following:

./trans
print
crash

10) Examine the list of "Losers" and compare this with the list in question (8), why are these lists different?

11) Which line would you move to the end of "LOG" in question (10) to make the list of "Losers" identical to that in question (8)?