aspnetcore/data/ef-rp/concurrency.md
Tom Dykstra, and Jon P Smith
[!INCLUDE about the series]
:::moniker range=">= aspnetcore-5.0"
This tutorial shows how to handle conflicts when multiple users update an entity concurrently.
A concurrency conflict occurs when:
If concurrency detection isn't enabled, whoever updates the database last overwrites the other user's changes. If this risk is acceptable, the cost of programming for concurrency might outweigh the benefit.
One way to prevent concurrency conflicts is to use database locks. This is called pessimistic concurrency. Before the app reads a database row that it intends to update, it requests a lock. Once a row is locked for update access, no other users are allowed to lock the row until the first lock is released.
Managing locks has disadvantages. It can be complex to program and can cause performance problems as the number of users increases. Entity Framework Core provides no built-in support for pessimistic concurrency.
Optimistic concurrency allows concurrency conflicts to happen, and then reacts appropriately when they do. For example, Jane visits the Department edit page and changes the budget for the English department from $350,000.00 to $0.00.
Before Jane clicks Save, John visits the same page and changes the Start Date field from 9/1/2007 to 9/1/2013.
Jane clicks Save first and sees her change take effect, since the browser displays the Index page with zero as the Budget amount.
John clicks Save on an Edit page that still shows a budget of $350,000.00. What happens next is determined by how you handle concurrency conflicts:
Keep track of which property a user has modified and update only the corresponding columns in the database.
In the scenario, no data would be lost. Different properties were updated by the two users. The next time someone browses the English department, they will see both Jane's and John's changes. This method of updating can reduce the number of conflicts that could result in data loss. This approach has some disadvantages:
Let John's change overwrite Jane's change.
The next time someone browses the English department, they will see 9/1/2013 and the fetched $350,000.00 value. This approach is called a Client Wins or Last in Wins scenario. All values from the client take precedence over what's in the data store. The scaffolded code does no concurrency handling, Client Wins happens automatically.
Prevent John's change from being updated in the database. Typically, the app would:
This is called a Store Wins scenario. The data-store values take precedence over the values submitted by the client. The Store Wins scenario is used in this tutorial. This method ensures that no changes are overwritten without a user being alerted.
<a name="concurrency"></a>
Properties configured as concurrency tokens are used to implement optimistic concurrency control. When an update or delete operation is triggered by xref:Microsoft.EntityFrameworkCore.DbContext.SaveChanges%2A or xref:Microsoft.EntityFrameworkCore.DbContext.SaveChangesAsync%2A, the value of the concurrency token in the database is compared against the original value read by EF Core:
Another user or process performing an operation that conflicts with the current operation is known as concurrency conflict.
On relational databases EF Core checks for the value of the concurrency token in the WHERE clause of UPDATE and DELETE statements to detect a concurrency conflict.
The data model must be configured to enable conflict detection by including a tracking column that can be used to determine when a row has been changed. EF provides two approaches for concurrency tokens:
Applying [ConcurrencyCheck] or xref:Microsoft.EntityFrameworkCore.Metadata.IProperty.IsConcurrencyToken to a property on the model. This approach is not recommended. For more information, see Concurrency Tokens in EF Core.
Applying xref:System.ComponentModel.DataAnnotations.TimestampAttribute or xref:Microsoft.EntityFrameworkCore.Metadata.Builders.PropertyBuilder.IsRowVersion%2A to a concurrency token in the model. This is the approach used in this tutorial.
The SQL Server approach and SQLite implementation details are slightly different. A difference file is shown later in the tutorial listing the differences. The Visual Studio tab shows the SQL Server approach. The Visual Studio Code tab shows the approach for non-SQL Server databases, such as SQLite.
Update the Models/Department.cs file with the following highlighted code:
The xref:System.ComponentModel.DataAnnotations.TimestampAttribute is what identifies the column as a concurrency tracking column. The fluent API is an alternative way to specify the tracking property:
modelBuilder.Entity<Department>()
.Property<byte[]>("ConcurrencyToken")
.IsRowVersion();
The [Timestamp] attribute on an entity property generates the following code in the xref:Microsoft.EntityFrameworkCore.ModelBuilder method:
b.Property<byte[]>("ConcurrencyToken")
.IsConcurrencyToken()
.ValueGeneratedOnAddOrUpdate()
.HasColumnType("rowversion");
The preceding code:
ConcurrencyToken to byte array. byte[] is the required type for SQL Server.IsConcurrencyToken configures the property as a concurrency token. On updates, the concurrency token value in the database is compared to the original value to ensure it has not changed since the instance was retrieved from the database. If it has changed, a xref:Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException is thrown and changes are not applied.ConcurrencyToken property to have a value automatically generated when adding or updating an entity.HasColumnType("rowversion") sets the column type in the SQL Server database to rowversion.The following code shows a portion of the T-SQL generated by EF Core when the Department name is updated:
The preceding highlighted code shows the WHERE clause containing ConcurrencyToken. If the database ConcurrencyToken doesn't equal the ConcurrencyToken parameter @p2, no rows are updated.
The following highlighted code shows the T-SQL that verifies exactly one row was updated:
@@ROWCOUNT returns the number of rows affected by the last statement. If no rows are updated, EF Core throws a DbUpdateConcurrencyException.
In the model, include a tracking column that can be used to determine when a row has been changed. In this sample, a GUID is used. Update the Models/Department.cs file with the following highlighted code:
Update the Data/SchoolContext.cs file by calling xref:Microsoft.EntityFrameworkCore.Metadata.IProperty.IsConcurrencyToken on the Department.ConcurrencyToken property:
IsConcurrencyToken configures the property as a concurrency token. On updates, the concurrency token value in the database is compared to the original value to ensure it has not changed since the instance was retrieved from the database. If it has changed, a xref:Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException is thrown and changes are not applied.
In the code that updates the entity, update the value of the concurrency token. In this sample, the method that updates the entity uses the following code. This step will be done later in the tutorial.
departmentToUpdate.ConcurrencyToken = Guid.NewGuid();
An alternative to updating the concurrency token in the update method is to set up a trigger so it's automatically updated by the database. For more information, see SQLite and EF Core Concurrency Tokens.
<!--* Call <xref:Microsoft.EntityFrameworkCore.ChangeTracking.PropertyEntry.OriginalValue> to set the `rowVersion` value to the value from the entity when it was read. The `OriginalValue` update code is shown in [the concurrency updates](#c-up) section of this document. This step will be done later in the tutorial. -->Adding the ConcurrencyToken property changes the data model, which requires a migration.
Build the project.
Run the following commands in the PMC:
Add-Migration RowVersion
Update-Database
The preceding commands:
Migrations/{time stamp}_RowVersion.cs migration file.Migrations/SchoolContextModelSnapshot.cs file. The update adds the following code to the BuildModel method: b.Property<byte[]>("ConcurrencyToken")
.IsConcurrencyToken()
.ValueGeneratedOnAddOrUpdate()
.HasColumnType("rowversion");
Run the following commands in a terminal:
dotnet ef migrations add RowVersion
dotnet ef database update
The preceding commands:
Migrations/{time stamp}_RowVersion.cs migration file.Migrations/SchoolContextModelSnapshot.cs file. The update adds the following highlighted code to the BuildModel method:b.Property<Guid>("ConcurrencyToken")
.IsConcurrencyToken()
.HasColumnType("TEXT");
<a name="scaffold"></a>
Follow the instructions in Scaffold Student pages with the following exceptions:
Department for the model class.Create a Pages/Departments folder.
Run the following command to scaffold the Department pages.
On Windows:
dotnet aspnet-codegenerator razorpage -m Department -dc SchoolContext -udl -outDir Pages\Departments --referenceScriptLibraries
On Linux or macOS:
dotnet aspnet-codegenerator razorpage -m Department -dc SchoolContext -udl -outDir Pages/Departments --referenceScriptLibraries
In the project folder, create the Utility class with the following code:
The Utility class provides the GetLastChars method used to display the last few characters of the concurrency token. The following code shows the code that works with both SQLite ad SQL Server:
The #if SQLiteVersion preprocessor directive isolates the differences in the SQLite and SQL Server versions and helps:
Build the project.
The scaffolding tool created a ConcurrencyToken column for the Index page, but that field wouldn't be displayed in a production app. In this tutorial, the last portion of the ConcurrencyToken is displayed to help show how concurrency handling works. The last portion isn't guaranteed to be unique by itself.
Update Pages\Departments\Index.cshtml page:
ConcurrencyToken to show just the last few characters.FirstMidName with FullName.The following code shows the updated page:
Update Pages/Departments/Edit.cshtml.cs with the following code:
<a name="c-up"></a>
xref:Microsoft.EntityFrameworkCore.ChangeTracking.PropertyEntry.OriginalValue is updated with the ConcurrencyToken value from the entity when it was fetched in the OnGetAsync method. EF Core generates a SQL UPDATE command with a WHERE clause containing the original ConcurrencyToken value. If no rows are affected by the UPDATE command, a DbUpdateConcurrencyException exception is thrown. No rows are affected by the UPDATE command when no rows have the original ConcurrencyToken value.
In the preceding highlighted code:
Department.ConcurrencyToken is the value when the entity was fetched in the Get request for the Edit page. The value is provided to the OnPost method by a hidden field in the Razor page that displays the entity to be edited. The hidden field value is copied to Department.ConcurrencyToken by the model binder.OriginalValue is what EF Core uses in the WHERE clause. Before the highlighted line of code executes:
OriginalValue has the value that was in the database when FirstOrDefaultAsync was called in this method.ConcurrencyToken value from the displayed Department entity in the SQL UPDATE statement's WHERE clause.The following code shows the Department model. Department is initialized in the:
OnGetAsync method by the EF query.OnPostAsync method by the hidden field in the Razor page using model binding:The preceding code shows the ConcurrencyToken value of the Department entity from the HTTP POST request is set to the ConcurrencyToken value from the HTTP GET request.
When a concurrency error happens, the following highlighted code gets the client values (the values posted to this method) and the database values.
The following code adds a custom error message for each column that has database values different from what was posted to OnPostAsync:
The following highlighted code sets the ConcurrencyToken value to the new value retrieved from the database. The next time the user clicks Save, only concurrency errors that happen since the last display of the Edit page will be caught.
The ModelState.Remove statement is required because ModelState has the previous ConcurrencyToken value. In the Razor Page, the ModelState value for a field takes precedence over the model property values when both are present.
The following shows the differences between the SQL Server and SQLite versions:
+ using System; // For GUID on SQLite
+ departmentToUpdate.ConcurrencyToken = Guid.NewGuid();
_context.Entry(departmentToUpdate)
.Property(d => d.ConcurrencyToken).OriginalValue = Department.ConcurrencyToken;
- Department.ConcurrencyToken = (byte[])dbValues.ConcurrencyToken;
+ Department.ConcurrencyToken = dbValues.ConcurrencyToken;
Update Pages/Departments/Edit.cshtml with the following code:
The preceding code:
page directive from @page to @page "{id:int}".ConcurrencyToken must be added so postback binds the value.ConcurrencyToken for debugging purposes.ViewData with the strongly-typed InstructorNameSL.Open two browsers instances of Edit on the English department:
The two browser tabs display the same information.
Change the name in the first browser tab and click Save.
The browser shows the Index page with the changed value and updated ConcurrencyTokenindicator. Note the updated ConcurrencyTokenindicator, it's displayed on the second postback in the other tab.
Change a different field in the second browser tab.
Click Save. You see error messages for all fields that don't match the database values:
This browser window didn't intend to change the Name field. Copy and paste the current value (Languages) into the Name field. Tab out. Client-side validation removes the error message.
Click Save again. The value you entered in the second browser tab is saved. You see the saved values in the Index page.
Update Pages/Departments/Delete.cshtml.cs with the following code:
The Delete page detects concurrency conflicts when the entity has changed after it was fetched. Department.ConcurrencyToken is the row version when the entity was fetched. When EF Core creates the SQL DELETE command, it includes a WHERE clause with ConcurrencyToken. If the SQL DELETE command results in zero rows affected:
ConcurrencyToken in the SQL DELETE command doesn't match ConcurrencyToken in the database.DbUpdateConcurrencyException exception is thrown.OnGetAsync is called with the concurrencyError.Update Pages/Departments/Delete.cshtml with the following code:
The preceding code makes the following changes:
page directive from @page to @page "{id:int}".ConcurrencyToken to display the last byte.ConcurrencyToken must be added so postback binds the value.Create a test department.
Open two browsers instances of Delete on the test department:
The two browser tabs display the same information.
Change the budget in the first browser tab and click Save.
The browser shows the Index page with the changed value and updated ConcurrencyTokenindicator. Note the updated ConcurrencyTokenindicator, it's displayed on the second postback in the other tab.
Delete the test department from the second tab. A concurrency error is display with the current values from the database. Clicking Delete deletes the entity, unless ConcurrencyToken has been updated.
This is the last tutorial in the series. Additional topics are covered in the MVC version of this tutorial series.
[!div class="step-by-step"] Previous tutorial
:::moniker-end
:::moniker range=">= aspnetcore-3.0 < aspnetcore-5.0"
This tutorial shows how to handle conflicts when multiple users update an entity concurrently (at the same time).
A concurrency conflict occurs when:
If concurrency detection isn't enabled, whoever updates the database last overwrites the other user's changes. If this risk is acceptable, the cost of programming for concurrency might outweigh the benefit.
One way to prevent concurrency conflicts is to use database locks. This is called pessimistic concurrency. Before the app reads a database row that it intends to update, it requests a lock. Once a row is locked for update access, no other users are allowed to lock the row until the first lock is released.
Managing locks has disadvantages. It can be complex to program and can cause performance problems as the number of users increases. Entity Framework Core provides no built-in support for it, and this tutorial doesn't show how to implement it.
Optimistic concurrency allows concurrency conflicts to happen, and then reacts appropriately when they do. For example, Jane visits the Department edit page and changes the budget for the English department from $350,000.00 to $0.00.
Before Jane clicks Save, John visits the same page and changes the Start Date field from 9/1/2007 to 9/1/2013.
Jane clicks Save first and sees her change take effect, since the browser displays the Index page with zero as the Budget amount.
John clicks Save on an Edit page that still shows a budget of $350,000.00. What happens next is determined by how you handle concurrency conflicts:
You can keep track of which property a user has modified and update only the corresponding columns in the database.
In the scenario, no data would be lost. Different properties were updated by the two users. The next time someone browses the English department, they will see both Jane's and John's changes. This method of updating can reduce the number of conflicts that could result in data loss. This approach has some disadvantages:
You can let John's change overwrite Jane's change.
The next time someone browses the English department, they will see 9/1/2013 and the fetched $350,000.00 value. This approach is called a Client Wins or Last in Wins scenario. (All values from the client take precedence over what's in the data store.) If you don't do any coding for concurrency handling, Client Wins happens automatically.
You can prevent John's change from being updated in the database. Typically, the app would:
This is called a Store Wins scenario. (The data-store values take precedence over the values submitted by the client.) You implement the Store Wins scenario in this tutorial. This method ensures that no changes are overwritten without a user being alerted.
EF Core throws DbConcurrencyException exceptions when it detects conflicts. The data model has to be configured to enable conflict detection. Options for enabling conflict detection include the following:
Configure EF Core to include the original values of columns configured as concurrency tokens in the Where clause of Update and Delete commands.
When SaveChanges is called, the Where clause looks for the original values of any properties annotated with the xref:System.ComponentModel.DataAnnotations.ConcurrencyCheckAttribute attribute. The update statement won't find a row to update if any of the concurrency token properties changed since the row was first read. EF Core interprets that as a concurrency conflict. For database tables that have many columns, this approach can result in very large Where clauses, and can require large amounts of state. Therefore this approach is generally not recommended, and it isn't the method used in this tutorial.
In the database table, include a tracking column that can be used to determine when a row has been changed.
In a SQL Server database, the data type of the tracking column is rowversion. The rowversion value is a sequential number that's incremented each time the row is updated. In an Update or Delete command, the Where clause includes the original value of the tracking column (the original row version number). If the row being updated has been changed by another user, the value in the rowversion column is different than the original value. In that case, the Update or Delete statement can't find the row to update because of the Where clause. EF Core throws a concurrency exception when no rows are affected by an Update or Delete command.
In Models/Department.cs, add a tracking property named RowVersion:
The xref:System.ComponentModel.DataAnnotations.TimestampAttribute attribute is what identifies the column as a concurrency tracking column. The fluent API is an alternative way to specify the tracking property:
modelBuilder.Entity<Department>()
.Property<byte[]>("RowVersion")
.IsRowVersion();
For a SQL Server database, the [Timestamp] attribute on an entity property defined as byte array:
The database generates a sequential row version number that's incremented each time the row is updated. In an Update or Delete command, the Where clause includes the fetched row version value. If the row being updated has changed since it was fetched:
Update or Delete commands don't find a row because the Where clause looks for the fetched row version value.DbUpdateConcurrencyException is thrown.The following code shows a portion of the T-SQL generated by EF Core when the Department name is updated:
The preceding highlighted code shows the WHERE clause containing RowVersion. If the database RowVersion doesn't equal the RowVersion parameter (@p2), no rows are updated.
The following highlighted code shows the T-SQL that verifies exactly one row was updated:
@@ROWCOUNT returns the number of rows affected by the last statement. If no rows are updated, EF Core throws a DbUpdateConcurrencyException.
For a SQLite database, the [Timestamp] attribute on an entity property defined as byte array:
Database triggers update the RowVersion column with a new random byte array whenever a row is updated. In an Update or Delete command, the Where clause includes the fetched value of the RowVersion column. If the row being updated has changed since it was fetched:
Update or Delete command doesn't find a row because the Where clause looks for the original row version value.DbUpdateConcurrencyException is thrown.Adding the RowVersion property changes the data model, which requires a migration.
Build the project.
Run the following command in the PMC:
Add-Migration RowVersion
Run the following command in a terminal:
dotnet ef migrations add RowVersion
This command:
Creates the Migrations/{time stamp}_RowVersion.cs migration file.
Updates the Migrations/SchoolContextModelSnapshot.cs file. The update adds the following highlighted code to the BuildModel method:
Run the following command in the PMC:
Update-Database
Open the Migrations/<timestamp>_RowVersion.cs file and add the highlighted code:
The preceding code:
Run the following command in a terminal:
dotnet ef database update
<a name="scaffold"></a>
Follow the instructions in Scaffold Student pages with the following exceptions:
Create a Pages/Departments folder.
Use Department for the model class.
Create a Pages/Departments folder.
Run the following command to scaffold the Department pages.
On Windows:
dotnet aspnet-codegenerator razorpage -m Department -dc SchoolContext -udl -outDir Pages\Departments --referenceScriptLibraries
On Linux or macOS:
dotnet aspnet-codegenerator razorpage -m Department -dc SchoolContext -udl -outDir Pages/Departments --referenceScriptLibraries
Build the project.
The scaffolding tool created a RowVersion column for the Index page, but that field wouldn't be displayed in a production app. In this tutorial, the last byte of the RowVersion is displayed to help show how concurrency handling works. The last byte isn't guaranteed to be unique by itself.
Update Pages\Departments\Index.cshtml page:
RowVersion to show just the last byte of the byte array.The following code shows the updated page:
Update Pages/Departments/Edit.cshtml.cs with the following code:
The xref:Microsoft.EntityFrameworkCore.ChangeTracking.PropertyEntry.OriginalValue is updated with the rowVersion value from the entity when it was fetched in the OnGetAsync method. EF Core generates a SQL UPDATE command with a WHERE clause containing the original RowVersion value. If no rows are affected by the UPDATE command (no rows have the original RowVersion value), a DbUpdateConcurrencyException exception is thrown.
In the preceding highlighted code:
Department.RowVersion is what was in the entity when it was originally fetched in the Get request for the Edit page. The value is provided to the OnPost method by a hidden field in the Razor page that displays the entity to be edited. The hidden field value is copied to Department.RowVersion by the model binder.OriginalValue is what EF Core will use in the Where clause. Before the highlighted line of code executes, OriginalValue has the value that was in the database when FirstOrDefaultAsync was called in this method, which might be different from what was displayed on the Edit page.RowVersion value from the displayed Department entity in the SQL UPDATE statement's Where clause.When a concurrency error happens, the following highlighted code gets the client values (the values posted to this method) and the database values.
The following code adds a custom error message for each column that has database values different from what was posted to OnPostAsync:
The following highlighted code sets the RowVersion value to the new value retrieved from the database. The next time the user clicks Save, only concurrency errors that happen since the last display of the Edit page will be caught.
The ModelState.Remove statement is required because ModelState has the old RowVersion value. In the Razor Page, the ModelState value for a field takes precedence over the model property values when both are present.
Update Pages/Departments/Edit.cshtml with the following code:
The preceding code:
page directive from @page to @page "{id:int}".RowVersion must be added so postback binds the value.RowVersion for debugging purposes.ViewData with the strongly-typed InstructorNameSL.Open two browsers instances of Edit on the English department:
The two browser tabs display the same information.
Change the name in the first browser tab and click Save.
The browser shows the Index page with the changed value and updated rowVersion indicator. Note the updated rowVersion indicator, it's displayed on the second postback in the other tab.
Change a different field in the second browser tab.
Click Save. You see error messages for all fields that don't match the database values:
This browser window didn't intend to change the Name field. Copy and paste the current value (Languages) into the Name field. Tab out. Client-side validation removes the error message.
Click Save again. The value you entered in the second browser tab is saved. You see the saved values in the Index page.
Update Pages/Departments/Delete.cshtml.cs with the following code:
The Delete page detects concurrency conflicts when the entity has changed after it was fetched. Department.RowVersion is the row version when the entity was fetched. When EF Core creates the SQL DELETE command, it includes a WHERE clause with RowVersion. If the SQL DELETE command results in zero rows affected:
RowVersion in the SQL DELETE command doesn't match RowVersion in the database.OnGetAsync is called with the concurrencyError.Update Pages/Departments/Delete.cshtml with the following code:
The preceding code makes the following changes:
page directive from @page to @page "{id:int}".RowVersion to display the last byte.RowVersion must be added so postback binds the value.Create a test department.
Open two browsers instances of Delete on the test department:
The two browser tabs display the same information.
Change the budget in the first browser tab and click Save.
The browser shows the Index page with the changed value and updated rowVersion indicator. Note the updated rowVersion indicator, it's displayed on the second postback in the other tab.
Delete the test department from the second tab. A concurrency error is display with the current values from the database. Clicking Delete deletes the entity, unless RowVersion has been updated.
This is the last tutorial in the series. Additional topics are covered in the MVC version of this tutorial series.
[!div class="step-by-step"] Previous tutorial
:::moniker-end
:::moniker range="< aspnetcore-3.0"
This tutorial shows how to handle conflicts when multiple users update an entity concurrently (at the same time). If you run into problems you can't solve, download or view the completed app. Download instructions.
A concurrency conflict occurs when:
If concurrency detection isn't enabled, when concurrent updates occur:
Optimistic concurrency allows concurrency conflicts to happen, and then reacts appropriately when they do. For example, Jane visits the Department edit page and changes the budget for the English department from $350,000.00 to $0.00.
Before Jane clicks Save, John visits the same page and changes the Start Date field from 9/1/2007 to 9/1/2013.
Jane clicks Save first and sees her change when the browser displays the Index page.
John clicks Save on an Edit page that still shows a budget of $350,000.00. What happens next is determined by how you handle concurrency conflicts.
Optimistic concurrency includes the following options:
You can keep track of which property a user has modified and update only the corresponding columns in the DB.
In the scenario, no data would be lost. Different properties were updated by the two users. The next time someone browses the English department, they will see both Jane's and John's changes. This method of updating can reduce the number of conflicts that could result in data loss. This approach:
You can let John's change overwrite Jane's change.
The next time someone browses the English department, they will see 9/1/2013 and the fetched $350,000.00 value. This approach is called a Client Wins or Last in Wins scenario. (All values from the client take precedence over what's in the data store.) If you don't do any coding for concurrency handling, Client Wins happens automatically.
You can prevent John's change from being updated in the DB. Typically, the app would:
This is called a Store Wins scenario. (The data-store values take precedence over the values submitted by the client.) You implement the Store Wins scenario in this tutorial. This method ensures that no changes are overwritten without a user being alerted.
When a property is configured as a concurrency token:
The DB and data model must be configured to support throwing DbUpdateConcurrencyException.
Concurrency conflicts can be detected at the property level with the ConcurrencyCheck attribute. The attribute can be applied to multiple properties on the model. For more information, see Data Annotations-ConcurrencyCheck.
The [ConcurrencyCheck] attribute isn't used in this tutorial.
To detect concurrency conflicts, a rowversion tracking column is added to the model. rowversion :
The DB generates a sequential rowversion number that's incremented each time the row is updated. In an Update or Delete command, the Where clause includes the fetched value of rowversion. If the row being updated has changed:
rowversion doesn't match the fetched value.Update or Delete commands don't find a row because the Where clause includes the fetched rowversion.DbUpdateConcurrencyException is thrown.In EF Core, when no rows have been updated by an Update or Delete command, a concurrency exception is thrown.
In Models/Department.cs, add a tracking property named RowVersion:
The Timestamp attribute specifies that this column is included in the Where clause of Update and Delete commands. The attribute is called Timestamp because previous versions of SQL Server used a SQL timestamp data type before the SQL rowversion type replaced it.
The fluent API can also specify the tracking property:
modelBuilder.Entity<Department>()
.Property<byte[]>("RowVersion")
.IsRowVersion();
The following code shows a portion of the T-SQL generated by EF Core when the Department name is updated:
The preceding highlighted code shows the WHERE clause containing RowVersion. If the DB RowVersion doesn't equal the RowVersion parameter (@p2), no rows are updated.
The following highlighted code shows the T-SQL that verifies exactly one row was updated:
@@ROWCOUNT returns the number of rows affected by the last statement. In no rows are updated, EF Core throws a DbUpdateConcurrencyException.
You can see the T-SQL EF Core generates in the output window of Visual Studio.
Adding the RowVersion property changes the DB model, which requires a migration.
Build the project. Enter the following in a command window:
dotnet ef migrations add RowVersion
dotnet ef database update
The preceding commands:
Adds the Migrations/{time stamp}_RowVersion.cs migration file.
Updates the Migrations/SchoolContextModelSnapshot.cs file. The update adds the following highlighted code to the BuildModel method:
Runs migrations to update the DB.
<a name="scaffold"></a>
Follow the instructions in Scaffold the student model and use Department for the model class.
Run the following command:
dotnet aspnet-codegenerator razorpage -m Department -dc SchoolContext -udl -outDir Pages\Departments --referenceScriptLibraries
The preceding command scaffolds the Department model. Open the project in Visual Studio.
Build the project.
The scaffolding engine created a RowVersion column for the Index page, but that field shouldn't be displayed. In this tutorial, the last byte of the RowVersion is displayed to help understand concurrency. The last byte isn't guaranteed to be unique. A real app wouldn't display RowVersion or the last byte of RowVersion.
Update the Index page:
RowVersion with the last byte of RowVersion.The following markup shows the updated page:
Update Pages/Departments/Edit.cshtml.cs with the following code:
To detect a concurrency issue, the xref:Microsoft.EntityFrameworkCore.ChangeTracking.PropertyEntry.OriginalValue%2A is updated with the rowVersion value from the entity it was fetched. EF Core generates a SQL UPDATE command with a WHERE clause containing the original RowVersion value. If no rows are affected by the UPDATE command (no rows have the original RowVersion value), a DbUpdateConcurrencyException exception is thrown.
In the preceding code, Department.RowVersion is the value when the entity was fetched. OriginalValue is the value in the DB when FirstOrDefaultAsync was called in this method.
The following code gets the client values (the values posted to this method) and the DB values:
The following code adds a custom error message for each column that has DB values different from what was posted to OnPostAsync:
The following highlighted code sets the RowVersion value to the new value retrieved from the DB. The next time the user clicks Save, only concurrency errors that happen since the last display of the Edit page will be caught.
The ModelState.Remove statement is required because ModelState has the old RowVersion value. In the Razor Page, the ModelState value for a field takes precedence over the model property values when both are present.
Update Pages/Departments/Edit.cshtml with the following markup:
The preceding markup:
page directive from @page to @page "{id:int}".RowVersion must be added so post back binds the value.RowVersion for debugging purposes.ViewData with the strongly-typed InstructorNameSL.Open two browsers instances of Edit on the English department:
The two browser tabs display the same information.
Change the name in the first browser tab and click Save.
The browser shows the Index page with the changed value and updated rowVersion indicator. Note the updated rowVersion indicator, it's displayed on the second postback in the other tab.
Change a different field in the second browser tab.
Click Save. You see error messages for all fields that don't match the DB values:
This browser window didn't intend to change the Name field. Copy and paste the current value (Languages) into the Name field. Tab out. Client-side validation removes the error message.
Click Save again. The value you entered in the second browser tab is saved. You see the saved values in the Index page.
Update the Delete page model with the following code:
The Delete page detects concurrency conflicts when the entity has changed after it was fetched. Department.RowVersion is the row version when the entity was fetched. When EF Core creates the SQL DELETE command, it includes a WHERE clause with RowVersion. If the SQL DELETE command results in zero rows affected:
RowVersion in the SQL DELETE command doesn't match RowVersion in the DB.OnGetAsync is called with the concurrencyError.Update Pages/Departments/Delete.cshtml with the following code:
The preceding code makes the following changes:
page directive from @page to @page "{id:int}".RowVersion to display the last byte.RowVersion must be added so post back binds the value.Create a test department.
Open two browsers instances of Delete on the test department:
The two browser tabs display the same information.
Change the budget in the first browser tab and click Save.
The browser shows the Index page with the changed value and updated rowVersion indicator. Note the updated rowVersion indicator, it's displayed on the second postback in the other tab.
Delete the test department from the second tab. A concurrency error is display with the current values from the DB. Clicking Delete deletes the entity, unless RowVersion has been updated.
See Inheritance on how to inherit a data model.
[!div class="step-by-step"] Previous
:::moniker-end