1
00:00:00,060 --> 00:00:09,390
‫All right, let's talk about the third property in the acid system isolation.

2
00:00:09,780 --> 00:00:13,590
‫Very, very critical and really underrated property.

3
00:00:13,620 --> 00:00:19,170
‫Not all of people understand, truly understand the ramifications of transaction isolation.

4
00:00:19,350 --> 00:00:21,420
‫So in this lecture, we're going to talk about isolation.

5
00:00:21,570 --> 00:00:22,830
‫And this is going to be a long lecture.

6
00:00:22,830 --> 00:00:28,470
‫So sit back, relax, grab a cup of coffee, tea or your favorite drink, and let's go through it.

7
00:00:28,710 --> 00:00:32,850
‫So to talk about isolation, we have to answer this question.

8
00:00:33,840 --> 00:00:35,400
‫We have transactions, correct?

9
00:00:36,120 --> 00:00:39,300
‫And if it's a single user, that's fine.

10
00:00:39,300 --> 00:00:44,520
‫But we have many TCP connections to my database if you support remote and remote connections.

11
00:00:45,150 --> 00:00:47,640
‫And then each connection execute transactions.

12
00:00:47,640 --> 00:00:56,190
‫So there is a chance where concurrency can happen, multiple transaction fighting over to write and

13
00:00:56,190 --> 00:00:58,320
‫to read the same pieces of data.

14
00:00:58,680 --> 00:01:01,470
‫And that's what isolation come into place.

15
00:01:02,040 --> 00:01:11,160
‫The question is, can my inflight transaction see changes made by other transactions that are also in

16
00:01:11,160 --> 00:01:11,640
‫flight?

17
00:01:12,030 --> 00:01:19,170
‫That's the question that needs answering, not only in flight, other in-flight induction, even transaction

18
00:01:19,170 --> 00:01:19,890
‫that has finished.

19
00:01:20,550 --> 00:01:26,040
‫What if I am running a transaction and I'm quitting reading, reading, reading, reading and some other

20
00:01:26,040 --> 00:01:27,930
‫transaction committed to change?

21
00:01:28,680 --> 00:01:30,690
‫The question is, should I see this change?

22
00:01:31,560 --> 00:01:32,570
‫Well, it depends.

23
00:01:32,580 --> 00:01:33,960
‫Do you want to see that change?

24
00:01:34,830 --> 00:01:35,160
‫Right?

25
00:01:35,370 --> 00:01:36,390
‫There is no answer.

26
00:01:36,390 --> 00:01:37,470
‫There is no right or wrong.

27
00:01:37,500 --> 00:01:43,230
‫So as a result of these, you get a bunch of read phenomena as they call it.

28
00:01:43,500 --> 00:01:44,790
‫And I had very fancy name.

29
00:01:45,210 --> 00:01:53,370
‫And the mean understanding of these read phenomena is these are usually undesirable.

30
00:01:53,700 --> 00:01:54,930
‫You don't want these.

31
00:01:55,380 --> 00:01:59,100
‫These are bad side effects, but we're going to go through them.

32
00:01:59,100 --> 00:02:00,780
‫We're going to understand what are they?

33
00:02:01,140 --> 00:02:07,620
‫And if you run into one of them, you're going to see and you understand, Oh, now I see what happening

34
00:02:07,620 --> 00:02:07,860
‫here.

35
00:02:08,040 --> 00:02:11,670
‫And these are one of the nastiest things to debunk, in my opinion.

36
00:02:13,800 --> 00:02:22,650
‫We're also going to talk about isolation levels that were introduced to solve these undesirable read

37
00:02:22,770 --> 00:02:23,760
‫phenomenons.

38
00:02:24,300 --> 00:02:24,660
‫Right?

39
00:02:25,680 --> 00:02:28,960
‫So let's talk about isolation read phenomenon.

40
00:02:29,070 --> 00:02:33,690
‫So we they decided to run and to the first 3D phenomenon called Dirty Read, and we're going to talk

41
00:02:33,690 --> 00:02:35,640
‫about them in details and with an example.

42
00:02:35,640 --> 00:02:43,050
‫But it's essentially a dirty read is I read that you, as an in-flight transaction can only running.

43
00:02:43,320 --> 00:02:50,820
‫You read something that some other transaction has wrote but didn't really commit yet.

44
00:02:51,600 --> 00:02:58,800
‫So there's a chance that this change that you just read could be rolled back or it could be committed,

45
00:02:59,040 --> 00:03:00,600
‫or it could be that Airbus could be crashed.

46
00:03:01,120 --> 00:03:01,260
‫Right?

47
00:03:01,920 --> 00:03:03,360
‫So this is called a dirty read.

48
00:03:03,660 --> 00:03:04,830
‫Anything that is dirty.

49
00:03:05,060 --> 00:03:13,060
‫It means that you wrote something and this right is not really fully flushed, not fully committed.

50
00:03:13,080 --> 00:03:14,070
‫It might change.

51
00:03:14,700 --> 00:03:15,780
‫And that's what it's called dirty.

52
00:03:15,890 --> 00:03:18,900
‫It's not repeatable.

53
00:03:18,900 --> 00:03:22,440
‫Reads are reads that you are in a transaction.

54
00:03:22,440 --> 00:03:24,060
‫You read a value, right?

55
00:03:24,360 --> 00:03:26,400
‫And then in the same transaction, you read it again.

56
00:03:26,670 --> 00:03:27,930
‫And that sounds ridiculous.

57
00:03:27,930 --> 00:03:28,620
‫Like what?

58
00:03:28,800 --> 00:03:31,320
‫Why would you ever read things twice?

59
00:03:31,320 --> 00:03:38,460
‫That's just dumb and an optimal, but no, believe me, you do this all the time without you realizing

60
00:03:38,610 --> 00:03:44,810
‫is not about doing select select idea from account and then doing a select idea from the count.

61
00:03:44,850 --> 00:03:46,580
‫Not the same exact query.

62
00:03:46,590 --> 00:03:47,890
‫No, we're not talking about that.

63
00:03:48,180 --> 00:03:51,090
‫That's yeah, it's a little bit odd to do that.

64
00:03:51,240 --> 00:03:54,480
‫But there are cases where you actually do the same exact way.

65
00:03:54,690 --> 00:04:03,990
‫But I'm talking about the different queries that yield the same value, and there are thousands of these

66
00:04:03,990 --> 00:04:04,410
‫cases.

