IIS工作进程回收正在定期中断.Net核心3应用程序中的MySQL客户端

Question

工作进程的自动每日IIS回收有时(每5-10天)会破坏应用程序连接到AWS Aurora (MySQL)服务器的能力。

在回收之后-我们得到这些错误。同一IIS实例中的其他工作进程继续正常工作-所有进程的配置都类似。错误的工作进程随后会挂起，必须回收IIS本身来修复该问题。

Oracle MySql.Data.MySqlClient .Net核心类库8.0.20

MySql.Data.MySqlClient.MySqlException (0x80004005)：无法连接到任何指定的MySQL主机。-> MySql.Data.MySqlClient.MySqlException (0x80004005)：超时。在操作完成之前超时时间已过，或者服务器没有响应。在MySql.Data.Common.StreamCreator.GetTcpStream(MySqlConnectionStringBuilder设置)在MySql.Data.MySqlClient.NativeDriver.Open()在MySql.Data.MySqlClient.NativeDriver.Open()在MySql.Data.MySqlClient.Driver.Open()在MySql.Data.MySqlClient.Driver.Create(MySqlConnectionStringBuilder设置在MySql.Data.MySqlClient.MySqlPool.CreateNewPooledConnection()在MySql.Data.MySqlClient.MySqlPool.GetPooledConnection()在MySql.Data.MySqlClient.MySqlPool.TryToGetDriver()在MySql.Data.MySqlClient.MySqlPool.GetConnection()在MySql.Data.MySqlClient.MySqlConnection.Open() ...

来自日志的更多信息...它似乎处理了最初的几个新请求-然后出现了问题-所以可能是巧合-尽管没有与问题相对应的事件日志错误...

连接池正在使用默认值:最大池大小100连接生存期0

附加信息:日志显示，在完全分解之前，在同一工作线程中，一些执行是正常的，其他的执行时间是几秒钟而不是不到100ms。因此，与池相关的东西可能会出错，或者是实例。

当循环发生时，肯定会进行调整。

Answer 1

经过更多的研究，我发现我们只是让C#垃圾收集处理SqlConnection对象，而不是正确地将该对象封装在"using“声明中。这是一个问题，因为在垃圾收集运行并销毁SqlConnection对象之前，底层数据库连接不会返回到连接池。因此，当事情特别繁忙时，我们愚蠢地饿死，尽管有一个装满食物的仓库，因为垃圾收集被推迟了，连接没有及时返回到池中。

现代的C#语法允许这种非常简单的声明，当对象超出作用域时，它立即运行析构函数。因此，当对象离开作用域时，系统会立即将底层连接返回到池中，防止应用程序饿死。

using MySqlConnection z_connection = new MySqlConnection();
...
using MySqlCommand z_command = z_connection.CreateCommand();
...
using MySqlDataReader z_reader = z_command.ExecuteReader();
...