Connection Leak with DI

[aspnet-hello]

From @ConX-Ryan on Sunday, September 17, 2017 1:17:08 PM

issuelink

services.AddTransient<IHttpContextAccessor, HttpContextAccessor>();
services.AddScoped<DbShardContextFactory>();

 services.AddScoped<ConXDbContext<Guid>>(provider => 
                 provider.GetService<DbShardContextFactory>().CreateShardContext());

 services.AddIdentity<AppUser, IdentityRole>()
                .AddEntityFrameworkStores<ConXDbContext<Guid>>()
                .AddDefaultTokenProviders();

I am using a single tenant config where i need to route to a customer shard based on the request. The DbShardContextFactory does this with help from the HttpContextAccessor.

Because the factory creates the DbContext instead of the DI Container it appears to not be disposing correctly even though defined as Scoped. so the .AddEntityFrameworkStores<ConXDbContext>()
call i believe is the issue

What is the correct pattern here to use the standard ASP.NET Core service collection?

I am having trouble defining the right pattern to use here, we are just migrating and what was previously working in Ninject .InRequestScope() is not the same with the in built DI.

What would be the functional equivalent pattern here?

Copied from original issue: aspnet/DependencyInjection#584

[aspnet-hello]

From @davidfowl on Sunday, September 17, 2017 5:11:54 PM

services.AddTransient<IHttpContextAccessor, HttpContextAccessor>();

This should be a singleton.

As for the other objects..

What is a DbShardContextFactory? How does the ShardDbContext<Guid> relate to the ConXDbContext<Guid>?

[aspnet-hello]

From @ConX-Ryan on Sunday, September 17, 2017 5:24:24 PM

How does the ShardDbContext relate to the ConXDbContext?

Sorry that is a typo, they are meant to be the same, i was trying to clean code up for example.

The DbShardContextFactory is responsible for providing a SqlConnection obj to the constructor of the ConXDbContext, it parses the request and maps a connection to a shard from the subdomain, previously it created and returned the new ConXDbContext but reading the ASP.NET Core docs because it wasnt created by the DI container it wont be disposed.

Thanks for your time :)

[aspnet-hello]

From @davidfowl on Sunday, September 17, 2017 5:30:02 PM

I inlined the wire up here to avoid going back to the link. What's not getting disposed?

[aspnet-hello]

From @ConX-Ryan on Sunday, September 17, 2017 5:35:50 PM

I believe that the .AddEntityFrameworkStores<ConXDbContext<Guid>>() is leading to the connection leak i am experiencing.

other repositories are being disposed in a "Scoped" fashion as expected.

[aspnet-hello]

From @ConX-Ryan on Monday, September 18, 2017 2:53:24 PM

I have resolved this issue by migrating to AutoFac, to use the InstancePerLifetimeScope and constructor resolution as EF needs the design time opts which lead to an ambiguous constructor error, then i am manually closing the connection in the DbShardContextFactory because even though the Dispose method is being called the connection was not closing.

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.