关闭SqlDataReader后sp_getapplock锁丢失，可否省略sp_releaseapplock调用？

核心结论 #

你可以安全省略手动调用sp_releaseapplock的操作，不需要依赖SqlDataReader的关闭逻辑释放锁，SQL Server原生机制和.NET的SQL连接池会自动完成锁的清理，不会出现锁泄漏问题。 #

执行sp_releaseapplock报错的根因 #

sp_getapplock的参数@LockOwner默认值为Transaction，代表锁的生命周期和当前事务绑定：

• 如果你没有显式开启事务，执行sp_getapplock的单条命令运行结束后，隐含的自动事务就会提交，对应的应用锁会被立刻释放。
• 后续创建SqlDataReader、读取数据的操作已经运行在新的事务上下文，到第5步手动释放锁时，你早就不再持有对应锁，自然会抛出异常。

锁自动释放的规则说明 #

• 事务级锁（默认@LockOwner='Transaction'）：锁会在事务提交或回滚时自动释放，完全不需要手动调用释放命令。
• 会话级锁（指定@LockOwner='Session'）：锁的生命周期绑定到数据库会话，当数据库连接的using块执行完毕，连接关闭归还到连接池时，.NET的SQL连接池会自动执行会话重置逻辑，清理该会话持有的所有应用程序锁、临时表等会话级资源。

推荐优化后的流程 #

如果你需要应用锁覆盖整个数据读取周期，可按以下逻辑调整实现，完全不需要手动处理锁释放：

• 在using块创建数据库连接后，首先显式开启事务
• 调用sp_getapplock并指定@LockOwner='Transaction'，获取应用锁
• 创建SqlDataReader读取数据，用完后正常关闭reader
• 提交或回滚事务，绑定到事务的锁会被自动释放
• 连接using块执行完毕，连接归还连接池

内容的提问来源于stack exchange，提问作者Don J