Question

在我们的应用程序中，我们不在程序中使用ADO.NET事务或SQL Server事务，现在我们在多个人使用时在我们的网站上收到以下错误。

事务（进程ID 73）在锁定时死锁与另一个进程通信缓冲资源并被选为死锁牺牲品。重新运行交易

由于缺少交易而导致此错误吗？我认为一致性将由DB本身处理。

有一件事我注意到SQLCommand.Timeout属性设置为10000.这会是错误的问题吗？

我尽快解决这个问题。请帮忙。

修改

我看到了ADO.NET事务的Isolationlevel属性，所以如果我在阅读时使用ADO.NET事务和适当的隔离级别属性（如“ReadUncommitted”）和写入期间的“Serializable”？

Answer 1

每个SQL DML（INSERT，UPDATE，DELETE）或DQL（SELECT）语句都在事务内部运行。 SQL Server的默认行为是它打开一个新事务（如果一个不存在），如果语句完成没有错误，则自动提交事务。

Sidharth提到的IMPLICIT_TRANSACTIONS行为基本上使SQL Server在某种程度上改变了它的行为 - 它在语句完成时使事务处于打开状态。

要在SQL Server错误日志中获得更好的信息，您可以打开trace flag。然后，这将告诉您死锁中涉及哪些连接（不仅仅是被杀死的连接），以及涉及哪些资源。然后，您可以确定导致死锁的行为模式。

如果您无法确定根本原因，则可能需要向应用程序添加一些其他代码 - 由于死锁而捕获sql错误，并多次重试该命令。这通常是最后的手段 - 最好确定涉及哪些表/索引，并制定一个避免首先出现死锁的策略。

Answer 2

IsolationLevel是你最好的选择。事务的默认序列化级别是“可序列化”，这是最严格的，如果在此级别存在循环引用，则死锁的可能性非常高。在阅读时将其设置为ReadCommitted，并在写入时将其设置为Serializable。

Sql server可以使用隐式事务，这可能是您的情况。尝试将其关闭：

SET IMPLICIT_TRANSACTIONS OFF;