Understanding Data Concurrency6:07 with James Churchill
Let's start with an overview of data concurrency and the two types of data concurrency controls—pessimistic and optimistic.
Comic Book Library Manager Web App
The Comic Book Library Manager web app can be viewed at http://comic-book-library-manager.azurewebsites.net/.
The project files for the Comic Book Library Manager web app are available at http://treehouse-project-downloads.s3.amazonaws.com/dotnet-ef-with-aspnet-mvc-comic-book-library-manager-completed.zip.
[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
You need to sign up for Treehouse in order to download course files.Sign up