@@ -44,14 +44,19 @@ relations and tuples). **The code here and elsewhere implicitly assumes that the
-`class TransactionState`: This class encapsulates some of the basic functionality of transactions, including some helper functions to create log records, keeping track of
what locks the transaction currently holds, etc.
#### `testing.py`
#### Development
This contains some code for testing. You should be able to run: `python3 testing.py` to get started. Note that the first time you run it, it will create the
two files `relation1` and `logfile`, but after you kill it, the logfile will be inconsistent (we never write out CHECKPOINT
records in normal course). So the second time you run it, it will error out since the restartRecovery code is not implemented. So if you want to work on the other
two tasks, you should remove those two files every time.
There are two testing files, `testingLocks.py` and `testingRecovery.py` ("testingX" means both), one for working
w/ locks and one for recover.
Currently the only way to stop a runaway `testing.py` is through killing it through Ctrl-C. If that doesn't work, try stopping it (Ctrl-Z), and then killing it using `kill %1`.
Both contain code for testing. Running `python3 testingLocks.py` should get you
started. Note that the first time you run it, it will create the two files `relation1` and
`logfile`, but after you kill it, the logfile will be inconsistent (we never write out
CHECKPOINT records in normal course). So the second time you run it, it will error out
since the restartRecovery code is not implemented. So if you want to work on the other two
tasks, you should remove those two files every time.
Currently the only way to stop a runaway `testingX` is through killing it through Ctrl-C. If that doesn't work, try stopping it (Ctrl-Z), and then killing it using `kill %1`.
### Your Task
...
...
@@ -72,9 +77,8 @@ order.
the database.
### Testing
Our testing will check both the contents of the database (the final versions of
the relation file) and the `logfile`.
**Locks**
For locking, you should verify that your IX locks are working as intended. For example, you should ensure that:
- distinct tuples can be simultaneously locked exclusively by different transactions
- a tuple locked exclusively prevents a shared lock on the entire table.
...
...
@@ -98,6 +102,14 @@ You can use `testingLocks.py` as the basis for your testing. The provided versio
Note that you should modify this test (change the transaction, or create a new one) such that it tests tuple locks as discussed above. This test works fine w/ tuple locks defaulting to table locks, but our tests will not.
We will test locks by running transactions that delay through `sleep`s. We will use timing
effects to ensure that your locks are conflicting when necessary, and not when not.
**Recovery**
Our testing will check both the contents of the database (the final versions of
the relation file) and the `logfile`.
For recovery there are two artifacts: the logfile and the state of the database. We will test both. We have provided three test logfiles, together w/ correct answers. We have not provided the correct databases but you should be able to determine correctness just be looking in the relation file. To test the lock files, do the following, for example:
