When to use PerThreadLifetimeManager?

by

The Per Thread Lifetime is a very dangerous lifestyle and in general you should not use it in your application, especially web applications.

This lifestyle should be considered dangerous, because it is very hard to predict what the actual lifespan of a thread is. When you create and start a thread using new Thread().Start(), you’ll get a fresh block of thread-static memory, which means the container will create a new per-threaded instance for you. When starting threads from the thread pool using ThreadPool.QueueUserWorkItem however, you get possibly an existing thread from the pool. The same holds when running in ASP.NET. ASP.NET pools threads to increase performance.

This means that a thread will almost always outlive a web request. ASP.NET on the other hand can run requests asynchronously, which means that a web request can be finished at a different thread. And this is a problem when working with a Per Thread lifestyle. And of course this effect is amplified when you start using async/await.

This is a problem since you will typically call Resolve<T> once at the beginning of the request. This will load the complete object graph including your services that are registered with the Per Thread lifestyle. When ASP.NET finishes the request at a different thread, this means that the resolved object graph moves to this new thread, including all Per Thread registered instances.

Since these instances are registered as Per Thread, they are probably not suited to be used at another thread. They are almost certainly not thread-safe (otherwise they would be registered as Singleton). Since the first thread that initially started the request is already free to pick up new requests, you can run into the situation where two threads access those Per Thread instances simultaneously. This will lead to race conditions and bugs that are hard to diagnose and find.

So in general, using Per Thread is a bad idea. Instead use a lifestyle that has a clear scope (an implicit or explicitly defined begin and end). The Per Web Request lifestyle that most DI frameworks implement is often implicitly scoped (you don’t have to end it yourself).

Specific to your question

To make things worse, the blog post you referenced contains a configuration error. The ICatalogService is defined with a Per Thread lifestyle. This service however depends on an IDALContext service, which is defined as Transient. Since a reference to a IDALContext instance is stored as private field inside the CatalogService, this means the DALContext lives as long as the ICatalogService does. This is a problem because IDALContext is defined as Transient and is probably not thread-safe.

The General Rule Of Lifestyle

The general rule is to let components only depend on services with an equal or longer lifetime. So a Transient can depend on a Singleton but not the other way around.

Since a Per Thread registered component will typically live very long, it can typically only safely depend on other Per Thread or Singleton instances. And since ASP.NET can split a single request up in multiple threads, it is not safe to use Per Thread in the context of a ASP.NET application (both MVC, Web Forms, and especially Web API).

More Related Contents:

  1. Is there a pattern for initializing objects created via a DI container
  2. Comparing Castle Windsor, Unity and StructureMap
  3. Ioc/DI – Why do I have to reference all layers/assemblies in application’s entry point?
  4. Why not use an IoC container to resolve dependencies for entities/business objects?
  5. What is a composition root in the context of dependency injection?
  6. Dependency Injection vs Factory Pattern
  7. Dependency Injection in attributes
  8. How do the major C# DI/IoC frameworks compare? [closed]
  9. How to implement Unit Of Work pattern with Dapper?
  10. Dependency Injection Unity – Conditional Resolving
  11. Inversion of Control < Dependency Injection [closed]
  12. Dependency injection through constructors or property setters?
  13. Unity Inject dependencies into MVC filter class with parameters
  14. Avoiding all DI antipatterns for types requiring asynchronous initialization
  15. Is UnitOfWork and GenericRepository Pattern redundant In EF 4.1 code first?
  16. Is there a good/proper way of solving the dependency injection loop problem in the ASP.NET MVC ContactsManager tutorial?
  17. Looking for a Ninject scope that behaves like InRequestScope
  18. When are .NET Core dependency injected instances disposed?
  19. How to extend a component with dependency injection?
  20. Meaning of bean discovery mode annotated in CDI 1.1
  21. Property Injection in ASP.NET Core
  22. Dagger @Reusable scope vs @Singleton
  23. MEF (Managed Extensibility Framework) vs IoC/DI
  24. ASP.Net Core Call a controller from another controller
  25. When to use Dependency Injection
  26. Passing constructor arguments when using StructureMap
  27. Net Core Dependency Injection for Non-Controller
  28. How do I handle classes with static methods with Ninject?
  29. Windsor castle Injecting properties of constructed object
  30. Singleton Per Call Context (Web Request) in Unity

Leave a Comment