【问题标题】:Deadlocks when running NServicebus service causes corrupt connection运行 NServicebus 服务时出现死锁导致连接损坏
【发布时间】:2013-03-12 08:19:53
【问题描述】:

我们正在为 Web 应用程序运行 NServiceBus,以处理用户执行“类似批处理”操作的情况。就像触发一个影响 1000 个实体的命令..

它运行良好,但是在中等负载期间我们会遇到一些死锁,这不是问题,只需重试消息.. 对吗? :)

当下一条消息到达并尝试打开连接时会出现问题。然后连接“损坏”。

我们收到以下错误: System.Data.SqlClient.SqlException (0x80131904): 新请求不允许启动,因为它应该带有有效的事务描述符

我在网上搜索过,我认为我们的问题是报告的NH "bug"

解决方法应该是禁用连接池。但我不喜欢这样,因为性能会下降..

我们正在运行 NServiceBus 2.6、NHibernate 3.3。

有人有这方面的经验吗?升级 NServiceBus 有帮助吗?

【问题讨论】:

  • 这听起来与我们遇到的问题非常相似。我们还没有解决它,并且目前正在与池一起跛行。您对 MSDTC 的设置是什么?
  • 我们有 2 个网络盒(硬件负载平衡,ip-sticky)和一个带有 MS DTC 服务器的故障转移 sql 服务器集群。
  • 我们现在禁用了连接池,问题不再发生。
  • 我认为您已经获得的信息比我可以从链接的问题中为您提供的信息要多得多,但我只是想在我们的案例中提出,问题显然是由于糟糕的 DTC 性能导致恶化SQL 超时。这些似乎可以通过使用远程 DTC 而不是本地 DTC 来缓解,如本文所述:sqlcat.com/sqlcat/b/msdnmirror/archive/2010/05/11/…
  • 好的!谢谢,我会验证这是否与我们的环境有关。我们遇到了一些“不应该”出现的 SQL 超时

标签: nhibernate deadlock nservicebus


【解决方案1】:

我过去见过这种情况,如果您的设计允许,请尝试将事务分成两部分,如果您将消息事务一直流到数据库操作,任何失败都会产生级联效应,并且会影响 (理想情况下,它也不应该)任何后续消息。

【讨论】:

  • 为了更清楚一点,我的意思是使用嵌套事务。数据库事务不应影响整个消息事务。
  • 我们使用 saga 将所有内容分解为小短事务。但是当死锁仍然发生时,我们在连接池打开时得到错误。
【解决方案2】:

除了更新命令中的 1000 个实体之外,您还可以发布一个事件来表示命令已完成,然后让多个订阅者对该事件进行操作以更新效果实体。在我看来,更新 1000 个实体的命令应该拆分为多个较小的命令。看看 sagas,看看如何处理长期运行的业务流程。例如,您可能有类似流程已启动、步骤 1 已完成、步骤 2 已完成、流程已完成等...

【讨论】:

  • 这就是我们所做的。当例如用户发出影响 1000 个实体的命令,我们将命令拆分为每个“实体”一个。它是由一个传奇来处理的。
  • 但是当其中一个事务死锁时,返回到连接池的连接已损坏,并且当服务重试消息时,它会获取损坏的连接,并且我们会收到所有新消息的事务错误消息..
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-02-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-05-09
  • 2017-03-15
相关资源
最近更新 更多