67
00:04:04,830 --> 00:04:10,830
‫One example is you get a reader value, but then you do a select sum, which also reads the value behind

68
00:04:10,830 --> 00:04:12,390
‫the scenes because it does a sum.

69
00:04:12,840 --> 00:04:17,520
‫These are different values, but they are dependent on the same entry that is in the database.

70
00:04:17,820 --> 00:04:23,790
‫So an unrepeatable read as when you read something and then you the database tries to read the same

71
00:04:23,790 --> 00:04:25,920
‫value again, that changes.

72
00:04:27,500 --> 00:04:27,830
‫Right.

73
00:04:28,100 --> 00:04:30,860
‫And this is called a non repeatable it.

74
00:04:30,980 --> 00:04:34,130
‫It was not repeatable in my own transaction.

75
00:04:34,550 --> 00:04:36,910
‫So that's what a read phenomena.

76
00:04:36,920 --> 00:04:39,410
‫Some people find this undesirable.

77
00:04:39,710 --> 00:04:40,010
‫Right?

78
00:04:40,530 --> 00:04:45,210
‫And we're going to show you show you an example of that phantom red phantom.

79
00:04:45,210 --> 00:04:50,180
‫And these are things that you cannot really read because they don't exist yet.

80
00:04:51,140 --> 00:04:52,190
‫I'm going to give you an example.

81
00:04:52,490 --> 00:04:58,940
‫So example with this is our range queries like, let's say, a selecta, all the activities between

82
00:04:58,940 --> 00:05:00,110
‫this date and this date.

83
00:05:00,320 --> 00:05:00,620
‫Right.

84
00:05:00,920 --> 00:05:06,860
‫When you do this range between this and this right, you get a number right, you get a certain values.

85
00:05:07,220 --> 00:05:10,070
‫But then let's say someone inserted a new Rosiere.

86
00:05:10,850 --> 00:05:14,000
‫It's a completely new rule, so it's not really and not repeatable.

87
00:05:14,000 --> 00:05:15,220
‫Read you didn't even read it.

88
00:05:15,230 --> 00:05:20,960
‫It's just something that is inserted that satisfies your range query now.

89
00:05:21,590 --> 00:05:30,320
‫Now, if you do that and you do another select read, you're going to give that phantom new role and

90
00:05:30,320 --> 00:05:35,480
‫you're going to give that read and that things might go really wrong with that.

91
00:05:35,690 --> 00:05:37,130
‫And that's called The Phantom Read.

92
00:05:37,430 --> 00:05:44,300
‫So you got you got certain result in the first situation, but the second one you you got you got a

93
00:05:44,510 --> 00:05:45,560
‫completely different result.

94
00:05:45,860 --> 00:05:48,080
‫So it's not really completely not repeatable.

95
00:05:48,080 --> 00:05:55,790
‫Read it's it doesn't qualify as an unrepeatable because you didn't really read it in the first place

96
00:05:55,790 --> 00:05:56,340
‫and you didn't.

97
00:05:56,550 --> 00:05:58,520
‫You can't quite catch it.

98
00:05:58,610 --> 00:06:00,860
‫I'm doing this with my head, but he can't see it.

99
00:06:01,340 --> 00:06:02,390
‫I'm doing this with my head.

100
00:06:04,460 --> 00:06:06,170
‫The fourth one is really lost updates.

101
00:06:06,530 --> 00:06:09,140
‫That means I wrote something.

102
00:06:09,680 --> 00:06:15,500
‫But before I commit this right, I try to read what I wrote.

103
00:06:15,980 --> 00:06:21,330
‫Well, this is very common because if if you aren't trans. and you write something and you turn on only,

104
00:06:21,350 --> 00:06:25,880
‫that's something that's completely void because you are in your own bubble.

105
00:06:26,180 --> 00:06:30,080
‫You can read what you wrote, but other times, actually, you really can't.

106
00:06:30,500 --> 00:06:32,600
‫Depends on whether dirty readers are enabled or not.

107
00:06:33,200 --> 00:06:33,590
‫But.

108
00:06:34,940 --> 00:06:38,720
‫Some other times action can actually change what you wrote.

109
00:06:38,900 --> 00:06:43,160
‫So if you turn around and read what you just wrote is just lost.

110
00:06:43,490 --> 00:06:45,320
‫And that's called lost updates.

111
00:06:45,380 --> 00:06:50,120
‫We're going to talk about when that actually can happen and how to circumvent this.

112
00:06:50,150 --> 00:06:50,540
‫All right.

113
00:06:50,570 --> 00:06:52,490
‫Dirty reads less than an example.

114
00:06:52,790 --> 00:06:58,980
‫So we have a sales table here and we have three columns product in quantity and the price.

115
00:06:59,630 --> 00:07:06,200
‫Product one has sold 10 quantities and each is $5.

116
00:07:06,230 --> 00:07:09,020
‫So the total price is, what, five hundred fifty dollars, $50.

117
00:07:10,190 --> 00:07:14,800
‫So we sold fifty dollars worth of product, one product to us twenty point thirty four dollars.

118
00:07:14,800 --> 00:07:16,720
‫So the total is, what, $80.

119
00:07:16,940 --> 00:07:18,530
‫So what is a dirty read in this case?

120
00:07:19,040 --> 00:07:24,050
‫You began a transaction as usual and you start this query.

121
00:07:24,350 --> 00:07:26,630
‫You select the product ID.

122
00:07:27,170 --> 00:07:33,110
‫And then the second column is, is is that actually the expression you multiplying the quantity times

123
00:07:33,110 --> 00:07:36,860
‫the price goes, you want to see the total right from sales.

124
00:07:37,370 --> 00:07:44,450
‫That's generally a bad query, not because we're doing an explosion, but because we don't have a work

125
00:07:44,450 --> 00:07:44,750
‫load.

126
00:07:45,140 --> 00:07:46,490
‫But we're explaining things here.

127
00:07:46,500 --> 00:07:53,390
‫So as long as they tell you that this is bad because if you have billions of sales now this is going

128
00:07:53,390 --> 00:07:56,030
‫through the whole entire table, you have to have always a range.

129
00:07:56,270 --> 00:07:58,290
‫You have to have a bounded query.

130
00:07:58,310 --> 00:07:59,840
‫I always say it's bounded.

131
00:08:00,200 --> 00:08:05,430
‫And the reason is this is an unbounded equation that means there is no bounds, which is just forever

132
00:08:05,450 --> 00:08:06,740
‫goes forever, right?

