How can I address Entity Framework context disposal issues within IIS Application Pool on an Azure VM hosting an MVC application?

Question

I am encountering an issue with the automatic disposal of the Entity Framework context within the IIS App Pool on my Azure Virtual Machine that is hosting an MVC application. The problem manifests as errors occurring on nearly all pages after a certain period of usage, which ceases after manually recycling the application pool. Previously, when the application was hosted on an EMBRATEL cloud server, this problem did not occur.

The application uses the following code to instantiate the database context:

private static ApolloDBEntities _instance;

public static ApolloDBEntities Instance
{
    get
    {
        if (_instance == null)
        {
            _instance = new ApolloDBEntities();
        }
        return _instance;
    }
}

However, it appears that at some point, this LINQ instance is being disposed unexpectedly. I have already scheduled automatic recycling of the application pool every day at 1 AM. Despite this, the issue persists.

I am seeking guidance on identifying the root cause of this problem and exploring potential solutions. Could it be related to IIS configuration, the garbage collector, or any other factors specific to the Azure environment? Any insights or recommendations on how to troubleshoot and mitigate this issue would be greatly appreciated.

Answer 1

you app probably fails when multiple users use the site, or if one page does not read all the results of a query.

While a dbcontext can be shared between threads, it does not support two concurrent queries. A second query can not be started until the first query has returned all its results. If you are using a singleton dbcontext, then you need to add locking around the queries. The lock needs to be taken before the query and released after all the entities have been read. You can use a .ToList() to read all the rows.

Be sure tracking is disabled, or you will get memory issues. You probably will anyway as dbcontext was designed to be disposed after each transaction was completed.

Answer 2

I cannot imagine the causes other than the IIS application pool recycle or use of static (i.e., singleton).

It is not appropriate to use static in the ASP.NET Web app unless it is absolutely necessary. The context class is probably not the case. The ASP.NET is multi-thread app where different thread is used to process the requests from a number of users. It means that multiple threads access singleton at the same time. You said "which ceases after manually recycling the application pool." Therefore, I guess that the use of static (i.e., singleton) is doubtful.