We will be analyzing a schedule under several variations of timestamp-based concurrency control.
You may find it helpful to consult the following summary of the rules related to timestamps from the coursepack: timestamp review
In each exercise, we will be considering the following schedule:
s1; r1(Y); s2; w2(Y); w2(X); s3; r3(Z); r2(Z); w3(Y); r3(X); c2; c3; w1(Y); r1(X); c1
You should assume that:
Assume that the timestamps assigned to the transactions are:
Note that these timestamps are consistent with the fact that T1 starts first, followed by T2, followed by T3.
In giving your answers, you should fill in a table that begins as follows:
| request | response | state changes and/or explanation |
|---|---|---|
| r1(Y) | allowed | RTS(Y) = 100 |
The third column should include any changes to the state maintained for the data item. If a request is denied or ignored, that column should also include a brief explanation of why.
You do not need to restart a transaction that is rolled back, which means that you can skip any requests by a transaction that come after the point at which it is rolled back.
Here again is the schedule that we’re considering:
s1; r1(Y); s2; w2(Y); w2(X); s3; r3(Z); r2(Z); w3(Y); r3(X); c2; c3; w1(Y); r1(X); c1
If the DBMS uses regular timestamp-based concurrency control without commit bits, what would be the response of the system to each of the requested actions in the schedule?
Note: Because commits don’t have an effect when we’re not using
commit bits, you do not need to include the commit actions
(c1, c2, etc.) in your table.
When using timestamp-based concurrency control, the DBMS can optionally maintain commit bits. What is the purpose of doing so?
Consider again the following schedule:
s1; r1(Y); s2; w2(Y); w2(X); s3; r3(Z); r2(Z); w3(Y); r3(X); c2; c3; w1(Y); r1(X); c1
What would the system’s response be to each of the requested actions if it uses commit bits? Make sure to include the responses to the commit requests (c1, c2, c3), since they are relevant when a system uses commit bits.
In addition to our prior assumptions, you should assume that all of the commit bits are initially true.
If a transaction is made to wait, you should include the relevant request a second time when the transaction is allowed to try again.
When using timestamp-based concurrency control, the DBMS can optionally maintain multiple versions of each item. What is the purpose of doing so?
Consider again this schedule:
s1; r1(Y); s2; w2(Y); w2(X); s3; r3(Z); r2(Z); w3(Y); r3(X); c2; c3; w1(Y); r1(X); c1
If the DBMS uses timestamp-based concurrency control without commit bits but with multiple versions of data items, what would be the response of the system to each of the requested actions in the schedule?
You should make the same assumptions as before about the timestamps of the transactions and the initial timestamps of the data items, and you should assume that all of the commit bits are initially true.
Note: Because commits don’t have an effect when we’re not using
commit bits, you do not need to include the commit actions
(c1, c2, etc.) in your table.
Remember to create a new version of a data item whenever necessary.
Last updated on November 15, 2024.