-------------------------------------------------------------------------------- LAB 7 | Timestamp-based and validation-based protocols. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- PRACTICE EXERCISES -------------------------------------------------------------------------------- (1) Get familiar with the terms: - transaction timestamp, - timestamp-ordering protocol, - validation protocol and its three phases, by attending the lecture and reading chapters 15.4, 15.5 from the textbook. (2) The operations of transactions T1, T2, arrive at the scheduler in the order shown on the following schedule. Simulate a timestamp-ordering scheduler and insert ROLLBACK commands when required. T1: T2: read(Y) read(X) read(X) read(Y) write(Y) (3) Consider a timestamp-ordering scheduler and transactions T1, T2, TS(T1)=3, TS(T2)=4. Furthermore, assume that the data items X and Y have last been read and written by a transaction with timestamp 1. Describe each step taken by the timestamp-ordering scheduler. T1: T2: read(X) read(Y) read(Y) read(X) write(Y) write(X) (4) The operations of transactions T1, T2, T3 arrive at the scheduler in the order shown on the following schedule. Simulate a timestamp-ordering scheduler and insert ROLLBACK commands when required. T1: T2: T3: read(Z) read(Y) write(Y) read(Y) read(Z) read(X) write(X) write(Y) write(Z) read(X) read(Y) write(Y) write(X) (5) The operations of transactions T1, T2, T3 arrive at the scheduler in the order shown on the following schedule. Simulate a timestamp-ordering scheduler and insert aborts when required. T1: T2: T3: read(X) read(Y) read(X) read(X) write(X) write(Y) write(X) read(Y) (6) Consider the following schedules. Indicate what happens when each schedule is processed by a validation-based scheduler (timestamps correspond to the order of operations in the schedules). Schedule 1 --------------------------------- T1: T2: T3: read(A,B) read(B,C) validate read(C,D) validate write(A) write(B) validate write(A) Schedule 2 --------------------------------- T1: T2: T3: read(A,B) read(B,C) validate read(C,D) write(A) validate write(D) validate write(A) (7) Consider the following schedules. Indicate what happens when each schedule is processed by a validation-based scheduler (timestamps correspond to the order of operations in the schedules). Schedule 1 -------------------------------- T1: T2: T3: read(A,B) read(B,C) read(C) validate validate validate write(A) write(B) write(C) Schedule 2 -------------------------------- T1: T2: T3: read(A,B) read(B,C) read(B) validate validate write(C) validate write(B) write(C) (8) CHECKLIST: - I can describe the timpestamp-ordering protocol and apply it to an example schedule. - I can list the properties of the timestamp-ordering protocol. - I can list and explain the phases of the validation protocol. - I can perform the validation test for an example set of transactions. - I can list the properties of the validation protocol. - I can differentiate locking, timestamp ordering, and validation protocols. I can identify their strengths and weaknesses. -------------------------------------------------------------------------------- HOMEWORK -------------------------------------------------------------------------------- DEADLINE: 22.12.2016, 21:59 In this exercise we will fix eating cookies from our cookie jar. We've already seen in the outputs of our experiments that not all the cookies are eaten correctly. Although we execute the 'monster_eat_cookie' function as many times as there are cookies in the jar, some cookies are not eaten at all and some are eaten multiple times. Consider the script 'cookie_jar_h7.py'. Your task is to fix eating the cookies such that at the end all cookies are eaten and every cookie is eaten exactly once. HINT: If an error occurs during eating, the transaction rolls back. Implement a mechanism that retries the transaction as long as it doesn't succeed. You may use the return value of the method 'monster_eat_cookie' to verify if the transaction succeeded. Implement a counter that, counts the number of times 'monster_eat_cookie' had to be retried. Modify the function 'summarize_eating' to output the number of retries with the key 'total_retries'. IMPORTANT: If you decide to modify the function 'monster_eat_cookie', do not modify its logics, especially the queries and the eating modes. Though, you may add your custom elements. We would like to observe the number of retries under different settings. For the evaluation, I will execute your script with varying parameters. However, I'll focus on READ COMMITTED and SERIALIZABLE isolation levels. We'll discuss the results of your script during the labs.