Efcore: Support context pool with multi tenancy - database per tenant

[MaklaCof]

EF Core support context pooling since version 2.0.

But this approach is not (based on SO answer) possible with context factory, which I need for handling multi tenancy (database per tenant) approach.

It would be awesome if EF Core would support context pooling and solving problem with one database per tenant.

[ajcvickers]

@MaklaCof Can you give some details on why you are using context pooling? Do you have performance tests that show it makes a significant difference? If so, it would be great if you could share your numbers.

[MaklaCof]

@ajcvickers
I was using it because it came out and promise better performance. It is always good to speed up parts of your code. I said to myself "I will gain performance, since I am using complex model, otherwise you would spend your resources building context pool.".

And I write this feature request because I am doing a lot of staff (reflection) in OnModelCreating.
Like:

• assign new (dynamic) columns to table
• apply global filter for all entities that implements IDeleted interface (soft delete)
• dynamically assign entities from all projects loaded by app modelBuilder.Entity(type)
• define scheme based on entity namespace (different project, different scheme)
• some default indexes based on implemented interface
• ...

Unfortunately I don't have any performance tests.

[ajcvickers]

@MaklaCof I suspect that switching on or off context pooling in an application like you describe will have an negligible effect on performance. Context pooling can give a perf improvement, but typically it is only measurable in simple, repeated queries coming in at very high volume. So the recommendation here is to switch of pooling. If that turns out to result in a performance hit, then let us know and we'll reconsider.

[MaklaCof]

@ajcvickers
I apologise to bother you, but doesn't context pooling also means connection pooling.
After update from 2.1 to 2.2 I notice a lot of Debug messages from Microsoft.EntityFrameworkCore namespace.

Every query I run:

• open connection
• execute query
• close connection

Surely this could be optimised. Opening and closing connection usually takes some time. So maybe not context pooling, but what about connection pooling? Is this duplicate to #13837?

I also noticed #11496 but I am confused. Are connection pooled or not?

[roji]

@MaklaCof connection pooling is implemented beneath the EF Core layer, in the ADO.NET layer: when you see "open connection" in your logs, this means EF Core is opening a DbConnection, but that pools as well. Assuming you're using SQL Server, then unless you specifically disable pooling by specifying Pooling=false in your connection string, it will be on by default. See these docs for more information.