1
00:00:00,270 --> 00:00:05,760
‫Very simple stuff, jump to the second one, isolation, I skipped consistency because we're going to

2
00:00:05,760 --> 00:00:13,290
‫go back to consistency and later after isolation, this is one of the longest and in my opinion, one

3
00:00:13,290 --> 00:00:14,730
‫of the most critical.

4
00:00:15,860 --> 00:00:21,600
‫Properties software engineer really should understand, really should understand isolation.

5
00:00:22,250 --> 00:00:24,740
‫What is isolation and isolation as.

6
00:00:25,970 --> 00:00:30,400
‫To be isolated is I want to stay alone and I don't want to interact with the world right.

7
00:00:30,740 --> 00:00:32,990
‫OK, let's take this in the transaction.

8
00:00:33,080 --> 00:00:37,100
‫A transaction is to to have a transaction that I was late.

9
00:00:37,130 --> 00:00:41,780
‫That means an in-flight transaction while I'm executing a transaction.

10
00:00:42,530 --> 00:00:50,210
‫Can this transaction see other changes made by other transactions that are in flight?

11
00:00:50,240 --> 00:00:51,970
‫OK, so that's what it means.

12
00:00:52,100 --> 00:00:53,770
‫I am now executing my stuff.

13
00:00:53,780 --> 00:00:59,080
‫Can I see other stuff people are making and is that OK?

14
00:00:59,990 --> 00:01:06,570
‫Right, am I isolate from the other ward and it's really up to the implementor, the software engineer

15
00:01:06,570 --> 00:01:11,930
‫here to adjust this knob of isolation that we're going to talk about?

16
00:01:12,200 --> 00:01:13,570
‫Do you want no isolation?

17
00:01:13,580 --> 00:01:14,440
‫I don't care.

18
00:01:14,810 --> 00:01:19,430
‫You can change anything you want, and I'm going to read whatever you change.

19
00:01:19,430 --> 00:01:23,980
‫And that's may be OK, but in some cases it is.

20
00:01:23,990 --> 00:01:25,040
‫No, no, sir.

21
00:01:25,320 --> 00:01:25,660
‫OK.

22
00:01:27,290 --> 00:01:35,900
‫We're going to talk about that isolation I talk about as a lack of isolation, you get in, get these

23
00:01:36,680 --> 00:01:42,560
‫read phenomena, I don't like how the fancy name for some reason is this.

24
00:01:42,650 --> 00:01:47,930
‫You're going to get some read ugliness, read weirdness.

25
00:01:47,930 --> 00:01:48,230
‫Right.

26
00:01:48,260 --> 00:01:54,830
‫Some weird stuff while you're reading transactions and as a lack of isolation.

27
00:01:55,130 --> 00:01:57,970
‫We're going to talk about that recently reading Phenomenas.

28
00:01:58,190 --> 00:02:00,590
‫This is there to read and all that stuff.

29
00:02:01,730 --> 00:02:11,210
‫And we're going to talk about isolation levels that a database can implement to get rid of the Reid

30
00:02:11,210 --> 00:02:11,980
‫phenomenas.

31
00:02:12,530 --> 00:02:17,180
‫So without isolation, you get a bunch of Reid phenomenas.

32
00:02:17,210 --> 00:02:22,100
‫We implement isolation levels to fix those problems.

33
00:02:22,130 --> 00:02:24,110
‫OK, let's talk about boom.

34
00:02:24,110 --> 00:02:25,650
‫Let's talk about the Reid phenomenon.

35
00:02:25,880 --> 00:02:27,320
‫We have three.

36
00:02:27,350 --> 00:02:28,670
‫I added the fourth one.

37
00:02:28,670 --> 00:02:30,560
‫I don't think it's a Reid phenomena.

38
00:02:30,560 --> 00:02:33,740
‫It's one of the bad things that can happen as a side effect.

39
00:02:33,980 --> 00:02:35,660
‫But I added it anyway.

40
00:02:36,290 --> 00:02:41,090
‫So the first one, dirty Reid, dirty Reid, essentially, as I am.

41
00:02:41,090 --> 00:02:42,450
‫And we saw that right.

42
00:02:43,010 --> 00:02:44,510
‫I don't think we saw that.

43
00:02:44,660 --> 00:02:46,220
‫But it's actually dirty.

44
00:02:46,220 --> 00:02:53,120
‫Reid what it is essentially is like I am in for a transaction and some other transaction made a change.

45
00:02:53,150 --> 00:02:56,960
‫That transaction did not commit that chant.

46
00:02:57,140 --> 00:02:58,490
‫And I read that change.

47
00:02:58,970 --> 00:03:04,850
‫So any minute that transaction can roll back that change and I just write a bad value, a dirty value

48
00:03:04,850 --> 00:03:06,700
‫that hasn't been committed.

49
00:03:06,710 --> 00:03:08,990
‫That's what it means is not repeatable.

50
00:03:08,990 --> 00:03:10,640
‫Reid's we're going to talk about that.

51
00:03:10,790 --> 00:03:13,670
‫It's like I write a value that is being committed.

52
00:03:13,820 --> 00:03:14,240
‫Right.

53
00:03:14,760 --> 00:03:16,220
‫Not necessarily committed or not.

54
00:03:16,580 --> 00:03:16,810
‫Right.

55
00:03:17,030 --> 00:03:23,360
‫But then I turn around and my same transaction and I read the same value, whether the same query or

56
00:03:23,360 --> 00:03:29,830
‫other query that give me the same path to that value, like a range query.

57
00:03:30,350 --> 00:03:33,390
‫And I did not get the same result.

58
00:03:33,410 --> 00:03:37,930
‫So my results, my rates were not repeatable in my same transaction.

59
00:03:38,330 --> 00:03:40,610
‫Some some users are fine with that.

60
00:03:41,000 --> 00:03:42,900
‫Some users are not fine with that.

61
00:03:42,920 --> 00:03:44,240
‫We're going to talk about that.

62
00:03:44,990 --> 00:03:46,190
‫OK, Fantome rates.

63
00:03:46,490 --> 00:03:52,970
‫I inserted a new another transaction inserting a new record and I picked that up.

64
00:03:52,970 --> 00:04:00,920
‫What I shouldn't have picked that up is usually happens with range queries or lost updates.

65
00:04:00,930 --> 00:04:05,000
‫Like when when you started to change something.

66
00:04:05,090 --> 00:04:05,440
‫Right.

67
00:04:05,450 --> 00:04:11,930
‫You change in transaction, you change a value and some other transaction overwrote your value before

68
00:04:11,930 --> 00:04:12,890
‫you even commit it.

69
00:04:12,890 --> 00:04:15,140
‫So you're going to commit a wrong value.

70
00:04:15,140 --> 00:04:17,480
‫So you just lost your update essentially.

71
00:04:17,660 --> 00:04:20,810
‫OK, and these are the four phenomenas.

72
00:04:20,810 --> 00:04:22,040
‫Let's talk about each of one.

73
00:04:22,060 --> 00:04:24,230
‫One of them read Doctorate's.

74
00:04:24,230 --> 00:04:25,880
‫Let's talk about dirty reads that.

75
00:04:25,980 --> 00:04:27,980
‫So we talk about it, read it or Dirty reads.

76
00:04:28,010 --> 00:04:32,180
‫I am going to read a value that hasn't been committed by another transaction.

77
00:04:33,440 --> 00:04:35,010
‫I have a sales table.

78
00:04:35,540 --> 00:04:36,920
‫Those are two products.

79
00:04:37,400 --> 00:04:39,020
‫Product one Procter.

80
00:04:39,470 --> 00:04:47,930
‫There's a quantity of sales is broken, has sold ten units at a price of five dollars product to twenty

81
00:04:48,590 --> 00:04:48,950
‫four.

82
00:04:49,850 --> 00:04:54,140
‫And I am asked to write a query to produce a report of my sales.

83
00:04:54,470 --> 00:04:58,310
‫So what I'm going to do is select the entire thing and some of those guys.

84
00:04:58,460 --> 00:05:02,420
‫So product one has sold what fifty dollars product to us.

85
00:05:02,420 --> 00:05:08,240
‫Give us like eighty dollars and then at the end I'm going to just view the sum of all the sales look.

86
00:05:08,360 --> 00:05:09,230
‫Very simple stuff.

87
00:05:09,830 --> 00:05:17,990
‫So to do that transaction, even if we don't really need to commit or change, you can also begin a

88
00:05:17,990 --> 00:05:18,680
‫transaction.

89
00:05:18,690 --> 00:05:19,130
‫Right.

90
00:05:19,130 --> 00:05:21,380
‫And that's, and that can have its value.

91
00:05:22,100 --> 00:05:27,650
‫I'm going to begin a transaction selecting the product ID and then multiplying the quantity times a

92
00:05:27,660 --> 00:05:33,860
‫price, obviously, and then from sales that will give me what we just saw it for, like one fifty per

93
00:05:33,860 --> 00:05:34,280
‫item.

94
00:05:34,430 --> 00:05:35,120
‫That sounds good.

95
00:05:35,540 --> 00:05:36,980
‫But here's the trick.

96
00:05:37,160 --> 00:05:41,090
‫While this is executing another transaction, just begin.

97
00:05:42,310 --> 00:05:50,750
‫Right, and let's talk another quantity, it just added some some someone made us another sale, right.

98
00:05:51,010 --> 00:05:55,150
‫And they updated the sales report where the bid is equal one.

99
00:05:55,360 --> 00:05:58,250
‫So now we just increase the quantity by five.

100
00:05:58,750 --> 00:05:59,620
‫That's pretty good.

101
00:05:59,980 --> 00:06:04,860
‫But I don't know if it's good because we just read this now.

102
00:06:05,470 --> 00:06:08,380
‫I just have an old value and might be that.

103
00:06:08,390 --> 00:06:10,080
‫OK, but let's see what will happen.

104
00:06:10,900 --> 00:06:11,300
‫Right.

105
00:06:11,500 --> 00:06:14,080
‫So I didn't commit this transaction to yet.

106
00:06:14,450 --> 00:06:14,770
‫Right.

107
00:06:16,280 --> 00:06:22,940
‫While I'm doing that, I did the second quarter, which is select some quantity times price, which

108
00:06:22,940 --> 00:06:27,680
‫is literally this time this plus some 20 plus for it.

109
00:06:28,130 --> 00:06:28,880
‫But guess what?

110
00:06:30,230 --> 00:06:32,150
‫This is giving me a wrong result.

111
00:06:32,160 --> 00:06:38,720
‫This is now reading the dirty value that never been committed yet.

112
00:06:39,080 --> 00:06:40,070
‫This guy is reading it.

113
00:06:40,640 --> 00:06:42,170
‫And that's a dirty read, right?

114
00:06:42,200 --> 00:06:43,390
‫We're reading the bad value.

115
00:06:43,910 --> 00:06:44,410
‫Why?

116
00:06:44,450 --> 00:06:51,890
‫Because it's leading to bad results in 50 plus eight is one theory.

117
00:06:52,340 --> 00:06:59,000
‫But I am showing the report one fifty five so you can see dirty reads are bad.

118
00:06:59,300 --> 00:07:02,390
‫OK, I'm not saying they are always bad.

119
00:07:03,830 --> 00:07:10,070
‫It's up to you if you can tolerate that or not, if you're building and stick around, for example,

120
00:07:10,070 --> 00:07:14,630
‫you don't really care for the number of likes, doesn't matter the number of users who actually like

121
00:07:14,630 --> 00:07:15,380
‫the picture.

122
00:07:15,780 --> 00:07:16,180
‫Right.

123
00:07:16,430 --> 00:07:19,170
‫So you might there is a price for everything.

124
00:07:19,170 --> 00:07:20,460
‫Guys, we're going to talk about that.

125
00:07:21,530 --> 00:07:25,920
‫You can I just say, yeah, I'm I'm going to implement the best isolation ever again.

126
00:07:26,210 --> 00:07:30,830
‫So there's a first rate phenomenon and we commit the transaction, obviously.

127
00:07:30,830 --> 00:07:31,880
‫But it's it's useless.

128
00:07:31,910 --> 00:07:33,320
‫We got better, though, so that's dirty.

129
00:07:34,040 --> 00:07:35,060
‫Let's talk about.

130
00:07:37,420 --> 00:07:46,270
‫None repeatable read like a non repeatable read is, as we said, read that I'm going to read something

