1
00:00:00,290 --> 00:00:00,670
Fine. Now,

2
00:00:00,660 --> 00:00:02,190
let's see the next problem

3
00:00:02,190 --> 00:00:06,270
due to concurrent execution, right, which is dirty read problem.

4
00:00:06,570 --> 00:00:06,820
Okay.

5
00:00:06,830 --> 00:00:10,370
Dirty-read problem. it is also known as write-read conflict.

6
00:00:10,410 --> 00:00:13,070
We have seen write-write conflict in the previous video.

7
00:00:13,110 --> 00:00:13,410
Right.

8
00:00:13,410 --> 00:00:15,290
This is write-read conflict.

9
00:00:15,720 --> 00:00:21,960
Reading an uncommitted data is called as dirty read, right, dirty read.

10
00:00:22,260 --> 00:00:24,640
So, we should always a avoid dirty reads.

11
00:00:24,890 --> 00:00:28,090
Ok, so let me explain this with the explain you with this example.

12
00:00:28,410 --> 00:00:31,850
So what is, what's happening here is T1 in transaction T1,

13
00:00:31,890 --> 00:00:36,840
we are going to read the value of A, let us assume the balance of account A is thousand dollars at this

14
00:00:36,840 --> 00:00:37,730
point of time.

15
00:00:37,770 --> 00:00:42,390
Right? Now what we're doing here. What transaction T1 is doing is, it is going to read this value

16
00:00:42,390 --> 00:00:44,430
of thousand in the register, right.

17
00:00:44,550 --> 00:00:45,920
It has read this value.

18
00:00:45,990 --> 00:00:52,030
Let us assume this register R1 and T1 is having this thousand fine and it is going to make this as

19
00:00:52,060 --> 00:00:53,660
900, fine.

20
00:00:54,030 --> 00:00:57,630
And it is going to write this value in the hard disk, right? Write

21
00:00:57,660 --> 00:00:58,770
this value in the hard disk.

22
00:00:58,770 --> 00:01:02,440
Because of which, it has become 900 fine.

23
00:01:02,460 --> 00:01:07,710
Now what's happening here is, transaction T2 is reading the value of A, right?

24
00:01:07,800 --> 00:01:09,790
It is going to read this value.

25
00:01:09,810 --> 00:01:10,200
Why?

26
00:01:10,230 --> 00:01:12,900
Because this is the value which is present in the hard disk.

27
00:01:12,900 --> 00:01:17,150
So from this I can say that this can also be said as transaction.

28
00:01:17,160 --> 00:01:27,810
B2 is reading the update of T1, right? T1 is writing something and that is being read by T2, right, that

29
00:01:27,810 --> 00:01:29,300
is being read by T2.

30
00:01:29,400 --> 00:01:31,320
So T1 has read this value,

31
00:01:31,320 --> 00:01:38,860
now T2 is going to read this value, fine. T2 has read this value and it has placed in the register, fine.

32
00:01:39,020 --> 00:01:44,730
Now one thing what can happen is see, we are having commit in T1 over here.

33
00:01:44,850 --> 00:01:52,830
Right, now what could happen here is let us assume T2 has read this value fine, now after some time this

34
00:01:52,830 --> 00:01:55,050
transaction fails.

35
00:01:55,290 --> 00:02:01,470
Let us assume at some point over here, this transaction fails, Now what will happen, if a transaction

36
00:02:01,470 --> 00:02:01,940
fails.

37
00:02:01,950 --> 00:02:04,620
What we will do? We will rollback, right?

38
00:02:04,800 --> 00:02:08,950
We will rollback which means we will start this transaction from the beginning.

39
00:02:09,100 --> 00:02:15,020
Right? We will start this transaction from the beginning. But, see if we start this transaction from the beginning,

40
00:02:15,030 --> 00:02:20,330
It is as same as, this transaction has not happened till this point, right?

41
00:02:20,490 --> 00:02:22,890
Which means we are going to start this transaction again.

42
00:02:23,460 --> 00:02:27,330
But what has happened because of this, this transaction has read

43
00:02:27,360 --> 00:02:29,540
the wrong value, right, wrong value.

44
00:02:29,610 --> 00:02:30,840
Why this is wrong value?

45
00:02:30,900 --> 00:02:36,780
Because T1 has not updated it. T1 is able to start this transaction again and after completing this transaction

46
00:02:36,780 --> 00:02:38,460
this value would become 900.

47
00:02:38,790 --> 00:02:43,700
But T2 has read this wrong value, right.

48
00:02:43,710 --> 00:02:50,010
Let us assume T2 has read this value and after some T1 got failed. Now, because of this failure we are going

49
00:02:50,010 --> 00:02:53,280
to rollback this transaction, but, T2 doesn't know that right?

