1
00:00:00,060 --> 00:00:01,320
‫What is going on, guys?

2
00:00:01,500 --> 00:00:09,510
‫This is a follow up lecture on the double booking prevention lecture that I made on this course.

3
00:00:09,900 --> 00:00:18,990
‫And you guys had a lot of other, you know, workarounds to solve the double booking problem, you know,

4
00:00:18,990 --> 00:00:21,750
‫and most of them are actually fine.

5
00:00:21,990 --> 00:00:28,680
‫But one in particular that I actually liked and I want to, you know, explore.

6
00:00:28,920 --> 00:00:32,730
‫I already answered this question many times in the in the Q&A section.

7
00:00:33,240 --> 00:00:36,810
‫But, you know, wards are very hard, you know, to express everything.

8
00:00:36,810 --> 00:00:40,530
‫It's always better to make a video and explain these in details.

9
00:00:41,430 --> 00:00:49,830
‫You know, the the the reason I want to talk about this particular approach is, is that, you know,

10
00:00:50,730 --> 00:00:58,340
‫to understand how things actually work when you when you issue this update statement to book a seat,

11
00:00:58,350 --> 00:00:58,580
‫right?

12
00:00:58,830 --> 00:01:04,590
‫So what we're talking about, obviously, I want you to obviously watch the double booking video before

13
00:01:04,590 --> 00:01:07,860
‫jumping into this video, right?

14
00:01:08,250 --> 00:01:09,510
‫Otherwise, you don't have context.

15
00:01:10,050 --> 00:01:17,550
‫But if you if you notice what we did is we are trying to book a seat effectively, right?

16
00:01:17,550 --> 00:01:20,850
‫And these are my seats effectively, right?

17
00:01:21,360 --> 00:01:30,720
‫And let's clear up this thing so as to update seats set is booked equal zero, you equal now.

18
00:01:30,990 --> 00:01:32,880
‫So it just cleared out everything.

19
00:01:33,060 --> 00:01:37,500
‫So we don't we don't have any other anything booked, right?

20
00:01:37,830 --> 00:01:43,590
‫So the idea we're building a system that is, I don't know, Airbnb cinema, you know, we don't want

21
00:01:43,590 --> 00:01:49,500
‫to book a particular seat and we want to prevent the problem with it where two people book the same

22
00:01:49,500 --> 00:01:56,280
‫seat effects of it effectively in a way that last when and which is the most dangerous kind of a situation,

23
00:01:56,280 --> 00:01:56,490
‫right?

24
00:01:56,530 --> 00:02:01,920
‫P2 people pay for a seat and two people, you know, kind of get this seat, but the last one actually

25
00:02:01,920 --> 00:02:02,550
‫gets the seat.

26
00:02:02,790 --> 00:02:03,600
‫That's very bad.

27
00:02:03,900 --> 00:02:10,330
‫So the way I proposed to solve this is using this statement, which is select blah blah blah.

28
00:02:10,350 --> 00:02:11,760
‫Four Update, right?

29
00:02:12,180 --> 00:02:21,450
‫Which effectively creates takes an exclusive lock on the roll so that this transaction is free to do

30
00:02:21,450 --> 00:02:26,390
‫all sorts of things until it commits so that it releases the lock.

31
00:02:26,670 --> 00:02:27,090
‫Right?

32
00:02:27,300 --> 00:02:32,730
‫And then the other transaction effectively, you know, Kent can resume.

33
00:02:32,790 --> 00:02:33,090
‫Right?

34
00:02:33,330 --> 00:02:37,680
‫So this way you have full control to kind of isolate the transaction.

35
00:02:37,680 --> 00:02:40,970
‫You have full control to serialize the transaction.

36
00:02:41,010 --> 00:02:42,090
‫This is a very common way.

37
00:02:42,630 --> 00:02:43,850
‫But other people said it was.

38
00:02:43,860 --> 00:02:50,520
‫And what if you did, you know, did another approach where you didn't select to check the seat of Steakin

39
00:02:50,820 --> 00:02:53,340
‫and then to acquire the lock?

40
00:02:53,340 --> 00:02:59,250
‫But no, just immediately do an update, right and then check the result of the update.

41
00:02:59,550 --> 00:03:03,710
‫If the if the if the seats take it or not, this approach will definitely work.

42
00:03:03,720 --> 00:03:08,730
‫But I wanted to explain why it is actually working and it's not actually guaranteed that is going to

43
00:03:08,730 --> 00:03:10,440
‫work on all database systems.

44
00:03:10,560 --> 00:03:12,570
‫That's why I want you guys to understand the fundamentals.

45
00:03:12,900 --> 00:03:18,540
‫If you understand the fundamental fundamentals, you guys are basically unstoppable, right?

46
00:03:18,540 --> 00:03:25,080
‫Because you understand the basics through any database that you're on, you and you basically understand

47
00:03:25,080 --> 00:03:25,500
‫everything.

48
00:03:25,620 --> 00:03:26,790
‫So let's take an example.

49
00:03:26,790 --> 00:03:30,840
‫So I'm going to go ahead and begin this transaction here, and I'm going to begin another transaction

50
00:03:30,840 --> 00:03:32,250
‫here and in this transaction.

51
00:03:32,250 --> 00:03:35,340
‫I want to book this seat for Hussain, right?

52
00:03:35,550 --> 00:03:37,770
‫Hassan is going to book seat one, right?

53
00:03:38,580 --> 00:03:45,120
‫And in this transaction, let's say Rick is going to book the same seat CET1.

54
00:03:45,240 --> 00:03:46,800
‫So we're going to do that.

55
00:03:47,280 --> 00:03:49,290
‫A lot of people suggested this right.

56
00:03:49,590 --> 00:03:58,020
‫Update seats set is booked equal, one the user is saying for which seat?

57
00:03:59,090 --> 00:03:59,360
‫Right.

58
00:03:59,730 --> 00:04:04,340
‫Sit sit for this seat, where I.D., which is the seat, I'd equal one.

59
00:04:04,550 --> 00:04:12,410
‫And not only that, only one is booked is actually zero when it's not booked and the seat is the one,

60
00:04:12,770 --> 00:04:15,080
‫go ahead and update their seat.

61
00:04:15,120 --> 00:04:17,210
‫So go ahead and now updated the seat.

62
00:04:17,210 --> 00:04:18,710
‫So I'm going to go ahead and do that.

63
00:04:18,920 --> 00:04:19,850
‫And you can see them.

64
00:04:19,910 --> 00:04:22,820
‫The transaction now successfully updated the rule.

65
00:04:23,240 --> 00:04:26,060
‫Keep in mind, we did not commit the transaction yet.

66
00:04:26,360 --> 00:04:33,890
‫So now in the other end, someone exactly made that almost exact identical statement because it is executed

67
00:04:33,910 --> 00:04:38,870
‫from the application line, but is booked equal one by the user equal.

68
00:04:38,870 --> 00:04:45,020
‫What Rick Ryan, where ID equal one and is booked equal zero.

69
00:04:45,140 --> 00:04:51,350
‫And here's what I want you to to think about what is actually happening right now.

70
00:04:52,700 --> 00:04:53,570
‫So here's what happened.

71
00:04:53,960 --> 00:04:56,360
‫We updated the transaction we have did in a row.

72
00:04:56,900 --> 00:04:58,370
‫Technically, we.

73
00:05:00,070 --> 00:05:02,500
‫Acquired an exclusive lock on the role.

74
00:05:03,070 --> 00:05:12,640
‫It's an update lock, so the rule is technically lock seat one is locked by the transaction implicitly,

75
00:05:12,640 --> 00:05:14,860
‫not explicitly like the way we did it.

76
00:05:14,920 --> 00:05:15,880
‫It's a different way.

77
00:05:15,880 --> 00:05:18,700
‫Explicitly when you say, Oh, I want to select for update, I don't.

78
00:05:18,700 --> 00:05:20,950
‫I'm going to do stuff I don't want to do.

