‫Very simple stuff, jump to the second one, isolation, I skipped consistency because we're going to
‫go back to consistency and later after isolation, this is one of the longest and in my opinion, one
‫of the most critical.
‫Properties software engineer really should understand, really should understand isolation.
‫What is isolation and isolation as.
‫To be isolated is I want to stay alone and I don't want to interact with the world right.
‫OK, let's take this in the transaction.
‫A transaction is to to have a transaction that I was late.
‫That means an in-flight transaction while I'm executing a transaction.
‫Can this transaction see other changes made by other transactions that are in flight?
‫OK, so that's what it means.
‫I am now executing my stuff.
‫Can I see other stuff people are making and is that OK?
‫Right, am I isolate from the other ward and it's really up to the implementor, the software engineer
‫here to adjust this knob of isolation that we're going to talk about?
‫Do you want no isolation?
‫I don't care.
‫You can change anything you want, and I'm going to read whatever you change.
‫And that's may be OK, but in some cases it is.
‫No, no, sir.
‫OK.
‫We're going to talk about that isolation I talk about as a lack of isolation, you get in, get these
‫read phenomena, I don't like how the fancy name for some reason is this.
‫You're going to get some read ugliness, read weirdness.
‫Right.
‫Some weird stuff while you're reading transactions and as a lack of isolation.
‫We're going to talk about that recently reading Phenomenas.
‫This is there to read and all that stuff.
‫And we're going to talk about isolation levels that a database can implement to get rid of the Reid
‫phenomenas.
‫So without isolation, you get a bunch of Reid phenomenas.
‫We implement isolation levels to fix those problems.
‫OK, let's talk about boom.
‫Let's talk about the Reid phenomenon.
‫We have three.
‫I added the fourth one.
‫I don't think it's a Reid phenomena.
‫It's one of the bad things that can happen as a side effect.
‫But I added it anyway.
‫So the first one, dirty Reid, dirty Reid, essentially, as I am.
‫And we saw that right.
‫I don't think we saw that.
‫But it's actually dirty.
‫Reid what it is essentially is like I am in for a transaction and some other transaction made a change.
‫That transaction did not commit that chant.
‫And I read that change.
‫So any minute that transaction can roll back that change and I just write a bad value, a dirty value
‫that hasn't been committed.
‫That's what it means is not repeatable.
‫Reid's we're going to talk about that.
‫It's like I write a value that is being committed.
‫Right.
‫Not necessarily committed or not.
‫Right.
‫But then I turn around and my same transaction and I read the same value, whether the same query or
‫other query that give me the same path to that value, like a range query.
‫And I did not get the same result.
‫So my results, my rates were not repeatable in my same transaction.
‫Some some users are fine with that.
‫Some users are not fine with that.
‫We're going to talk about that.
‫OK, Fantome rates.
‫I inserted a new another transaction inserting a new record and I picked that up.
‫What I shouldn't have picked that up is usually happens with range queries or lost updates.
‫Like when when you started to change something.
‫Right.
‫You change in transaction, you change a value and some other transaction overwrote your value before
‫you even commit it.
‫So you're going to commit a wrong value.
‫So you just lost your update essentially.
‫OK, and these are the four phenomenas.
‫Let's talk about each of one.
‫One of them read Doctorate's.
‫Let's talk about dirty reads that.
‫So we talk about it, read it or Dirty reads.
‫I am going to read a value that hasn't been committed by another transaction.
‫I have a sales table.
‫Those are two products.
‫Product one Procter.
‫There's a quantity of sales is broken, has sold ten units at a price of five dollars product to twenty
‫four.
‫And I am asked to write a query to produce a report of my sales.
‫So what I'm going to do is select the entire thing and some of those guys.
‫So product one has sold what fifty dollars product to us.
‫Give us like eighty dollars and then at the end I'm going to just view the sum of all the sales look.
‫Very simple stuff.
‫So to do that transaction, even if we don't really need to commit or change, you can also begin a
‫transaction.
‫Right.
‫And that's, and that can have its value.
‫I'm going to begin a transaction selecting the product ID and then multiplying the quantity times a
‫price, obviously, and then from sales that will give me what we just saw it for, like one fifty per
‫item.
‫That sounds good.
‫But here's the trick.
‫While this is executing another transaction, just begin.
‫Right, and let's talk another quantity, it just added some some someone made us another sale, right.
‫And they updated the sales report where the bid is equal one.
‫So now we just increase the quantity by five.
‫That's pretty good.
‫But I don't know if it's good because we just read this now.
‫I just have an old value and might be that.
‫OK, but let's see what will happen.
‫Right.
‫So I didn't commit this transaction to yet.
‫Right.
‫While I'm doing that, I did the second quarter, which is select some quantity times price, which
‫is literally this time this plus some 20 plus for it.
‫But guess what?
‫This is giving me a wrong result.
‫This is now reading the dirty value that never been committed yet.
‫This guy is reading it.
‫And that's a dirty read, right?
‫We're reading the bad value.
‫Why?
‫Because it's leading to bad results in 50 plus eight is one theory.
‫But I am showing the report one fifty five so you can see dirty reads are bad.
‫OK, I'm not saying they are always bad.
‫It's up to you if you can tolerate that or not, if you're building and stick around, for example,
‫you don't really care for the number of likes, doesn't matter the number of users who actually like
‫the picture.
‫Right.
‫So you might there is a price for everything.
‫Guys, we're going to talk about that.
‫You can I just say, yeah, I'm I'm going to implement the best isolation ever again.
‫So there's a first rate phenomenon and we commit the transaction, obviously.
‫But it's it's useless.
‫We got better, though, so that's dirty.
‫Let's talk about.
‫None repeatable read like a non repeatable read is, as we said, read that I'm going to read something
‫in my transaction and I'm going to read it again.
‫I'm getting two different values, you might say.
‫Why are you reading the same values twice, you idiot?
‫Why are you doing that?
‫You just read it.
‫Why are you reading twice?
‫There are believe me, when you writing code, when you're writing a transaction, you will need to
‫do that sometimes.
‫And we're going to show you an example I had to think about.
‫An example is but there's an example.
‫Same thing, right?
‫Beginning the transaction.
‫I'm going to select the account of report.
‫Right.
‫That sounds good.
‫Fifty and eighty three.
‫And then this is the total of this is one thirty.
‫But guess what?
‫A transaction began at the same time.
‫And it updated account sounds like it's the same transaction, but here's the little bit different I
‫did hear.
‫I actually changed that.
‫Now it's 15 and I also committed that's the difference between the first one and that.
‫So whatever I'm doing next is actually not a dirty read.
‫Right.
‫I'm reading a committed value.
‫It's a legit value, but the question is, should I read that committed value or not?
‫OK, so to me, if this has been committed, it's a legit value.
‫It's not like the previous one where someone actually rolled back.
‫Right.
‫Or could could be rolled back.
‫It's not a dirty value.
‫It's an actual committed value.
‫So I'm going to turn around, do the sum, but now I'm going to get a better result.
‫Despite me committing, I get a bad result.
‫So having it committed or not doesn't really matter.
‫Now, I got this phenomena of a unrepeatable read.
‫In this example, because their first read gave me that some one felty, the secondary gave me a different
‫sum.
‫So that's a non repeatable read in itself.
‫OK, so not a bit of a read.
‫So we read this first we get a result, then we read it again.
‫We got a different result.
‫So that's another bit of read.
‫We can discuss ways to fix this.
‫How can you fix this?
‫We can talk about things, how to fix that nonprofitable, read, write and obviously going to come
‫out of that phantom read your phantom.
‫Right.
‫So what Fantham reads is actually interesting because here's here's an example of Fantham read.
‫Let's say I began the transaction, do the same thing, selecting count and then some the whole thing
‫would get one 30, 50 sales.
‫And at the same time, here's the other transaction I didn't actually update it just inserted record.
‫And this incident, new cell of a totally different product, and now you committed that, so it's changed.
‫It's in the database and in the same time that the first transaction is still executing, I am selecting
‫all the current prices from sales.
‫That is a bad sign because now you just accounted for product three on the first sheet of your paper
‫report you did not account for.
‫That's right.
‫So now the sum of those of it is the one 30, but usually 140.
‫That's a phantom rate.
‫And the reason is factory, because this is one of the code.
‫So that range queries where you're selecting, but you're getting.
‫Extra rose, so.
‫If we're going to talk about ways to fix that, this is a little bit harder to fix and and to avoid
‫the previous ones, you can implement locks and version controls to get away with it.
‫But this this is a new value.
‫How do you lock it?
‫It's a new value.
‫Can say, hey, don't read that.
‫Right.
‫It's just really interesting.
‫And that one of the ways to fix that is actually serialisation isolation level.
‫All right.
‫Let's talk about the isolation levels.
‫Right.
‫This is very interesting, guys.
‫I really like this topic.
‫So isolation levels are levels of isolation.
‫Hosain, what what are you talking about?
‫So isolation levels are levels that implemented by the database to fix those phenomena that we talked
‫about.
‫OK, and there's a nice table by Wikipedia here that I'm going to reference here is very nice.
‫It just explains the whole thing here.
‫OK, so really committed is the first type of isolation, which is, I don't know, I call the isolation
‫level is that literally offers no isolation whatsoever.
‫That transaction, when your transaction starts in a free and committed way, is not going to is going
‫to it's not going to perform any isolation, any changes.
‫The database is happening.
‫You're going to see it.
‫So you're going to get dirty reads here, obviously, because you're just doing everything you're going
‫to get none repeatable reads.
‫Obviously, you're going to get phantom reads right.
‫And you get it lost updates as well.
‫Yeah.
‫The Reid committed is each there is little bit of isolation here and most database's implement that
‫and.
‫Most of the time, this is this is the one of the best transaction isolation level because you're happy
‫with that, you're happy to read committed stuff.
‫But here's the thing.
‫Each query in the transaction only commit to the stuff at that time of their query.
‫So each query you execute get to see the new committed values at that time.
‫OK, and that could be fine, right?
‫Sometimes it is not OK.
‫So that's what it means to recommit that you are seeing and viewing the committed staff at the time
‫of the query.
‫OK.
‫So anything that is committed, you're going to see it.
‫Obviously, this does not work on our example that we show, because we showed even that is committed,
‫the sales report came out wrong.
‫Right.
‫But there are certain cases where committed is enough for you get repeatable, read each query in the
‫transaction, only sees committed of the dates at the beginning of the transaction.
‫So it's the repeatable read isolation level gives you the ability to see.
‫Committed values, but not at every single equerry at the beginning of the transaction.
‫So once you begin a transaction, you will only see changes that have been committed before you start
‫the transaction.
‫OK, so that gives you a nice isolation, tight to view, and that's really powerful stuff.
‫So now I'm not going to go through the implementation aspects of this database is some database that
‫implements versioning to implement this like, hey, when you start a transaction like Cassandre, right.
‫You start a transaction.
‫I am inversion zero and then anything I read is belong to version zero of the database.
‫Okay, so if other transactions are committing stuff, changing stuff, they are updating to version
‫one version to over three.
‫I am only reading version zero.
‫And that's gives me a nice consistent view which we get to talk about that.
‫Right.
‫So repeatable rates.
‫So this way I guarantee that I'm going to read the same repeatable read Reiger and then get the same
‫read because I'm reading the same version.
‫Some database is implemented as a form of a lock, which is a little bit more expensive.
‫OK, so you have you establish an exclusive look and say, no, I am only reading this.
‫Please, guys, don't change this, OK?
‫Don't change it.
‫So if once we establish an exclusive lock, we cannot.
‫Nobody actually can or nobody can change that stuff.
‫It's not acceptable.
‫So so the lock approach of that, another approach to another approach to implement repeatable raises,
‫you're going to start in place of shared locks.
‫So you guarantee that nobody can actually change your data because everybody that needs to edit, they
‫need to establish an exclusive lock to edit these rows.
‫Right.
‫And you get about what to read.
‫And then once you do that, you release the shared lock, OK, so you implement some sort of a shared
‫look, but you just blocked people from editing.
‫So versioning is kind of a little bit better.
‫But there is a pros and cons for each one, obviously serializable.
‫That's the easiest way to implement and the kind of a slowest.
‫And the the performance goes down with every level of isolation.
‫So it's like I think of as a charter, this is no isolation.
‫This is the highest isolation level game.
‫But this is the fastest thing.
‫This is the slowest thing.
‫The serializable is essentially each transaction has to be serialized.
‫Right.
‫So if you as if they are serialist, almost like serios.
‫Right.
‫So the transaction just followed by another transaction, they cannot be executed in parallel.
‫Essentially, they try as much as possible.
‫The database does a little bit tricky things to to execute.
‫Some of them are parallel, but most of them I you can think of as a serialized.
‫Right.
‫So if you're serialized, nothing running in parallel, you're happy, right.
‫This is the best thing ever.
‫If you're not nothing, nothing in running parallel, then you're not going to get in concurrency issue.
‫You don't have isolation problems anyway.
‫So this is the best way.
‫Most of the time this is implemented at the application level.
‫The application place is a lock and says, guys, stop touching my stuff, I'm updating it or I'm reading
‫it, all right.
‫And then start reading everything and then goes away.
‫That's the table I was talking about with or from Wikipedia.
‫You have the read and committed level, all of that stuff.
‫All this phenomenas can occur, obviously, because we don't care uncommented read anything.
‫Right.
‫Any change that happens there to read lost updates, you get an unrepeatable you get phantom reads read
‫I committed.
‫What are we going to do is essentially read only the committee's stuff.
‫So you're not going to get dirty reads.
‫You know that because you're reading only committed stuff but you're going to get your not repeatable
‫reads because each query is getting then you committed stuff.
‫Right.
‫So if you queried at that point the first query of the transaction and then you turn around and query
‫again between those two queries, someone might change the value and committed it.
‫So you're reading the committed value, but it change so it's not repeatable and that's might not be
‫desirable.
‫Obviously, you might get fandoms as well.
‫Repeatable read.
‫You're not going to get dirty, it's because we're eating only committed stuff, but in addition of
‫that, we're only reading committed stuff at the beginning of transactions.
‫So you're not going to repeat your you're not going to get a unrepeatable read.
‫All of you are repeatable because you're reading the same version of the database at the start of the
‫transaction or that the database will force you to places a lock and then we'll only read the stuff
‫at the beginning.
‫OK, so that's essentially a reputable read and by Fantome still can occur as a result because you cannot
‫control Newroz, you can only control what you can only control rows that you can lock.
‫Right.
‫And this is debatable with versioning, you actually can get away with it.
‫You write this so this table is not entirely accurate with what if you implemented versioning with repeatable
‫rates, you can actually.
‫You might get away with repeatable reads, right, if you in the Virginny, I think Grogs DB and the
‫Facebook story is that Virginny serializable best thing ever.
‫I'm not going to say this, but if you're serializer a transaction, you're not going to get any of
‫that stuff.
‫You are guaranteed that nobody touches anything.
‫Unless.
‫They have a lock, right?
‫So you started the transaction, you placed the shared lock, right.
‫And if someone want to bring in the exclusive lock, they will get they will get an error because there
‫are Shedlock, there are read logs.
‫So and we talk about Shedlock and Redlegs.
‫I'm going to reference the video there, guys.