Implementing FusionCache with EF Core 5

[tomaz-moharic]

Hi! First, thank you for making such a great library! I am trying to implement FusionCache into an API running on EF Core 5, Mysql and Redis. The issue is that when the FactorySoftTimeout is triggered and the factory is supposed to continue in the background and update the cache when finished, we are instead presented by an System.ObjectDisposedException error:

It looks like the DbContext gets disposed before the factory running in the background is finished working with it. How can I keep the DbContext open for the factory to finish its task?

This is my EF Core database configuration:

This is the FusionCache configuration:

And this is how FusionCache is used inside a Controller:

In the Service, DbContext object is accessed via a dependency injection.

If you need any additional information or code snippets I will be happy to provide.

I would be very thankful for any help or advice you can offer.

Kind regards,
Tomaž

[jodydonetti]

Hi! First, thank you for making such a great library!

Hi Tomaž, thanks to you for trying it out!

I am trying to implement FusionCache into an API running on EF Core 5, Mysql and Redis. The issue is that when the FactorySoftTimeout is triggered and the factory is supposed to continue in the background and update the cache when finished, we are instead presented by an System.ObjectDisposedException error
[...]
It looks like the DbContext gets disposed before the factory running in the background is finished working with it.

Yep, I think you spotted the exact issue,

Looking at your code it seems to me you have configured both EF Core and FusionCache correctly, separately: the problem seems to be in the intersection of the 2 of them + the automatic lifetime management of the DI container.

Basically it boils down to this:

• in the controller you need a DbContext
• the DbContext is injected in the controller's ctor by the DI container
• the DI container is configured (by default) to set a scoped lifetime for the DbContext
• the "scope" in this case is the web request
• when the web request is over the DbContext is automatically disposed

All of this is normally good but in this case if a soft timeout is hit, the factory (which contains the query being run) is put in a background thread and the rest of the code would go on with stale data: then, when the data from MySql starts getting back, the web request is already done and the DbContext has been disposed either before or (like in the screenshot you posted) while the results are coming back from the db.

So basically it all boils down to this point you made:

How can I keep the DbContext open for the factory to finish its task?

which is similar to this issue I've found on SO, since both of them are basically "background tasks".

To wrap things up: let me try a couple of ideas I have, will let you know as soon as possible.

And thank you for the detailed description of the issue, it has been helpful in spotting the exact issue!

[jodydonetti]

While reading some docs about EF Core, I've stumbled upon this https://docs.microsoft.com/en-us/ef/core/dbcontext-configuration/#avoiding-dbcontext-threading-issues .

Basically it says to never do multiple operations at the same time on the same DbContext (I didn't know that, I'm not that fond with EF Core). Enabling timeouts in FusionCache means that a GetOrSet operation may finish before the underlying query is finished, and that means you may also fall into this other problem, too.

Practical example: imagine doing a GetOrSet and right after that another operation with the same DbContext: if a timeout kicks in you would now have 2 operations going on at the same time.

A solution to this is for the factory to use a different single purpose DbContext, but honestly I don't think it's a thing of beauty.

My suggestion - while I keep on trying to find a solution to this - is to not enable timeouts and use FusionCache with the other features, like cache stampede prevention, fail-safe, etc.

Anyway I'll keep studying this issue to see if I can find something better.

[jodydonetti]

Hi @tomaz-moharic , since as we said we are basically talking about the combo db context + background execution, I think this may be a solution https://blog.hildenco.com/2018/12/accessing-entity-framework-context-on.html

I admit it may not be super beautiful (and I will keep trying to find a nicer one) but at least it may solve your issue.

Please let me know if this helped.

[tomaz-moharic]

Thank you so much for all the effort and suggestions, I'll read through, give it a try and let you know how it worked! I am super busy at the moment so it might take me a day or two, but I will let you know asap when I find out anything.

[jodydonetti]

Hi @tomaz-moharic , did you happen to find some time and try these?

I think I've found a nice way to put all of this togheter to handle this scenario which would support timeouts, is (I hope 😅) nicely designed, does not get in the way of the IOC container/lifetimes/disposability/etc and should not be problematic in terms of perf, allocations, etc.

Let me know if you are interested.

[tomaz-moharic]

Hi @jodydonetti!

Hi @tomaz-moharic , since as we said we are basically talking about the combo db context + background execution, I think this may be a solution https://blog.hildenco.com/2018/12/accessing-entity-framework-context-on.html

I admit it may not be super beautiful (and I will keep trying to find a nicer one) but at least it may solve your issue.

Please let me know if this helped.

First of all, thank you for the suggestion above, it is working without any issues.

I am however very much interested in a more elegant solution, that I could put in production without feeling anxious 😄.

Thanks for all the time you are putting into this!

[jodydonetti]

Ok, this evening (italian time) I'll write it down 👍

[tomaz-moharic]

Great, thanks!

[jodydonetti]

Hi @tomaz-moharic , sorry for being uber late 😅

So, here's my thinking: in general reusing the same DbContext during the execution of an mvc action is the right thing to do, because of unit of work support, the ability to save a batch of changes with only one call to the db at the end with a single SaveChanges(), etc.
But this is true only if you want to change data in the action.

If instead you simply want to read some data, and even more so if you may read that from a cache, you absolutely don't want that, because the entity would be detached from the current DbContext. On top of this, if you'll only read data it may be a good idea to disable change tracking to get better perf (save some cpu cycles and memory allocations).

All in all I think the right solution would be to just use a new throwaway DbContext for every read operation, and to also NOT have that DbContext lifetime's linked to the controller's lifetime, so to avoid the exception you encountered here.

I also see in your screenshots that you already have some sort of service ("ServiceContestFindReturnModel", so I guess there's a ContestService class or something similar).

So, in the end I would make that service dependent of the IServiceScopeFactory interface (by putting it in the ctor) and then, inside each specific method (egFindModelByWhatever) you just create a new throwaway scope via scopeFactory.CreateScope() that would have its lifetime tied to that operation, something like this:

public class ContestService {
  private IServiceScopeFactory _scopeFactory;

  // CTOR
  public ContestService(IServiceScopeFactory scopeFactory, [...]) {
    _scopeFactory = scopeFactory;
    [...]
  }

  [...]

  public async Task<ServiceContestFindReturnModel> FindByWhateverAsync(ContestFindModel findModel) {
    using (var scope = _scopeFactory.CreateScope()) {
      using (var dbctx = scope.GetRequiredService<YourDbContext>()) {
        // DO YOUR THINGS HERE...
      }
    }
  }

  [...]
}

In case you are worried about creating too many DbContexts and using them for just 1 query, I don't think it would be a problem: you are already basically doing that in each action, and I see you also enabled dbctx pooling, which will reuse them instead of creating a new one each time.

One more thing: it may be the case that you find it strange or kinda "dirty" to have this sort of split between reading+writing data (reusing the same DbContext + save changes at the end, etc) and only reading data (one DbContext per shot, disable change tracking, etc). But that is in line with the known CQS approach (not necessarily the full CQRS/EventSourcing thing) where the read model/flow (query) is separate from the write one (command).
Just something to notice.

Hope this helps!

[jodydonetti]

Hi @tomaz-moharic , did you happen to have time to take a look at this?

[jodydonetti]

Closing this since the suggested solutions worked well.