79
00:05:20,970 --> 00:05:24,070
‫I don't want anyone to touch my stuff for you, right?

80
00:05:24,400 --> 00:05:29,650
‫So you're assuming the database will acquire this and will not do anything for you.

81
00:05:30,130 --> 00:05:34,510
‫In this case, the database actually acquired a lock on the role for you.

82
00:05:34,600 --> 00:05:34,820
‫All right.

83
00:05:34,840 --> 00:05:36,190
‫So the role is now look.

84
00:05:36,370 --> 00:05:43,240
‫That is why when I hit enter here that the transaction number two for REQ will be blocked.

85
00:05:44,020 --> 00:05:45,280
‫Now, why is it blocked?

86
00:05:45,730 --> 00:05:47,050
‫What exactly happened here?

87
00:05:47,740 --> 00:05:53,620
‫I want you to answer these kind of questions and before you kind of pause the video and then answer

88
00:05:53,620 --> 00:05:57,250
‫these questions now that you're in lecture, I don't know, 65 or 70.

89
00:05:57,640 --> 00:06:00,220
‫You must understand these fundamentals.

90
00:06:00,550 --> 00:06:03,570
‫You must understand the isolation level Reid committed.

91
00:06:04,000 --> 00:06:09,070
‫You know, Reid uncommitted, uh, raw locks all these stuff.

92
00:06:09,070 --> 00:06:10,810
‫You must understand it before.

93
00:06:11,320 --> 00:06:14,480
‫If you're here, you probably do because you watched the previous thing.

94
00:06:14,500 --> 00:06:16,310
‫So now what happened?

95
00:06:16,960 --> 00:06:23,310
‫We did a work loss because we want to update something we did as an index search idea.

96
00:06:23,320 --> 00:06:24,710
‫Call one and his book Equal Zero.

97
00:06:24,730 --> 00:06:26,590
‫So what did what does the database do?

98
00:06:26,620 --> 00:06:27,430
‫Well, it depends.

99
00:06:27,730 --> 00:06:30,790
‫I I believe we have a primary key index.

100
00:06:30,790 --> 00:06:33,280
‫Will Bosca's don't have primary keys, but you get my point.

101
00:06:33,370 --> 00:06:37,060
‫It's a secondary key that points to the heap directly, but it's an index.

102
00:06:37,240 --> 00:06:45,580
‫So Postgres Chris did a B tree traversal on the ID index to find ID number one.

103
00:06:46,540 --> 00:06:56,310
‫It found the tuple I.D. and now it detected that this tuple is locked because of this transaction,

104
00:06:56,620 --> 00:07:01,480
‫lock management of post-crisis say, Hey, wait a second, this this this thing is locked.

105
00:07:01,930 --> 00:07:08,680
‫I'm not supposed to touch it, so I'm going to pull this until because I'm about to update it or I can't

106
00:07:08,680 --> 00:07:13,240
‫update it because someone is actually, uh, locking it right?

107
00:07:13,300 --> 00:07:18,110
‫So you can't even you can read it, which we did, right, but we cannot update.

108
00:07:18,340 --> 00:07:22,960
‫So now the question is, if we read this right, we didn't go to the heap.

109
00:07:22,960 --> 00:07:24,010
‫We're still in the index.

110
00:07:24,610 --> 00:07:27,460
‫If we did go to the heap, right?

111
00:07:27,700 --> 00:07:30,610
‫What do you think the value will be of the booked right?

112
00:07:31,860 --> 00:07:34,290
‫The value of the book here is actually.

113
00:07:35,790 --> 00:07:36,320
‫Zero.

114
00:07:37,440 --> 00:07:38,730
‫It's not booked yet.

115
00:07:39,030 --> 00:07:39,810
‫You might say I say no.

116
00:07:39,960 --> 00:07:41,250
‫We just excuse the transaction.

117
00:07:41,610 --> 00:07:46,110
‫No, yes, we executed the transaction, but this transaction is isolated.

118
00:07:46,320 --> 00:07:47,880
‫It started the same time.

