Reference no: EM13336584

Design considerations and calculation

Question 1

Consider a database with objects X and Y and assume that there are two transactions T1 and T 2. Transaction T 1 reads objects X and Y and then writes object X. Transaction T 2 reads objects X and Y and then writes objects X and Y.

1. Give an example schedule with actions of transactions T1 and T 2 on objects X and Y that results in a write-read conflict.

2. Give an example schedule with actions of transactions T1 and T 2 on objects X and Y that results in a read-write conflict.

3. Give an example schedule with actions of transactions T1 and T 2 on objects X and Y that results in a write-write conflict.

4. For each of the three schedules, show that Strict 2PL disallows the schedule.

Question 2

Answer the following questions: SQL supports four isolation-levels and two access-modes, for a total of eight combinations of isolation-level and access-mode. Each combination implicitly defines a class of transactions; the following questions refer to these eight classes:

1. Consider the four SQL isolation levels. Describe which of the phenomena can occur at each of these isolation levels: dirty read, unrepeatable read, and phantom problem.

2. For each of the four isolation levels, give examples of transactions that could be run safely at that level.

3. Why does the access mode of a transaction matter?

Question 3

Consider the following classes of schedules: serializable, conflict-serializable, viewserializable, recoverable, avoids-cascading-aborts, and strict. For each of the following schedules, state to which of the preceding classes it belongs. If you cannot decide whether a schedule belongs in a certain class based on the listed actions, explain briefly.The actions are listed in the order they are scheduled and prefixed with the transaction name. If a commit or abort is not shown, the schedule is incomplete; assume that abort or commit must follow all the listed actions.

1. T1:R(X), T2:R(X), T1:W(X), T2:W(X)

2. T1:W(X), T2:R(Y), T1:R(Y), T2:R(X)

3. T1:R(X), T2:R(Y), T3:W(X), T2:R(X), T1:R(Y)

4. T1:R(X), T1:R(Y), T1:W(X), T2:R(Y), T3:W(Y), T1:W(X), T2:R(Y)

5. T1:R(X), T2:W(X), T1:W(X), T2:Abort, T1:Commit

6. T1:R(X), T2:W(X), T1:W(X), T2:Commit, T1:Commit

7. T1:W(X), T2:R(X), T1:W(X), T2:Abort, T1:Commit

8. T1:W(X), T2:R(X), T1:W(X), T2:Commit, T1:Commit

9. T1:W(X), T2:R(X), T1:W(X), T2:Commit, T1:Abort

10. T2: R(X), T3:W(X), T3:Commit, T1:W(Y), T1:Commit, T2:R(Y), T2:W(Z), T2:Commit

11. T1:R(X), T2:W(X), T2:Commit, T1:W(X), T1:Commit, T3:R(X), T3:Commit

12. T1:R(X), T2:W(X), T1:W(X), T3:R(X), T1:Commit, T2:Commit, T3:Commit

Question 4

Consider the execution shown in the following figure. In addition, the system crashes during recovery after writing two log records to stable storage and again after writing another two log records.

LSN LOG

00 begin_checkpoint

10 end_checkpoint

20 update: T1 writes P1

30 update: T2 writes P2

40 update: T3 writes P3

50 T2 commit

60 update: T3 writes P2

70 T2 end

80 update: T1 writes P5

90 T3 abort

X CRASH, RESTART

1. What is the value of the LSN stored in the master log record?

2. What is done during Analysis?

3. What is done during Redo?

4. What is done during Undo?

5. Show the log when recovery is complete, including all non-null prevLSN and undonextLSN values in log records.