IIS应用池回收引发未提交事务及登录问题排查咨询

让我一步步拆解你的问题和排查思路，帮你理清核心逻辑：

1. IIS应用池回收时，数据库连接池会被清空吗？ #

答案是肯定会。要搞清楚：.NET（大部分IIS托管应用基于这个技术栈）的数据库连接池是进程级别的资源——它属于当前运行的工作进程。当IIS回收应用池时，会直接终止旧的工作进程，这个进程里的所有资源（包括连接池）都会被系统销毁回收。新启动的工作进程会创建全新的连接池，绝对不会复用旧进程里的任何连接。

所以你之前“连接池未被清空”的假设其实不成立，这点要先纠正。

2. 关于“过期旧连接无法正常访问数据库”的判断 #

基于上面的结论，这个假设的前提（连接池未被清空）不存在。不过可以补充一个相关场景：如果是应用进程未被销毁，但连接池里的连接在数据库端已经被主动断开（比如数据库重启、连接超时），此时应用尝试从连接池取连接时，.NET的连接池机制会自动检测到无效连接，将其从池中移除并创建新的有效连接——除非你的代码没有正确处理连接异常，才会出现问题。

但回到你的场景，应用池回收后的问题和“旧连接复用”无关，因为旧进程已经被销毁了。

3. 应用1-2小时后自动恢复，是否是未提交事务被终止？ #

这个猜测非常合理，大概率是正确的。原因主要有两个：

• 当旧工作进程被终止时，它持有的数据库连接会被强制断开，数据库会自动回滚这个连接上未提交的事务——但如果是某些长事务或者数据库端的清理延迟，可能不会立刻完成。
• 数据库通常有自己的会话超时/事务超时机制（比如SQL Server的remote query timeout默认是10分钟，部分场景下如果事务未被主动终止，数据库会在超时后强制回滚）。如果你的未提交事务属于这种“悬挂”状态，等到数据库完成清理、释放相关资源（比如锁）后，新进程的请求就能正常执行，这就对应了你看到的1-2小时后自动恢复的现象。

整体方向是对的，核心抓住了未提交事务 + 应用池回收的交互影响这个关键点，但可以优化几个排查细节：

• 优先检查应用代码里的事务处理逻辑：是否存在异常分支未提交/回滚事务的情况？比如try块里开了事务，但catch块里没有正确执行回滚？
• 查看数据库的日志（比如SQL Server的事务日志、错误日志），追踪应用池回收时间点前后的事务状态，确认是否有未提交事务被延迟回滚的记录。
• 核对数据库的超时设置（会话超时、事务超时），看是否和1-2小时的恢复时间匹配，是否存在超时配置过长的情况。
• 启用IIS的详细日志，记录应用池回收前后的请求失败情况，结合数据库日志交叉验证问题触发的时序。

内容的提问来源于stack exchange，提问作者Gaurav Kumar