Uploaded by Will Reed

Concurrency Practice

advertisement
1. What happens after step 2 and why? (Continue to step 3 and 4 and then answer)
After step 2, the transaction in terminal 2 got stuck waiting because it
was requesting a write (X) lock for an object that already granted a write (X)
lock to the transaction in terminal 1. I didn’t realize this was the case until
after step 3 (I forgot auto-commit was turned off), so I forced the transaction
in terminal 2 to abort.
2. What happens after step 3 and 4 and why?
After step 3, the transaction in term1 is complete and term1 releases the X
lock. After step 4, the transaction in term2 is complete but did not actually do
anything since I mistakenly aborted the transaction in step 2. If I had not done this,
I assume term2 would be granted the X lock after it was released from term1 in
step 3, and I would receive an error that the transaction cannot be completed
because it is attempting to carry out the same write that was already done by term1
in step 1.
3. What happens after step 7 and step 8 and why?
After step 7, term1 is granted an S lock to read the values of the entire artist
table. After step 8, term2 is concurrently granted an S lock to read the values of the
entire artist table, so both terminals are allowed to read the same table at the same
time. This is because a transaction can be granted an S lock on an object that
another transaction has an S lock for before it is committed.
The caveat is: in step 7, term1 does not display the row for Artist 156,
because term2 has not committed writing to it, and therefore has not released its X
lock on Artist 156. For the same reason, in step 8, term2 does not display the row
for Artist 155 because term 1 has not finished writing to it, NOR does it display
Artist 156 since term2 itself has not finished writing to it.
4. What happens after step 12 and why?
After step 12, term2 is now able to display the row for Artist 155, because
term1 has released its X lock on it by committing in step 11. However, it still does
not display the row for Artist 156, because term2 still has an X lock on it.
5. Explain the results (wait to see) of steps 13 to 16 and why?
1. Step 13: term1 gets an X lock to write to Song 275.
2. Step 14: term2 gets an X lock to write to Artist 160.
3. Step 15: term1 requests an X lock to write to Artist 160.
4. Step 16: term2 requests an X lock to write to Song 275.
This creates a deadlock because both terminals have unfinished changes with
their respective objects for which they have X locks on, and both terminals are now
waiting on each other to commit. As a result, term1 automatically aborts the action
of step 15 as a result of deadlock detection.
At this point, the deadlock is resolved, but term2 is still waiting for term1 to
release its X lock on Song 275.
6. What happens after step 17 and why?
Since term1 rolls back the proposed changes and releases its X lock on Song
275, term2 is now able to leave the waiting queue, obtain the X lock, and write to
Song 275. However, the changes term2 has now made to Artist 160 and Song275
are not committed, so term2 still holds X locks on both of those objects.
7. What happens after step 21 and why?
18: term1 doesn’t display song 275
19: term1 doesn’t display artist 160
20: term2 does display song 275
21: term2 does display artist 160
Since term2 still holds X locks on Song 275 and Artist 160 for the duration
of steps 18-21, term1 is not granted an S lock for either object, and thus displays
the Artist and Song tables, excluding these two objects from each respective table.
After steps 20 and 21, term2 does display the tables with Song 275 and Artist 160,
since it is still holding an X lock on each of those objects.
8. What happens after step 26 and why?
After term2 commits and releases both of its X locks in step 22, neither
terminal is then holding X locks on any object. Term1 however, is still holding S
locks on the Song table, excluding Song 275, and on the Artist table, excluding
Artist 160.
After step 23 and 24, term1 requests, and is finally granted, an S lock for
Song 275 and Artist 160, since term2 released the X locks on both. Now, term1 is
able to display each of the entirely inclusive tables.
After steps 25 and 26, term2 also requests, and is also granted, S locks for
the Song and Artist tables, and displays them, since S locks are not exclusive.
Download