DbContext Pooling does not dispose LazyLoader

[smitpatel]

https://github.com/aspnet/EntityFrameworkCore/blob/2bdb72f0206ef0f4657f565b5a5bf7226564befc/src/EFCore.Specification.Tests/LazyLoadProxyTestBase.cs#L1602

Enable pooling with above switch. 12 tests fails in LazyLoadProxySqlServerTest.
In non pooling case when we dispose context, we also dispose lazy loader. And tests verify that we throw appropriate exception.
In pooling case we are not disposing lazy loaders so the lazy loading works without exception hence test failure.

Also enable pooling for test base when fixing this issue.

[ajcvickers]

This is a known issue with pooling and lazy loading. Pooling relies on reusing services which means the scope and the therfore the lazy loader service is never disposed. However, we decided this was okay beacause it is unlikely to cause issues, and if issues do exist, then the solution is to stop using pooling.

[ajcvickers]

Updated: dotnet/EntityFramework.Docs#501

[raymens]

We've actually ran our services with this combination for a few months. Fortunately due to our constant deployments the memory was freed due to restarts. Until we hit a slower period and we did hit the 100% memory. It took quite some figuring out, including looking at memory dumps, to see what was going on. Once the use of Pool and Proxies stood out, this issue was found quite quickly and thus also the fix.

Although the docs mention the issue of keeping state with a DbContext can be troublesome, it might help to emphasize lazy loading specifically. As this feels more like a built-in feature where you only figure out after quite some time that it's also considered state.

I've created dotnet/EntityFramework.Docs#3472 in case anyone agrees

[ajcvickers]

@raymens What you are describing doesn't seem to fit with this issue. It could be a manifestation of #25486, which is about the proxies themselves retaining a reference to the DbContext, although that also doesn't seem to match the symptons you are describing. Could you create a new issue and attach or reference a runnable repro that causes the memory leak? That way we can really understand what is going on.