Description of bug
The DataProvider is starting to be used in objects that are being registered in the Dependency Injection container. Transient registered objects that use the DataProvider will create a new database connection every time the DataProvider.Instance() is executed. If an instance is requested many times in a single call this could spam the database with connection requests. While working on a change I noticed the connection pool limit would hit capacity and DNN will throw an exception and stop functioning. To solve this problem we will need to come up with a strategy for the DataProvider to be registered with Dependency Injection. The implications of this are massive since so much of the platform depend on the DataProvider.
Code Example
The code sample below should help explain the problem
public interface IMyService
{
void DoSomething();
}
public class MyService : IMyService
{
public void DoSomething()
{
var provider = DataProvider.Instance();
// omitted code
}
}
Now suppose this service is being used in multiple places at once. The best example I have is the Globals static apis are now wrapping Dependency Injection calls. Consider the following code
public static class Globals
{
// omitted code
public static void DoSomething() => DependencyProvider.GetRequiredService<IMyService>().DoSomething();
// omitted code
}
If there is a call stack that invokes Globals.DoSomething() multiple times, it will resolve a new instance of IMyService every single time which will create a separate SQL connection from the DataProvider.Instance() statement.
Steps to reproduce
see description above
Current behavior
SQL Connection Pool Limit can be exceeded with dependencies that use DataProvider.Instance()
Expected behavior
The DataProvider should be registered with the Dependency Injection container to limit the number of instances that can be created at once
Screenshots
N/A
Error information
I don't have the error log anymore, as I identified this problem while debugging a platform change I was working on
Additional context
N/A
Affected version
Affected browser
N/A
Description of bug
The DataProvider is starting to be used in objects that are being registered in the Dependency Injection container. Transient registered objects that use the DataProvider will create a new database connection every time the
DataProvider.Instance()is executed. If an instance is requested many times in a single call this could spam the database with connection requests. While working on a change I noticed the connection pool limit would hit capacity and DNN will throw an exception and stop functioning. To solve this problem we will need to come up with a strategy for the DataProvider to be registered with Dependency Injection. The implications of this are massive since so much of the platform depend on the DataProvider.Code Example
The code sample below should help explain the problem
Now suppose this service is being used in multiple places at once. The best example I have is the
Globalsstatic apis are now wrapping Dependency Injection calls. Consider the following codeIf there is a call stack that invokes
Globals.DoSomething()multiple times, it will resolve a new instance ofIMyServiceevery single time which will create a separate SQL connection from theDataProvider.Instance()statement.Steps to reproduce
see description above
Current behavior
SQL Connection Pool Limit can be exceeded with dependencies that use
DataProvider.Instance()Expected behavior
The DataProvider should be registered with the Dependency Injection container to limit the number of instances that can be created at once
Screenshots
N/A
Error information
I don't have the error log anymore, as I identified this problem while debugging a platform change I was working on
Additional context
N/A
Affected version
Affected browser
N/A