Hey everyone, welcome back. In this video, part five of topic six in our database class, I'm going to discuss dirty reads, inconsistent reads, and phantom reads. Let's get started. So, that lost update problem shows you how, when you have multiple people trying to work with the same data at the same time, it's pretty easy to lose track of things, unless we have specific mechanisms in place to prevent it. So, that is a concurrency issue, and it's not to lost update problem as an example, but we can talk about these concurrency issues a little more formally, by studying the three different types of concurrency control problems. And these are dirty reads. In consistent reads, these are also called non-repeatable reads, same thing. And phantom reads. So, these three issues are our three possible concurrency control problems that we need to handle, or we need to consider handling. So, let's talk about each of these in turn. What does it dirty read? Well, in a dirty read, a transaction is allowed to read, data in the database that have been modified, but have not yet been committed. So, it would be like if you and I are working with the same data at the same time, and you have proposed a change to the data value, and if I am allowed to see that change before you have made it permanent, that is dirty read. And the reason that this can be problematic is because your transaction might fail. So, remember, transactions involve multiple steps. If any of those steps fails, whatever sort of modifications or proposed changes that the previous steps in the transaction have made, they'll all need to be undone. They're not going to be made a permanent part of the database. That is, they're not going to be committed to the database. So, what I'm seeing is your work in progress, even though it's not official, you may decide not to save it. And in that sense, I might be making my decisions on what to do based on a change that you've proposed, that you ultimately decide not to make. So, you can imagine how this could cause problems. As if your transaction ultimately fails, and I'm relying on a proposed, but a proposed change that was never actually made to the database, then what I'm doing could potentially introduce bad data into the database. So, our second concurrency control problem is an inconsistent read or a non-reputable read. And I think non-reputable is a good way of describing this because it suggests that we're going to, a transaction is going to read a value in the database multiple times. So, it might read it at the beginning of the transaction, and it might read the value again at the end of the transaction. And if it finds that the value has changed between those two reads, then what we have is an inconsistent read. So, it would be like using our previous inventory example. Let's say that we begin by requesting how many units of item 100 do we have an inventory. So, maybe the answer is 10. And then I'm going to propose some changes, but before I do, I check to make sure that nothing has changed in the meantime. So, I propose my changes, and then before committing those changes, I check to see if the inventory level is still 10. And if I find that it is not, then something has happened between, or well, my transaction was in process. I say, somebody else changed that value that I was working with. So, whatever proposed changes I was going to make would potentially lead to inaccurate data in the database. So, someone was allowed to read, or someone was allowed to change the data and that led to an inconsistent read for my transaction. And then we can have a phantom read. And a phantom read is somewhat similar to an inconsistent read, but it manifests itself when a transaction rereads a data set and finds that a new record has been added. So, for using like a sales scenario, as with the examples from a little earlier, then it would be like if an additional sale had been added, well, we were still busy processing our sales transaction. And now, things have changed, right? And that the, maybe the calculations that I had made as part of my transaction, the changes that I was going to make to the database would no longer be accurate. So, let's say, for example, that I don't know, maybe we're trying to, we have a transaction that's trying to calculate our total daily sales thus far. And we start off, we're just going to sum all of the individual sales for the day. So, when we start off, we figure out how many we have and we start adding them up. And then by the time we get done and we're ready to save the result, some, at some point, where we were busy doing our task, another sale was added to the database. Hey, so whatever result we get now is not going to be accurate. So, if a transaction is allowed to add new records to the database, well, we are busy working with those data, it can lead to a phantom read as a concurrency control problem. So, these things again, it all happens just because we have multiple users trying to work with the same data at the same time. We need to have ways of handling this stuff.