Lifetime Management - Learning Module

Loading content...

0/246

Transient Lifetime — New Instance Each Time

The Lifetime Question

When you register a service with a dependency injection container, you're answering two fundamental questions: What should be created? and How long should it live? The first question is about types and interfaces. The second—the question of lifetime—is where the real complexity emerges.

Lifetime management determines how many instances of a service exist, when they're created, when they're disposed, and who shares them. Get it wrong, and you'll face memory leaks, stale data, thread-safety violations, or subtle bugs that manifest only under specific conditions. Get it right, and your application becomes predictable, efficient, and maintainable.

Transient lifetime is the simplest of the three major lifetime strategies. Every time you request a transient service, you receive a brand-new instance. No sharing, no caching, no ambiguity. This simplicity makes transient lifetime the safest default—but also potentially the most wasteful.

What You Will Learn

By the end of this page, you will understand transient lifetime at a deep level: its semantics, its memory implications, when it's the right choice, and when its apparent simplicity masks hidden costs. You'll learn to reason about instance creation graphs and identify scenarios where transient services are essential versus wasteful.

Defining Transient Lifetime

A transient service is one that the container creates anew for every single request. There is no object reuse whatsoever. If Component A requests a Logger and Component B requests the same Logger service one millisecond later, they receive two different Logger instances.

This behavior stems from a fundamental design choice: stateless independence. Each consumer gets its own exclusive instance, ensuring:

No shared mutable state — One consumer cannot corrupt another's dependency
No threading concerns — Each thread naturally gets its own instances
Predictable disposal — Lifetime is bound to the consumer, not to global scope
Simple reasoning — What you create is yours alone

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// In .NET Core / .NET 5+
public void ConfigureServices(IServiceCollection services)
{
    // Every request for IEmailSender creates a new SmtpEmailSender
    services.AddTransient<IEmailSender, SmtpEmailSender>();
    
    // Every request for IValidator creates a new OrderValidator
    services.AddTransient<IValidator<Order>, OrderValidator>();
    
    // Factory-based transient with custom creation logic
    services.AddTransient<IDocumentProcessor>(provider => 
    {
        var config = provider.GetRequiredService<IConfiguration>();
        var logger = provider.GetRequiredService<ILogger<PdfProcessor>>();
        return new PdfProcessor(config["Pdf:LibraryPath"], logger);
    });
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// In Spring Framework, transient is called "prototype" scope
@Configuration
public class AppConfig {
    
    // Every request creates a new EmailSender
    @Bean
    @Scope("prototype")
    public EmailSender emailSender() {
        return new SmtpEmailSender();
    }
    
    // Alternative: using component scanning
}
 
@Component
@Scope("prototype")
public class DocumentProcessor {
    private final Logger logger;
    
    @Autowired
    public DocumentProcessor(Logger logger) {
        this.logger = logger;
        System.out.println("New DocumentProcessor created: " + this.hashCode());
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// In InversifyJS
import { Container, injectable, inject } from "inversify";
 
const container = new Container();
 
// Default binding is transient - each get() returns new instance
container.bind<IEmailSender>(TYPES.EmailSender)
    .to(SmtpEmailSender)
    .inTransientScope();
 
// Demonstrating transient behavior
const sender1 = container.get<IEmailSender>(TYPES.EmailSender);
const sender2 = container.get<IEmailSender>(TYPES.EmailSender);
console.log(sender1 === sender2); // false - different instances
 
// In NestJS
@Injectable({ scope: Scope.TRANSIENT })
export class ReportGenerator {
    private readonly instanceId = Math.random();
    
    constructor(private readonly logger: Logger) {
        this.logger.log(`ReportGenerator ${this.instanceId} created`);
    }
}

Instance Creation Mechanics

Understanding how containers create transient instances reveals important performance characteristics. When you request a transient service, the container must:

Resolve the registration — Look up how to create the requested type
Resolve dependencies — Recursively resolve all constructor dependencies
Invoke the constructor — Allocate memory and call the constructor
Perform property injection — If configured, inject additional properties
Return the instance — Hand off the fully-constructed object

This process happens every time. For deeply nested dependency graphs, transient services can trigger significant object creation cascades.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Consider this dependency chain - ALL are transient
public class OrderController
{
    private readonly IOrderService _orderService;
    public OrderController(IOrderService orderService) => _orderService = orderService;
}
 
public class OrderService : IOrderService
{
    private readonly IOrderRepository _repository;
    private readonly IEmailSender _emailSender;
    private readonly IAuditLogger _auditLogger;
    
    public OrderService(
        IOrderRepository repository,
        IEmailSender emailSender,
        IAuditLogger auditLogger)
    {
        _repository = repository;
        _emailSender = emailSender;
        _auditLogger = auditLogger;
    }
}
 
public class OrderRepository : IOrderRepository
{
    private readonly IDbContextFactory _contextFactory;
    private readonly ILogger<OrderRepository> _logger;
    
    public OrderRepository(
        IDbContextFactory contextFactory, 
        ILogger<OrderRepository> logger)
    {
        _contextFactory = contextFactory;
        _logger = logger;
    }
}
 
// If ALL services are transient, resolving OrderController creates:
// - 1 OrderController
// - 1 OrderService  
// - 1 OrderRepository
// - 1 IDbContextFactory
// - 1 ILogger<OrderRepository>
// - 1 EmailSender
// - 1 AuditLogger
// = 7+ objects per controller resolution!

The Cascade Effect

When a transient service depends on other transient services, object creation cascades through the entire graph. In web applications handling thousands of requests per second, this can create millions of short-lived objects, stressing the garbage collector significantly. This doesn't mean transient is wrong—it means you must design with awareness.

Visualizing the Creation Timeline:

Consider what happens during two consecutive HTTP requests when services are transient:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Request 1 (Thread A):
├── Resolve OrderController → NEW instance #1
│   └── Resolve IOrderService → NEW OrderService #1
│       ├── Resolve IOrderRepository → NEW OrderRepository #1
│       ├── Resolve IEmailSender → NEW EmailSender #1
│       └── Resolve IAuditLogger → NEW AuditLogger #1
├── Execute controller action
└── Request completes → All instances eligible for GC
 
Request 2 (Thread B, 1ms later):
├── Resolve OrderController → NEW instance #2 (NOT #1 reused!)
│   └── Resolve IOrderService → NEW OrderService #2
│       ├── Resolve IOrderRepository → NEW OrderRepository #2
│       ├── Resolve IEmailSender → NEW EmailSender #2
│       └── Resolve IAuditLogger → NEW AuditLogger #2
├── Execute controller action
└── Request completes → All instances eligible for GC
 
After 1000 requests: 5000+ objects created and garbage collected

Memory and Garbage Collection Implications

Transient instances are short-lived by design. They're created, used briefly, and then become garbage. This pattern has specific implications for memory management and garbage collection:

Advantages:

Objects are typically small and die young (Gen 0 collection)
No long-lived references prevent collection
Memory is reclaimed promptly after request completion
Peak memory usage stays bounded

Disadvantages:

High allocation rate in hot paths
GC overhead from frequent collections
Potential for Gen 0 exhaustion under high load
Object construction costs cannot be amortized

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// Diagnostic code to understand transient allocation impact
public class DiagnosticEmailSender : IEmailSender
{
    private static int _instanceCount = 0;
    private readonly int _instanceId;
    
    public DiagnosticEmailSender()
    {
        _instanceId = Interlocked.Increment(ref _instanceCount);
        Console.WriteLine($"EmailSender #{_instanceId} created. Total: {_instanceCount}");
    }
    
    ~DiagnosticEmailSender()
    {
        Console.WriteLine($"EmailSender #{_instanceId} finalized");
    }
    
    public Task SendAsync(Email email)
    {
        // Implementation
    }
}
 
// After 10,000 requests:
// "EmailSender #10000 created. Total: 10000"
// (Finalizer output scattered throughout as GC runs)
 
// Contrast with singleton - would show:
// "EmailSender #1 created. Total: 1"
// (No finalizer output until application shutdown)

GC Pressure Comparison: Transient vs Singleton
Metric	All Transient	Mixed Lifetimes	Impact
Objects/Request	7-15 (typical)	2-4 (service layer)	3-5x more allocations
Gen 0 Collections	Frequent	Occasional	CPU overhead
GC Pause Time	Many small pauses	Fewer pauses	Latency jitter
Memory Churn	High	Moderate	Cache locality
Peak Memory	Bounded	Higher baseline	Different trade-off

When GC Overhead Matters

For most applications, modern GC handles transient allocations efficiently. Concern about GC overhead typically matters only for: (1) Very high-throughput systems (10K+ requests/second), (2) Latency-sensitive applications (real-time, gaming), or (3) Resource-constrained environments. Profile before optimizing—premature optimization with lifetimes can introduce bugs.

Thread Safety Characteristics

Transient services provide natural thread isolation. Since each request (typically on its own thread) receives its own instance, there's no shared state to protect. This is the core appeal of transient lifetime for services that maintain internal state.

Consider the contrast:

Transient: Thread-Safe by Isolation

•Each thread gets its own instance
•No locks needed for internal state
•No race conditions possible
•Instance state is inherently private
•Simple code, correct behavior

Singleton: Requires Explicit Safety

•All threads share one instance
•Must be stateless or lock-protected
•Race conditions if not careful
•All state is potentially shared
•Complex code, brittle behavior

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
// This service maintains per-request state
// Transient lifetime makes it inherently safe
public class RequestCorrelator : IRequestCorrelator
{
    private readonly List<string> _events = new();
    private readonly Stopwatch _stopwatch = Stopwatch.StartNew();
    
    public void RecordEvent(string eventName)
    {
        // NO LOCKING NEEDED - this instance serves only one request
        _events.Add($"{_stopwatch.ElapsedMilliseconds}ms: {eventName}");
    }
    
    public IReadOnlyList<string> GetEventLog() => _events.AsReadOnly();
}
 
// Registration
services.AddTransient<IRequestCorrelator, RequestCorrelator>();
 
// Usage in controller
public class OrderController : ControllerBase
{
    private readonly IRequestCorrelator _correlator;
    private readonly IOrderService _orderService;
    
    public OrderController(IRequestCorrelator correlator, IOrderService orderService)
    {
        _correlator = correlator;
        _orderService = orderService;
    }
    
    [HttpPost]
    public async Task<IActionResult> CreateOrder(OrderRequest request)
    {
        _correlator.RecordEvent("Received request");
        var order = await _orderService.CreateAsync(request);
        _correlator.RecordEvent("Order created");
        
        // Log for diagnostics - shows events only from THIS request
        _logger.LogInformation("Request timeline: {Events}", 
            string.Join(", ", _correlator.GetEventLog()));
        
        return Ok(order);
    }
}

The Same Service as Singleton Would Break

If RequestCorrelator were registered as singleton, all concurrent requests would write to the same _events list, creating race conditions, corrupted data, and meaningless logs. The same code that's perfectly safe as transient becomes a critical bug as singleton. Lifetime choice fundamentally affects correctness, not just performance.

When to Use Transient Lifetime

Transient is the right choice in several well-defined scenarios. Understanding these patterns helps you make confident lifetime decisions:

Ideal Scenarios for Transient Lifetime

•Services with per-request state — Any service that accumulates state during its lifetime: request correlators, validation collectors, workflow trackers, operation contexts.
•Lightweight, stateless services — Services that are cheap to construct and maintain no state: simple validators, mappers, formatters. The creation overhead is negligible.
•Services wrapping disposable resources — When each use needs its own resource: file handles, HTTP connections, database readers. The transient scope ensures proper disposal.
•Services with non-thread-safe dependencies — When your service uses libraries that aren't thread-safe, transient isolation prevents threading bugs.
•Factory-created services — When services need runtime parameters: services.AddTransient<IReport>(sp => new Report(userId, reportDate)).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Use Case 1: Per-request validation context
public interface IValidationContext
{
    void AddError(string field, string message);
    bool IsValid { get; }
    IEnumerable<ValidationError> Errors { get; }
}
 
// MUST be transient - accumulates errors for single validation operation
services.AddTransient<IValidationContext, ValidationContext>();
 
// Use Case 2: Wrapping non-thread-safe library
public class ExcelExporter : IExcelExporter
{
    private readonly ExcelPackage _package; // EPPlus is not thread-safe
    
    public ExcelExporter()
    {
        _package = new ExcelPackage(); // Each export gets fresh instance
    }
    
    public byte[] Export(ReportData data) { /* ... */ }
}
 
services.AddTransient<IExcelExporter, ExcelExporter>();
 
// Use Case 3: Simple stateless utility
public class DateFormatter : IDateFormatter
{
    // No state, cheap to construct
    public string FormatForDisplay(DateTime date) => date.ToString("MMM dd, yyyy");
    public string FormatForApi(DateTime date) => date.ToString("O");
}
 
services.AddTransient<IDateFormatter, DateFormatter>();
 
// Use Case 4: Service needing fresh disposable per operation
public class FileProcessor : IFileProcessor
{
    private readonly IFileSystem _fileSystem;
    
    public FileProcessor(IFileSystem fileSystem)
    {
        _fileSystem = fileSystem; // Assume this needs fresh instance per operation
    }
}
 
services.AddTransient<IFileProcessor, FileProcessor>();

When NOT to Use Transient Lifetime

Despite being safe by default, transient is the wrong choice when the cost of repeated instantiation outweighs its benefits:

Avoid Transient When...

•Construction is expensive — Services that require significant initialization (loading config, establishing connections, warming caches) shouldn't recreate this work per request.
•Services hold shared caches — If a service's value comes from accumulating data across requests (in-memory caches, rate limiters), transient defeats the purpose.
•Services manage external connections — Database connection pools, message queue clients, and HTTP client instances should typically be singletons to amortize connection costs.
•Same instance semantics are required — If business logic depends on all consumers seeing the same state, transient creates invisible bugs.
•High-throughput hot paths — In latency-critical paths handling thousands of requests per second, excessive transient creation adds measurable overhead.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// ❌ WRONG: Expensive initialization repeated per request
public class ConfigurationService : IConfigurationService
{
    private readonly Dictionary<string, string> _settings;
    
    public ConfigurationService(IConfigurationSource source)
    {
        // Takes 200ms to load from remote source
        // As transient: 200ms added to EVERY request
        _settings = source.LoadAllSettings(); // Expensive!
    }
}
 
// ❌ WRONG: Cache that never caches
public class UserCache : IUserCache
{
    private readonly Dictionary<int, User> _cache = new();
    
    public User GetOrAdd(int userId, Func<int, User> factory)
    {
        if (!_cache.TryGetValue(userId, out var user))
        {
            user = factory(userId);
            _cache[userId] = user;
        }
        return user;
    }
}
// As transient: _cache is always empty! Cache provides zero benefit.
 
// ❌ WRONG: Connection pool recreation
public class DatabaseService : IDatabaseService
{
    private readonly NpgsqlConnection _connection;
    
    public DatabaseService(string connectionString)
    {
        // Connection establishment takes 50-200ms
        _connection = new NpgsqlConnection(connectionString);
        _connection.Open(); // Network round trip!
    }
}
// As transient: new connection per request = massive latency
 
// ✅ CORRECT: These should be singletons or scoped
services.AddSingleton<IConfigurationService, ConfigurationService>();
services.AddSingleton<IUserCache, UserCache>();
services.AddSingleton<IDatabaseService, DatabaseService>();

The Cost of Misplaced Transients

A common performance bug is registering an expensive service as transient 'because it's the default' or 'to avoid threading issues.' The fix isn't avoiding transient—it's designing services that are naturally thread-safe (stateless), then registering them as singletons. Transient should be a deliberate choice for stateful services, not a safety blanket.

Transient Services and Resource Disposal

A critical consideration for transient services is disposal. When a transient service implements IDisposable, the container is responsible for disposing it—but the timing depends on the resolution context.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// In ASP.NET Core / Microsoft.Extensions.DependencyInjection
public class FileHandler : IFileHandler, IDisposable
{
    private readonly FileStream _stream;
    private bool _disposed;
    
    public FileHandler(string path)
    {
        _stream = File.OpenRead(path);
    }
    
    public void Dispose()
    {
        if (!_disposed)
        {
            _stream.Dispose();
            _disposed = true;
            Console.WriteLine("FileHandler disposed");
        }
    }
}
 
services.AddTransient<IFileHandler>(sp => new FileHandler("data.txt"));
 
// Scenario 1: Resolved from root container (singleton scope)
var handler1 = app.Services.GetRequiredService<IFileHandler>();
// ⚠️ handler1 is tracked by root container
// ⚠️ Will NOT be disposed until application shutdown!
// ⚠️ This is a resource leak!
 
// Scenario 2: Resolved from scoped container (per-request)
using (var scope = app.Services.CreateScope())
{
    var handler2 = scope.ServiceProvider.GetRequiredService<IFileHandler>();
    // handler2 is tracked by this scope
} // Scope disposes -> handler2.Dispose() called automatically ✓
 
// Scenario 3: In ASP.NET Core controller
public class FilesController : ControllerBase
{
    private readonly IFileHandler _handler; // Resolved per-request scope
    
    public FilesController(IFileHandler handler)
    {
        _handler = handler;
    }
    
    [HttpGet]
    public IActionResult Get()
    {
        // Use _handler
        return Ok();
    }
    // Request ends -> scope disposes -> _handler.Dispose() called ✓
}

The Root Container Trap

When you resolve a disposable transient from the root container (not from a scope), the container tracks it for later disposal. But 'later' means application shutdown—potentially hours or days later. This creates a memory leak where transient IDisposable instances accumulate. Always resolve transient disposables from scoped containers.

Transient IDisposable Behavior by Resolution Context
Resolution Context	Disposal Timing	Risk Level
Scoped container (per-request)	End of scope	✓ Safe
Using block with CreateScope()	End of using block	✓ Safe
Root container directly	Application shutdown	⚠️ Memory leak!
Injected into singleton	Application shutdown	⚠️ Resource held too long

Summary: Transient Lifetime Mastery

Transient lifetime is the simplest strategy: new instance every time. This simplicity provides safety through isolation—no shared state, no threading concerns. But simplicity comes with costs: higher allocation rates, more GC pressure, and repeated construction overhead.

Key Takeaways

•Transient creates fresh instances — Every resolution request returns a new object. No reuse, no sharing.
•Thread safety through isolation — Each consumer gets exclusive access to its instance, eliminating race conditions by design.
•Best for stateful services — When services accumulate per-request state, transient is often the only correct choice.
•Avoid for expensive services — Services with costly initialization should use singleton or scoped lifetime to amortize that cost.
•Watch IDisposable carefully — Transient disposables must be resolved from scopes, never from the root container.
•Understand cascading creation — Transient dependencies create new instances throughout the entire dependency graph.

What's next:

Transient solves the isolation problem but creates many instances. The next page explores Scoped Lifetime—the middle ground that provides instance sharing within a defined boundary (like an HTTP request) while maintaining isolation across boundaries.

Page Complete

You now understand transient lifetime at a deep level: its semantics, its memory implications, its thread-safety characteristics, and when to use or avoid it. Next, we'll explore scoped lifetime—instance reuse within a boundary.