131
00:07:46,270 --> 00:07:48,120
‫in my transaction and I'm going to read it again.

132
00:07:48,130 --> 00:07:51,340
‫I'm getting two different values, you might say.

133
00:07:51,490 --> 00:07:54,850
‫Why are you reading the same values twice, you idiot?

134
00:07:54,850 --> 00:07:55,860
‫Why are you doing that?

135
00:07:55,870 --> 00:07:56,530
‫You just read it.

136
00:07:56,530 --> 00:07:57,430
‫Why are you reading twice?

137
00:07:57,760 --> 00:08:02,410
‫There are believe me, when you writing code, when you're writing a transaction, you will need to

138
00:08:02,410 --> 00:08:03,340
‫do that sometimes.

139
00:08:03,790 --> 00:08:06,970
‫And we're going to show you an example I had to think about.

140
00:08:06,970 --> 00:08:09,090
‫An example is but there's an example.

141
00:08:09,250 --> 00:08:10,320
‫Same thing, right?

142
00:08:10,990 --> 00:08:12,130
‫Beginning the transaction.

143
00:08:12,520 --> 00:08:14,260
‫I'm going to select the account of report.

144
00:08:14,620 --> 00:08:14,950
‫Right.

145
00:08:15,370 --> 00:08:16,210
‫That sounds good.

146
00:08:16,210 --> 00:08:18,090
‫Fifty and eighty three.

147
00:08:18,910 --> 00:08:22,180
‫And then this is the total of this is one thirty.

148
00:08:22,180 --> 00:08:22,780
‫But guess what?

149
00:08:23,290 --> 00:08:24,850
‫A transaction began at the same time.

150
00:08:25,760 --> 00:08:31,280
‫And it updated account sounds like it's the same transaction, but here's the little bit different I

151
00:08:31,280 --> 00:08:31,760
‫did hear.

152
00:08:32,050 --> 00:08:34,300
‫I actually changed that.

153
00:08:34,550 --> 00:08:39,290
‫Now it's 15 and I also committed that's the difference between the first one and that.

154
00:08:39,410 --> 00:08:43,340
‫So whatever I'm doing next is actually not a dirty read.

155
00:08:43,340 --> 00:08:43,750
‫Right.

156
00:08:44,600 --> 00:08:46,680
‫I'm reading a committed value.

157
00:08:46,910 --> 00:08:52,760
‫It's a legit value, but the question is, should I read that committed value or not?

158
00:08:53,040 --> 00:08:57,550
‫OK, so to me, if this has been committed, it's a legit value.

159
00:08:57,560 --> 00:09:01,340
‫It's not like the previous one where someone actually rolled back.

160
00:09:01,340 --> 00:09:01,810
‫Right.

161
00:09:01,820 --> 00:09:03,680
‫Or could could be rolled back.

162
00:09:03,710 --> 00:09:04,870
‫It's not a dirty value.

163
00:09:05,330 --> 00:09:07,420
‫It's an actual committed value.

164
00:09:07,970 --> 00:09:12,860
‫So I'm going to turn around, do the sum, but now I'm going to get a better result.

165
00:09:13,580 --> 00:09:18,850
‫Despite me committing, I get a bad result.

166
00:09:18,860 --> 00:09:21,950
‫So having it committed or not doesn't really matter.

167
00:09:22,700 --> 00:09:25,880
‫Now, I got this phenomena of a unrepeatable read.

168
00:09:26,870 --> 00:09:34,370
‫In this example, because their first read gave me that some one felty, the secondary gave me a different

169
00:09:34,370 --> 00:09:34,750
‫sum.

170
00:09:35,750 --> 00:09:38,720
‫So that's a non repeatable read in itself.

171
00:09:38,880 --> 00:09:40,460
‫OK, so not a bit of a read.

172
00:09:40,460 --> 00:09:44,030
‫So we read this first we get a result, then we read it again.

173
00:09:44,040 --> 00:09:45,080
‫We got a different result.

174
00:09:45,470 --> 00:09:46,840
‫So that's another bit of read.

175
00:09:46,870 --> 00:09:49,220
‫We can discuss ways to fix this.

176
00:09:49,490 --> 00:09:50,560
‫How can you fix this?

