8(B) CONFLICT SERIALIZABILITY AND LOCKING

 Consider the following 2 schedules of *attempted* reads/writes by transactions. >>Schedule A << T1 T2 R(m) R(n) R(n) W(m) >>Schedule B << T1 T2 T3 R(m) R(y) W(z) W(m) W(n) abort (and release locks held) For schedules A and B do the following: 1/ Assuming that the reads/writes actually occur in the order given, indicate whether or not the schedule is (i) serial, (ii) serializable (in which case say which serial order it is equivalent to), (iii) non-serializable. 2/ Assume that you use a locking mechanism, and in each schedule every read R(b) is immediately preceded by an attempt to acquire an s-lock on b, and right before every write W(b) there is an attempt to acquire an x-lock on b. Annotate the schedule to indicate where each transaction asks for a lock, and then mark the places where a transaction is blocked and where deadlock occurs. (Use the notation illustrated in the lecture notes where blue Xlock and red Blocked words appear.) Do this in two ways: 2.i/ assume each transaction commits, (and thus releases its locks) immediately after the last R/W operation in it, if it reaches that point; (this is the normal case) 2.ii/ assume that the commits in each transaction occur at the end of the entire schedule (i.e., when all transaction actions are done reading and writing), and in the order T1.commits, T2.commits (, T3.commits). So schedule A would, under assumption ii/, look like T1 T2 Slock(m,T1);R(m) Slock(n,T1); R(n) Slock(n,T2);R(n) Xlock(m,T2);W(m) attempt commit attempt commit (Note: the schedules say "attempt commit" since one cannot be sure that the corresponding action is reached.) 3/ Which of the schedules in 2(i) and 2(ii) are "strict 2-phase locking"? [ASIDE ON NOTATION: Some books write schedules linearly by mixing the actions, and adding an argument (or subscript) to indicate which transaction executes it. e,g, >>Schedule A << with policy (i) would be R(1,m) R(1,n) try-commit(1) R(2,n) W(2,m) try-commit(2)