Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
A
assignments424fall23
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package Registry
Container Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Peter Keleher
assignments424fall23
Commits
8dccfbb3
Commit
8dccfbb3
authored
1 year ago
by
Peter J. Keleher
Browse files
Options
Downloads
Patches
Plain Diff
auto
parent
66805c02
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
assign8.md
+87
-0
87 additions, 0 deletions
assign8.md
with
87 additions
and
0 deletions
assign8.md
0 → 100644
+
87
−
0
View file @
8dccfbb3
## Assignment 8: Rollback Recovery
### Due Dec 1, 2023, 11:59PM
You will be implementing rollback recovery in
`transactions.py`
. More
specifically, you will be implementing the
`restartRecovery()`
with functionality as described in Section 19.4, most specifically 19.4.2. You will be recovering as if from a
crash. Implement both the
**redo**
and
**undo phases**
, including
re-execution,
*compensating log records*
, etc.
Be sure to write back all modified values.
### Setup
Download files for Assignment 9
<a
href=
"https://sedna.cs.umd.edu/424/assign/assignment9Dist.tgz?1"
>
here
</a>
.
*We do not provide a new Vagrant file as you can use your existing VM's with this project, or just natively on Macs.*
## Log records
We use the following log records types:
-
`[1, "START"]`
: starts transaction 1.
-
`[5, "COMMIT"]`
: commit transaction 5.
-
`[4, "ABORT"]`
: Abort transaction 4.
-
`[5, "UPDATE", "R", "2", "A", "10", "7"]`
: Updates attr "A" from
original value "10" to new value "7" for
record with primary_id "2", of relation R.
-
`[4, "CLR", "R", "11", "A", "10"]`
:
*Compensation log record*
written during undo
when changing attribute "A", id "11" back to "10".
-
`[-1, "CHECKPOINT", []]`
: Written at end of restart recovery to
document that all prior changes have been committed to
disk. Checkpoint records written during failure-free operation include
a list of active transactions. During recovery there will be no active
transactions.
For fun, and possibly debugging, the following is the format of the
"relation" files. The file is a sequence of 1200-character
blocks. The first block contains a list consisting of:
-
the schema, such as ["ID", "A"]. All columns are of type string.
-
number of data blocks
-
data blocks, each of which is a 1200-character string containing a
nest list of tuples. With the schema above, each tuple contains a
value for "ID" and another for "A".
## In More Detail
Your task is implement
`restartRecovery()`
in
`transactions.py`
. This function is
called if the log file indicates an inconsistency (specifically 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. You
will:
-
implement the
*redo*
phase of Section 16.4 by rolling forward from the
last checkpoint or the beginning of the log:
-
keep track of active transactions, taking into account any information
from the checkpoint
-
redo any UPDATE and CLR records encountered
-
implement the
*undo*
phase of Section 16.4 by rolling back from the end
of the log:
-
reverse the effects of any encountered UPDATE records by changing the data
in the relation back to the original, and append CLR records
-
add abort records when encountering the START record for any active transaction
-
push all changes to the relation file (using
`BufferPool.writeAllToDisk`
).
-
write a checkpoint record to the log at the end.
Note that order in the log is important, we expect the log and relation files
to match the answers exactly.
#### Testing
You may use
`testingRecoveryNo.py <num>`
to test your code. This script:
-
copies
`recoveryTest<num>_logfile`
and
`recoveryTest<num>_relation`
from
`recoveryTests-original`
to the
current directory
-
reads them in and calls
`restartRecovery()`
-
writes the logfile to "logfile"
-
writes the possibly modified relation back to the same file.
For example,
`python3 testingRecoveryNo.py 1`
writes back
`logfile`
and
`recoverytest1_relation`
to the
current directory. The original copies of both were copied from
`./recoveryTests-original`
. You can find correct output files for some of the
tests in
`./recoveryTests-answers`
.
You may,
**and should**
, create your own testfiles. Either modify the test
script or populate
`./recoveryTests-original`
with tests 17, 18, etc.
`vis.pl`
may help debugging relation files.
### Submission
Submit modified
`transactions.py`
file to
<a
href=
"https://www.gradescope.com/courses/535193/assignments/2852215"
>
Gradescope
</a>
.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment