Entity Framework Core Pitfalls: Asynchronous vs Synchronous Calls and Interceptors

Introduction

Another on my EF Core pitfalls series. This time, interceptors and synchronous/asynchronous calls.

Problem

You surely know about EF Core interceptors, a very useful feature that I talked about many times. What's the problem with them? Well, all of the interceptor interfaces define both synchronous as well as asynchronous versions of their methods. This is so that, for example, when we call DbContext.SaveChanges the synchronous version is called, and when it's DbContext.SaveChangesAsync, the asynchronous one instead. I think you get the idea.

So, imagine we added an interceptor, inheriting from SaveChangesInterceptor, to our collection of interceptors. If we then commit the changes in the DbContext through a call to DbContext.SaveChanges, only SavingChanges, SavedChanges, SavedChangesFailed, SaveChangedCanceled and, or, ThrowingConcurrencyException methods will be called, and you may be very surprised because your well-crafted asynchronous one wasn't.

Solution

Two possible solutions:

  1. Always make sure you call the same version of each operation, synchronous or asynchronous, and implement only the matching method on the interceptors consistently
  2. Have both versions call the same shared code, for example:
public override InterceptionResult<int> SavingChanges(DbContextEventData eventData, InterceptionResult<int> result)
{
    SaveChanges(eventData.Context);
    return base.SavingChanges(eventData, result);
}

public override ValueTask<InterceptionResult<int>> SavingChangesAsync(DbContextEventData eventData, InterceptionResult<int> result, CancellationToken cancellationToken))
{
    SaveChanges(eventData.Context);
    return base.SavingChangesAsync(eventData, result, cancellationToken);
}

private void SaveChanges(DbContext context)
{
    //where the magic actually happens
}

Conclusion

Hope you find this useful. Stay tuned for more!

Location: Coimbra, Portugal

Comments

Post a Comment

Popular posts from this blog

OpenTelemetry with ASP.NET Core

Image
Introduction I wrote a post not too long ago about the building blocks of telemetry , or distributed tracing , with ASP.NET Core. Now I'm going to talk about how we can see it working using an open source bundle, otel-lgtm . Mind you, this may not be 100% suitable for production, but for development purposes, it should be fine, all concepts apply, of course. I won't cover everything about OpenTelemetry here, but should hopefully give you some insights as to what's there and how you can make good use of it. First, lets see what some of the concepts are. If you're interested in learning more about metrics, I suggest having a look at my post on this topic . OpenTelemetry OpenTelemetry  (OTel) provides a single, open-source standard, and a set of technologies to capture and export metrics, traces, and logs from your cloud-native applications and infrastructure. OTel is both a standard and a reference implementation that builds on other standards, such as W3C Distributed Tr...
Read more

ASP.NET Core Middleware

Image
Introduction This post is another of those "back to basics", still, there was one thing or two that I feel were not properly discussed elsewhere, hence this post. The ASP.NET Core Pipeline and Middleware You may know that ASP.NET Core defines a pipeline. This is where the incoming requests are processed and the response submitted. Each component in the pipeline - a middleware - can do things with the message (the request), such as check if it is authenticated and have rights to access the requested resource, turn the request into an MVC-style controller and action invocation, log it, and what not. You can read more about it here . The ASP.NET Core pipeline, from Microsoft The order by which the middleware is added to the pipeline matters. For example, the authorisation middleware must come after the authentication one, static files must come before routing, and exception handling must come before everything. The middleware order, from Microsoft A middleware is just a piece of...
Read more

.NET Cancellation Tokens

Introduction Cancellation tokens in .NET were introduced as part of the  .NET 4 Cancellation Framework . Essentially, it is a standard, cooperative, way to request for the cancellation of the execution of an operation. By cooperative it means that the code that uses it must abide to some rules, as opposed to the cancellation just stopping (killing) the execution. One example of cancellation is, on a web app, when the client closes the connection while the server is performing some long operation. In cases such as this, we may want to abort the operation, as we are not sending the results anywhere (or not, as we shall see). Because of this, ASP.NET Core allows us to add a parameter of type  CancellationToken  to our asynchronous actions, it is automatically associated with the client and is therefore signalled when the client connection is closed. A  CancellationToken  is, essentially, behind the scenes, a ManualResetEvent . Throughout this article I will either ...
Read more