ASP.NET WebForms页面是否会在请求生命周期内持有数据库连接？

为什么连接资源紧张时未出现写入数据缺失？ #

• 连接池耗尽、SQL Server连接超时异常均发生在连接获取阶段，尚未进入SQL执行逻辑。只要业务逻辑执行到请求A、请求B的SQL执行步骤，说明程序已经成功从池内获取到有效连接，只要SQL执行无报错、提交成功，数据就会正常持久化到库，不会出现拿到连接后无故跳过某条SQL执行的情况。目前未观测到数据丢失，说明当前故障场景只有两种可能：要么请求在获取连接阶段就直接失败返回，整个请求的所有写入逻辑都未触发；要么请求成功获取到连接后，所有SQL均正常执行完成并提交，无中间中断情况。
• 非事务场景下的单SQL执行具备原子性：每个独立的数据库请求执行成功后就会完成持久化，不会受后续其他请求获取连接失败的影响。如果请求A、请求B为独立非事务逻辑，即便请求B获取连接失败，也只会导致B的写入未执行，不会回滚A的写入结果。当前未观测到部分数据缺失，说明当前负载尚未出现「请求成功执行A后，执行B时无法获取连接」的场景，或是业务逻辑存在前置校验，未获取到足够连接的情况下不会触发任何写入操作。

同请求内多次调用open()/close()是否会一直持有连接？ #

• 常规场景下不会一直持有：主流SQL Server驱动（如.NET SqlClient、Java mssql-jdbc）的内置连接池默认实现为，代码调用close()时并不会真正关闭物理连接，只是将连接归还到连接池供其他请求复用；后续调用open()时会优先从池内获取空闲连接，若同请求内无并发数据库操作，大概率会复用同一个物理连接，但本质上每次close()后你已经释放了连接持有权。
• 两种特殊场景会出现请求周期内持有连接的情况：
  • 连接上开启了未提交/回滚的事务：事务未结束时，即便调用close()，驱动也不会将连接归还到池，会一直持有到事务完成。
  • 框架开启了请求级连接绑定配置：部分Web框架支持将同一个请求获取的连接绑定到请求上下文，整个请求生命周期内复用同一个连接，直到请求处理完成后才归还到池，这种情况下即便多次调用open()/close()，连接也不会被其他请求占用，是高负载下连接池快速耗尽的常见诱因之一。

内容的提问来源于stack exchange，提问作者Ian Warburton