问题标签 [deadlock]

我们在 Stack Overflow SQL Server 2005 数据库中看到了一些有害但罕见的死锁情况。

我附加了分析器，使用这篇关于故障排除死锁的优秀文章设置了跟踪配置文件，并捕获了一堆示例。奇怪的是，死锁写总是一样的：

另一个死锁语句各不相同，但通常是对帖子表的某种琐碎、简单的读取。这个总是在僵局中被杀死。这是一个例子

非常清楚，我们看到的不是写/写死锁，而是读/写。

目前，我们混合使用了 LINQ 和参数化 SQL 查询。我们已添加with (nolock)到所有 SQL 查询中。这可能对一些人有所帮助。我们还有一个（非常）写得很糟糕的徽章查询，我昨天修复了它，每次运行需要超过 20 秒，并且每分钟都在运行。我希望这是一些锁定问题的根源！

不幸的是，大约 2 小时前我又遇到了一个死锁错误。完全相同的症状，完全相同的罪魁祸首。

真正奇怪的是，您在上面看到的锁定写入 SQL 语句是非常具体的代码路径的一部分。它仅在向问题添加新答案时执行 - 它使用新答案计数和最后日期/用户更新父问题。显然，相对于我们正在进行的大量读取，这并不常见！据我所知，我们并没有在应用程序的任何地方进行大量写入。

我意识到 NOLOCK 有点像一把巨大的锤子，但是我们在这里运行的大多数查询不需要那么准确。你会关心你的用户资料是否过时了几秒钟吗？

正如Scott Hanselman 在这里所讨论的，在Linq 中使用 NOLOCK 有点困难。

我们正在考虑使用

在基本数据库上下文上，以便我们所有的 LINQ 查询都有这个集合。否则，我们将不得不将我们进行的每个 LINQ 调用（嗯，简单的读取调用，其中绝大多数）封装在一个 3-4 行的事务代码块中，这很难看。

我想我有点沮丧，因为 SQL 2005 中的琐碎读取可能会导致写入死锁。我可以看到写/写死锁是一个大问题，但是读吗？我们不是在这里经营银行网站，我们不需要每次都完美准确。

想法？想法？

您是为每个操作实例化一个新的 LINQ to SQL DataContext 对象，还是为所有调用共享相同的静态上下文？

Jeremy，我们大部分时间都在基础控制器中共享一个静态数据上下文：

您是否建议我们为每个控制器、每个页面或......更频繁地创建一个新的上下文？

最近，Jeff发布了关于他与阅读相关的数据库死锁问题的帖子。 多版本并发控制（MVCC）声称可以解决这个问题。它是什么，哪些数据库支持它？

更新：这些支持它（其他哪些？）

• 甲骨文
• PostgreSQL

在编写多线程应用程序时，最常见的问题之一是死锁。

我对社区的问题是：

1. 什么是死锁？

2. 你如何检测它们？

3. 你会处理它们吗？

4. 最后，您如何防止它们发生？

我不是 C# 的初学者，但我确实需要增加我的理解，所以我选择了一个经典的死锁问题来编写代码，以帮助自己学习一些更高级的 C# 概念。餐饮哲学家问题似乎是一个很好的问题，但我需要一些帮助才能开始。我知道我需要将“食客”作为对象来处理，但是为了模拟进餐之间的随机延迟，我是否应该将每个食客的线程放在单独的线程中？我是否需要某种“主人”来监控所有动作？欢迎任何一般的设计概念建议，但我想将 grunt 编程作为练习。谢谢！

我正在寻找有关如何在 SQL Server 2000 数据库中调试和解决死锁问题的建议。有人建议我使用跟踪标志 1024 和 3605，我发现它们给了我以下信息：

1024 - 此跟踪标志返回参与死锁的锁类型和受影响的当前命令。

3605 - 此跟踪标志将跟踪输出发送到错误日志。

仍然需要发现特定的存储过程、表和索引，因此目标是使用这些跟踪标志来做到这一点。然后从那里我会更好地了解哪些索引需要调整、调整查询的锁定提示以及需要修复的潜在存储过程错误。

关于将这一切归结为常见问题的任何其他建议或快乐结局的战争故事？

从这个帖子。一个明显的问题是可扩展性/性能。交易使用还会引发哪些其他问题？

你能说有两组问题，一组是长期运行的事务，一组是短期运行的事务吗？如果是，您将如何定义它们？

编辑：死锁是另一个问题，但数据不一致可能会更糟，具体取决于应用程序域。假设一个值得交易的领域（银行，使用规范的例子），死锁的可能性更像是为确保数据一致性而付出的代价，而不是交易使用的问题，或者你会不同意？如果是这样，您将使用哪些其他解决方案来确保无死锁的数据一致性？

开发人员正在寻找最佳方法来识别特定线程内特定事务的死锁。我们遇到了死锁错误，但这些在 FB 2.0 中非常普遍

发生死锁，它们导致客户端和数据库之间的数据库连接中断。

• 我们将实时（每秒一次）数据发送到数据库。
• 我们打开一个由大约 30 个线程组成的线程池，并使用它们来摄取数据（大约每秒 1-2 kB）。
• 有时数据库只能占用这么多，以至于我们使用池中的下一个线程来尽可能保持流最新。

除了达到最大线程数和中断连接之外，有时这会产生死锁。

因此，我们真的需要就这是否是每秒摄取这么多数据的最佳方法提出意见。我们有多达 100 个这些客户端同时访问数据库。
平均每天的交易量约为 1.5 到 180 万笔。

我找不到适合 Ruby 的 ThreadPool 实现，所以我写了我的（部分基于这里的代码：http://web.archive.org/web/20081204101031/http://snippets.dzone.com: 80/ posts/show/3276 ,但更改为等待/信号和其他实现 ThreadPool 关闭。但是在运行一段时间后（有 100 个线程并处理大约 1300 个任务），它在第 25 行因死锁而死 - 它等待新工作有任何想法，为什么会发生？

调试由于 Win32 生产过程中的死锁而导致的明显挂起的步骤和技术是什么。我听说 WinDbg 可以用于此目的，但您能否提供有关如何实现此目的的明确提示？

我在运行在 MS SQL Server 2005 之上的 .NET 2.0 webapp 上遇到了非常罕见但令人讨厌的 SQL 死锁。过去，我们一直以非常经验的方式处理 SQL 死锁 - 基本上是调整查询直到它工作。

然而，我发现这种方法非常不令人满意：耗时且不可靠。我非常希望遵循确定性查询模式，这些模式将通过设计确保不会遇到 SQL 死锁 - 永远。

例如，在 C# 多线程编程中，一个简单的设计规则（如锁）必须按照其字典顺序来确保不会发生死锁。

是否有任何 SQL 编码模式可以保证是防死锁的？