50
00:02:53,280 --> 00:02:59,060
So what T2 will do, it has read the value of 900 and it will calculate the interest which is 4 percent.

51
00:02:59,100 --> 00:03:01,380
4 percent of 900 is nothing but 54.

52
00:03:01,620 --> 00:03:03,380
So this will be added with 9.

53
00:03:03,390 --> 00:03:11,220
This will be added, made as 954 fine? And 954 fine, and, let us assume that this value of 954 is

54
00:03:11,520 --> 00:03:13,260
being written over here. Right?

55
00:03:13,500 --> 00:03:17,910
It is being written over here. So because of this, what will happen, see this can be done in a lot of ways.

56
00:03:17,910 --> 00:03:18,120
Okay.

57
00:03:18,120 --> 00:03:21,120
It really depends on when this transaction fails.

58
00:03:21,200 --> 00:03:21,420
Okay.

59
00:03:21,430 --> 00:03:25,540
Let us assume that we are going to write this value of 954 over here.

60
00:03:25,590 --> 00:03:27,130
This operation is being performed.

61
00:03:27,350 --> 00:03:27,860
Okay.

62
00:03:27,960 --> 00:03:28,710
954.

63
00:03:28,720 --> 00:03:31,390
And let us assume at this point of time, transaction

64
00:03:31,460 --> 00:03:34,960
T1 fails. Okay, at this point of time, transaction T1 fails.

65
00:03:35,070 --> 00:03:40,740
So because of this what will happen and transaction T1 will start from the beginning and it will read

66
00:03:40,740 --> 00:03:42,320
this value of 954.

67
00:03:43,050 --> 00:03:45,020
Right? It will read this value of 954.

68
00:03:45,180 --> 00:03:47,620
So there is definitely some problem over here.

69
00:03:47,810 --> 00:03:48,420
Right?

70
00:03:48,520 --> 00:03:50,680
See this update is definitely wrong.

71
00:03:50,880 --> 00:03:51,210
Okay.

72
00:03:51,240 --> 00:03:55,800
This is going to be done one more time which means this 954 will be read by T1 and

73
00:03:55,800 --> 00:03:59,010
it will be made as 854. Right? 854.

74
00:03:59,190 --> 00:04:04,440
So after completing both the transactions, see we are done with both the transactions. This transaction is done,

75
00:04:04,770 --> 00:04:05,370
fine.

76
00:04:05,370 --> 00:04:06,860
This transaction is also done.

77
00:04:07,160 --> 00:04:07,820
Now

78
00:04:07,860 --> 00:04:08,100
now,

79
00:04:08,100 --> 00:04:14,250
once both the transactions are done we are getting 854 as the result, which is definitely wrong.

80
00:04:14,250 --> 00:04:14,970
Why?

81
00:04:15,030 --> 00:04:16,550
See what we are supposed to get?

82
00:04:16,560 --> 00:04:22,250
If we would have followed serial schedule then T1 should have made thousand as nine

83
00:04:22,380 --> 00:04:27,100
hundred fine and T2 should have made this 900 this nine,

84
00:04:27,110 --> 00:04:31,520
this nine T2 should have made this 900 as 954, right.

85
00:04:31,530 --> 00:04:36,480
This is the value which we are supposed to get after completing both the transactions but we have got

86
00:04:36,540 --> 00:04:39,260
854 which is definitely wrong.

87
00:04:39,270 --> 00:04:40,470
Why did this happen?

88
00:04:40,560 --> 00:04:42,960
Because we have done this transaction two times.

89
00:04:43,230 --> 00:04:49,120
So this is definitely an incorrect value, right? So this schedule is going to produce inconsistent result.

90
00:04:49,540 --> 00:04:49,880
Right?

91
00:04:50,070 --> 00:04:55,440
So such a schedule should not be accepted, right, such a schedule should not be accepted.

92
00:04:55,440 --> 00:05:03,630
So what I want to tell you is, in case if a transaction is trying to read the update of another transaction

93
00:05:04,260 --> 00:05:10,130
then this transaction should wait for this transaction to commit.

94
00:05:10,390 --> 00:05:11,780
Ok, this transaction to commit.

95
00:05:11,970 --> 00:05:13,170
Let us assume that.

96
00:05:13,470 --> 00:05:18,580
Let us assume that this transaction didn't read it and let us assume we are having commit over here.

97
00:05:20,550 --> 00:05:21,680
Ok, commit over here.

98
00:05:21,790 --> 00:05:22,480
Now tell me,

99
00:05:22,480 --> 00:05:24,260
will there be any problem over here?

100
00:05:24,580 --> 00:05:28,140
will there be any problem, in that case what will happen. In that case,