133
00:08:06,770 --> 00:08:08,090
‫Yeah, we have two rows there.

134
00:08:08,090 --> 00:08:13,730
‫But when things work with €2, it doesn't necessarily work with over 100000 rows.

135
00:08:14,450 --> 00:08:16,400
‫But yeah, we got we got the idea, right?

136
00:08:16,490 --> 00:08:19,220
‫So we have, uh, what we are going to get is a product.

137
00:08:19,220 --> 00:08:20,930
‫One is 50 and the product is 80.

138
00:08:20,960 --> 00:08:21,260
‫Right?

139
00:08:21,500 --> 00:08:22,190
‫That's all we got.

140
00:08:22,970 --> 00:08:23,780
‫And this is the list.

141
00:08:23,800 --> 00:08:24,320
‫I don't know.

142
00:08:24,320 --> 00:08:29,630
‫Maybe I'm generating a report, a sales report and now another transaction started.

143
00:08:29,870 --> 00:08:34,520
‫While this is actually running, so these are in parallel now, right?

144
00:08:34,730 --> 00:08:38,390
‫So this story and this is now so we selected this.

145
00:08:38,390 --> 00:08:43,520
‫We read the actual values that aren't currently in the table transactions to start.

146
00:08:43,540 --> 00:08:48,830
‫And right after this guy read the values, it actually made some more sale.

147
00:08:49,070 --> 00:08:51,860
‫Some people more made some more seasoned product one.

148
00:08:52,190 --> 00:08:54,340
‫We added an extra five.

149
00:08:54,350 --> 00:08:56,750
‫We sold in excess of five products, right?

150
00:08:57,050 --> 00:08:59,590
‫So now what will happen is now it's 15.

151
00:08:59,940 --> 00:09:02,750
‫OK, now look at this.

152
00:09:03,530 --> 00:09:05,180
‫We're doing another query.

153
00:09:05,180 --> 00:09:10,580
‫But now we're just want to sum all that all the sales, regardless of the product.

154
00:09:11,540 --> 00:09:18,920
‫What do you think the value should be versus what do you think the value will be based on a dirty read

155
00:09:18,920 --> 00:09:21,290
‫configuration look or will happen?

156
00:09:22,560 --> 00:09:25,920
‫We're going to get 1:55 why?

157
00:09:27,150 --> 00:09:33,590
‫Because if you multiply this 15 by five plus eight years ago, this didn't change.

158
00:09:33,600 --> 00:09:37,320
‫So the original sum is actually 130, if you think about it, 50 plus 80.

159
00:09:37,620 --> 00:09:40,320
‫But we added a $25 worth of sales.

160
00:09:40,770 --> 00:09:45,030
‫So if you add that you're going to get 155, which is technically no wrong.

161
00:09:45,480 --> 00:09:52,420
‫But if within the same transaction, this is inconsistent because if you actually print this in a report,

162
00:09:52,420 --> 00:09:57,930
‫then you went to the manager said, OK, oh, product 150 product to 80, and then you print it all

163
00:09:57,930 --> 00:09:58,530
‫the way down.

164
00:09:58,530 --> 00:10:01,680
‫In the summary, you put in the sum as 155, there's what.

165
00:10:01,920 --> 00:10:02,730
‫What are you doing?

166
00:10:03,060 --> 00:10:04,290
‫That's just wrong.

167
00:10:04,620 --> 00:10:04,980
‫Right?

168
00:10:05,280 --> 00:10:06,360
‫And why did we do that?

169
00:10:06,360 --> 00:10:08,760
‫Because we read a dirty read.

170
00:10:09,210 --> 00:10:11,220
‫This guy didn't even commit.

171
00:10:11,220 --> 00:10:12,990
‫And yet we read the value.

172
00:10:13,320 --> 00:10:16,830
‫You notice that the line of the commit didn't even happen.

173
00:10:17,100 --> 00:10:20,490
‫Now we come into my transaction, which we lived in, didn't change anything.

174
00:10:20,490 --> 00:10:24,470
‫But we're just reading just to tell you that the transaction is terminated.

175
00:10:24,750 --> 00:10:26,610
‫But now this guy just, hey, you know what?

176
00:10:26,670 --> 00:10:27,270
‫Never mind.

177
00:10:27,300 --> 00:10:30,630
‫I'm going to roll back because, hey, we did.

178
00:10:30,630 --> 00:10:36,300
‫And I actually made five five sales rollback, so I know this is actually worse.

179
00:10:36,690 --> 00:10:41,250
‫You write a dirty read and that Druid has has gone right.

180
00:10:42,090 --> 00:10:44,580
‫And that is really a problem.

181
00:10:44,590 --> 00:10:46,290
‫You get an inconsistent result.

182
00:10:46,410 --> 00:10:47,370
‫So let's talk about none.

183
00:10:47,370 --> 00:10:47,910
‫Repeatable.

184
00:10:47,910 --> 00:10:48,480
‫Read here.

185
00:10:49,290 --> 00:10:49,680
‫--.

186
00:10:49,680 --> 00:10:50,550
‫Configuration here.

187
00:10:50,580 --> 00:10:52,140
‫10:50 10.

188
00:10:52,140 --> 00:10:53,400
‫Five twenty four.

189
00:10:53,910 --> 00:10:55,350
‫And then we're going to begin a transaction.

190
00:10:56,400 --> 00:10:58,200
‫Now we're going to select the same exact thing.

191
00:10:58,200 --> 00:11:01,530
‫We're going to get product 150 product to 80.

192
00:11:01,800 --> 00:11:03,990
‫So what is a non repeatable rate here?

193
00:11:04,530 --> 00:11:06,280
‫Another transaction begins, but look at that.

194
00:11:06,300 --> 00:11:07,050
‫The arrow is shorter.

195
00:11:07,050 --> 00:11:07,930
‫I'm a little shorter.

196
00:11:07,950 --> 00:11:08,370
‫Why?

197
00:11:08,420 --> 00:11:11,220
‫Because here's what I'm going to do this time.

198
00:11:11,220 --> 00:11:13,320
‫I'm going to make the sale and guess what?

199
00:11:13,800 --> 00:11:15,870
‫I'm going to actually commit.

200
00:11:16,900 --> 00:11:20,290
‫The change before the second transaction.

201
00:11:20,980 --> 00:11:25,300
‫Finish it or before the second transaction actually made the second query to do do the.

202
00:11:25,990 --> 00:11:26,500
‫Look at this.

