7 hours 36 minutes
I welcome to model for sequel programming to this is less than three concurrency and transactions were moving into Sub lesson 3.5 concurrency problems. One.
And this lesson. We're going to describe the four main types of concurrency problems that occur in my sequel as well as other sequel databases,
and in the next lesson will describe how you address those problems and when to consider that they might be a larger issue for you than previously than previously thought.
Now, courtesy problems are related to resource management, and typically the more users of the system that you acquire, the larger the possibility that some of these problems may occur.
So, for example, consider that we have a process one or user one
we have processed, too, or user, too.
Now, let's say process one
calls the ad employees procedure
okay, and it goes and it adds, starts adding,
and process, too,
is selecting employee data.
So it's going in there to read the data and bring it back.
Now we've dealt some with transactions and we know that there is a commit feature in which the commit is sent to the database
to say OK, you have the data, go ahead and save it
well without being careful. You may be allowing processes to read uncommitted data,
maybe process one goes in there,
insert some data
and then decides to take that data out. Decides it's not committed.
And while that was happening, process to win in there.
Read the uncommitted data on Returned the information to the user.
So process to is now presenting information to the user
that does not exist in the database
because it was uncommitted and processed. One decided for some reason to not commit that data,
and that's called a dirty read.
Now, in this example, we have two processes heir to users that we're talking about. But depending on the size of your application, you could very easily have three
users of the system
up to, you know, maybe hundreds, maybe thousands of users. And the more users you have, the more likely that something like this is going to happen. And to your end users, it's gonna they're gonna be describing seeing data that was never there.
So another type of concurrency problem is called the lost update.
So what is a lost update
The last update is, if process one here
select some data from the employee table and decides to make a change based on that selection.
So it's selected that data. It's decided to change some of that data
process to comes in right behind process one,
see some other data
and decides to make a change based on that data.
So Process one
applies an update
and then process to without re selecting from the table, because this was happening very, very close to each other. They both selected and read at nearly the same time and made their decisions
based on what they saw at that time. And let's say that Process one had changed some data
that would have changed processes to decision.
And now process one updates the data and process to also updates the data without considering the changes that process one made
that is considered a lost update.
The next concurrency problem is called the non repeatable read.
This occurs when to select statements, try to get the same data, but end up getting different values.
For example, let's say process, too,
is selecting data.
Process three comes in real fast changes the data
and process. One
selects that same data, the process to selected but gets different results. And it's because Process three was actually in the middle of their select statements, changing the values
that's considered a non repeatable read and is considered a type of concur concurrency problem.
The next type of concurrency problem is called Phantom Reads
Now. Ah, Phantom Read occurs when you
select data that is, in the process, a process of being either inserted or deleted.
An example of this would include if process one.
invoices past due
right as processed, too, is updating whether or not and voices or do or not.
Um, so let's say process one. Grab some invoices that are past due. But at the same time, process to was marking some of these as not do. And now process one is running off with these do invoices that really don't exist.
Now, some of these concurrency problems arm or significant, depending on what industry you are in.
For example, Phantom reads may not be that important for a CMS system like WordPress, where you're just publishing articles and someone just needs to click refresh to see the updated. Ah, article data.
But in a situation where a bank is using software, that stuff needs to be much more controlled. And they can't be sending out
past due invoices on accident because of the Phantom read problem. So some of these will not be as Africa ble
the type of application you're dealing with.
So that concludes this lesson on concurrency problems. And the next lesson we'll look at how to implement my sequel features that help prevent these problems. There are some benefits and some drawbacks to actually solving these problems, and in the next lesson will talk about those. I hope to see you there. Thank you.