177
00:09:50,600 --> 00:09:55,910
‫We can talk about things, how to fix that nonprofitable, read, write and obviously going to come

178
00:09:55,910 --> 00:09:59,120
‫out of that phantom read your phantom.

179
00:09:59,120 --> 00:09:59,290
‫Right.

180
00:09:59,300 --> 00:10:05,690
‫So what Fantham reads is actually interesting because here's here's an example of Fantham read.

181
00:10:06,920 --> 00:10:11,570
‫Let's say I began the transaction, do the same thing, selecting count and then some the whole thing

182
00:10:11,900 --> 00:10:13,910
‫would get one 30, 50 sales.

183
00:10:13,910 --> 00:10:20,870
‫And at the same time, here's the other transaction I didn't actually update it just inserted record.

184
00:10:21,750 --> 00:10:28,590
‫And this incident, new cell of a totally different product, and now you committed that, so it's changed.

185
00:10:28,770 --> 00:10:35,700
‫It's in the database and in the same time that the first transaction is still executing, I am selecting

186
00:10:35,700 --> 00:10:37,620
‫all the current prices from sales.

187
00:10:41,030 --> 00:10:50,240
‫That is a bad sign because now you just accounted for product three on the first sheet of your paper

188
00:10:50,240 --> 00:10:52,580
‫report you did not account for.

189
00:10:52,610 --> 00:10:53,660
‫That's right.

190
00:10:53,930 --> 00:10:57,910
‫So now the sum of those of it is the one 30, but usually 140.

191
00:10:58,370 --> 00:10:59,540
‫That's a phantom rate.

192
00:10:59,550 --> 00:11:02,540
‫And the reason is factory, because this is one of the code.

193
00:11:02,660 --> 00:11:08,450
‫So that range queries where you're selecting, but you're getting.

194
00:11:09,670 --> 00:11:12,760
‫Extra rose, so.

195
00:11:13,600 --> 00:11:21,220
‫If we're going to talk about ways to fix that, this is a little bit harder to fix and and to avoid

196
00:11:22,030 --> 00:11:28,410
‫the previous ones, you can implement locks and version controls to get away with it.

197
00:11:28,690 --> 00:11:30,150
‫But this this is a new value.

198
00:11:30,160 --> 00:11:31,150
‫How do you lock it?

199
00:11:31,270 --> 00:11:32,250
‫It's a new value.

200
00:11:32,290 --> 00:11:33,850
‫Can say, hey, don't read that.

201
00:11:34,180 --> 00:11:34,680
‫Right.

202
00:11:34,730 --> 00:11:36,850
‫It's just really interesting.

203
00:11:36,850 --> 00:11:43,060
‫And that one of the ways to fix that is actually serialisation isolation level.

204
00:11:43,300 --> 00:11:43,660
‫All right.

205
00:11:44,650 --> 00:11:46,440
‫Let's talk about the isolation levels.

206
00:11:46,450 --> 00:11:46,720
‫Right.

207
00:11:47,050 --> 00:11:48,570
‫This is very interesting, guys.

208
00:11:48,580 --> 00:11:49,930
‫I really like this topic.

209
00:11:50,380 --> 00:11:56,170
‫So isolation levels are levels of isolation.

210
00:11:56,620 --> 00:11:58,180
‫Hosain, what what are you talking about?

211
00:11:58,450 --> 00:12:04,870
‫So isolation levels are levels that implemented by the database to fix those phenomena that we talked

212
00:12:04,870 --> 00:12:05,200
‫about.

213
00:12:05,300 --> 00:12:10,570
‫OK, and there's a nice table by Wikipedia here that I'm going to reference here is very nice.

214
00:12:10,700 --> 00:12:12,320
‫It just explains the whole thing here.

215
00:12:12,350 --> 00:12:17,440
‫OK, so really committed is the first type of isolation, which is, I don't know, I call the isolation

216
00:12:17,440 --> 00:12:20,590
‫level is that literally offers no isolation whatsoever.

217
00:12:21,190 --> 00:12:28,480
‫That transaction, when your transaction starts in a free and committed way, is not going to is going

218
00:12:28,480 --> 00:12:31,510
‫to it's not going to perform any isolation, any changes.

