From dfa8666af8bc14409a263355c7926a5eb22e1d44 Mon Sep 17 00:00:00 2001 From: keleher <keleher@cs.umd.edu> Date: Tue, 3 Dec 2019 17:31:16 -0500 Subject: [PATCH] auto --- README.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index dd80f7b..1fe3913 100644 --- a/README.md +++ b/README.md @@ -60,14 +60,17 @@ Currently the only way to stop a runaway `testingX` is through killing it throug ### Your Tasks -Your task is to finish a few of the unfinished pieces in the two files (10 -points for each). Search for **TO BE IMPLEMENTED** in `transactions.py` +Your task is to finish a few of the unfinished pieces in `transactions.py` (search for +**TO BE IMPLEMENTED**). * [10 points] Implementing IX Locks in `transactions.py`: Currently the code supports S, X, and IS locks. So if a transaction needs to lock a tuple in the X mode, the entire relation is locked. This is of course not ideal and we would prefer to use IX locks (on the relation) to speed up concurrency. The code for this will largely mirror the code for IS. You will have to change the `getXLockTuple()` function and also the `compatibility_list` appropriately. -* [20 points] Function `restartRecovery()` in `transaction.py`: This function is called if the log file indicates an inconsistency (i.e., if the logfile does not end with an empty CHECKPOINT record). If that's the case, then you must analyze the logfile and do a recovery on that. +* [20 points] Function `restartRecovery()` in `transaction.py`: This function is called if + the log file indicates an inconsistency (i.e., if the logfile does not end with an empty + CHECKPOINT record). If that's the case, then you must analyze the logfile and do a + recovery on that (see 16.4.2 for details). For the recovery, you will need to write the code for both `revertChanges` and `restartRecovery`. `revertChanges` works by writing a compensating log record (CLR) for each update that a failed transaction does, in the correct -- GitLab