203
00:11:27,310 --> 00:11:30,370
‫So we we actually persisted.

204
00:11:30,550 --> 00:11:31,660
‫This is not a dirty read.

205
00:11:31,780 --> 00:11:35,530
‫This is an actual valid right and valid read.

206
00:11:35,530 --> 00:11:41,020
‫So the value is actually 15, but we read the value B prior to that change.

207
00:11:41,560 --> 00:11:45,040
‫So now what should we do now?

208
00:11:45,040 --> 00:11:48,610
‫I do a some count price from sales and guess what we're going to do?

209
00:11:48,820 --> 00:11:51,310
‫We're going to get the exact same wrong result.

210
00:11:51,460 --> 00:11:54,550
‫We'll get 1:55 when it should have been 130.

211
00:11:55,030 --> 00:11:55,300
‫Right.

212
00:11:55,540 --> 00:11:57,130
‫That's the actual result.

213
00:11:57,130 --> 00:11:58,090
‫That is desirable.

214
00:11:59,320 --> 00:12:01,360
‫So no, this is not really a dirty read.

215
00:12:01,870 --> 00:12:04,540
‫This is an actual, committed read.

216
00:12:04,990 --> 00:12:12,100
‫But the problem is this was a non repeatable read because you read the values here and you read them

217
00:12:12,100 --> 00:12:14,110
‫kind again, right?

218
00:12:14,290 --> 00:12:16,360
‫But you read them through an aggregation function.

219
00:12:16,940 --> 00:12:17,200
‫Right?

220
00:12:18,390 --> 00:12:22,980
‫And as a result, you got an inconsistent rally and you might say I was in this case, I don't want

221
00:12:22,990 --> 00:12:28,440
‫none of it body, not all the time because we're going to come to that.

222
00:12:28,440 --> 00:12:31,560
‫But fixing this is expensive.

223
00:12:32,160 --> 00:12:41,010
‫Fixing this so that you don't, you're all is the same version of the value here is not it is not easy.

224
00:12:41,850 --> 00:12:48,960
‫A lot of data is supported through NBCC, but is not easy because now you have to keep a version of

225
00:12:48,960 --> 00:12:51,690
‫the product one at the original state.

226
00:12:51,870 --> 00:12:53,220
‫That's what post-GST does, by the way.

227
00:12:53,390 --> 00:12:59,430
‫Topolsky is always any updates create a new version of the road and never changes the same value.

228
00:12:59,790 --> 00:13:09,150
‫While MySchool and Oracle, and maybe also a SQL server, changes this.

229
00:13:09,510 --> 00:13:14,990
‫The final value changes 250mm, but it keeps another table called the undo grade.

230
00:13:15,420 --> 00:13:16,500
‫I'm writing and do here.

231
00:13:16,500 --> 00:13:24,630
‫I don't know if you can't see it, but the undo stack keeps an actual writing to desk a place where

232
00:13:24,630 --> 00:13:31,800
‫all the previous values O product one, by the way, it used to be 10 at turns to be 15, right?

233
00:13:32,340 --> 00:13:33,150
‫We, I don't know.

234
00:13:33,430 --> 00:13:34,980
‫It keeps the delta changes.

235
00:13:35,340 --> 00:13:41,610
‫So now if this guy want to read in Postgres, it will read the original version.

236
00:13:42,240 --> 00:13:44,940
‫It just just keeps a version pointer here.

237
00:13:45,120 --> 00:13:52,050
‫So there is another roll product, one version to write version B, for example, so you don't get confused.

238
00:13:52,440 --> 00:13:56,730
‫But in my sequel, what will happen is it doesn't.

239
00:13:56,730 --> 00:14:03,030
‫It cannot read that it has to go and crack open the undo log and then read that values.

240
00:14:03,030 --> 00:14:06,150
‫And that could be expensive for long running transactions, right?

241
00:14:06,450 --> 00:14:08,640
‫Because it cannot trust this latest value anymore.

242
00:14:09,060 --> 00:14:14,480
‫So, yeah, this was just a short explanation of isolated, but we're going to come to that yet.

243
00:14:14,490 --> 00:14:17,760
‫And then we come out and obviously nothing changes bad.

244
00:14:17,850 --> 00:14:18,450
‫Not repeatable.

245
00:14:18,460 --> 00:14:19,440
‫Read can be bad.

246
00:14:19,560 --> 00:14:21,940
‫So it's really up to you guys.

247
00:14:22,530 --> 00:14:26,160
‫You cannot just go by this example and say, Oh, I'm fine.

248
00:14:26,160 --> 00:14:32,250
‫No, really comes back to what are you trying to build and then just understand this problem and say,

249
00:14:32,520 --> 00:14:33,360
‫Hey, I'm fine.

250
00:14:33,360 --> 00:14:37,020
‫I'm even fine with dirty rates because I don't think anybody is fine with their theory.

251
00:14:37,160 --> 00:14:41,430
‫Dirtiness is the wars, but I have actually built an application.

252
00:14:41,430 --> 00:14:45,900
‫What I relied on dirty read, which was a very bad idea.

253
00:14:46,650 --> 00:14:48,000
‫I regretted that later.

254
00:14:49,050 --> 00:14:51,110
‫Let's talk about Phantom Reed.

255
00:14:51,420 --> 00:14:54,720
‫So Phantom reads result from range queries.

256
00:14:54,720 --> 00:14:58,170
‫Anything that can potentially give you one or more results.

257
00:14:58,890 --> 00:15:01,590
‫Pretty much phantom eight always happen.

258
00:15:01,860 --> 00:15:03,570
‫Do you think about it if you have a where clause?

259
00:15:03,870 --> 00:15:05,260
‫I can't think of an example of Phantom.

260
00:15:05,320 --> 00:15:06,600
‫It could not happen, to be honest.

261
00:15:07,830 --> 00:15:10,920
‫So exemplification sales would begin transaction.

262
00:15:11,460 --> 00:15:21,630
‫We do a select quantity price sales, and this time I'm reading this product 50 and 80 transaction to

263
00:15:21,630 --> 00:15:23,510
‫start it now.

264
00:15:23,520 --> 00:15:30,640
‫It didn't really update it inserted a new and new product, completely new product, right?

265
00:15:31,320 --> 00:15:36,510
‫So now if you insert a new product, well, that's fine, because in this case, we don't really read

266
00:15:36,510 --> 00:15:36,930
‫this product.