101
00:05:28,150 --> 00:05:29,400
let me start from the beginning.

102
00:05:29,460 --> 00:05:29,900
Ok.

103
00:05:30,010 --> 00:05:35,310
So, we are having the value of thousand, fine? for A in the hard disk.

104
00:05:35,320 --> 00:05:40,720
Now we are going to read this value, into the register fine because of which, it has become thousand.

105
00:05:40,720 --> 00:05:41,650
Fine.

106
00:05:41,650 --> 00:05:46,370
This is R1 and it has been made us nine nine hundred.

107
00:05:46,630 --> 00:05:47,090
Fine.

108
00:05:47,320 --> 00:05:51,320
And this value of nine hundred has been written in the hard disk, fine.

109
00:05:51,400 --> 00:05:56,750
And this value has been made as permanent because of this commit. Ok? Because of this commit,

110
00:05:56,820 --> 00:05:57,330
Fine.

111
00:05:57,410 --> 00:05:57,840
Now,

112
00:05:57,850 --> 00:06:01,620
let us assume this transaction is reading this this value. Ok?

113
00:06:01,930 --> 00:06:07,310
This value has been read by this transaction and it has been pasted in the register R2, fine.

114
00:06:07,330 --> 00:06:13,870
Now, let us assume, six percent interest has been added to this, right? See this is 6 percent right.

115
00:06:13,960 --> 00:06:15,500
So sorry for this.

116
00:06:15,550 --> 00:06:16,440
This is 6 percent.

117
00:06:16,450 --> 00:06:16,850
Okay.

118
00:06:16,880 --> 00:06:18,200
It doesn't matter anyway.

119
00:06:18,310 --> 00:06:20,800
So 6 percent of 900 is nothing but 54.

120
00:06:20,800 --> 00:06:21,120
Right.

121
00:06:21,530 --> 00:06:22,370
So.

122
00:06:23,030 --> 00:06:26,620
So it is 0.06 into 900.

123
00:06:26,920 --> 00:06:30,280
So both the zeros will get cancelled and this point will go away, because of this

124
00:06:30,290 --> 00:06:31,770
we get 954.

125
00:06:31,810 --> 00:06:37,390
So this 900 will be made as 954, fine because of this, fine.

126
00:06:37,400 --> 00:06:40,720
Now what happens if this transaction fails somewhere over here.

127
00:06:40,900 --> 00:06:42,940
In that case, we will perform rollback.

128
00:06:43,090 --> 00:06:49,030
But because of that rollback, B will be heading to this position, right.

129
00:06:49,040 --> 00:06:50,810
B will be heading to this position.

130
00:06:50,930 --> 00:06:53,740
If we head to this position, what'll happen?

131
00:06:53,840 --> 00:06:55,620
There is nothing wrong in it right.

132
00:06:55,640 --> 00:06:58,840
There is nothing wrong in it because we don't have any operations to perform.

133
00:06:59,180 --> 00:07:05,120
So we are done with both the transactions and after completing both the transactions we are ending up

134
00:07:05,210 --> 00:07:10,850
with the value of nine hundred and fifty four. See, we will end up with the value of 954.

135
00:07:10,870 --> 00:07:11,300
Why?

136
00:07:11,630 --> 00:07:13,260
Because of this write of A.

137
00:07:13,280 --> 00:07:15,930
This 954 will be written over here.

138
00:07:16,340 --> 00:07:19,160
This 900 has been read by, written by this transaction.

139
00:07:19,220 --> 00:07:23,090
Right. Now, because of this write, this 954 will be written over here.

140
00:07:23,510 --> 00:07:28,000
So after completing both the transactions we are getting the correct value of 954.

141
00:07:28,300 --> 00:07:29,930
Right, so this is the consistent result.

142
00:07:30,260 --> 00:07:37,580
Now why we got a consistent result over here because this transaction has waited for this transaction

143
00:07:37,580 --> 00:07:40,000
to commit before reading.

144
00:07:40,400 --> 00:07:48,770
In case if this transaction would have read this value, this update of the T1, if T2 has read the update

145
00:07:48,770 --> 00:07:55,650
of T1 without waiting for commit, then there is a chance of inconsistency, right,

146
00:07:55,790 --> 00:07:59,650
in case if the transaction fails. Let us assume we have commit over here.

147
00:07:59,660 --> 00:08:02,080
Now if transaction fails over here then there is a,

148
00:08:02,120 --> 00:08:08,180
there is inconsistency. Right? Now in case because, why this problem happened because this transaction

149
00:08:08,210 --> 00:08:15,250
did not wait for this transaction to commit, before that it has read the value, right? Now in case if this transaction

150
00:08:15,250 --> 00:08:21,180
T2 would have waited for T1 to commit and in case if it would have been, if it would have

