Entity Framework DbContext is Not Thread-Safe. C# Code Examples – Part 4.

Continuing our deep dive into the thread safety concerns of Entity Framework’s DbContext, this part explores advanced patterns and practical solutions for safely handling DbContext in multi-threaded applications. We will cover locking techniques, context scoping with dependency injection, and how to properly use async methods to avoid thread safety issues.

Thread-Safety Challenges with DbContext

The DbContext is designed for a single-threaded usage, maintaining stateful information like change tracking and database connections. When accessed concurrently without safeguards, it may cause data corruption, runtime exceptions, or unpredictable behavior. EF Core explicitly does not support concurrent operations on the same DbContext instance.

Typical exception message you might encounter is “A second operation was started on this context before the previous one completed.” This is a built-in thread-safety check by EF Core.

Using Locks for Thread Safety – Not Recommended but Possible

In rare cases where parallelism is limited and unavoidable on the same DbContext, you can use synchronization primitives like lock to serialize access.

private readonly object _dbContextLock = new object();

public IList GetUsersSafely(MyDbContext context)
{
    lock(_dbContextLock)
    {
        return context.Users.ToList();
    }
}

Warning: Locking restricts concurrency and can become a bottleneck. It should be a last resort, not a general solution.

Scoped DbContext with Dependency Injection

In ASP.NET Core or other DI frameworks, configure DbContext with scoped lifetime. This ensures one instance per request or service scope, avoiding sharing across threads.

services.AddDbContext<MyDbContext>(options =>
    options.UseSqlServer(connectionString),
    ServiceLifetime.Scoped);

Accessing DbContext through constructor injection automatically scopes it per logical operation, preventing thread issues.

Async / Await Best Practices

Always await asynchronous EF Core calls before initiating another operation on the same DbContext. This avoids overlapping database operations that cause exceptions.

public async Task ProcessDataAsync(MyDbContext context)
{
    var users = await context.Users.ToListAsync();
    var products = await context.Products.ToListAsync();

    // Both queries run sequentially on the same context safely
}

Never run EF Core queries in parallel on the same context instance.

Use IDbContextFactory for Concurrent Operations

When you need true concurrency, rely on IDbContextFactory<TContext> to create isolated DbContext instances for each thread or operation.

public class DataService
{
    private readonly IDbContextFactory<MyDbContext> _contextFactory;

    public DataService(IDbContextFactory<MyDbContext> factory)
    {
        _contextFactory = factory;
    }

    public async Task LoadMultipleSetsAsync()
    {
        var task1 = Task.Run(async () =>
        {
            using var context = _contextFactory.CreateDbContext();
            return await context.Users.ToListAsync();
        });

        var task2 = Task.Run(async () =>
        {
            using var context = _contextFactory.CreateDbContext();
            return await context.Orders.ToListAsync();
        });

        await Task.WhenAll(task1, task2);
    }
}

This pattern avoids shared state and leverages multiple contexts safely in parallel.

Summary and Recommendations

• Do not share a single DbContext instance across threads.
• Use scoped lifetimes with dependency injection to keep context instances per operation scope.
• Await all async EF calls before starting new ones on the same context.
• Use IDbContextFactory to create contexts for parallel operations.
• Avoid locking on DbContext unless absolutely necessary.

Following these practices ensures thread-safe, reliable data access with Entity Framework and C#.