Document best practices for stateful context pooling

[GregJF]

[Enter feedback here]
You said

Context pooling works by reusing the same context instance across requests. This means that it's effectively registered as a Singleton in terms of the instance itself so that it's able to persist.

registering a dbContext as Singleton is not advisable as all users will share the same instance for the life of the application
The better way is to register dbContext as Scoped (in .net core) or webRequest (in most IoC products)

Regards
GregJF

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: e638463f-fec2-ca39-37a4-b3580fa874d8
• Version Independent ID: e96b453f-0256-8bc9-bd21-1343f2fe246c
• Content: Advanced Performance Topics
• Content Source: entity-framework/core/performance/advanced-performance-topics.md
• Product: entity-framework
• Technology: entity-framework-core
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[roji]

@GregJF the documentation describes a limitation in the way DbContext pooling works; since context instances are pooled across requests, the lifetime of each context instance is effectively like a singleton-registered service (although the context instances themselves aren't directly registered in DI at all). This is a fundamental characteristic of how pooling works.

However, we should probably add some guidance on how to work with pooled contexts that need to vary state across requests (i.e. scoped IDbContextFactory, DbConnection interception for connection strings). dotnet/efcore#14625 has some discussion around these. /cc @ajcvickers