267
00:15:36,930 --> 00:15:39,180
‫But get this, it actually commits it.

268
00:15:39,510 --> 00:15:42,390
‫So now we have $10 to No.

269
00:15:42,570 --> 00:15:46,770
‫10 quantity of product, three at a price of one and an extra $10.

270
00:15:47,640 --> 00:15:50,850
‫So now what do we do here in the in your original transaction?

271
00:15:51,150 --> 00:15:55,080
‫You're going to do us some quantity from sales, which it doesn't have as an unbounded query.

272
00:15:55,110 --> 00:15:56,940
‫There is no there is no bound to it.

273
00:15:57,180 --> 00:16:01,680
‫So that means we're going to unfortunately some all of them and go to product three.

274
00:16:02,670 --> 00:16:03,270
‫Yikes.

275
00:16:03,690 --> 00:16:06,360
‫So we get 140, which should be 130.

276
00:16:06,810 --> 00:16:08,470
‫We read a committed value.

277
00:16:08,820 --> 00:16:14,490
‫No, that's not really a dirty and that just happened to show up in our range query.

278
00:16:14,930 --> 00:16:15,070
‫Right.

279
00:16:15,990 --> 00:16:21,540
‫It's not really a repeatable read because we never actually read Product three to begin with in the

280
00:16:21,540 --> 00:16:22,470
‫previous one.

281
00:16:22,620 --> 00:16:25,440
‫We read these two values and they changed later.

282
00:16:25,830 --> 00:16:26,130
‫OK.

283
00:16:26,460 --> 00:16:32,430
‫So and why are we differentiating between the two is really the implementation when it comes to it?

284
00:16:32,730 --> 00:16:39,200
‫Like if you if you really want to know your guys are interested, it just comes down to locking in non

285
00:16:39,210 --> 00:16:40,260
‫repeatable reads.

286
00:16:40,440 --> 00:16:46,770
‫When we read something, we wanted to guarantee repeatable reads and you think that the transaction

287
00:16:46,770 --> 00:16:49,980
‫reads, it just obtains a shared lock on it.

288
00:16:50,400 --> 00:16:51,780
‫It's not really a shared luck.

289
00:16:51,780 --> 00:16:53,070
‫It's one kind of locks.

290
00:16:53,090 --> 00:16:55,380
‫We're going to talk about locks in this course as well.

291
00:16:55,740 --> 00:17:03,810
‫And then and then if it just make sure that this red read doesn't change for that transaction, that's

292
00:17:03,810 --> 00:17:04,680
‫what it makes sure of.

293
00:17:04,920 --> 00:17:09,780
‫But how does it get rid of new rules that has never been read?

294
00:17:10,290 --> 00:17:10,920
‫How does it get?

295
00:17:11,310 --> 00:17:16,590
‫You cannot even see the rule to lock it, to prevent it from changing you.

296
00:17:16,890 --> 00:17:17,520
‫That's what.

297
00:17:17,680 --> 00:17:20,450
‫On Tom Ridge, you can grab it right, it's Phantom.

298
00:17:20,750 --> 00:17:23,840
‫So last update, let's talk about the last read phenomenons.

299
00:17:24,500 --> 00:17:31,780
‫So then Tim thing here we know we're going to begin to transaction in parallel concurrently.

300
00:17:33,080 --> 00:17:37,740
‫We're going to update one of these guys did the quantity to increase.

301
00:17:38,420 --> 00:17:44,000
‫Let's say we added a $10 sale to 10 units of sales to product one.

302
00:17:44,900 --> 00:17:47,540
‫Now from 10, it turns to 20.

303
00:17:47,900 --> 00:17:48,830
‫Transaction two.

304
00:17:49,490 --> 00:17:53,090
‫Updated the same quantity to add five.

305
00:17:53,540 --> 00:17:54,290
‫But guess what?

306
00:17:54,860 --> 00:18:00,980
‫This quantity now it's reading the original value because they started the same thing, so both of them

307
00:18:01,400 --> 00:18:05,120
‫actually read quantity as 10, though this guy is also 10.

308
00:18:05,750 --> 00:18:11,280
‫So now what it will do is it will take the 10 plus five and then store it into the product.

309
00:18:11,300 --> 00:18:16,010
‫So now we have 15, so now we lost the value here.

310
00:18:17,180 --> 00:18:17,700
‫OK.

311
00:18:17,720 --> 00:18:20,150
‫And that's what happens in this situation.

312
00:18:20,990 --> 00:18:25,910
‫So now we commit the transaction transaction to us faster, so it committed.

313
00:18:26,150 --> 00:18:31,430
‫And now we have the value 15 and now transaction one assumes that it made the sale.

314
00:18:31,550 --> 00:18:32,750
‫It will do the same.

315
00:18:32,930 --> 00:18:36,350
‫And we're going to give you a completely different result.

316
00:18:36,560 --> 00:18:42,780
‫That is absolutely wrong because it should have been 180, but we got actually less resolved.

317
00:18:42,980 --> 00:18:43,330
‫Why?

318
00:18:43,370 --> 00:18:48,350
‫Because our update was actually overwritten by another transaction.

319
00:18:48,650 --> 00:18:50,690
‫And as a result, it was lost.

320
00:18:51,710 --> 00:18:53,060
‫One of the nastiest thing.

321
00:18:53,150 --> 00:18:58,700
‫And this is going to be solved basically by actually locking the row said, Hey, if someone rolled

322
00:18:58,710 --> 00:19:04,130
‫over, locks are very popular here, we're going to talk about them here like, Hey, did I just change

323
00:19:04,130 --> 00:19:04,410
‫this?

324
00:19:04,430 --> 00:19:07,280
‫I don't want anyone else to change the same rule.

325
00:19:07,340 --> 00:19:08,540
‫There is no point of it.

326
00:19:08,810 --> 00:19:10,250
‫Let me finish and then release it.

327
00:19:10,250 --> 00:19:14,630
‫And then once I'm done, you go your own merry way.

328
00:19:14,750 --> 00:19:15,260
‫All right.

329
00:19:16,990 --> 00:19:19,930
‫We talked about these phenomenons, we need to talk about isolation.

330
00:19:19,960 --> 00:19:23,830
‫I know this, this lectures little long, guys, but there's a lot of information here.

331
00:19:24,400 --> 00:19:27,340
‫Feel free to ask questions and to understand this better.

332
00:19:27,850 --> 00:19:30,400
‫So isolation levels for in-flight transaction, what are they?

