Concurrency (cont.) Schedule

In multiprogramming environment, Several transaction run concurrently Database consistency can be destroy Schedules to ensure consistency DBMS has concurrency-control schemes

Schedule is order of execution of operation from various transactions. (execution sequence) Schedule of set of transaction consist of all operations in all transactions. Schedule S of n transactions T 1, T 2,…, T n is An ordering of the operations of the transactions And for each transaction T i, the order of operations of T i in S must appear in the same order in with they occur in T i Schedule of transaction?

Serial Schedule Each serial schedule consists of a sequence of instructions from various transactions, where the instructions belonging to one single transaction appear together in that schedule. (Schedule S and S’ are called serial if the operations of each transaction are executed consecutively)

Example Transfer money from account A to B Read_item(A) A := A – 50 Write_item(A) Read_item(B) B := B + 50 Write_item(B) Transfer 10% of A to Account B Read_item(A) temp := 0.1*A A:= A-temp Write_item(A) Read_item(B) B := B + temp Write_item(B)

Serial Schedule (T1 and then T2) Read_item(A) A := A – 50 Write_item(A) Read_item(B) B := B + 50 Write_item(B) Read_item(A) temp := 0.1*A A:= A-temp Write_item(A) Read_item(B) B := B + temp Write_item(B) T1 T2 Schedule 1 – a serial schedule in which T1 is followed by T2 A=1000 A= =950 A=950 A=1000, B = 2000 B= =2050 B=2050 A=950 A=95 A=950-95=855 A=855 B=2050 B= =2145 B=2145 A=855, B = 2145 A+B = = 3000 A+B = = 3000

EX. Serial Schedule (T1 and then T2) Read_item(A) temp := 0.1*A A:= A-temp Write_item(A) Read_item(B) B := B + temp Write_item(B) Read_item(A) A := A – 50 Write_item(A) Read_item(B) B := B + 50 Write_item(B) T1 T2 Schedule 2 – a serial schedule in which T2 is followed by T1 A=900 A=900-50=850 A=850 B= =2150 A=1000 Temp=100 A= =900 A=900 B= =2100 B=2000 B=2100 B=2150 A=1000, B = 2000 A+B = = 3000 A=850, B = 2150 A+B = = 3000

Concurrent schedule Database system execute several transactions concurrently, the schedule no longer needs to be serial. OS may execute one transaction and then currently may execute the 2 nd transaction, and then switch back to the 1 st one, and so on. Several execution sequences, the various instructions may be interleaved

Example (one possible schedule) Read_item(A) A := A – 50 Read_item(A) temp := 0.1*A A:= A-temp Write_item(A) Read_item(B) Write_item(A) Read_item(B) B := B + 50 Write_item(B) B := B + temp Write_item(B) T1 T2 Schedule 4 – Concurrent schedule A=1000 A= = 950 A=950 Temp=95 A = = 855 A = 855 B=2000 B= = 2050 B =2050 B =2000 B = =2095 B =2095 Result A+B = = 3000 Result A+B = = 2950 inconsistency A=1000, B=2000

Example (one possible schedule) Read_item(A) A := A – 50 Write_item(A) Read_item(A) temp := 0.1*A A:= A-temp Write_item(A) Read_item(B) B := B + 50 Write_item(B) Read_item(B) B := B + temp Write_item(B) T1 T2 Schedule 3 – Concurrent equivalent to schedule 1 A=1000 A= = 950 A=950 Temp=95 A = = 855 A = 855 B=2000 B= = 2050 B =2050 B = =2145 B =2145 Result A+B = = 3000 Result A+B = = 3000 A=1000, B=2000

Concurrent control component of DB system carried out the job to ensure that any schedule that get executed will leave database in a consistent state. We ensure consistency of DB under concurrent execution by making sure that any schedule that executed has the same effect as a schedule that could have occurred without any concurrent execution (SERIALIZABILITY).

Serializability? When several transactions execute concurrently in the database, The consistency of data may no longer be preserved. It is therefore necessary for the system to control the interacting among the concurrent transactions,

Since a transaction is a unit that preserved, a serial execution of transactions guarantees that consistency is preserved. A schedule captures the key actions of transactions that affect concurrent execution, such as read and write operations, while abstracting away internal details of the executions of the transaction. We require that any schedule produced by concurrent processing of a set of transactions will have an effect equivalent to a schedule produced when these transitions are run serially in some order. A system that guarantees this property is said to ensure serializability. There are several different notions of equivalence leading to the concepts of conflict serialzability and view serializability.

