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



我正在使用Microsoft Navision 2009,很多时候,例如,如果您下了一个新订单,并在稍后更改了记录中的某些内容,那么经常会发生,您会收到一条消息:

另一个用户更改了记录,您无法执行任何操作 更改记录。

因此,我们现在调查是否最好选择另一个版本的Navision。例如:

Micrososft Navision 2013 .因为2013利用树层体系结构。2009利用两层架构。

所以我的问题是:

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

该错误表明与并发控制相关,而不是像死锁那样的SQL(您开始对记录执行某些操作,另一个用户编辑同一记录,然后尝试将更改保存在修改后的记录上)。

这与 2 层与 3 层体系结构无关,而是处理并发控制的方式:

  • 首先保存更改获胜(乐观,罕见冲突假设)或
  • 首先进入编辑模式会阻止其他更改者的访问(悲观,通常是冲突假设)

有关 Navision 中的并发控制的更多详细信息,请参阅此处(第 7 点)。看起来使用了乐观并发控制。

正如 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等)的隔离级别从可序列化切换到可重复读取。虽然也可以对 NAV 2009 进行此更改,但在 NAV 2013 中,它是默认选项。此更改直接降低了阻塞/死锁的可能性。您可以在此处阅读有关此更改的更多信息:https://blogs.msdn.microsoft.com/nav/2011/05/12/microsoft-dynamics-nav-changes-by-version/

除此之外,重写了整个数据访问堆栈,并丢弃了所有与本机数据库兼容的代码。这允许针对SQL服务器进行优化(与本机数据库体系结构相反),引入更有效的查询和数据缓存。虽然它不会直接影响块,但这意味着更快的数据操作,因此,锁的持有时间更短。https://msdn.microsoft.com/en-us/library/hh169480(v=nav.70).aspx

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

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

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

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

这种机制被称为乐观锁定 - 这实际上是没有锁定。程序应针对不太可能由多个人同时更改的实体使用乐观锁定进行设计。当两个人同时更改它时,乐观锁定可防止第二个人在不知道更改的情况下覆盖第一个人更改。所以这是一件好事。它可以防止合并冲突。不好的是,第二个人必须重新加载数据,看到更改并必须再次执行自己的更改 - 或者决定现在不更改它。

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

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

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

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

相关内容

  • 没有找到相关文章

最新更新