我Microsoft Navision 2009和我一起工作了很多次，例如，如果您下了一个新订单，然后在记录中更改了某些内容，那么您经常会收到一条消息：
另一个用户更改了记录，您无法更改记录。
所以我们现在调查是否最好选择另一个版本的 Navision。例如：
Micrososft Navision 2013. 因为2013使用了树层架构。并2009利用两层架构。
所以我的问题是：
死锁多发生在两层架构还是三层架构？为什么？
问问题
600 次
5 回答
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 服务器（相对于本机 DB 架构），引入更有效的查询和数据缓存。虽然它不直接影响块，但它意味着更快的数据操作，因此，锁的持有时间更短。 https://msdn.microsoft.com/en-us/library/hh169480(v=nav.70).aspx
与后台发布的一些其他功能一起，这些更改可能导致 NAV 2013 在 SQL 锁定方面比 NAV 2009 更有效。
于 2016-02-22T13:15:55.747 回答
1
正如在其他答案中所说，这不是锁定问题，这是并发问题。在这种情况下，升级到 Nav 2013 不会有任何效果。更不用说 Nav 2009 是第一个引入 3 层功能的版本。因此，您现在可以在和服务层中使用 RTC。
但是话又说回来，如果这个问题最近出现，可以假设您使用的是为您的需求定制的 Nav 应用程序版本，而不是纯 Cronus。在这种情况下，您可能会遇到一些经常更新订单的错误，例如定期更新订单状态的作业。像这样的作业可能每分钟执行一次，虽然用户需要五分钟来更改订单，但订单可能会通过定期作业更新五次。因此，请仔细查看您的修改并确保它们不是问题。
于 2016-02-20T18:29:24.583 回答
0
正如@alexei 所说：这与 2 层或 3 层架构无关。而且它根本不是死锁。
该机制称为乐观锁定- 实际上是无锁定。一个程序应该使用乐观锁定来设计实体，这些实体不可能同时被多个人更改。当 2 个人同时更改它时，乐观锁定可防止第二个人在不知道更改的情况下覆盖第一个人的更改。所以这是一件好事。它可以防止合并冲突。不好的是，第二个人必须重新加载数据，查看更改并且必须再次进行自己的更改 - 或者决定现在不更改它。
另一方面的悲观锁定是真正的资源锁定。一个人为即将被更改的实体设置了一个锁。该人更改实体并释放锁。与此同时，没有其他人能够编辑锁定的实体。这里的好处是第二个人永远不必再做这项工作，因为保存永远不会失败。但它也有缺点：第二个人必须等待。用户在去吃午饭时忘记解锁他们的资源，甚至在去度假时忘记解锁资源。所以其他用户必须能够打破这些锁，否则程序必须在一段时间后打破它们。
不加锁也是一种策略。如果你从头开始构建一些东西——没有某种框架，这是默认的。两个人都可以像乐观锁定一样同时编辑一个实体。然后第一个保存它。然后第二个保存它并在不知情的情况下覆盖第一个更改。这也可以是一种策略，但在大多数业务案例中并不是一个好的策略。
使用哪种锁定机制是您的应用程序设计的问题。或者，如果您的限制是使用其中之一，您必须设计您的应用程序，使其最适合它。
于 2016-02-20T13:42:49.480 回答
-2
这是一个修订控制问题。也许 Navision 不适合您的需求。尝试另一个修订控制系统。
于 2016-02-20T10:33:22.940 回答