119
00:07:48,040 --> 00:07:48,390
‫Right.

120
00:07:48,660 --> 00:07:52,950
‫So this guy still sees the role as unblocked.

121
00:07:52,950 --> 00:07:56,340
‫So that's why it managed to actually fetch that role.

122
00:07:56,730 --> 00:08:04,080
‫So now we fixed that role, we found that this role is actually, you know, an booked so I can actually

123
00:08:04,080 --> 00:08:04,400
‫fidget.

124
00:08:04,410 --> 00:08:08,430
‫But when I tried to update it, I failed because there is a low lock on it.

125
00:08:08,880 --> 00:08:12,660
‫Now what happened if I commit my transaction here?

126
00:08:13,410 --> 00:08:15,950
‫When I commit my transaction, two things will happen, right?

127
00:08:16,770 --> 00:08:22,860
‫It's like it really depends on where you are at the mercy of the database implementation.

128
00:08:22,980 --> 00:08:26,870
‫I'm sorry you're at the mercy of the database implementation at this end.

129
00:08:27,210 --> 00:08:27,480
‫Right?

130
00:08:27,780 --> 00:08:32,520
‫Because the more they do commit, the roll will be locked.

131
00:08:32,610 --> 00:08:34,680
‫I mean, there will be released, right?

132
00:08:35,250 --> 00:08:37,970
‫I'm going to change these values and make them committed.

133
00:08:37,980 --> 00:08:45,900
‫So the rule now will belong to Hussein and the book value is going to set to one.

134
00:08:46,860 --> 00:08:49,590
‫So what will happen on this transaction, right?

135
00:08:50,160 --> 00:08:51,150
‫Will that transaction?

136
00:08:51,150 --> 00:08:55,920
‫Because remember the transaction already seen the roll on booked?

137
00:08:56,460 --> 00:08:58,860
‫Is that even a word on what not booked, right?

138
00:08:59,520 --> 00:09:00,660
‫So what will happen here?

139
00:09:01,950 --> 00:09:03,230
‫Well, let's see what happened.

140
00:09:04,490 --> 00:09:11,780
‫We committed that and immediately on the posters on the other end, it did not updated which which is

141
00:09:11,780 --> 00:09:12,740
‫exactly what we want.

142
00:09:12,740 --> 00:09:14,690
‫That's the desired behavior, but why?

143
00:09:15,110 --> 00:09:19,100
‫If you really think about it, Paul here did a trick, right?

144
00:09:19,310 --> 00:09:19,940
‫Slip off.

145
00:09:19,970 --> 00:09:23,960
‫Yes, it is a little bit earlier, right?

146
00:09:23,990 --> 00:09:26,630
‫So Bosca's did the trick here.

147
00:09:26,990 --> 00:09:33,470
‫It actually refreshed the rule to look at the final result.

148
00:09:34,250 --> 00:09:34,700
‫Right?

149
00:09:35,660 --> 00:09:41,180
‫And then when it detected that, oh, the final results actually is booked equal zero.

150
00:09:41,420 --> 00:09:43,340
‫No, it's not right.

151
00:09:43,370 --> 00:09:43,880
‫Why?

152
00:09:44,180 --> 00:09:52,310
‫Because when we did that at the world that actually was running the the the row was actually, in fact,

153
00:09:52,310 --> 00:09:52,910
‫not booked.

154
00:09:53,180 --> 00:09:59,930
‫But the moment this transaction committed now, the isolation level changed because this is read, committed,

155
00:10:00,140 --> 00:10:00,470
‫right?

156
00:10:00,710 --> 00:10:04,850
‫I'm allowed to read committed values that are here.

157
00:10:05,150 --> 00:10:14,180
‫So now only if your isolation level is read committed and the database actually refreshes the values

158
00:10:14,180 --> 00:10:15,950
‫of the row up uncommitted.

159
00:10:16,280 --> 00:10:20,870
‫So now you can actually read the values here and make the decision.

160
00:10:21,940 --> 00:10:22,660
‫As a result.