219
00:12:31,660 --> 00:12:32,950
‫The database is happening.

220
00:12:33,280 --> 00:12:34,020
‫You're going to see it.

221
00:12:34,510 --> 00:12:39,070
‫So you're going to get dirty reads here, obviously, because you're just doing everything you're going

222
00:12:39,070 --> 00:12:42,460
‫to get none repeatable reads.

223
00:12:42,460 --> 00:12:45,060
‫Obviously, you're going to get phantom reads right.

224
00:12:45,070 --> 00:12:46,840
‫And you get it lost updates as well.

225
00:12:47,010 --> 00:12:47,380
‫Yeah.

226
00:12:48,890 --> 00:12:55,250
‫The Reid committed is each there is little bit of isolation here and most database's implement that

227
00:12:56,210 --> 00:12:56,660
‫and.

228
00:12:57,930 --> 00:13:04,980
‫Most of the time, this is this is the one of the best transaction isolation level because you're happy

229
00:13:04,980 --> 00:13:07,730
‫with that, you're happy to read committed stuff.

230
00:13:08,160 --> 00:13:08,920
‫But here's the thing.

231
00:13:09,090 --> 00:13:15,530
‫Each query in the transaction only commit to the stuff at that time of their query.

232
00:13:16,080 --> 00:13:23,710
‫So each query you execute get to see the new committed values at that time.

233
00:13:23,840 --> 00:13:27,440
‫OK, and that could be fine, right?

234
00:13:27,480 --> 00:13:29,130
‫Sometimes it is not OK.

235
00:13:29,160 --> 00:13:37,350
‫So that's what it means to recommit that you are seeing and viewing the committed staff at the time

236
00:13:37,350 --> 00:13:38,790
‫of the query.

237
00:13:38,940 --> 00:13:39,410
‫OK.

238
00:13:39,780 --> 00:13:42,270
‫So anything that is committed, you're going to see it.

239
00:13:44,080 --> 00:13:50,180
‫Obviously, this does not work on our example that we show, because we showed even that is committed,

240
00:13:50,200 --> 00:13:52,020
‫the sales report came out wrong.

241
00:13:52,120 --> 00:13:52,440
‫Right.

242
00:13:52,750 --> 00:14:00,790
‫But there are certain cases where committed is enough for you get repeatable, read each query in the

243
00:14:00,790 --> 00:14:06,930
‫transaction, only sees committed of the dates at the beginning of the transaction.

244
00:14:06,940 --> 00:14:16,270
‫So it's the repeatable read isolation level gives you the ability to see.

245
00:14:18,220 --> 00:14:24,020
‫Committed values, but not at every single equerry at the beginning of the transaction.

246
00:14:24,040 --> 00:14:32,320
‫So once you begin a transaction, you will only see changes that have been committed before you start

247
00:14:32,330 --> 00:14:33,310
‫the transaction.

248
00:14:33,650 --> 00:14:41,530
‫OK, so that gives you a nice isolation, tight to view, and that's really powerful stuff.

249
00:14:41,860 --> 00:14:47,440
‫So now I'm not going to go through the implementation aspects of this database is some database that

250
00:14:47,440 --> 00:14:51,910
‫implements versioning to implement this like, hey, when you start a transaction like Cassandre, right.

251
00:14:52,210 --> 00:14:53,440
‫You start a transaction.

252
00:14:53,830 --> 00:15:01,670
‫I am inversion zero and then anything I read is belong to version zero of the database.

253
00:15:01,700 --> 00:15:06,940
‫Okay, so if other transactions are committing stuff, changing stuff, they are updating to version

254
00:15:06,940 --> 00:15:08,460
‫one version to over three.

255
00:15:08,740 --> 00:15:11,500
‫I am only reading version zero.

256
00:15:11,590 --> 00:15:15,790
‫And that's gives me a nice consistent view which we get to talk about that.

257
00:15:15,790 --> 00:15:16,060
‫Right.

258
00:15:16,090 --> 00:15:17,030
‫So repeatable rates.

259
00:15:18,160 --> 00:15:25,750
‫So this way I guarantee that I'm going to read the same repeatable read Reiger and then get the same

260
00:15:25,750 --> 00:15:27,550
‫read because I'm reading the same version.

