Implement Quiescent Checkpointing

[couger01]

Exercise 14.46 (p.431) asks you to add quiescent checkpointing to the simpledb server. The SimpleDB DBMS implements quiescent checkpointing at the end of recovery and before the server is ready to accept incoming requests. Figure 14-9 (p.388), tells you what needs to happen during a quiescent checkpoint:

Stop accepting new transactions
Wait for existing transactions to finish
Flush all modified buffers
Append a quiescent checkpoint record to the log and flush it
Start accepting new transactions

Your goal in this assignment is to implement quiescent checkpointing after every 10 transactions (way too few in general, but a nice number for our purposes). You must follow the algorithm outlined in 14-9. To implement this algorithm, exercise 14.46 provides some details. A little more detail is provided here.

For a quiescent checkpoint to occur, the database system must not allow any more transactions to start. This can be accomplished if the Transaction constructor checks to see if a checkpoint is in progress. If a checkpoint is in progress, the thread executing the transaction must wait on a wait list for some object.

Java has the ability to Wait and Notify. See the BufferMgr class to see how wait and notify work. You will need to implement a similar functionality for quiescent checkpointing.

A static variable should be created in the Transaction class to hold all currently active transactions (those transactions that have been created but have not yet committed or rolled back). This list of active transactions are the transactions that started before the checkpoint began and have not yet completed (i.e. committed or rolled back).

When a quiescent checkpoint operation begins, a CheckPoint thread should be created that checks to see if there are any active transactions. If there are, it should wait for a little bit (a second) and then check to see if any transactions are active again. Eventually, there will be no active transactions since no new ones should start while a checkpoint is in progress.

When no transactions are currently active, the checkpoint thread should follow the algorithm presented in figure 14-9. The class called RecoveryMgr has much of the code that is required by the checkpoint algorithm, but you will likely have to copy and modify the code to do what you want. Take a look at the recover method in the RecoveryMgr class. The recover method requires a transaction number, which you will not have. With a little work, that code can be modified so that it will create a checkpoint record without needing a current transaction.