Assignment 2 Mod 3 - Solution
Assignment 2 Mod 3 - Solution
Assignment 2 Mod 3 - Solution
Session: 2016-2017
T2
T1
T4
T3
T5
The above graph does not contain any cycle. Therefore, this schedule is conflict
serializable. The equivalent serial schedule will be:
<T1,T3,T4,T2,T5>
3. Draw one example of the following Schedules:
a. Non Recoverable
T1
r(A)
w(A)
T2
r(A)
w(A)
commit
T1 fails
T2 read A after T1 writes, T2 commits and T1 fails. T2 has read a value which
was produced by T1, Therefore, T1 should commit before T2. Otherwise, the
schedule is non-recoverable.
b.
Recoverable
T1
r(A)
w(A)
T2
r(A)
w(A)
commit
commit
Here, T2 commits after T1 therefore it is recoverable.
c.
Cascadeless
T1
r(A)
w(A)
commit
T2
r(A)
w(A)
commit
T2 reads value written by T1 only after T1 commits. This is cascadeless schedule.
d. Recoverable but not Cascadeless
The answer given in part b is recoverable but not cascadeless because if T1 fails,
T2 also has to fail. Therefore, it is cascaded.
4. Consider the following two transactions:
T1
R1(X);
X:=X-N;
W1(X);
R1(Y);
Y:=Y-N;
W1(Y);
T2
R2(X);
X:=X+M;
If X > 90 then exit;
Else W2(X);
Consider the following two schedules, where X=80, Y=90, M = 2 and N = 2. What will be the
outcome of following schedules? What problems related to concurrency occur in the following
schedules? Describe.
a)
T1
T2
R1(X);
X:=X-N;
R2(X);
X:=X+M;
W1(X);
R1(Y);
If X > 90 then exit;
Else W2(X);
Y:=Y+N;
W1(Y);
Answer:
X = 82
Y = 92
Here, lost update problem occurs. Since update of T1 is lost. T2 performs w2(X) after
T1s w1(X).
b)
T1
R1(X);
X:=X-N;
W1(X);
T2
R2(X);
X:=X+M;
If X > 90 then exit;
Else W2(X);
R2(Y);
T1 fails.
Answer:
X = 80, Y = 90
Dirty Read Problem.
T2 reads value of X written by T1 and later T1 fails, T2 read a value which is temporary.
5. Consider the following four schedules due to three transactions (indicated by the subscript)
using read and write on a data item x, denoted by r(x) and w(x) respectively. Which one of them
is conflict serializable? (GATE 01_2014)
(A) r1(x); r2(x); w1(x); r3(x); w2(x)
T1
T2
T3
T2
T3
T2
T3
T2
T3
No cycles Exist, Hence, Conflict Serializable; Equivalent Serial Schedule: <T2, T3, T1>
6. Determine which of the following schedules are conflict serializable? For each serailizable
schedule, determine the equivalent serial schedule:
a. r1(x); r3(x); w1(x); r2(x); w3(x)
b. r1(x); r3(x); w3(x); w1(x); r2(x)
c. r3(x); r2(x); w3(x); r1(x); w1(x)
d. r3(x); r2(x); r1(x); w3(x); w1(x)
Solution: Same way, this question can be Solved.
7. Consider the three transactions T1, T2 and T3, and the schedules S1 and S2 given below.
Draw the serializability (precedence) graphs for S1 and S2, and state whether each schedule is
serializable or not. If a schedule is serializable, write down the equivalent serial schedule(s).
T1: r1(x); r1(z); w1(x)
T2: r2(z); r2(y); w2(z); w2(y)
T3: r3(x); r3(y); w3(y)
S1: r1(x); r2(z); r1(z); r3(x); r3(y); w1(x); w3(y); r2(y); w2(z); w2(y)
S2: r1(x); r2(z); r3(x); r1(z); r2(y); r3(y); w1(x); w2(z); w3(y); w2(y)
Solution:
Draw a serializability graph for S1 and S2 as we have already presented in solution for ques 5
and find out equivalent serial schedule if the schedule is serializable.
8. Consider the schedules S3, S4 and S5 below. Determine whether each schedule is strict,
cascade less, recoverable, or non-recoverable. (Determine the strictest recoverability condition
that each schedule satisfies.)
S3: r1(x); r2(z); r1(z); r3(x); r3(y); w1(x); c1; w3(y); c3; r2(y); w2(z); w2(y); c2;
S4: r1(x); r2(z); r1(z); r3(x); r3(y); w1(x); w3(y); r2(y); w2(z); w2(y); c1; c2; c3;
S5: r1(x); r2(z); r3(x); r1(z); r2(y); r3(y); w1(x); c1; w2(z); w3(y); w2(y); c3; c2;
Solution:
Definition of Recoverable, Cascadeless and strict:
Recoverable: If Tj reads X after Ti writes X; commit of Ti must appear before commit of Tj.
Cascadeless: If Tj reads X after Ti writes X; commit of Ti must appear before read(X) of Tj.
Strict: If Tj reads X or writes X after Ti writes X; commit of Ti must appear before read(X) or
write(X) of Tj.
S3:
T1
r1(x)
T2
T3
r2(z)
r1(z)
r3(x)
r3(y)
w1(x)
c1
w3(y)
c3
r2(y)
w2(z)
w2(y)
c2
This schedule is:
1. Recoverable T2 reads y after T3 writes y and commit of T3 appears before commit of T2.
2. Cascadeless T2 reads y after T3 writes y and after T3 commits.
3. Strict - T2 reads y after T3 writes y and after T3 commits.
S4
T1
r1(x)
T2
T3
r2(z)
r3(x)
r1(z)
r3(y)
w1(x)
w3(y)
r2(y)
w2(z)
w2(y)
c1
c2
c3
This schedule is:
1. Not recoverable T2 reads y after T3 writes y. Commit of T3 appears after the commit of T2.
T3 may fail after the commit of T2 which is wrong.
2. Not cascadeless or cascaded - If T3 fails, T2 also has to fail. T2 does not read a committed
value of y.
3. Not strict T2 does not read a committed value of y.
S5:
T1
r1(x)
T2
T3
r2(z)
r3(x)
r1(z)
r2(y)
r3(y)
w1(x)
c1
w2(z)
w3(y)
w2(y)
c3
c2
This schedule is:
1. Recoverable: No write dependencies exist (No read occurs after write) Therefore,
Recoverable.
2. Cascadeless: No read occurs after write. Therefore, no cascaded failures and cascadeless.
3. Not Strict: w2(y) of T2 appears after w3(y) of T3. w2(y) of T2 must appear after commit of T3
in order to make it strict. Hence, this schedule is not strict.
9. Consider the following schedule S of transactions T1, T2, T3, T4:
(GATE 02_2014)
Determine whether S is conflict serializable, recoverable, cascadeless and strict? Give reasons in
support of your answer.
Answer:
T2
T1
T3
T4
[read(B); B = B + 1; write(B);]
T1: read(B);
if (B = 0) then
[read(A); A = A + 1; write(A);]
Let the consistency requirement be (A=0 or B = 0)
(A and B equals 0), with A = B = 0 the initial values
(a) Show that every serial execution involving these two transactions preserves the consistency
of the database.
(b) Show a concurrent execution of T0 and T1 which produces a nonserializable schedule.
(c) Is there a concurrent execution of T0 and T1 which produces a serializable schedule?
Soln : T0 and T1 in this order gives A=0, B=1 and T1 and T0 in this order gives A=1, B=0.
Therefore the consistency requirement is preserved.
(b) Show a concurrent execution of T0 and T1 which produces a nonserializable schedule.
Soln:
T1
T2
r(A)
r(B)
w(B)
r(B)
r(A)
w(A)
T2
Lock-S(B)
r(B)
Lock-X(A)
Wait; (deadlock)
Rollback;
Lock-S(B)
r(B)
Lock-X(A)
w(A)
unlock(B)
unlock(A)
Commit;
13. Consider the following transaction log from the start of the run of a database system that is
capable of running undo/redo logging with checkpoints:
1) <START T1>
2) <T1, A, 50, 25>
3) <T1, B, 250, 25>
4) <START T2>
5) <T1, A, 75, 50>
6) <T2, C, 55, 25>
7) <COMMIT T1>
8) <START T3>
9) <T3, E, 65, 25>
10) <T2, D, 35, 25>
11) <START CKPT (T2,T3)>
12) <T2, C, 45, 55>
13) <COMMIT T2>
14) <START T4>
15) <T4, F, 120, 25>
16) <COMMIT T3>
17) <END CKPT>
18) <T4, F, 150, 120>
19) <COMMIT T4>
Assume the log entries are in the format <Tid, Variable, New value, Old value> What is the value
of the data items A, B, C, D, E, and F on disk after recovery:
1. if the system crashes just before line 10 is written to disk?
Soln: undo(T3), undo(T2), redo(T1)
2. if the system crashes just before line 13 is written to disk?
Soln: undo(T2), undo(T3)
3. if the system crashes just before line 14 is written to disk?
Soln: undo(T3) and redo(T2)
4. if the system crashes just before line 19 is written to disk?
Soln: undo(T4), redo(T2), redo(T3)
5. if the system crashes just after line 19 is written to disk?
Soln: redo(T4)
14. Explain the purpose of checkpoint mechanism.
Soln: The purpose of checkpoints is to reduce unnecessary redo operations on the data items by
the transactions which have successfully committed before failure has occurred.
How often should checkpoints be performed? How does the frequency of checkpoints affect
System performance when no failure occurs.
The time it takes to recover from system crash.
The time it takes to recover from a disk crash.
Soln: Checkpointing is done with log-based recovery schemes to reduce the time required for
recovery after a crash. If there is no checkpointing, then the entire log must be searched after a
crash, and all transactions undone/redone from the log. If checkpointing had been performed,
then most of the log-records prior to the checkpoint can be ignored at the time of recovery.
Another reason to perform checkpoints is to clear log-records from stable storage as it gets full.
Since checkpoints cause some loss in performance while they are being taken, their frequency
should be reduced if fast recovery is not critical. If we need fast recovery checkpointing
frequency should be increased. If the amount of stable storage available is less, frequent
checkpointing is unavoidable. Checkpoints have no effect on recovery from a disk crash;
archival dumps are the equivalent of checkpoints for recovery from disk crashes.