Asp.net web api + entity framework: multiple requests cause data conflict

Question

I'm developing an app with VS2013, using EF6.02, and Web API 2. I'm using the ASP.NET SPA template, and creating a RESTful api against an entity framework data source backed by a sql server. (In development, this resides on the SQL Server local instance.)

I've got two API methods so far (one that just reads data, one that writes data), and I'm testing them by calling them in the javascript. When I only call a single method in my script, either one works perfectly. But if I call both in script (without waiting for either's callback to fire), I get bad results and different exceptions in the debugger. Some exceptions state that the save can't be completed because there are pending transactions. Another exception stated something about a conflict with other threads. And sometimes, the read operation fails with a null pointer exception when trying to read a result set.

"New transaction is not allowed because there are other threads running in the session."

This makes me question if I'm correctly getting a new DBContext per request. My code for this looks like:

    static Startup()
    {
        context = new Data.SqlServer.AppDbContext();
  ...
    }

and then whenever instantiating a unit of work, I access Startup.context.

I've tried to implement the unit of work pattern, and each request shares a single UOW object which has a single DBContext object.

My question: Do I have additional responsibility to ensure that web requests "play nicely" with eachother? I hope that this is a problem that others have already dealt with. Perhaps the errors that I'm seeing are legitimate in the sense that if one user's data is being touched, it is temporarily in an invalid state and if other requests come in at that exact moment, they indeed will fail (and I should code anticipating these failures). I guess that even if each request has its own DBContext, they still share the same underlying SQL data source so perhaps that's causing issues.

I can try to put together a testcase, but I get differing behavior depending on where I put breakpoints and how long I spend on them, reaffirming to me that this is timing related.

Thanks for any help or suggestions... -Ben

score 2 · Accepted Answer · answered Dec 22 '13 at 16:59

Your problem is where you are setting your context. The Startup method is for when the entire application starts, thus any request made will all use the same context. This is not a per request setup, but rather a per application setup. As to why you are getting the errors, EntityFramework is NOT thread-safe. Since IIS spawns many threads to handle concurrent request, your single context is being used across multiple threads.

As for a solution, you can look into

-Dependency Injection frameworks (such as Ninject or Unity)

-place a using statement in your UnitOfWork classes

using(var context = new Data.SqlServer.AppDbContext()){//do stuff}

-Or, I have seen instances of people creating a class that gets the context for that request and stores it in the HttpContext.Cache[] element (using a unique name so you can retrieve it in another class easily), making it so that you will reuse the same context for the same request. Something like this:

public AppDbContext GetDbContext()
    {
        var httpContext = HttpContext.Current;
        if (httpContext == null) return new AppDbContext();
        const string contextTypeKey = "AppDbContext";
        if (httpContext.Items[contextTypeKey] == null)
        {
            httpContext.Items.Add(contextTypeKey, new AppDbContext());
        }
        return httpContext.Items[contextTypeKey] as AppDbContext;
    }

To use the above method, make a simple call var context = GetDbContext();

Note

We have all of the above methods, but this is specifically to the third method. It seems to work well with two caveats. First, do not use this in a using statement as it will not be available to any other classes during the scope of the request (you dispose it). And secondly, ensure that you have a call on Application_EndRequest that does actually dispose of it. We saw these little buggers hanging around after the request ended in memory causing a huge spike in memory usage.

Thanks very much for the detailed response, Tommy. Time for me to roll up my sleeves! — BenjiFB, Dec 22 '13 at 18:16
I had another thought: Instead of a 'using' statement, would it make sense to instantiate the data context inside the constructor of the controller? — BenjiFB, Dec 22 '13 at 21:49
@BenjiFB - sure, thats where option one comes into play. You can use Ninject/Unity to inject a context into your controller / unit of work classes, etc. These can also be configured as once per request so you are not injected a new copy each time if you so choose. — Tommy, Dec 22 '13 at 21:53
Hey @Tommy, I had a followup question for you: The reason why I did the init in the Startup method is because I used the VS2013 SPA template, and that's where they initialized the UserManager object. The template used the overload that took no DbContext, so I explicitly created the DbContext and passed it in (so I could reuse it). But this begs the question: while it seems necessary to scope the DbContext smaller (to the individual request instead of app startup), can we leave the UserManager scoped to the whole app? Or is the template using a bad practice? (Continued below) — BenjiFB, Dec 26 '13 at 13:00
You can disregard that comment. I think my new question is different enough that I posted it separately: http://stackoverflow.com/questions/20790990/why-does-the-asp-net-spa-template-instantiate-usermanager-once-for-all-requests — BenjiFB, Dec 26 '13 at 20:43

Asp.net web api + entity framework: multiple requests cause data conflict

1 Answers1