333
00:19:31,330 --> 00:19:39,430
‫So I'm going to talk about many, many isolation levels they that were invented to fix those read phenomena

334
00:19:39,430 --> 00:19:40,240
‫that we talked about.

335
00:19:40,810 --> 00:19:47,410
‫So when I try and start my transaction, you set this isolation level using key what I believe set isolation

336
00:19:47,410 --> 00:19:49,000
‫level literally in a transaction.

337
00:19:49,030 --> 00:19:54,660
‫This is the sequel command for you saying, Hey, I want to start a transaction with Reid uncommitted.

338
00:19:54,670 --> 00:20:00,310
‫That's the first one which I believe no database supports except sequels ever read.

339
00:20:00,340 --> 00:20:02,620
‫Uncommitted is just means no isolation.

340
00:20:02,920 --> 00:20:11,350
‫I wouldn't to read anything you read is visible by any body outside that changes this value.

341
00:20:11,620 --> 00:20:19,150
‫I just read uncommitted, as is related to the transaction itself, so it means no isolation and this

342
00:20:19,150 --> 00:20:23,640
‫is from outside is visible to the transaction, whether it's committed or not.

343
00:20:23,650 --> 00:20:25,510
‫That's what's called read uncommitted.

344
00:20:25,750 --> 00:20:28,510
‫You can read uncommitted values as a result.

345
00:20:28,600 --> 00:20:30,400
‫You can get dirty.

346
00:20:30,400 --> 00:20:33,070
‫Reads here bad, obviously.

347
00:20:33,370 --> 00:20:40,780
‫But if you think about it, it's technically fast because I don't really need to maintain anything.

348
00:20:41,170 --> 00:20:44,910
‫It's questionable because the implementation, you know, know what the implementation is.

349
00:20:44,920 --> 00:20:48,400
‫You just assume from theory that it's fast but could be not.

350
00:20:50,040 --> 00:20:56,610
‫Really committed this this isolation is the one of the most popular isolation levels out there, and

351
00:20:56,680 --> 00:21:04,830
‫a lot of databases optimize their engines for Reid committed workloads, which means each query in a

352
00:21:04,830 --> 00:21:09,640
‫transaction only sees committed changes by either transaction.

353
00:21:09,660 --> 00:21:12,060
‫And we talked about that in the examples.

354
00:21:12,780 --> 00:21:20,910
‫So now if if there is a transaction that makes a change ride while I'm reading something, I'm not going

355
00:21:20,910 --> 00:21:24,150
‫to see this change unless the transaction committed was its committed.

356
00:21:24,150 --> 00:21:26,700
‫While I'm running, I'm still running the transaction.

357
00:21:27,060 --> 00:21:29,190
‫I'll be able to see that change.

358
00:21:30,510 --> 00:21:32,490
‫You might not be happy with that.

359
00:21:32,910 --> 00:21:37,440
‫Is it heads could get inconsistent, but just understand that this exist.

360
00:21:37,950 --> 00:21:43,650
‫And I believe this is the default isolation level for many, many databases.

361
00:21:44,100 --> 00:21:49,710
‫Just understand that what if you have a long running transaction and you think that has been committed

362
00:21:50,310 --> 00:21:52,560
‫will be picked up by transaction?

363
00:21:52,860 --> 00:22:02,220
‫This could be bad, repeatable read, which is the isolation level was invented to fix the non repeatable

364
00:22:02,220 --> 00:22:03,570
‫read write none of biddable.

365
00:22:03,570 --> 00:22:10,800
‫Read Is this bad read phenomena or repeatable read is the isolation level to make the reader repeatable.

366
00:22:10,910 --> 00:22:15,090
‫That means as I read and I read it again, is not going to change.

367
00:22:15,090 --> 00:22:18,040
‫I can read a thousand times as long as I'm in the same transaction.

368
00:22:18,420 --> 00:22:19,470
‫The value will not change.

369
00:22:19,770 --> 00:22:20,790
‫Let's read this definition.

370
00:22:20,910 --> 00:22:24,630
‫By the way, I rewrote this definition based on my understanding.

371
00:22:24,690 --> 00:22:31,620
‫You will not find these definitions on the web because, frankly speaking, computer scientists always

372
00:22:31,620 --> 00:22:35,370
‫complicate things because they added all the all of jargon for some reason.

373
00:22:35,520 --> 00:22:35,780
‫Right?

374
00:22:36,030 --> 00:22:42,900
‫So based on my personal experience and professional experience working since 2005, this is what I give

375
00:22:42,900 --> 00:22:42,960
‫you.

376
00:22:42,960 --> 00:22:46,620
‫I give you things that are practical that you can touch and feel right.

377
00:22:46,650 --> 00:22:47,880
‫Fixed a typo there, here.

378
00:22:48,150 --> 00:22:54,900
‫So the transaction will make sure that when our query reads are raw, that role will remain unchanged

379
00:22:54,900 --> 00:22:57,810
‫while it's while the transaction is running effectively, right?

380
00:22:57,960 --> 00:22:58,980
‫So that's what it means.

381
00:22:59,520 --> 00:23:06,150
‫Only when you actually when the toxin actually reads a value, reads an object, needs a role, reads

382
00:23:06,150 --> 00:23:06,810
‫a column.

383
00:23:07,230 --> 00:23:13,290
‫Then we going to make sure that as long as this transaction is running, that add value will never change.

384
00:23:13,650 --> 00:23:20,440
‫But if you didn't learn it, if you don't read it, we're not going to copy a version of that role.

385
00:23:20,500 --> 00:23:22,700
‫If you if that, if you can get my point, right?

386
00:23:22,710 --> 00:23:24,840
‫Because how do you implement something like that?

387
00:23:25,440 --> 00:23:27,900
‫Think about what the database is doing for you.

388
00:23:28,560 --> 00:23:32,340
‫There is cost for everything, and this is a cost.

389
00:23:32,940 --> 00:23:36,720
‫If you you can, you can take a snapshot of the entire database if you want.

390
00:23:36,720 --> 00:23:40,170
‫And that's another observation level, by the way, called snapshot, right?

391
00:23:40,320 --> 00:23:41,700
‫But that's also expensive.

392
00:23:44,530 --> 00:23:52,100
‫There is a thing snapshot, each query in a transaction only sees changes that have been committed up

393
00:23:52,100 --> 00:23:53,870
‫to the start of the transaction.

394
00:23:54,320 --> 00:23:57,380
‫It's like a snapshot of the whole database at that moment.

