@@ -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