261
00:15:28,030 --> 00:15:31,660
‫Some database is implemented as a form of a lock, which is a little bit more expensive.

262
00:15:31,930 --> 00:15:38,200
‫OK, so you have you establish an exclusive look and say, no, I am only reading this.

263
00:15:38,200 --> 00:15:40,920
‫Please, guys, don't change this, OK?

264
00:15:41,680 --> 00:15:42,280
‫Don't change it.

265
00:15:42,280 --> 00:15:45,760
‫So if once we establish an exclusive lock, we cannot.

266
00:15:45,760 --> 00:15:49,500
‫Nobody actually can or nobody can change that stuff.

267
00:15:49,950 --> 00:15:50,680
‫It's not acceptable.

268
00:15:51,450 --> 00:16:01,390
‫So so the lock approach of that, another approach to another approach to implement repeatable raises,

269
00:16:01,570 --> 00:16:04,690
‫you're going to start in place of shared locks.

270
00:16:04,690 --> 00:16:11,710
‫So you guarantee that nobody can actually change your data because everybody that needs to edit, they

271
00:16:11,710 --> 00:16:16,600
‫need to establish an exclusive lock to edit these rows.

272
00:16:16,600 --> 00:16:16,890
‫Right.

273
00:16:16,900 --> 00:16:18,460
‫And you get about what to read.

274
00:16:18,700 --> 00:16:22,780
‫And then once you do that, you release the shared lock, OK, so you implement some sort of a shared

275
00:16:22,780 --> 00:16:25,240
‫look, but you just blocked people from editing.

276
00:16:25,300 --> 00:16:27,700
‫So versioning is kind of a little bit better.

277
00:16:28,150 --> 00:16:33,070
‫But there is a pros and cons for each one, obviously serializable.

278
00:16:33,640 --> 00:16:37,210
‫That's the easiest way to implement and the kind of a slowest.

279
00:16:37,480 --> 00:16:43,990
‫And the the performance goes down with every level of isolation.

280
00:16:44,230 --> 00:16:47,250
‫So it's like I think of as a charter, this is no isolation.

281
00:16:47,260 --> 00:16:49,470
‫This is the highest isolation level game.

282
00:16:49,900 --> 00:16:51,930
‫But this is the fastest thing.

283
00:16:51,940 --> 00:16:53,230
‫This is the slowest thing.

284
00:16:54,010 --> 00:16:58,510
‫The serializable is essentially each transaction has to be serialized.

285
00:16:58,690 --> 00:16:59,020
‫Right.

286
00:16:59,290 --> 00:17:02,650
‫So if you as if they are serialist, almost like serios.

287
00:17:02,650 --> 00:17:02,890
‫Right.

288
00:17:03,100 --> 00:17:07,420
‫So the transaction just followed by another transaction, they cannot be executed in parallel.

289
00:17:07,420 --> 00:17:10,390
‫Essentially, they try as much as possible.

290
00:17:10,600 --> 00:17:14,470
‫The database does a little bit tricky things to to execute.

291
00:17:14,470 --> 00:17:19,210
‫Some of them are parallel, but most of them I you can think of as a serialized.

292
00:17:19,230 --> 00:17:19,510
‫Right.

293
00:17:19,720 --> 00:17:23,980
‫So if you're serialized, nothing running in parallel, you're happy, right.

294
00:17:24,400 --> 00:17:25,960
‫This is the best thing ever.

295
00:17:26,140 --> 00:17:31,740
‫If you're not nothing, nothing in running parallel, then you're not going to get in concurrency issue.

296
00:17:31,840 --> 00:17:33,940
‫You don't have isolation problems anyway.

297
00:17:34,810 --> 00:17:36,100
‫So this is the best way.

298
00:17:36,100 --> 00:17:38,770
‫Most of the time this is implemented at the application level.

299
00:17:38,980 --> 00:17:44,560
‫The application place is a lock and says, guys, stop touching my stuff, I'm updating it or I'm reading

300
00:17:44,560 --> 00:17:46,210
‫it, all right.

301
00:17:46,210 --> 00:17:48,940
‫And then start reading everything and then goes away.

302
00:17:49,510 --> 00:17:53,350
‫That's the table I was talking about with or from Wikipedia.