395
00:23:57,890 --> 00:24:04,370
‫This is guaranteed to get rid of every read phenomena.

396
00:24:05,240 --> 00:24:11,040
‫This repeatability doesn't get rid of phantom reads because we saw that phantom only just sneaks in.

397
00:24:11,060 --> 00:24:11,810
‫It's an insult.

398
00:24:11,810 --> 00:24:18,650
‫We never actually read a value to a locket or to to obtain some sort of a lock so that we can aversion

399
00:24:18,650 --> 00:24:18,780
‫it.

400
00:24:18,800 --> 00:24:20,810
‫We didn't even get to do that right.

401
00:24:21,440 --> 00:24:22,730
‫Snapshot isolation.

402
00:24:22,730 --> 00:24:27,080
‫Just hey, it's just, Hey, this is this is what I read at that stage.

403
00:24:27,290 --> 00:24:31,940
‫And Postgres repeatable read is actually a snapshot.

404
00:24:31,940 --> 00:24:35,000
‫Isolation is just everything a versioned.

405
00:24:35,270 --> 00:24:41,810
‫So if I'm going to start a transaction, you kind of timestamp which version you are in.

406
00:24:42,290 --> 00:24:45,260
‫And then as a result, you're always going to agree this version.

407
00:24:45,260 --> 00:24:52,760
‫So even if you inserted rows show up, you will not pick them up because the database will filter things

408
00:24:52,760 --> 00:24:54,230
‫based on your version effectively.

409
00:24:54,710 --> 00:24:56,840
‫And that's the power of the snapshot isolation.

410
00:24:57,770 --> 00:25:02,840
‫The final one, or the basically the slowest, if you think about it, is the realizable.

411
00:25:03,020 --> 00:25:05,570
‫That means there are no concurrency anymore.

412
00:25:05,960 --> 00:25:11,810
‫Just each transaction is physically, almost physically database is implemented differently.

413
00:25:12,020 --> 00:25:14,270
‫But as if they are serialized after the other.

414
00:25:14,270 --> 00:25:19,850
‫So if there are three transactions stored in the same place, they will be serialized based on.

415
00:25:20,210 --> 00:25:23,750
‫Now this depends on the linearity, ability and stuff.

416
00:25:23,750 --> 00:25:25,070
‫Complicated stuff like that.

417
00:25:25,310 --> 00:25:31,070
‫Which one goes first is the question that the database tries to answer so that you get almost the same

418
00:25:31,070 --> 00:25:31,520
‫results.

419
00:25:34,380 --> 00:25:39,030
‫And obviously, I talked about that each day of and permit isolation level differently.

420
00:25:39,480 --> 00:25:44,070
‫Don't don't overstress, will this isolation level just understand that they exist?

421
00:25:45,090 --> 00:25:49,290
‫Most of the time, you're never going to run into this complex situation.

422
00:25:49,290 --> 00:25:55,620
‫But if you do know that these things exist, especially with a lot of users changing and reading at

423
00:25:55,620 --> 00:25:58,110
‫the same time, this is when you start.

424
00:25:58,500 --> 00:26:00,180
‫You need to know about this, at least.

425
00:26:01,710 --> 00:26:02,940
‫I thought this from Wikipedia.

426
00:26:03,770 --> 00:26:05,130
‫I like this table a lot.

427
00:26:05,520 --> 00:26:11,610
‫It doesn't have the snapshot isolation, but if you if you look at this, you can see that read uncommitted.

428
00:26:11,610 --> 00:26:14,550
‫Everything may occur with the all the reed phenomenon.

429
00:26:14,830 --> 00:26:16,440
‫A. This reed committed.

430
00:26:16,980 --> 00:26:19,550
‫Everything can happen except dirty reed.

431
00:26:19,560 --> 00:26:24,000
‫You cannot get dirty because I'm reading committed to stuff repeatable, right?

432
00:26:24,690 --> 00:26:26,220
‫You don't get dirty leads.

433
00:26:26,400 --> 00:26:30,090
‫You don't get lost updates and you don't get none.

434
00:26:30,090 --> 00:26:31,440
‫Repeatable reads as well.

435
00:26:32,680 --> 00:26:34,500
‫Because we fix that old repeatable.

436
00:26:34,960 --> 00:26:36,190
‫But you still get fandoms.

437
00:26:36,400 --> 00:26:41,110
‫But in serialized well and also snapshot, you don't get any of this.

438
00:26:41,320 --> 00:26:42,940
‫It's all fixed effectively.

439
00:26:43,630 --> 00:26:43,920
‫Right.

440
00:26:43,930 --> 00:26:48,700
‫And there is a slight difference between, say, realizable and snapshot.

441
00:26:49,460 --> 00:26:54,400
‫Realizable is effectively just slows things down.

442
00:26:54,550 --> 00:27:01,480
‫If you think about it, right, because it just serialized this thing while Snapshot takes a version

443
00:27:01,840 --> 00:27:04,900
‫of the database at the start of the transaction.

444
00:27:04,930 --> 00:27:09,880
‫Now, when I say a version of the database, I'm not talking about actual backup, right?

445
00:27:10,180 --> 00:27:13,990
‫It's the database have to implement this in a optimized manner.

446
00:27:14,560 --> 00:27:14,930
‫Makes sense.

447
00:27:15,540 --> 00:27:19,150
‫Guys, let's talk about a little bit of database implementation of isolation.

448
00:27:20,170 --> 00:27:23,470
‫Is that devious implements isolation level differently?

449
00:27:23,470 --> 00:27:27,760
‫Of course, there is the pessimistic, pessimistic the dust bowl.

450
00:27:27,760 --> 00:27:35,200
‫Is that a pessimistic yet pessimistic approach, which is this me, the pessimistic concurrency controls?

451
00:27:35,200 --> 00:27:40,960
‫To be specific, it means I'm going to use locks and I'm going to dedicate an entire section.

452
00:27:40,960 --> 00:27:43,390
‫Lecturers talking about locks talk.

453
00:27:43,990 --> 00:27:46,090
‫When you get to that, you're going to learn more about it.

454
00:27:46,600 --> 00:27:48,130
‫But effectively, I'm going to opt in.

455
00:27:48,130 --> 00:27:55,150
‫Are a roll over locks, table locks, page locks, a table lock that means any change I make, I'm going

456
00:27:55,150 --> 00:27:56,620
‫to put in a lock and the whole table.

457
00:27:56,710 --> 00:27:57,930
‫Very, very expensive.

