Serial and Serializable Schedules (Section 18.1) Sean Gilpin ID: 109

Overview Topics Covered: Schedules Serial Schedules Serializable Schedules Effect of Transaction Semantics Notation for Transactions and Schedules

Introduction In this section we are concerned with how transactions can be executed so as to preserve the consistency of the database. The example of consistency used in this section is A=B. As long as A=B is always true after we finish running the transactions then the consistency is preserved.

Schedules A schedule is a time-ordered sequence of actions taken by one or more transactions. READ and WRITE actions, and their orders are important when considering concurrency.

Serial Schedule A schedule is serial if the transactions are executed as a whole one after the other. For example if T2 is scheduled to run after T1 is completely finished then the schedule is serial. If T2 is scheduled to run when T1 is only halfway finished then the schedule is not serial. A serial schedule will preserve the consistency of the database state.

Example of Serial Schedule T1T2AB 25 READ(A,t) t := t+100 WRITE(A,t)125 READ(B,t) t := t+100 WRITE(B,t)125 READ(A,s) s:= s*2 WRITE(A,s)250 READ(B,s) s := s*2 WRITE(B,s)250

Example Explored Notice that before the transactions are run that A=B=25 After the transactions run A=B=250, so consistency was preserved.

Serializable Schedule A schedule is serializable if its effect on the database state is the same as that of some serial schedule. Must consider all initial states of the database.

Example of Serializable Schedule T1T2AB 25 READ(A,t) t := t+100 WRITE(A,t)125 READ(A,s) s:= s*2 WRITE(A,s)250 READ(B,t) t := t+100 WRITE(B,t)125 READ(B,s) s := s*2 WRITE(B,s)250

Example Explored This schedule has the same outcome as the serial schedule we explored earlier, so it is serializable. It is important to see that the consistency is conserved for all initial database values not just for A=B=25 You can deduce that if the initial state is A=B=c then this schedule will have the outcome A=B=2(c+100).

Effect of Transaction Semantics So far we have considered in detail the operations performed by the transactions. It is not realistic for the scheduler to concern itself with the details of transactions. To simplify the job of the scheduler, we will assume that no arithmetic coincidences will occur that would allow a schedule to be serializable.

Explanation of Assumption T1T2AB 25 READ(A,t) t := t+100 WRITE(A,t)125 READ(A,s) s:= s*2 WRITE(A,s)250 READ(B,s) s := s*2 WRITE(B,s)50 READ(B,t) t := t+100 WRITE(B,t)150

Explanation of Assumption Notice in previous example that the consistency is not preserved. A=250 and B=150 at the end of the schedule.

Explanation of Assumption T1T2AB 25 READ(A,t) t := t+100 WRITE(A,t)125 READ(A,s) s:= s*1 WRITE(A,s)125 READ(B,s) s := s*1 WRITE(B,s)25 READ(B,t) t := t+100 WRITE(B,t)125

Explanation of Assumption This schedule is the same except we multiply by 1 instead of 2. This schedule leads to a consistent state unlike previous example. The point of the original assumption is that the database will not have time to explore such mathematical coincidences and it would not schedule the transaction in this way.

Notation for Transactions and Schedules Only the read and writes performed by the transaction matter. r T (X) and w T (X) will be shorthand for transaction T reads and writes element X. The transactions used in examples can be rewritten as: T 1 : r 1 (A); w 1 (A); r 1 (B); w 1 (B); T 2 : r 2 (A); w 2 (A); r 2 (B); w 2 (B); The details of what T1 and T2 are doing (adding versus multiplying) do not matter since we will assume the worse.