Being new to the Entity Framework, I'm really rather stuck on how to proceed with this set of issues. On the project I am currently working on, the entire site is heavily integrated with the EF model. At first, the access to the EF context was being controlled using an Dependency Injection bootstrapper. For operational reasons we were not able to use an DI library. I removed this and used a model of individual instances of the context object where required. I started getting the following exception:
The type 'XXX' has been mapped more than once.
We came to the conclusion that the different instances of the context were causing this issue. I then abstracted the context object into a single static instance which was being accessed by each thread/page. I'm now getting one of several exceptions about transactions:
New transaction is not allowed because there are other threads running in the session.
The transaction operation cannot be performed because there are pending requests working on this transaction.
ExecuteReader requires the command to have a transaction when the connection assigned to the command is in a pending local transaction. The Transaction property of the command has not been initialized.
The last of these exceptions occurred on a load operation. I wasn't trying to save the context state back to the Db on the thread that failed. There was another thread performing such an operation however.
These exceptions are intermittent at best, but I have managed to get the site to go into a state where new connections were refused due to a transaction lock. Unfortunately I cannot find the exception details.
I guess my first question is, should the EF model be used from a static single instance? Also, is it possible to remove the need for transactions in EF? I've tried using a TransactionScope object without success...
To be honest I'm a lot stuck here, and cannot understand why (what should be) fairly simple operations are causing such an issue...
Creating one global Entity Framework DbContext in a web application is very bad. The DbContext class is not thread-safe (and same holds for Entity Framework v1's ObjectContext class). It is built around the concept of the unit of work and this means you use it to operate a single use case: thus for a business transaction. It is meant to handle one single request.
The exception you get happens because for each request you create a new transaction, but try to use that same DbContext. You are lucky that the DbContext detects this and throws an exception, because now you found out that this won't work.
The DbContext contains a local cache of entities in your database. It allows you to make a bunch of changes and finally submit those changes to the database. When using a single static DbContext, with multiple users calling SaveChanges on that object, how is it supposed to know what exactly should be committed and what shouldn't?
Because it doesn't know, it will save all changes, but at that point another request might still be making changes. When you're lucky, either EF or your database will fail, because the entities are in an invalid state. If you're unlucky, entities that are in an invalid state are successfully saved to the database and you might find out weeks later that your data got corrupted.
The solution to your problem is to create at least one DbContext per request. While in theory you could cache an object context in the user session, this also is a bad idea, because in that case the DbContext will typically live too long and will contain stale data (because its internal cache will not automatically be refreshed).
UPDATE (2023): Note that caching a DbContext in a user session is very different from the modern DbContext pooling that recent versions of Entity Framework support. With context pooling, Entity Framework will clear the cache of a DbContext, once its returned to the pool to prevent the dreaded issues I described above.
Also note that having one DbContext per thread is about as bad as having one single instance for the complete web application. ASP.NET uses a thread pool which means that a limited amount of threads will be created during the lifetime of a web application. This basically means that those DbContext instances will in that case still live for the lifetime of the application, causing the same problems with staleness of data.
You might think that storing a DbContext in the thread-case of a single .NET (managed) thread would be thread-safe, but this is usually not the case, as ASP.NET has an asynchronous model that allows finishing requests on a different thread than where it was started (and the latest versions of MVC and Web API even allow an arbitrary number of threads handle one single request in sequential order). This means that the thread that started a request and created the DbContext can become available to process another request long before that initial request finished. The objects used in that request however (such as a web page, controller, or any business class), might still reference that DbContext. Since the new web request runs in that same thread, it will get the same DbContext instance as what the old request is using. This again causes race conditions in your application and cause the same thread-safety issues as what one global DbContext instance causes.
UPDATE (2023): Modern frameworks such as ASP.NET Core use an asynchronous programming model (async/await) across its stack. This amplifies the effect of thread switching even more. One single web request could easily run over a number different threads.