死锁多发生在两层架构还是三层架构？为什么？答案

【问题标题】：Deadlocks occur more often in a two-tier architecture or in a three-tier architecture? And why?死锁多发生在两层架构还是三层架构？为什么？
【发布时间】：2016-06-02 00:08:28
【问题描述】：

我正在与Microsoft Navision 2009 合作很多次，例如，如果您下了一个新订单，然后在记录中更改了某些内容，那么您经常会收到一条消息：

另一个用户更改了记录，您无能为力更改记录。

所以我们现在调查是否最好选择另一个版本的 Navision。例如：

Micrososft Navision 2013。因为2013 使用了树层架构。而2009 使用了两层架构。

所以我的问题是：

死锁更常发生在两层架构还是三层架构中？为什么？

【问题讨论】：

您使用的是 Classic 还是 RTC？如果您使用的是 RTC，您可能想尝试 Property RefreshOnActivate

标签： architecture deadlock dynamics-nav dynamics-nav-2015

【解决方案1】：

该错误表明与并发控制有关，而不是 SQL 之类的死锁（您开始对记录执行操作，另一个用户编辑同一记录，然后您尝试将更改保存在已修改的记录上）。

这与2层vs 3层架构无关，而是concurrency control的处理方式：

首先保存更改获胜（乐观、罕见冲突假设）或
首先进入编辑模式会阻止其他更改者访问（悲观，经常与假设发生冲突）

Navision 中有关并发控制的更多详细信息可以在here 中找到（第 7 点）。貌似使用了乐观并发控制。

【讨论】：

好的，谢谢您的评论。但无论如何。然后一般。在两层架构中比在树层架构中更常发生死锁。这也是我的问题之一。
@SavantTheIncredible - 我不认为它们是相关的，因为这是由数据持久性的完成方式引起的，而不是是否存在第三层（逻辑）。它通常在存在 2 层和 3 层的数据层中处理。有关详细信息，请参阅this question。
@Alexei，看起来链接指向 Dynamics AX 而不是 Nav。
Nav 使用锁定来发布例程并乐观地处理其他所有内容。

【解决方案2】：

正如 Alexey 和 pommes 已经说过的，从 2 层架构切换到 3 层架构在 SQL 块/死锁方面没有任何改变。

但是，如果我们更具体地说是从 NAV 2009 迁移到 NAV 2013，除了 3 层架构之外，还有其他一些变化直接针对 SQL 阻塞问题。

其中之一是重新设计销售和采购过帐例程，以显着减少总帐分录表被锁定的时间： https://blogs.msdn.microsoft.com/nav/2012/10/17/gl-entry-table-locking-redesign-in-microsoft-dynamics-nav-2013/

另一个重要的变化是将用于悲观并发（LOCKTABLE等）的隔离级别从SERIALIZABLE切换到REPEATABLE READ。虽然也可以对 NAV 2009 进行此更改，但在 NAV 2013 中它是默认选项。这种变化直接降低了阻塞/死锁的概率。您可以在此处阅读有关此更改的更多信息： https://blogs.msdn.microsoft.com/nav/2011/05/12/microsoft-dynamics-nav-changes-by-version/

除此之外，整个数据访问堆栈都被重写了，所有与 native-db 兼容的代码都被丢弃了。这允许优化 SQL 服务器（相对于原生数据库架构），引入更有效的查询和数据缓存。虽然它不直接影响块，但它意味着更快的数据操作，因此，锁的持有时间更短。 https://msdn.microsoft.com/en-us/library/hh169480(v=nav.70).aspx

与后台发布的其他一些功能一起，这些更改可能会导致 NAV 2013 在 SQL 锁定方面比 NAV 2009 更有效。

【讨论】：

【解决方案3】：

正如在其他答案中所说，这不是锁定问题，这是并发问题。在这种情况下，升级到 Nav 2013 不会产生任何影响。更不用说 Nav 2009 是第一个引入 3 层功能的版本。因此，您现在可以在和服务层中使用 RTC。

但是话又说回来，如果最近出现此问题，可以假设您使用的是为您的需求定制的 Nav 应用程序版本，而不是纯 Cronus。在这种情况下，您可能会遇到一些经常更新订单的错误，例如定期更新订单状态的作业。像这样的作业可能每分钟执行一次，虽然用户更改订单需要五分钟，但订单可能会通过定期作业更新五次。因此，请仔细查看您的修改并确保它们不是问题。

【讨论】：

对不起，可能和死锁无关。但可以肯定的是，nav 2009 是两层应用程序。那是为了苏尔。没有网络客户端。
你为什么这么肯定？ link1 link2 请记住，3 层架构和 Web 客户端不是一回事。第 1 层是 SQL Server，第 2 层是 Nav 服务器（在 Nav2009 中引入），第 3 层是客户端（RTC 或 Web 客户端）。 Nav 2009 仍然可以使用老式客户端，这不是强制性的。
RTC 是瘦客户端，就像 Web 客户端一样。

【解决方案4】：

正如@alexei 所说：这与 2 层或 3 层架构无关。而且它根本不是死锁。

该机制称为乐观锁定 - 实际上是no 锁定。一个程序应该使用乐观锁定来设计实体，这些实体不可能同时被多个人更改。当 2 个人同时更改它时 乐观锁定 防止第二个人在不知道更改的情况下覆盖第一个人的更改。所以这是一件好事。它可以防止合并冲突。坏事是，第二个人必须重新加载数据，查看更改并且必须再次进行自己的更改 - 或者决定现在不更改。

另一边的

悲观锁定是真正的资源锁定。一个人为即将被更改的实体设置了一个锁。该人更改实体并释放锁。与此同时，没有其他人能够编辑锁定的实体。这里的好处是第二个人永远不必再做这项工作，因为保存永远不会失败。但它也有缺点：第二个人必须等待。用户在去吃午饭时忘记解锁他们的资源，甚至在去度假时忘记解锁资源。所以其他用户必须能够打破这些锁，否则程序必须在一段时间后打破它们。

不加锁也是一种策略。如果你从头开始构建一些东西——没有某种框架，这是默认的。两个人都可以像乐观锁定一样同时编辑一个实体。然后第一个保存它。然后第二个保存它并在不知情的情况下覆盖第一个更改。这也可以是一种策略，但在大多数业务案例中并不是一个好的策略。

这是您的应用设计使用哪种锁定机制的问题。或者，如果您的限制条件是使用其中之一，则您必须设计您的应用程序，使其最适合它。

【讨论】：

【解决方案5】：

这是一个版本控制问题。也许 Navision 不适合您的需求。尝试另一个修订控制系统。

【讨论】：

我认为该错误表明与并发相关的错误（“谁的更改获胜”）并且与修订控制系统无关。