未提交事务导致的数据锁答案

【问题标题】：Data locks caused by non-committed transactions未提交事务导致的数据锁
【发布时间】：2017-05-17 20:31:13
【问题描述】：

我的 Web 应用程序连接到 SQL Server 2016 Express 数据库，我们一直受到系统某些区域的数据锁的困扰。

我的同事今天注意到，当使用 KILL 进程终止一个长时间运行的事务时，几个表面上已经提交的事务被回滚了。

我在In SQL Server, how do I know what transaction mode I'm currently using? 上使用@vladV 的脚本检查了实际上数据库似乎处于自动提交模式。

因此，必须是数据库中的某些东西正在打开一个新事务而不是提交它。

于是我在数据库中找到了四个存储过程，其中包含以下内容

SET  IMPLICIT_TRANSACTIONS  ON
... code ...
IF @@TRAN_COUNT>0 COMMIT WORK

我是否正确地说，在某些/大多数情况下，即使在退出存储过程之后，这样的存储过程也会使事务保持打开状态，这可能是数据锁定问题的根源？

如果是这样，那么我可以通过这样做来纠正代码

SET IMPLICIT_TRANSACTIONS OFF

存储过程何时退出？

【问题讨论】：

【解决方案1】：

我说得对吗？在某些/大多数情况下，这样的存储过程会使事务保持打开状态

一些。取决于后面的事情。使用 SQL Server 中的隐式事务，在您运行读取数据库的查询之前，事务不会自动启动。

我可以通过执行 SET IMPLICIT_TRANSACTIONS OFF 来修正代码

没有。这不会结束任何未完成的交易。

请注意，COMMIT 不会将@@trancount 减为 0。它会减 1。因此，如果您有多个 BEGIN TRAN 语句，或者在事务隐式开始后有一个显式 BEGIN TRAN，那么您将需要多个 COMMIT .

你可以试试

WHILE @@trancount > 0 COMMIT TRANSACTION

这肯定会提交任何未完成的交易。

【讨论】：

谢谢！如果我用 BEGIN TRANSACTION 替换 SET IMPLICIT TRANSACTIONS ON 并用 COMMIT TRANSACTION 替换 SET IMPLICIT TRANSACTIONS OFF 可能会更好。你怎么看？
我更喜欢不使用隐式事务，并明确地处理所有事务。所以这是一个很好的方向，但更多的是改变。
好的。我将重写存储过程以仅使用显式事务。