‫To spend a few moments to discuss the difference between optimistic concurrency control and pessimistic
‫currents, concurrency control, so optimistic because of control and pessimistic concurrency control
‫is so critical.
‫It's it's basically the atomic level of how you pick which path decides basically what database you're
‫going to run.
‫Let's discuss that today.
‫I'm going to talk about optimistic versus pessimistic.
‫If you don't want to support any control at all, you want to build a single user database that nobody
‫else is going to add.
‫Just one single user is going to slam and edit this stuff, right.
‫That is no multi users.
‫There is no ability to to do transactions and there is no ability to do isolation.
‫You know, you're not, you know, trying to isolate anyone from your reads all rise, for that matter.
‫So if you do that, if you don't do that, you don't have to worry about anything.
‫You kind of click off this video.
‫But if you do, which most databases do post physical Mongo DB, most databases need to support multiuser
‫and don't think of multiuser as Web users.
‫We're talking about multiple transactions that doesn't have to come from the same user.
‫Let's say it say there are a thousand viewers.
‫Those are technically multi user, but to the database they might come from the same database instance
‫user.
‫You're not going to create a different database user for every single web interface, right?
‫You don't do that.
‫So but but the idea of concurrency is there is the key here.
‫And how do you forget about all this mumbo jumbo that we're talking about?
‫Concatenating control and all this stuff?
‫How would you stop and think about it?
‫Forget about all the papers that I've been writing about database systems and take this question and
‫try to answer it yourself, how would you prevent someone from changing a value that you just change
‫and you want to persist?
‫How do you do that?
‫So you started a transaction and you changed some value.
‫How do you then prevent someone else from changing that value?
‫Because that's dangerous, right?
‫Unless that value is committed and the other transaction starts.
‫It should always see that latest change and then have the idea of changing it.
‫If you allow this update to happen, then there is this thing as called a lost update.
‫You you made a change, but you turn around and it's lost.
‫There's a lot of misconception about this because a lost update only happens in the same transaction.
‫You wrote something, right?
‫You didn't commit yet any attempt to read it and use all their.
‫That is dangerous because basically it causes corruption.
‫This is not the last update that I'm going to describe.
‫You start a transaction, you change a field value, you commit and then you read it and it's not there.
‫That is not a lost transaction.
‫Why?
‫Because after you commit, someone else could have started the transaction, changed the field and then
‫committed and then you read that committed value that that someone that transaction that changed.
‫So that's technically not a loss of Diso measuring loss, but it is very hard.
‫But effectively, it is.
‫It is almost like you're you're just reading this transaction history.
‫Right.
‫So how would you build a system that prevents these kind of things?
‫A classic example is to use something called locking.
‫Hey, I'm updating this row.
‫I'm going to lock it.
‫Why?
‫Because I don't want anyone to change that value as long as my transaction is running.
‫I want to go my own thing.
‫I'm doing update to other fields, to other columns, to other tables.
‫But by that value shouldn't really change.
‫As long as you touched it, you changed it.
‫You don't want it to change during your transaction.
‫That's the definition of lost update, right?
‫How do you do that if you write that about you, you can say, look, that you can tell the database
‫to lock it and by definition, this is a global concept that tells any other transaction that says,
‫hey, if another transaction attempt to write to this law, right to this row, that particular field
‫we're talking about roads, not columns.
‫You're right, there is no concept of column based block, although it's fun.
‫But there isn't there there's only road blocks for simplicity.
‫You can build something like that, but it's so expensive.
‫So I like the road.
‫So other person want to update another field of the same road.
‫They can't do that.
‫And you can define what that means.
‫Can't what does that mean?
‫You can fail or you can make them wait.
‫And that's what locks do.
‫What?
‫This model is called pessimistic because you are so pessimistic that you don't trust anyone.
‫You just say, I'm going to lock this thing and I'm just going to prevent anyone from changing this
‫thing.
‫And I don't care of anyone didn't because someone you might you might just go through the whole transaction
‫and nobody actually try to touch your.
‫Roll, right?
‫But do you think you're pessimistic, it's like taking your umbrella every time you go out regardless,
‫that's pessimistic, right?
‫Because you think it's going to rain.
‫Don't get me wrong, I love rain.
‫But if you don't like rain and you think it's going to rain, you're always going to take the umbrella
‫of you.
‫I'm talking when you leave the car, not in the car, of course, you can have it in the car there,
‫but even if you go to the grocery store, you can go for a walk.
‫You take the umbrella with you all the time.
‫That's pessimistic.
‫Concurrency control, right?
‫If it rained, you have a rare right, you might say, and what's wrong with is that it seems like this
‫is the best approach ever.
‫Always take the umbrella with you.
‫The umbrella is heavy, the umbrella cost, strength ride.
‫My skinny arm cannot handle them, but I love locks all the same way.
‫Locks are expensive.
‫Locks need management.
‫You need to manage locks that are free.
‫Living locks are free.
‫They are not.
‫Nothing in this world is free.
‫You've got to understand that everything is a program and everything needs to be coded and locks need
‫to be coded.
‫And they are so -- expensive.
‫They are so God dang hard to get right.
‫And now you can get to this like, oh, that is the ideal Frole level log's.
‫There is an ideal table log's.
‫There is that ideal page log's.
‫Right.
‫And you can define what all these mean a table look.
‫I mean, hey, don't don't allow anyone to touch this or table or look.
‫I mean, don't allow anyone to update this.
‫Now, I'm going to ask you this question.
‫How would you implement rollover level locks?
‫Could be another table, right, some some simple example, keep in memory a running and running ledger
‫of all the rows that have been locks.
‫Some of you might say that's dumb.
‫Why?
‫Because what if a transaction updater million ro your memory is going to need to manage a million wrong?
‫Oh yeah.
‫Well you have to have a million.
‫Our memory is memory free.
‫No, memory is not free.
‫My friend's memory is not free.
‫So lock management is expensive.
‫That's French, by the way, for expensive if you didn't get it.
‫Lock management is expensive, especially euro level locks.
‫That's why most databases try not to implement rollover locks.
‫And we can get into this role management and dive deep into how each database manage locks.
‫And that's how you pick a database.
‫By the way, guys, it's not because what is faster once it really depends on on you and what do you
‫need?
‫I still didn't come to the other.
‫This is what talk is, still pessimistic or pessimistic.
‫And I say good luck management.
‫So difficult.
‫Difficult, right.
‫And then so so some some databases like SQL Server, for example, they manage locks in memory that
‫the more put raw locks in memory.
‫You're going to blow up your memory very quickly so you can.
‫So SQL Server have this idea of something called lock escalation where says, OK, I'm about to lock
‫seven thousand rows.
‫You know what?
‫If you're touching this many rows, I don't trust you.
‫I'm going to save memory and I'm going to lock I'm going to put one lock on the entire table.
‫Yikes.
‫Yes, you just lucky that timetable.
‫Right, which is which is sometimes it is memory efficient.
‫But you cause more weight on other transactions and those transactions are low running that up the toll
‫roads, you are doomed.
‫My friends, you're.
‫So as it goes over, you can tune this.
‫That's where database tuning comes in.
‫Other databases, which is my favorite PostgreSQL manage rows, row locks.
‫In desk, and you might say that that's just dumb, because it that that I have to write a desk to lock
‫the table.
‫Well, if you think about it, if you were right to a role, aren't you writing to ask anyway?
‫How about we just lock in there?
‫OK, so they are they are smarter than I have time to explain the details of that.
‫I don't even get the level of details.
‫They are these in hints.
‫They they manage all this stuff.
‫This is what interested me.
‫The I love this stuff.
‫I love to talk about these different decisions that engineers make based on like if you go this way,
‫you go this way.
‫If you go this way, then it goes right.
‫You you can build completed.
‫That's where databases go completely different path based in the simple decision that they make a branch
‫decision.
‫So Postgres don't put the law because of memory, but they do it on desk.
‫So that means they have more IO SQL Server on the other hand, put it on memory, but you have like
‫escalation and all that stuff.
‫Let's stop talking about pessimistic gun control and let's go to the lock free optimistic ocasek.
‫And we are optimistic people.
‫We are open minded.
‫We like life and we are pro humanity.
‫I don't know.
‫I'm saying we are so optimistic that we say, sir, you can update this field, you can update this
‫role, and we're not going to unlock it.
‫Why?
‫Because chances that some other transactions are going to be updated are really low.
‫Let's be blips.
‫Let's be optimistic a little bit.
‫Don't take that -- umbrella with you if it rain well.
‫You can just go to the store and buy one or just throw out, OK, OK, you get a little bit wet, who
‫cares?
‫So that's optimistic because the control.
‫So what does that mean?
‫That means if you update a rule, just do your own thing and then commit.
‫But during the commit, we're going to do a slight Beeny check at the committee level.
‫We're going to say if the rule change underneath you, we're going to fail your transaction.
‫Some of you might cringe at that, I understand.
‫But hey, just try it, you got to go get go change your clothes, son.
‫It's OK.
‫Who cares?
‫It's just little water.
‫It's a little bit of water.
‫So if it fails, just roll back, fail, give the user a little bit of a beautiful error that says,
‫OK, just chill.
‫It's not a big deal.
‫And Mongo DB, as is this model uses this thing that's called Wire Tiger and that I'm researching more
‫about why Target is exclusively it looks like it's an exclusively lugg structure military and designed
‫around the idea of having it uses multicore uses, tries to suck the life out of your SEIP multiple
‫core CPU as much as possible, try to utilize them to the to the maximum efficiency.
‫And that's what they claim.
‫I'm just reading.
‫Right.
‫And the most important part is they use optimistic concurrency control.
‫They say, well.
‫I don't want to deal with the headache of managing my locks.
‫I don't want to take my umbrella with me everywhere I go.
‫Ambarella Zahavi.
‫Stop taking your umbrellas with you and instead just be optimistic, my friend, be optimistic.
‫Why are you like this?
‫Why?
‫It's OK if it fails to try your transaction, so now you put some more burden on the client side to
‫retry the transactions.
‫And most developers might be familiar with this model says, OK, yeah, I know I get this very all
‫the time, just really trying, which is doesn't sound like a big deal.
‫Yeah, a little bit of code at your end.
‫And to be honest, I don't I don't have a favorite.
‫I just think every use case really depends on on how which path to take.
‫You want to take the optimistic path or you want to take the pessimistic path.
‫Right.
‫Usually usually databases don't call themselves pessimistic.
‫You're not going to go to Bosco's and you can read their book is all we're using pessimistic anti-gun
‫control.
‫No, no, nobody's saying that because that's kind of a negative way, right?
‫Nobody writes that.
‫But you are going to see mongerer talk about all this optimistic as it gets, because optimistic is
‫way better than pessimistic.
‫Right.
‫But technically speaking, Postgres, MySQL, SQL Server, Oracle, even, they are pessimistic.
‫This is GANDIL locks on and we're going to lock this stuff.
‫All right.
‫Obviously, I might have missed some of the things.
‫What do you think is best in your personal opinion?
‫Let's just have a discussion and have a discussion.
‫What what do you think is.
‫But I don't think there is a better way, to be honest.
‫It's like I kind of prefer pessimistic because it's OK.
‫I'm a pessimistic guy.
‫It's like luck, my stuff.
‫Don't touch it.
‫Don't touch my stuff.
‫Don't touch meyerrose.
‫As long, but but also I think of all of these management of the locks, right?
‫That's why I prefer Posterous, right?
‫Yeah, you can see the right amplification results of postscripts because of all this managing the logs
‫and the rights and all that stuff becomes a little bit too much sometimes.
‫But if it's a cost you have to pay compared to memory, you might say, hey, I'm going to use SQL Server,
‫I'm going to put all my lacson on memory.
‫I'm going to have to terabytes Wolfram.
‫All right, guys, I'm going to see in the next one you guys, the awesome by.