Question

We have been trying to analyse this exception:

Message: Error: Object reference not set to an instance of an object..
Stacktrace: at System.RuntimeTypeHandle.CreateInstance(RuntimeType
type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached,
RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) at
System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean
skipCheckThis, Boolean fillCache) at
System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly,
Boolean skipVisibilityChecks, Boolean skipCheckThis, Boolean
fillCache) at System.Activator.CreateInstanceT at
Z.Services.ObjectContextManagement.ScopedObjectContextManager1.get_ObjectContext()
at Z.Services.DatabaseAccess.DatabaseAccess2.Manage() at
Z.Services.DatabaseAccess.DatabaseAccess`2.get_ObjectContext()

Basically we get an error when getting the ObjectContext.

From this question: Entity Framework lazy loading doesn't work from other thread we see that EF is dependent upon staying on the same thread.

From this Jon Skeet’s answer to this question: Will a request in IIS run on a single thread? we see that IIS has thread agility.

When there is a lower traffic volumn we do not see this error, but when the load increases we see the error.

So the question: If EF is dependent upon staying on a single thread, and IIS does not keep the request on a single thread, can EF be used on an application that is deployed on IIS?

Edit

var frameworkAssembly = Assembly.GetAssembly(typeof(ObjectContextManager<>));
var managerType = frameworkAssembly.GetType(managerTypeName + "`1", true, true);
managerType = managerType.MakeGenericType(typeof(TObjectContext));
ObjectContextManager = Activator.CreateInstance(managerType) as ObjectContextManager<TObjectContext>;

It appears that the error occurs on the last line of the above code. The error only occurs in production under heavy load.

Edit 2

The ObjectContextManager inherits from ObjectContext which is an EF class.

 public abstract class ObjectContextManager<T> where T : ObjectContext

Answer 1

I’ve hit some issues with thread agility and IIS recently. IIS can shift the thread of a request as it goes through the pipeline. This doesn’t mean you have to be more aware of concurrency; what is important is the way context data is attached to the thread.

In an ASP.NET environment, this storage is done via the HttpContent.Current variable, which holds details for the current request being handled on the current thread. It does this via the System.Runtime.Remoting.Messaging.CallContext.HostContext variable.

Many solutions for keeping data per thread make use of the ThreadStatic attribute, however this fails in an ASP environment because of the thread switch. The thread static starts off valued, then appears to become null midway through the processing pipeline.

ASP.NET will keep track of the HttpContext, the CurrentPrincipal, and possibly the locale as well. CallContext data and data stored in ThreadStatic variables is not copied.

The answer, while irritating, is to change the strategy and use HttpContext.Current.Items instead of CallContext or thread statics.

In your case, check the strategy in use for EF, and see if the implementation is pluggable.

As Jon Skeet points out, more information is available on Cup(Of T), but use this more as a launchpad for your discovery rather than an end in itself.