concurrency (cont.) schedule. in multiprogramming environment, several transaction run concurrently...
DESCRIPTION
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?TRANSCRIPT
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