Sql server 2008 SQL Server 2008和ADO.NET的死锁问题

在我们的应用程序中，我们在过程中既不使用ADO.NET事务也不使用SQL Server事务，现在当多人使用时，我们的网站中出现以下错误

事务（进程ID 73）在与另一个进程的锁通信缓冲区资源上被死锁，并被选为死锁受害者。重新运行事务

此错误是由于缺少事务导致的吗？我认为一致性将由DB自己处理

我注意到SQLCommand.Timeout属性设置为10000。这会是错误的一个问题吗

我正在努力尽快解决这个问题。请帮忙

编辑

---

我看到了ADO.NET transaction的Isolationlevel属性，因此如果我在读取时使用ADO.NET transaction并带有适当的Isolationlevel属性，如“ReadUncommitted”，在写入时使用“Serializable”，那么Isolationlevel是最好的选择。事务的默认序列化级别为“Serializable”，这是最严格的，如果在此级别存在循环引用，则死锁的可能性非常高。在读取时将其设置为ReadCommitted，并在写入时将其序列化

Sql server可以使用隐式事务，这是您的案例中可能发生的情况。尝试将其设置为：

SET IMPLICIT_TRANSACTIONS OFF;

请在此处阅读：

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

Sidharth提到的隐式_事务行为基本上使SQL Server在某种程度上改变了它的行为——当语句完成时，它使事务保持打开状态

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

---

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

对timeout属性值10000有任何评论吗？不要认为超时是一个问题。我通过DBCC TRACEON（1204）打开了死锁信息。现在等待下一个死锁进行更多分析。