Why should you care?

ShopNest traffic spikes fail with "timeout waiting for connection" if connections are held open too long or pool starved.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

// Good: short-lived context per request (default Scoped)
// Bad: manual connection left open
await using var conn = new SqlConnection(connectionString);
await conn.OpenAsync();
// always dispose — EF manages via DbContext dispose

services.AddDbContextPool<ShopNestDbContext>(options =>
    options.UseSqlServer(connectionString), poolSize: 128);

What happened?

• DbContextPool reuses context instances with reset state — reduces allocation.
• Underlying SqlConnection still pools at ADO.NET layer when contexts dispose promptly.

Practice next

1. Keep DbContext Scoped per request — do not hold across await external APIs long.
2. Consider AddDbContextPool for high-throughput read APIs.
3. Monitor SQL Server connection count during load tests.
4. Load test with vs without AddDbContextPool measuring allocations.
5. Log pool exhaustion errors and correlate with slow external calls inside transactions.

Remember

SQL connections pool automatically when disposed. DbContextPool reduces context allocation overhead. Avoid long-lived contexts and leaks.

ShopNest pool exhaustion fix

Checkout held transaction during 30s payment SDK call — pool exhausted; team moved payment outside transaction.

Outcome: Connection timeouts disappear under peak load.