7 hours 36 minutes
Hi. Welcome back to Module four. Sequel programming to we're currently in less than three concurrency and transactions removing into sub lesson 3.6 concurrency problems, too. In the previous lesson, we briefly went over the different types of concurrency problems you can encounter, which included the dirty reads,
the lost updates,
the non repeatable reads and the Phantom reads in this lesson. We're going to look at the different transaction, the isolation levels you can set to help deal with these problems as well as display. One of the problems that occur is using a procedure and a simple table.
Now the transaction isolation level is a setting for your transactions that you are running in your database.
So we have four levels to choose from. In my sequel, we have read uncommitted, read, committed, repeatable, read and serialize herbal
and well, if we'll go to the top, we will notice that read Uncommitted allows all four problems,
while serialize herbal prevents all four problems.
So why would you not just choose the
most or the more strict isolation level and prevent all the problems? Well, there is a tradeoff that you make as you move down the isolation level or up. Depending on your perspective, the performance is impacted, so read uncommitted has better performance than serialize herbal. So
depending on your application,
you may not want to take the performance. And as you may not consider these
these problems to be significant enough,
and there are other ways to avoid them as well.
For example, a bank will probably want the strictest isolation level,
while a CMS like WordPress may not care all that much because they're dealing more with articles and user comments. And if one of those gets accidentally dropped, it's, you know, it's not a huge deal than if someone's check accidentally gets dropped.
So with that said, let's take a look at how we can set these in my sequel, and then we'll also take a look at a problem
that ah kind of shows what kind of concurrency issues you could run into.
So if we go and look at the isolation levels now, you could set these per session or global. I chose just to set them as a ah global setting for this lesson.
If I highlight this
statement right here and just quit the play button,
it'll run that statement.
I could do that with any of these statements
to set the isolation level
to or the global isolation levels. Whatever I choose will not go ahead and leave mine on Reed Uncommitted.
Now let's take a look at one of the what one of these problems might look like.
So in this sequel script, I have a few different statements running. I have a drop and recreate procedure running at the top.
After that finishes I go hood and delete from this count table that I made,
which is a very simple table. It's two columns, is the I. D. And the counter
on the counter column is what we're updating with. The next number is like an anchor nip
So I didn't delete that or empty the table to start over.
I then call the procedure I just created up here,
and I let that run. I then select
from that table looking for problems. So what I'm doing in this select statement as I'm selecting the counter column, I'm running the count function and I'm grouping by the counter and ordering by count descending. So what that will do is it will show me any columns where the same number got added twice.
Now, as you can tell by this procedure, the way it's laid out, the idea and this procedure is that I'm just incriminating plus one
and I'm adding it to the table.
I don't want to add the same number to the table,
so if that happens, that could be a problem.
So let's go ahead and run this. I have to be Beaver sessions open,
which are basically simulating two connections to the database. So I'm gonna run this and I'm gonna run this at the same time.
But first, I'm gonna go ahead and get rid of this start transaction line by commenting it outs,
comment that out,
out, go. So now we are not we're not using The transactions were just running it without that.
So let's go ahead and run this
and then we'll quickly jump over here and run this one.
So this one's executing, and this one's executing at the same time in parallel.
So let's see what our results look like.
So you can see that we have an issue here.
It's Ah, the counter 15 52 guys considered inserted twice 7 83 got inserted twice. Thio two or three got in sort of twice. So what happened was that these two different processes selected the same counter column, added one to it and inserted at the same time.
Now, depending on your application and depending on what you're doing, that could be a problem.
Let's go ahead and turn back on the transactions
and let's run it again
around this one again.
Now they're both executing.
So we got an air,
the transition locks the table. So one of the columns aired, or one of the procedures aired out and this was prevented by the use of the transaction. This is actually a good thing. Um, we didn't do any kind of air catch in in this script. So
of course, when it
encountered in there, it just stopped and crashed.
But let's go ahead and take a look at our table to see if we see any problems.
And no, we don't. We don't have any problems. They both ran for a
Let's see that each do 1000. So
our highest number is
14 10. So one of these didn't run all the way through,
but it stopped before it accidentally introduced a ah additional count
that shouldn't be there.
Have you run that again?
Run that again
again. We'll get the same thing.
This one's still running
and again, where we've protected ourselves with the use of transactions.
So there's other things you can do to when you can't use transactions. And in fact, in an upcoming lesson in with triggers, we have to use a different method if we want to update tables safely
because the transactions aren't actually allowed to be used from triggers and we'll discuss that later lesson. So that finishes this lesson on concurrency problems, too. It's definitely something you want to look at. You want to consider with respect to what your application is trying to accomplish and be aware of the, uh, the
the type of problems and obstacles you might have to deal with
when you have procedures running that are inserting data into, ah,
various tables that rely on that data to make a decision. In any case, go ahead and download. These, uh,
these documents are these ah procedures. If you are curious about running them yourself, they're attached to the lesson. And ah, I hope to see you in the next lesson. Thank you.