Why is services.AddDbContext<dbContext>() makes dbContext as a Scoped service?Shoudln't be a Singleton service?

Question

I am using ASP.NET Core 2.2 with Pomelo.EntityFramework.MySql.

Here is my code:

 services.AddDbContext<dbContext>(options => options.UseMySQL(appConfigsSection["DbConnectionString"]));
 services.AddSingleton<IUserService, UserService>();


 services.AddAuthentication(x =>
            {
                x.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                x.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            })
            .AddJwtBearer(x=> {
                x.Events = new JwtBearerEvents
                {
                    OnTokenValidated = context =>
                    {
                        var userService = context.HttpContext.RequestServices.GetRequiredService<IUserService>();       
                    }
                };

Here is the error:

asp.net core Cannot consume scoped service from singleton

on the line of:

 var userService = context.HttpContext.RequestServices.GetRequiredService<IUserService>();

My understanding is the DBContext should be used as a Singleton service, so is the IUserService. But it seems that DBContext is treated as a Scoped Service.

I can easily fix it by switching my IUserService back to Scoped Service. But I am wondering why can't I use DBContext as a Single service?

I think the DBContext should be used as a Singleton service, correct??

here

Most definitely NOT. Even scoped may be too much. A DbContext is like an NHibernate session - transient, single user and disconnected in nature, it shouldn't stay alive any longer than necessary. Just like connections, it's not expensive to create or close thanks to connection pooling. Just like connections, if it lives too long it accumulates changes. If its connection stays open for too long, it accumulates locks leading to blocking in the database and possibly deadlocks. — Panagiotis Kanavos
Given its disconnected nature a DbContext caches changes too, just like a DataTable, which means it can't be used by different threads/users. All these things aren't limitations as they make DbContext fast and scalable. — Panagiotis Kanavos
A meaningful question would be why scoped instead of transient? During a web request, if the code requests the same context multiple times, it would make sense to cache all objects and changes until the end of the request, and persist them just once with a single call to SaveChanges at the very end. This would perform better than eg 4 methods during the same request, creating a new CustomersContext context to retrieve and modify the same customer, and then save the changes 4 times, potentially overwriting each other's changes — Panagiotis Kanavos

juunas juunas · Accepted Answer · 2019-04-17T07:28:41

DbContext should not be used as a singleton because it is holding a connection object which cannot be used by multiple threads at the same time. You will run into errors if two requests try to use it at the same time. If your service depends on the context, the service cannot be a singleton.

Scoped makes sense since it allows for you to pass around DB objects between services and get the same DbContext in all of them so you can query entities in one service and save the changes in another.

You can change it to transient if you need to run queries in parallel in two services for example. The service lifetime is a parameter on AddDbContext().

Why is services.AddDbContext<dbContext>() makes dbContext as a Scoped service?Shoudln't be a Singleton service?

1 Answers