161
00:10:23,330 --> 00:10:23,540
‫Right.

162
00:10:24,050 --> 00:10:32,980
‫So and what I'd like to add is something I forgot to add here is I, I remembered after editing the

163
00:10:32,980 --> 00:10:36,490
‫video as post-cruise actually stores.

164
00:10:36,730 --> 00:10:46,210
‫The knowledge about lock information in the role itself is just another field in the row.

165
00:10:46,220 --> 00:10:50,410
‫And you know, these columns live where obviously in the heap, right?

166
00:10:50,770 --> 00:10:57,370
‫So when we go to the heap to fetch the is book value, that's when we looked at the lock information

167
00:10:57,370 --> 00:11:03,130
‫and we obviously jump to another sort of data structure to fetch the value that is actually locked or

168
00:11:03,130 --> 00:11:03,430
‫not.

169
00:11:03,820 --> 00:11:04,150
‫Right.

170
00:11:04,360 --> 00:11:10,590
‫That's when the that the database, the transaction decided to to block itself, right?

171
00:11:10,750 --> 00:11:12,910
‫So that's that's that jump is very critical.

172
00:11:13,120 --> 00:11:20,020
‫And when the row has been released, what happened here is Bosca's refreshed the heap value.

173
00:11:20,060 --> 00:11:24,430
‫It actually said, OK, yeah, I'm own, I'm blocked, but I cannot just resume.

174
00:11:24,610 --> 00:11:28,660
‫I have to kind of re execute the query in a sense, right?

175
00:11:28,900 --> 00:11:30,190
‫To see the actual values?

176
00:11:30,190 --> 00:11:32,380
‫Yeah, I have at a given point.

177
00:11:32,380 --> 00:11:34,120
‫It was not book, but now how about now?

178
00:11:34,120 --> 00:11:35,680
‫Is it actually booked, right?

179
00:11:36,070 --> 00:11:38,440
‫And yeah, depends on the implementation.

180
00:11:38,440 --> 00:11:40,150
‫And that's what I wanted to clarify, right?

181
00:11:40,510 --> 00:11:42,010
‫This is how postscript that is it.

182
00:11:42,310 --> 00:11:45,250
‫My sequel does it completely differently, right?

183
00:11:45,430 --> 00:11:47,530
‫SQL Server does it completely differently.

184
00:11:47,540 --> 00:11:48,490
‫They look in memory.

185
00:11:48,610 --> 00:11:50,440
‫And can you guarantee the same result?

186
00:11:50,650 --> 00:11:51,580
‫Absolutely not.

187
00:11:51,760 --> 00:11:53,530
‫You might get lucky, right?

188
00:11:53,770 --> 00:11:58,240
‫If you execute this query and you see that SQL Server Michael does it this way.

189
00:11:58,480 --> 00:12:04,900
‫But I wouldn't unless you absolutely sure that this is how the database implemented this stuff.

190
00:12:05,410 --> 00:12:09,700
‫Now you're you're at the at the bowels of the database implementation.

191
00:12:09,710 --> 00:12:15,520
‫And basically, this is the power that I want you to have as an engineer, as someone who actually is

192
00:12:15,520 --> 00:12:19,690
‫learning database engineering, just understand that this is all code.

193
00:12:19,960 --> 00:12:22,450
‫You know, it's all written by human.

194
00:12:22,930 --> 00:12:27,640
‫They make decisions, they get emotional, they write one piece of code, they get emotional, they

195
00:12:27,640 --> 00:12:30,640
‫write another piece of code that gets broken.

196
00:12:30,640 --> 00:12:31,650
‫You know, nothing's perfect.

197
00:12:31,810 --> 00:12:34,090
‫Whatever we're looking at is written by human, you know?

198
00:12:34,430 --> 00:12:39,760
‫And this is what I wanted to break, because when I first learned database engineering around 10 nine

199
00:12:39,760 --> 00:12:46,900
‫years ago, I was always, you know, getting intimidated by all these terminologies.

200
00:12:46,900 --> 00:12:52,360
‫But once you really, really, really understand what's going on, you're basically unstoppable because

