What is the reason behind choosing DbContext Pooling for all database components?

[sa-es-ir]

I was checking database components for EF Core, like SqlServer, Postgres, or MySql, in all of them we used:

builder.Services.AddDbContextPool<TContext>(ConfigureDbContext);

I know that it is a good practice for high-performance application but also brings some issues for entity tracking or maybe thread safety.

I just wanted to know what the benefits of using DbContext pooling? is it because of .NET Aspire and the way it handles connections and discovery?

[davidfowl]

cc @roji

[roji]

The advantages of DbContext pooling are explained here in the EF docs. In a nutshell, every DbContext internally has a number of non-shared services and initialization that it requires, and so instantiating a DbContext is a non-trivial amount of work (and allocates some amount of memory). DbContext pooling simply eliminates that overhead.

I'm not sure what issues you're referring to exactly - DbContext pooling should interfere with either thread safety or entity tracking. If you need to vary state across DbContext instances (e.g. a tenant ID) then you may need to jump through some extra hoops, but that's generally doable (and documented in the link I posted above).

[sa-es-ir]

@roji Thanks, based on my experience a long time ago, it wasn't easy to handle the number of pooled dbContext and also getting a stale object twice, so I was curious to add an option and ask the caller to register a Pooling or just register as a Scoped.

[roji]

DbContext pooling allows easily setting the number of pooled contexts (though that's usually not a setting you need to tweak). I'm also not sure what you're referring to by "getting a stale object twice". For any application that cares about performance, I'd highly recommend turning on context pooling by default - it has very little downsides and is effectively a free optimization in most scenarios.

[sa-es-ir]

@roji Still, my point is that it is better to give the caller this flexibility to decide whether to pool or not. If pooling is desired, then there should be an option to set poolSize (the default size is 1024).

Thank you for the response.

[roji]

As I wrote above, there is an option to set poolize - that's very clearly shown in the docs.

[sa-es-ir]

@roji BUT this is inside Nuget package and not exposed!
Here is the code for postgres extension:

https://github.com/dotnet/aspire/blob/main/src/Components/Aspire.Npgsql.EntityFrameworkCore.PostgreSQL/AspireEFPostgreSqlExtensions.cs#L69

[roji]

Definitely feel free to open an issue on the Aspire repo asking for this parameter to be exposed there as well. At the EF level it is already exposed.

I'll also note that it should be quite rare for people to have to adjust this number, and any inability to do so should definitely not lead to abandoning pooling altogether, as might be suggested above.

Finally, note that the idea of Github discussions is to write threaded replies on the original comment, rather than open a new conversation thread each time as you've been doing.

[sa-es-ir]

Thanks @roji, and appreciate your attention. I'll do it for the next discussions.