Preview
Video Player
00:00
00:00
Understanding Data Concurrency
6:07Let's start with an overview of data concurrency and the two types of data concurrency controls—pessimistic and optimistic.
[MUSIC]
0:00
Hi, my name is James.
0:04
The consumers of an application,
whether they are automated processes or
0:06
actual people,
are often referred to as users.
0:10
We can refer to the entire group of our
applications users, as our user base.
0:14
When developing an application using
our local development environment
0:19
our application typically just has
a single concurrent user ourselves.
0:22
In a production environment,
0:27
a small user base might include anywhere
from five to a few dozen users.
0:28
Whereas a medium to large user base
can include anywhere from hundreds
0:33
to thousands or
even tens of thousands of users.
0:37
Given that, it's not unusual for
0:41
web applications to be designed to support
more than one concurrent user at a time.
0:43
Data concurrency, the topic of
this workshop, is the ability for
0:49
multiple users to access, or
change data at the same time.
0:52
The more users that you have trying
to access and change the same data,
0:57
the more challenging it is to provide
data that's reliable and consistent.
1:01
Let's look at a common situation that
can arise when supporting multiple,
1:06
concurrent users.
1:10
>> As we learn about data
concurrency in this workshop,
1:11
we'll work with
the Comic Book Library Manager web app.
1:14
Developed using ASP.net NVC and
identify framework, this app
1:17
allows users to manager a digital library
of comic books by giving them tools for
1:22
creating, updating and
deleting comic books series and artists.
1:27
To follow along with this workshop,
see the teachers notes for
1:33
a link to download the project files.
1:36
For this example,
1:38
let's imagine that the browser on the left
represents our first concurrent user.
1:39
We'll call them user one.
1:44
And the browser on the right
represents our second concurrent user.
1:46
Let's call them user two.
1:50
User one views the detail for
the comic book, Bone number three and
1:53
chooses to edit the record.
1:57
User number two also views the details for
Bone number three and chooses to edit
2:02
the record before user one has had
a chance to finish making their update.
2:07
User one updates the average rating value.
2:12
And clicks the save button.
2:18
Just after that, user number
two updates the description and
2:21
clicks the save button.
2:25
Notice that user one isn't able to
see the update that user two made.
2:35
This is because user
two saved their update
2:39
after the detail page was loaded for
user one.
2:42
Also notice that the detail
page that was loaded for
2:46
user two, doesn't reflect
the change that user one made.
2:48
If user one reloads the detail page,
2:52
they'll see the same information
that user two is seeing.
2:55
But what happened to
the change that user one made?
3:02
Their change was successfully persisted
to the database when they clicked
3:05
the save button.
3:08
We saw confirmation of that when
the detail page was initially loaded.
3:10
Unfortunately, user two updated
a version of the record
3:14
that was retrieved from the database,
before that change was made.
3:17
So when user two clicked the save button,
the persistent version of the record that
3:22
contained the previous average rating
value, overwriting the updated
3:26
value that user one had persisted to
the database just a moment before.
3:31
>> This example often referred
to as last one in wins,
3:37
shows that if concurrency isn't properly
handled, data changes can be lost.
3:41
Even worst, the lost data can be
difficult for users to detect.
3:46
As we saw, both users saw the result
that they were expecting.
3:50
In order to prevent data loss,
3:54
we can implement data concurrency
controls in our applications.
3:56
Data concurrency controls come
in two different flavors.
4:00
Pessimistic and optimistic.
4:03
With pessimistic concurrency control,
when a user reads a record it's locked.
4:06
If another user tries to
read that same record,
4:10
they'll receive an error message letting
them know that the record is in use.
4:13
Once the user that locked
the record is done with it,
4:17
the record is unlocked making it
available again to other users.
4:19
With optimistic concurrency control,
records are not locked when they read,
4:24
which allows multiple users
to read the same record.
4:28
When a user initiates
an update the data for
4:32
the record is checked if it has
changed since it was initially read.
4:34
If the data has been changed,
4:38
the user trying to make the update
will receive an error message.
4:40
Pessimistic concurrency
control can result in slower
4:44
overall performance due
to record blocking.
4:47
When one user is waiting for
another user to release a record lock,
4:50
even worse record deadlocks can occur when
two users are blocked, each waiting for
4:54
a record that the other user has locked.
4:59
Because of these challenges identity
framework doesn't provide support for
5:02
pessimistic concurrency control.
5:05
Instead, identify framework
provides support for
5:07
optimistic concurrency control.
5:10
But it's not enabled by default.
5:12
Remember, without any concurrency
control the last one in wins.
5:15
When each user naturally works
off their own group of records,
5:19
a lack of concurrency control
may not present a problem.
5:23
When that's not the case, implementing
an optimistic concurrency control
5:26
is a necessity,
especially when data loss is unacceptable.
5:30
Let's review what we'll
cover in this workshop.
5:35
We started with an overview
of data concurrency and
5:38
why it's important to implement
data concurrency controls.
5:41
Next, we'll see how to enable EF support
for optimistic concurrency control and
5:44
how to handle concurrency exceptions
when both editing and deleting records.
5:49
Then, we'll briefly discuss
an alternative strategy for
5:54
handling data concurrency,
using pessimistic or explicit locking.
5:57
Next up we'll see how to configure
EF to use optimistic concurrency.
6:03