201
00:12:52,360 --> 00:12:55,870
‫you understand you're going to ask the right questions, guys.

202
00:12:56,080 --> 00:13:02,080
‫And when you ask the right questions, if someone actually understand, they can reply back to you and

203
00:13:02,080 --> 00:13:05,020
‫that will guide you to the answer.

204
00:13:05,020 --> 00:13:09,130
‫You know, don't take things as surface value.

205
00:13:09,130 --> 00:13:14,200
‫Always understand, always ask questions and the nature of the questions you ask.

206
00:13:14,290 --> 00:13:19,750
‫And I start to see some people in this course actually ask these kind of questions, you know, dig

207
00:13:19,750 --> 00:13:20,200
‫deep.

208
00:13:20,200 --> 00:13:24,610
‫They kind of dig deep and try to, OK, why is it doing this way?

209
00:13:24,640 --> 00:13:25,830
‫Why is it not done this way?

210
00:13:25,840 --> 00:13:27,070
‫This is the great questions.

211
00:13:27,070 --> 00:13:29,440
‫You know, nothing is perfect.

212
00:13:29,650 --> 00:13:32,310
‫Nothing, absolutely nothing is perfect, though.

213
00:13:32,320 --> 00:13:39,730
‫You see no anything that is there has been done by human and human or imperfect by nature, right?

214
00:13:39,970 --> 00:13:47,410
‫So I know this got philosophical, but I really want you to understand this, you know, just any ask

215
00:13:47,410 --> 00:13:49,750
‫the right questions, you're going to get the value.

216
00:13:50,020 --> 00:13:52,570
‫And as a result, you're going to find the answer, right?

217
00:13:52,840 --> 00:13:58,390
‫All right back to the video in that case, detective, that oh, the role is actually, oh yeah, it's

218
00:13:58,540 --> 00:13:59,730
‫ID number one.

219
00:13:59,740 --> 00:14:03,130
‫That's true, but it's actually it's booked, Ryan.

220
00:14:03,340 --> 00:14:09,230
‫So that that that statement is false, which will break that condition.

221
00:14:09,790 --> 00:14:16,390
‫I cannot guarantee what will happen in Bosca's if, for example, both of these are actually indexed.

222
00:14:16,390 --> 00:14:25,090
‫You created a combined index where those two guys are actually index and you search index and you found

223
00:14:25,390 --> 00:14:28,540
‫the values indexed right?

224
00:14:28,540 --> 00:14:35,680
‫And you find that you did a search before that right and you found that the the row is actually not

225
00:14:35,680 --> 00:14:36,040
‫booked.

226
00:14:36,640 --> 00:14:41,170
‫The Bosca's might decide to say, Hey, it's not booked, let's go ahead and go ahead and commit.

227
00:14:41,200 --> 00:14:44,350
‫You will never go to the heap to see the actual updated value.

228
00:14:44,680 --> 00:14:45,580
‫Or maybe a whoa.

229
00:14:45,730 --> 00:14:46,000
‫Right?

230
00:14:46,300 --> 00:14:52,150
‫So that's why I'm saying that this will definitely work, but you really need to understand why it actually

231
00:14:52,150 --> 00:14:52,600
‫worked.

232
00:14:52,990 --> 00:14:56,800
‫Not because, uh, we're filtering on this.

233
00:14:56,810 --> 00:15:02,470
‫No at work because of the database semantics and the acid transactions.

234
00:15:02,470 --> 00:15:08,140
‫And there are so many other things that you really need to understand in order to get this.

235
00:15:08,230 --> 00:15:09,730
‫So, yeah, definitely you can use this.

236
00:15:10,120 --> 00:15:17,680
‫But the down the down side of using this approach is, first of all, you need to be in committed mode

237
00:15:17,680 --> 00:15:18,370
‫to do that.

238
00:15:18,580 --> 00:15:21,190
‫Second of all, you really don't have.

239
00:15:21,520 --> 00:15:27,430
‫Much control when it comes to this transaction, you only you're at the mercy of that particular update