303
00:17:53,620 --> 00:17:56,600
‫You have the read and committed level, all of that stuff.

304
00:17:56,600 --> 00:18:03,760
‫All this phenomenas can occur, obviously, because we don't care uncommented read anything.

305
00:18:04,270 --> 00:18:04,630
‫Right.

306
00:18:04,630 --> 00:18:10,970
‫Any change that happens there to read lost updates, you get an unrepeatable you get phantom reads read

307
00:18:11,230 --> 00:18:11,890
‫I committed.

308
00:18:11,890 --> 00:18:16,510
‫What are we going to do is essentially read only the committee's stuff.

309
00:18:16,510 --> 00:18:17,950
‫So you're not going to get dirty reads.

310
00:18:18,220 --> 00:18:23,230
‫You know that because you're reading only committed stuff but you're going to get your not repeatable

311
00:18:23,230 --> 00:18:27,850
‫reads because each query is getting then you committed stuff.

312
00:18:28,180 --> 00:18:28,540
‫Right.

313
00:18:28,780 --> 00:18:35,230
‫So if you queried at that point the first query of the transaction and then you turn around and query

314
00:18:35,230 --> 00:18:39,970
‫again between those two queries, someone might change the value and committed it.

315
00:18:40,030 --> 00:18:45,610
‫So you're reading the committed value, but it change so it's not repeatable and that's might not be

316
00:18:45,610 --> 00:18:46,150
‫desirable.

317
00:18:46,330 --> 00:18:47,950
‫Obviously, you might get fandoms as well.

318
00:18:48,190 --> 00:18:49,120
‫Repeatable read.

319
00:18:51,230 --> 00:18:56,630
‫You're not going to get dirty, it's because we're eating only committed stuff, but in addition of

320
00:18:56,630 --> 00:19:01,040
‫that, we're only reading committed stuff at the beginning of transactions.

321
00:19:01,040 --> 00:19:05,180
‫So you're not going to repeat your you're not going to get a unrepeatable read.

322
00:19:05,420 --> 00:19:11,060
‫All of you are repeatable because you're reading the same version of the database at the start of the

323
00:19:11,060 --> 00:19:18,410
‫transaction or that the database will force you to places a lock and then we'll only read the stuff

324
00:19:18,410 --> 00:19:19,040
‫at the beginning.

325
00:19:19,070 --> 00:19:25,610
‫OK, so that's essentially a reputable read and by Fantome still can occur as a result because you cannot

326
00:19:25,610 --> 00:19:34,030
‫control Newroz, you can only control what you can only control rows that you can lock.

327
00:19:34,040 --> 00:19:34,360
‫Right.

328
00:19:34,790 --> 00:19:39,300
‫And this is debatable with versioning, you actually can get away with it.

329
00:19:39,320 --> 00:19:46,430
‫You write this so this table is not entirely accurate with what if you implemented versioning with repeatable

330
00:19:46,430 --> 00:19:47,660
‫rates, you can actually.

331
00:19:49,660 --> 00:19:55,480
‫You might get away with repeatable reads, right, if you in the Virginny, I think Grogs DB and the

332
00:19:55,480 --> 00:20:02,270
‫Facebook story is that Virginny serializable best thing ever.

333
00:20:02,380 --> 00:20:07,990
‫I'm not going to say this, but if you're serializer a transaction, you're not going to get any of

334
00:20:07,990 --> 00:20:08,530
‫that stuff.

335
00:20:09,430 --> 00:20:13,210
‫You are guaranteed that nobody touches anything.

336
00:20:14,470 --> 00:20:15,430
‫Unless.

337
00:20:17,450 --> 00:20:19,520
‫They have a lock, right?

338
00:20:19,550 --> 00:20:23,180
‫So you started the transaction, you placed the shared lock, right.

339
00:20:23,330 --> 00:20:29,450
‫And if someone want to bring in the exclusive lock, they will get they will get an error because there

340
00:20:29,480 --> 00:20:30,940
‫are Shedlock, there are read logs.

341
00:20:31,250 --> 00:20:33,920
‫So and we talk about Shedlock and Redlegs.

342
00:20:33,920 --> 00:20:35,270
‫I'm going to reference the video there, guys.