Example ( Serializability ) Read_item(A) A := A – 50 Write_item(A) Read_item(A) temp := 0.1*A A:= A-temp Write_item(A) Read_item(B) B := B + 50 Write_item(B) Read_item(B) B := B + temp Write_item(B) T1 T2 Schedule 3 – Concurrent equivalent to schedule 1 A=1000 A= = 950 A=950 Temp=95 A = = 855 A = 855 B=2000 B= = 2050 B =2050 B = =2145 B =2145 Result A+B = = 3000 Result A+B = = 3000 A=1000, B=2000

Conflict serializability 2 transactions, effected operations Write and Read operations Combination of write read operations show as followed Read(Q), Read(Q) no conflict Read(Q), Write(Q) Write(Q), Read(Q) Write(Q), Write(Q)

I i,J j are operations of transaction T i and T j, respectively. Both I i and J j are read instruction, the relative order of operation is not matter. I i, J j conflict if they are operations by different transactions on the same data and, at least 1 operation is write operation Example see schedule 3

Example ( Serializability ) Read_item(A) A := A – 50 Write_item(A) Read_item(A) temp := 0.1*A A:= A-temp Write_item(A) Read_item(B) B := B + 50 Write_item(B) Read_item(B) B := B + temp Write_item(B) T1 T2 Schedule 3 – Concurrent equivalent to schedule 1 A=1000, B=2000 conflictNot conflict Can swap

Read_item(A) Write_item(A) Read_item(A) Write_item(A) Read_item(B) Write_item(B) Read_item(B) Write_item(B) T1 T2 Read_item(A) Write_item(A) Read_item(A) Read_item(B) Write_item(A) Write_item(B) Read_item(B) Write_item(B) T1 T2 Read_item(A) Write_item(A) Read_item(B) Write_item(B) Read_item(A) Write_item(A) Read_item(B) Write_item(B) T1 T2 Schedule 3 is conflict equivalent to schedule 1 If Schedule S can be transformed into a schedule S’ by a series of swaps of no conflicting instructions, say that S and S’ conflict equivalent

The schedule S is conflict serializable if it is conflict equivalent to a serial schedule. Schedule 3 is conflict serializable, since it is conflict equivalent to the serial schedule 1

Read_item(Q) Write_item(Q) T3 T4 Schedule 7 Is this schedule “conflict serializable”? Why? Answer No, because it is not equivalent to either the serial schedule or

View Serializability The schedule S and S’ are said to be view equivalent if 3 condition are met. For each data item Q, it transaction T i reads the initial value of Q in S, the transaction T i,in S’, must also read the initial value of Q. For each data item Q, if transaction T i executes read(Q) in S, and if the value produced by Write(Q) operation executed by transaction T j, then the read(Q) operation of transaction T i must, in schedule S’, also read the value Q that was produced by the same write(Q) operation of T j For each data item Q, the transaction (if any) that performs the final write(Q) operation in schedule S must perform the final write(Q) operation in schedule S’.

Condition 1 and 2 ensure that each transaction reads the same values in both S and S’ and, therefore, performs the same computation. Condition 3, coupled with 1 and 2, ensures that both schedules result in the same final system state. Schedule 1 is view equivalent to schedule 3, because the values of account A and B read by transaction T2 were produced by T1 in both schedules. A schedule S is view serializable if it is view equivalent to a serial schedule. Every conflict serializable is also view serializable, but there are view serializable schedules that are not conflict serializable.

Testing for conflict serializability using preceding graph The graph consist of a pair G = (V,E) Where V is a set of vertices and E is a set of edges. The set of vertices consists of all transactions participating in the schedule. The set of edges consists of all edges T i →T j for which one of 3 conditions hold. T i executes write(Q) before T j executes read(Q) T i executes read(Q) before T j executes write(Q) T i executes write(Q) before T j executes write(Q)

If T i →T j exists in precedence graph, then, in any serial schedule S’ equivalent to S, T i must appear before T j Example the precedence graph for schedule 1 and 2 Precedence graph for schedule 4, it contains the edge T 1 →T 2 because T1 executes read(A) before T2 executes write(A). It also contains the edge T 2 →T 1 because T2 executes read(B) before T1 executes write(B) T1T2 Schedule 1 T2T1 Schedule 2 T2T1 Schedule 4 (not serializable)

We can test a given schedule for conflict serializability by constructing a precedence graph for the schedule. However, there are more efficient concurrency control schemes for serializability. The approach taken in commercial DBMS design is to design “protocol (set of a rules)” that – if followed by every individual transaction or if enforced by a DBMS concurrency control subsystem – will ensure serailizability of all schedules in which the transaction participate.

Transaction Definition in SQL Commit Rollback