240
00:15:27,430 --> 00:15:27,970
‫statement.

241
00:15:28,270 --> 00:15:31,270
‫But what if you, for example, want to do multiple things right?

242
00:15:31,930 --> 00:15:32,410
‫I want to.

243
00:15:32,710 --> 00:15:34,230
‫I want to book that.

244
00:15:34,240 --> 00:15:34,780
‫I want to.

245
00:15:34,780 --> 00:15:37,090
‫I want to take a look on that role.

246
00:15:37,480 --> 00:15:37,870
‫All right.

247
00:15:38,530 --> 00:15:41,800
‫And then do multiple things in this case before I commit.

248
00:15:42,940 --> 00:15:48,280
‫So you can with explicit looking, you have a little bit more lenient way, right?

249
00:15:48,310 --> 00:15:55,030
‫You don't your database doesn't do like implicit things for you to behind the scenes that you don't

250
00:15:55,030 --> 00:15:56,030
‫understand, right?

251
00:15:56,320 --> 00:16:00,670
‫So I kind of prefer the for update approach, but this definitely work.

252
00:16:00,670 --> 00:16:04,720
‫And obviously, as as some people said, this is kind.

253
00:16:07,700 --> 00:16:08,510
‫More efficient.

254
00:16:09,350 --> 00:16:17,630
‫I'm hesitant to say that, but uh, it's just that in this approach, we're we're also taking a lock,

255
00:16:17,630 --> 00:16:25,610
‫but the lock is is is is a database internal lock, not a user lock that we have maintained, right?

256
00:16:25,610 --> 00:16:31,480
‫So there will be a lot of cases where you take a lock that you did actually didn't need to take, right?

257
00:16:32,000 --> 00:16:38,060
‫But again, at the end of the day, Postgres and other database system is a pessimistic, you know,

258
00:16:38,630 --> 00:16:42,860
‫pessimistic concurrency control, which means they always take a look.

259
00:16:43,010 --> 00:16:43,310
‫Right?

260
00:16:43,310 --> 00:16:48,650
‫They always take the umbrella with them as as I always say that they always they can look.

261
00:16:48,650 --> 00:16:54,830
‫And at the end of the day, yeah, maintaining managing locks are expensive.

262
00:16:55,190 --> 00:17:02,810
‫But when you manage the locks right, you take that you'll be protected from these kind of situations.

263
00:17:03,200 --> 00:17:08,300
‫Other approach where you become optimistic on cancer control, where, hey, I'm not going to take a

264
00:17:08,300 --> 00:17:09,080
‫lock, right?

265
00:17:09,260 --> 00:17:13,190
‫But at the end of the transaction, I'll detect the change and feel the transaction.

266
00:17:13,430 --> 00:17:18,800
‫I prefer pessimistic personally because, you know, I don't want to retry my transactions.

267
00:17:19,010 --> 00:17:21,590
‫I know NoSQL databases always prefer that approach.

268
00:17:21,770 --> 00:17:22,670
‫Nothing wrong with that.

269
00:17:22,700 --> 00:17:24,650
‫I just a personal preference.

270
00:17:24,650 --> 00:17:28,160
‫At the end of the day, I don't like my transaction if I want to.

271
00:17:28,990 --> 00:17:32,480
‫If my transaction will fail, I want it to fail for the right reasons.

272
00:17:32,900 --> 00:17:33,320
‫I want to.

273
00:17:33,380 --> 00:17:35,630
‫I don't want it to fail because of a concurrency problem.

274
00:17:37,550 --> 00:17:41,000
‫Because that's just another condition in your application that you have to take care of.

275
00:17:41,030 --> 00:17:41,350
‫All right.

276
00:17:42,020 --> 00:17:43,130
‫I think that's it for me today.

277
00:17:43,610 --> 00:17:45,170
‫Hope you enjoyed this video Uh.

278
00:17:45,590 --> 00:17:48,080
‫And uh, enjoy the course.

279
00:17:48,770 --> 00:17:49,080
‫You may.