458
00:27:57,940 --> 00:28:05,590
‫By the way, I run into a lot of situations where my transactions lock the entire table called lock

459
00:28:05,590 --> 00:28:06,250
‫escalation.

460
00:28:06,250 --> 00:28:12,550
‫It's escalated the road to a table lock and then all transactions were just pending trying to change

461
00:28:12,550 --> 00:28:13,360
‫other values.

462
00:28:13,360 --> 00:28:14,980
‫And it couldn't because the table was locked.

463
00:28:15,340 --> 00:28:20,710
‫Page lock the actual logical page that contained the changes on lock.

464
00:28:21,130 --> 00:28:24,130
‫This is especially true in case of clustering.

465
00:28:24,310 --> 00:28:27,130
‫If you want to cluster your table again, we're going to talk about that as well.

466
00:28:27,580 --> 00:28:32,110
‫And then these pages that you write to also have certain locks.

467
00:28:32,530 --> 00:28:35,140
‫So effectively there is a pessimistic approach lock.

468
00:28:35,380 --> 00:28:36,670
‫Hey, I'm changing.

469
00:28:36,670 --> 00:28:37,210
‫Lock it.

470
00:28:37,240 --> 00:28:38,920
‫Don't let anybody touch this.

471
00:28:39,280 --> 00:28:43,270
‫So if you lock a role, only that role won't be able to touch it.

472
00:28:44,470 --> 00:28:46,210
‫You're going to see some examples.

473
00:28:46,390 --> 00:28:52,210
‫When I showed in both Chris and Michael that when we tried to update something, it will succeed.

474
00:28:52,210 --> 00:28:54,100
‫But another transaction will try to update.

475
00:28:54,340 --> 00:28:57,670
‫It will just sit there and wait because the row is locked.

476
00:28:59,440 --> 00:29:02,500
‫Optimistic usually don't use the locks.

477
00:29:02,500 --> 00:29:03,700
‫That's the other approach.

478
00:29:04,360 --> 00:29:07,630
‫That means there will be any pending transaction.

479
00:29:07,930 --> 00:29:09,580
‫So also not only that.

480
00:29:09,910 --> 00:29:11,920
‫So nobody will wait on the other.

481
00:29:13,120 --> 00:29:20,470
‫And also the benefit of this is the lock management, which is extremely expensive, by the way.

482
00:29:20,740 --> 00:29:23,440
‫Now, because how do you know about a role as lock?

483
00:29:23,470 --> 00:29:25,000
‫You have to maintain that memory, right?

484
00:29:25,180 --> 00:29:26,350
‫You have to keep track.

485
00:29:26,350 --> 00:29:27,160
‫The database has to keep.

486
00:29:27,160 --> 00:29:28,180
‫It's like, Oh, this is luck.

487
00:29:28,180 --> 00:29:28,660
‫This is not.

488
00:29:28,960 --> 00:29:29,620
‫This is locked.

489
00:29:30,310 --> 00:29:32,860
‫This is expensive, especially rollover locks.

490
00:29:32,860 --> 00:29:37,030
‫If you have like 700000 tape rolls that you need to lock.

491
00:29:37,990 --> 00:29:43,810
‫This is expensive, so optimistic a lot of people prefer this approach where, hey, I'm not going to

492
00:29:43,810 --> 00:29:50,710
‫obtain an actual lock, but I am going to just let things play by ear.

493
00:29:50,710 --> 00:29:57,370
‫And when something actually when people start people, when transactions start stepping on each other,

494
00:29:58,030 --> 00:30:00,070
‫boom, I'm going to fail the transaction.

495
00:30:01,290 --> 00:30:08,790
‫And the user should just retry, and the error is called usually a serialized, well, error you get,

496
00:30:08,790 --> 00:30:15,090
‫it's like, hey, some something changed at the beginning of the transaction, so that just retry the

497
00:30:15,090 --> 00:30:15,650
‫transaction.

498
00:30:15,660 --> 00:30:17,960
‫No sequel that it was his preferred.

499
00:30:17,970 --> 00:30:24,630
‫This approach to locking because locking is expensive, repeatable, Reid locks.

500
00:30:24,900 --> 00:30:27,540
‫I talk about that a little bit repeatable.

501
00:30:27,540 --> 00:30:34,710
‫Reid locks the rules, it reads, but it could be expensive if you read a lot of rose Bosca's implements

502
00:30:35,010 --> 00:30:36,570
‫repeatable read as a snapshot.

503
00:30:36,960 --> 00:30:42,480
‫We talked about that right snapshot and repeatable read, and Bosca's are identical to the same thing.

504
00:30:43,290 --> 00:30:49,500
‫This is why you don't get phantom reads with poor scores and repeatable rates, where in other databases

505
00:30:49,770 --> 00:30:53,010
‫you get phantom reads or they're beatable reads and.

506
00:30:54,460 --> 00:30:56,230
‫Spoiler alert, that's part of a quiz.

507
00:30:59,360 --> 00:31:05,900
‫See, realizable are usually implemented with optimistic concurrency control, because if you actually

508
00:31:05,900 --> 00:31:11,240
‫truly do see realizable, then is going to your data is going to be so slow, right?

509
00:31:11,300 --> 00:31:13,720
‫Because what is the realizable just one after the other, right?

510
00:31:14,330 --> 00:31:18,910
‫So that's why database is implemented with the optimistic concurrency control.

511
00:31:19,220 --> 00:31:23,240
‫You can also implement that pessimistically if you want to select for update.

512
00:31:23,380 --> 00:31:25,430
‫Hey, I'm going to select this, but I'm going to lock it.

513
00:31:26,030 --> 00:31:26,660
‫That's what you do.

514
00:31:27,200 --> 00:31:34,970
‫So let's summarize those election isolation is the result of having the transaction run in complete

515
00:31:34,970 --> 00:31:37,580
‫isolation from other concurrent transactions.

516
00:31:37,610 --> 00:31:44,840
‫As a result, we get rid phenomenons and we have a lot of isolation levels that have been invented to

517
00:31:44,840 --> 00:31:46,350
‫fix great phenomenons.

518
00:31:47,210 --> 00:31:49,230
‫Let's jump to the next lecture.

519
00:31:49,250 --> 00:31:49,610
‫Good job.

520
00:31:49,610 --> 00:31:51,140
‫By the way, I'm finishing this lecture.

521
00:31:52,100 --> 00:31:52,580
‫Good job.