151
00:08:21,440 --> 00:08:26,240
read the value after commit, then we would not have got this problem, right?

152
00:08:26,240 --> 00:08:35,360
So what I want to tell you is, reading an uncommitted update is what we mean by dirty-read, right, or reading

153
00:08:35,450 --> 00:08:36,890
an uncommitted write. See,

154
00:08:37,010 --> 00:08:39,540
this is this is uncommitted

155
00:08:39,610 --> 00:08:40,140
write.

156
00:08:40,180 --> 00:08:40,460
Right.

157
00:08:40,460 --> 00:08:41,500
We have performed, right.

158
00:08:41,540 --> 00:08:42,870
And this has not committed.

159
00:08:43,250 --> 00:08:46,130
But we are still reading this uncommitted write.

160
00:08:46,140 --> 00:08:46,640
Right?

161
00:08:46,670 --> 00:08:48,580
This is what we mean by dirty-read.

162
00:08:48,590 --> 00:08:50,910
We should always avoid dirty-read.

163
00:08:50,980 --> 00:08:51,280
Right?

164
00:08:51,290 --> 00:08:54,390
If we don't avoid dirty-read then we will get inconsistency.

165
00:08:54,530 --> 00:08:55,230
Fine.

166
00:08:55,400 --> 00:08:55,810
We should

167
00:08:55,820 --> 00:08:59,280
avoid dirty-reads that is a transaction T2

168
00:08:59,960 --> 00:09:03,310
which is about to read the update of another transaction

169
00:09:03,330 --> 00:09:10,530
T1. So, T1 has made an update and this transaction is waiting for, waiting to read this update, fine.

170
00:09:10,750 --> 00:09:16,250
Read the update of another transaction T1, it should wait for T1. This transaction T2 should wait

171
00:09:16,250 --> 00:09:17,840
for T1 to commit.

172
00:09:18,740 --> 00:09:21,580
If it doesn't wait for T1 to commit

173
00:09:21,590 --> 00:09:27,470
and if it reads the value then that is that is dirty-read and because of which we will get inconsistent

174
00:09:27,470 --> 00:09:28,610
results.

175
00:09:28,640 --> 00:09:30,380
So we have seen two problems right.

176
00:09:30,380 --> 00:09:33,650
One thing is write-write conflict and another one is write-read conflict.

177
00:09:33,710 --> 00:09:40,100
What is write-write conflict? In case if we are having 2 writes of the same data items across two different

178
00:09:40,100 --> 00:09:43,850
transactions then there should be read in between.

179
00:09:43,850 --> 00:09:44,350
Right.

180
00:09:44,420 --> 00:09:47,380
Else there we will get inconsistent results or it is called as

181
00:09:47,390 --> 00:09:51,140
lost-update problem which means the second write will

182
00:09:51,290 --> 00:09:51,860
overwrite

183
00:09:51,860 --> 00:09:58,580
the first write because of which the first write made by a transaction is being lost.

184
00:09:58,580 --> 00:09:58,790
Right.

185
00:09:58,790 --> 00:10:00,710
So we say it as lost-update problem.

186
00:10:00,740 --> 00:10:02,760
So what what do you mean by dirty-read problem?

187
00:10:02,960 --> 00:10:08,740
If a transaction is trying to read the update of another transaction then this transaction should wait

188
00:10:08,750 --> 00:10:13,630
for this transaction to commit before reading else we will get inconsistency. See,

189
00:10:13,710 --> 00:10:16,950
again we are having the same data item over here.

190
00:10:16,950 --> 00:10:17,490
Right?

191
00:10:17,520 --> 00:10:24,060
Let us assume it is reading, it is writing B and it is reading A, will there be any problem?

192
00:10:24,110 --> 00:10:26,300
This is not write-read conflict. Right?

193
00:10:26,350 --> 00:10:31,140
This is not write-read conflict. The data item has to be same.

194
00:10:31,250 --> 00:10:34,760
The data item has to be same and there should not be any commit over

195
00:10:34,790 --> 00:10:38,800
here. In order to say that, here we are having write-write write-

196
00:10:38,810 --> 00:10:42,390
read conflict. Ok? In case, if we have commit over here,

197
00:10:42,410 --> 00:10:45,460
then there is no write-read conflict for the schedule right.

198
00:10:45,530 --> 00:10:49,480
Also in case if the data items are different over here then there is no write-

199
00:10:49,480 --> 00:10:54,320
read conflict for the schedule, ok? What they might give you is they might give you a schedule something

200
00:10:54,320 --> 00:10:58,900
like this and they will ask whether we are having write-read conflict for the schedule or not.

201
00:10:58,910 --> 00:11:02,120
And you are supposed to find out that okay I think it is very simple now.