Entity Framework Core: Postgres Concurrency Checks
Last week’s post on SQLite Concurrency Checks used this repo which contains examples of using Entity Framework Core with SQLite and Postgres. This post is going to tackle concurrency checks using Postgres to keep the projects in the repo with the same level of functionality. You can grab the sample code before any change here. This whole post will only be touch files found in the Postgres folder/project.
Context Changes and Data Migration
Unlike SQLite, Postgres has better built-in support for concurrency checks. If you read the official docs on Optimistic Concurrency and Concurrency Tokens you will find that all tables have an implicit/hidden system column call xmin which holds the ID of the latest updating transaction which means it gets changed automatically every time a row is changed.
The Postgres Entity Framework Core provide contains an extension that makes it very simple to use the xmin column as a concurrency token. In the ContactDbContext add the following to the OnModelCreating function to enable concurrency checking on the specified entity, in this case, a Contact.
modelBuilder.Entity<Contact>().ForNpgsqlUseXminAsConcurrencyToken();
Next, from a command prompt in the same directory as your project file using the following .NET CLI command to generate a migration for the above change. This migration is a bit strange since the column technically already exists, but the migration seemed to be needed.
dotnet ef migrations add Concurrency --context ContactsDbContext
Then, use the following command to apply the migration to your database.
dotnet ef database update --context ContactsDbContext
Testing it out
For a quick and dirty test, I added a ConcurrencyTest razor page under the Contacts directory. This function is going to ensure a specific contact exists, then pull the contact from two different DBContexts, make a mutation on the resulting contact objects, then attempt to save. The first save will work and the second should fail. Please note that this function isn’t an example of how things should be done just a quick and dirty way to prove that the concurrency check is happening.
public void OnGet()
{
var context1 =
new ContactsDbContext(new DbContextOptionsBuilder<ContactsDbContext>()
.UseNpgsql("yourConnectionString")
.Options);
var contactFromContext1 = context1.Contacts
.FirstOrDefault(c => c.Name == "Test");
if (contactFromContext1 == null)
{
contactFromContext1 = new Contact
{
Name = "Test"
};
context1.Add(contactFromContext1);
context1.SaveChanges();
}
var context2 =
new ContactsDbContext(new DbContextOptionsBuilder<ContactsDbContext>()
.UseNpgsql("yourConnectionString")
.Options);
var contactFromContext2 = context2.Contacts
.FirstOrDefault(c => c.Name == "Test");
contactFromContext1.Address = DateTime.Now.ToString();
contactFromContext2.Address = DateTime.UtcNow.ToString();
context1.SaveChanges();
context2.SaveChanges();
}
Run the application and hit the ConcurrenctTest route which is https://localhost:44324/Contacts/ConcurrencyTest for my test. The following is the resulting exception.
An unhandled exception occurred while processing the request.
DbUpdateConcurrencyException: Database operation expected to affect 1 row(s) but actually affected 0 row(s). Data may have been modified or deleted since entities were loaded. See http://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions.
Wrapping Up
This process was much simpler using Postgres than SQLite. Not that the SQLite version was hard just not as simple of a path.
The code in its final state can be found here.
Entity Framework Core: Postgres Concurrency Checks Read More »
