Singleton Per Call Context (Web Request) in Unity

Neat solution, but each instance of LifetimeManager should use a unique key rather than a constant:

private string _key = string.Format("PerCallContextLifeTimeManager_{0}", Guid.NewGuid());

Otherwise if you have more than one object registered with PerCallContextLifeTimeManager, they're sharing the same key to access CallContext, and you won't get your expected object back.

Also worth implementing RemoveValue to ensure objects are cleaned up:

public override void RemoveValue(){     CallContext.FreeNamedDataSlot(_key);}

While this is fine calling this PerCallContextLifeTimeManager, I'm pretty sure this is not "safe" to be considered an ASP.Net Per-request LifeTimeManager.

If ASP.Net does its thread-swap then the only thing taken across to the new thread through CallContext is the current HttpContext - anything else you store in CallContext will be gone. This means under heavy load the code above could have unintended results - and I imagine it would be a real pain to track down why!

The only "safe" way to do this is with HttpContext.Current.Items, or doing something like:

public class PerCallContextOrRequestLifeTimeManager : LifetimeManager{    private string _key = string.Format("PerCallContextOrRequestLifeTimeManager_{0}", Guid.NewGuid());    public override object GetValue()    {      if(HttpContext.Current != null)        return GetFromHttpContext();      else        return GetFromCallContext();    }    public override void SetValue(object newValue)    {      if(HttpContext.Current != null)        return SetInHttpContext();      else        return SetInCallContext();    }    public override void RemoveValue()    {    }}

This obviously means taking dependencies on System.Web :-(

Much more information on this available at:

http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html

Thanks for your contribution,

But the question proposed implementation has two drawbacks, one of which is a serious bug as already stated by Steven Robbins in his answer and Micah Zoltu in a comment.

1. Call context is not guaranteed to be preserved by Asp.Net for a single request. Under load, it can switch to another one, causing proposed implementation to break.
2. It does not handle releasing of dependencies at request end.

Currently, Unity.Mvc Nuget package supplies a PerRequestLifetimeManager for doing the work. Do not forget to register its associated UnityPerRequestHttpModule in bootstrapping code otherwise dependencies releasing will not be handled either.

Using bootstrapping

DynamicModuleUtility.RegisterModule(typeof(UnityPerRequestHttpModule));

or in web.config system.webServer/modules

<add name="UnityPerRequestHttpModule" type="Microsoft.Practices.Unity.Mvc.UnityPerRequestHttpModule, Microsoft.Practices.Unity.Mvc" preCondition="managedHandler" />

It appears its current implementation is also suitable for web forms. And it does not even depend on MVC. Unfortunately, its assembly does, because of some other classes it contains.

Beware, in case you use some custom http module using your resolved dependencies, they may be already disposed in the module EndRequest. It depends on module execution order.