Concurrency (cont.)Concurrency (cont.)ScheduleSchedule

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 T1, T2,…, Tn is An ordering of the operations of the transactions And for each transaction Ti, the order of operations of

Ti in S must appear in the same order in with they occur in Ti

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*AA:= A-tempWrite_item(A)Read_item(B)B := B + tempWrite_item(B)

T1 T2Schedule 1 – a serial schedule in which T1 is followed by T2

A=1000A=1000-50=950

A=950

A=1000 , B = 2000

B=2000+50=2050

B=2050A=950

A=95A=950-95=855

A=855B=2050

B=2050+95=2145

B=2145

A=855 , B = 2145

A+B =855 + 2145 = 3000

A+B =1000+2000 = 3000

EX. Serial Schedule (T1 and then T2)

Read_item(A)temp := 0.1*AA:= A-tempWrite_item(A)Read_item(B)B := B + tempWrite_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=900A=900-50=850

A=850

B=2100+50=2150

A=1000Temp=100A=1000-100=900

A=900

B=2000+100=2100B=2000

B=2100

B=2100

B=2150

A=1000 , B = 2000A+B =1000+2000 = 3000

A=850 , B = 2150

A+B =850 + 2150 = 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 2nd transaction, and then switch back to the 1st 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*AA:= A-tempWrite_item(A)

Read_item(B) Write_item(A) Read_item(B) B := B + 50 Write_item(B)

B := B + tempWrite_item(B)

T1 T2Schedule 4 – Concurrent schedule

A=1000

A=1000-50 = 950

A=950

A=950Temp=95

A =950-95 = 855 A = 855

B=2000B=2000+50 =

2050B =2050

B =2000

B =2000+95=2095B

=2095

Result A+B = 1000 + 2000 = 3000

Result A+B = 855 + 2095 = 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*AA:= A-tempWrite_item(A)

Read_item(B) B := B + 50 Write_item(B)

Read_item(B)B := B + tempWrite_item(B)

T1 T2Schedule 3 – Concurrent equivalent to schedule 1

A=1000

A=1000-50 = 950A=950 A=950

Temp=95A =950-95 = 855 A = 855 B=200

0B=2000+50 = 2050B =2050 B

=2050B =2050+95=2145B

=2145

Result A+B = 1000 + 2000 = 3000

Result A+B = 855 + 2145 = 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*AA:= A-tempWrite_item(A)

Read_item(B) B := B + 50 Write_item(B)

Read_item(B)B := B + tempWrite_item(B)

T1 T2Schedule 3 – Concurrent equivalent to schedule 1

A=1000

A=1000-50 = 950A=950 A=950

Temp=95A =950-95 = 855 A = 855 B=200

0B=2000+50 = 2050B =2050 B

=2050B =2050+95=2145B

=2145

Result A+B = 1000 + 2000 = 3000

Result A+B = 855 + 2145 = 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)

Ii,Jj are operations of transaction Ti and Tj, respectively.

Both Ii and Jj are read instruction, the relative order of operation is not matter.

Ii, Jj 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*AA:= A-tempWrite_item(A)

Read_item(B) B := B + 50 Write_item(B)

Read_item(B)B := B + tempWrite_item(B)

T1 T2Schedule 3 – Concurrent equivalent to schedule 1

A=1000, B=2000conflict

Not conflictCan 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)Write_item(Q)

T3 T4

Schedule 7

Is this schedule “conflict serializable”?Why?

AnswerNo, because it is not equivalent to either the serial schedule <T3,T4> or <T4,T3>

View SerializabilityThe schedule S and S’ are said to be view equivalent if 3

condition are met. For each data item Q, it transaction Ti reads the initial

value of Q in S, the transaction Ti ,in S’, must also read the initial value of Q.

For each data item Q, if transaction Ti executes read(Q) in S, and if the value produced by Write(Q) operation executed by transaction Tj , then the read(Q) operation of transaction Ti must, in schedule S’, also read the value Q that was produced by the same write(Q) operation of Tj

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

Ti→Tj for which one of 3 conditions hold. Ti executes write(Q) before Tj executes read(Q) Ti executes read(Q) before Tj executes write(Q) Ti executes write(Q) before Tj executes write(Q)

If Ti→Tj exists in precedence graph, then, in any serial schedule S’ equivalent to S, Ti must appear before Tj

Example the precedence graph for schedule 1 and 2

Precedence graph for schedule 4, it contains the edge T1→T2 because T1 executes read(A)

before T2 executes write(A). It also contains the edge T2→T1 because T2 executes read(B)

before T1 executes write(B)

T1 T2

Schedule 1

T2 T1

Schedule 2

T2 T1

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