c# - TransactionScope 而不是使用锁

Question

我目前有一种方法可以读取数据以确定是否需要更新，然后将更新推送到数据库(依赖注入(inject))。该方法受到严重打击，我发现了与并发相关的错误，即多次更新，因为多个线程在第一次更新之前读取数据。

我用锁解决了这个问题，效果很好。我怎样才能使用 TransactionScope 来做同样的事情呢？我可以吗？它会像锁一样阻塞另一个线程吗？此外，我是否可以像使用锁一样“锁定”一个特定的“id”(我保留了一个字典，其中存储了一个要为每个 id 锁定的对象)？

我正在使用 Entity Framework 5，尽管它被存储库和工作单元模式隐藏了。

Answer 1

应用程序级锁定可能不是解决此问题的方法。首先，您通常只需要锁定单个记录或记录范围。接下来您可能稍后需要锁定另一个修改并进入相当复杂的代码。

这种情况通常用乐观或悲观并发来处理。

• 乐观并发 - 您将拥有额外的数据库生成列(数据库通常具有特殊类型，如时间戳或行版本)。每次更新记录时，数据库都会自动更新该列。如果将此列配置为行版本，EF 将在更新的 where 条件中包含该列 => 执行的更新将搜索具有给定键和行版本的记录。如果找到记录，它将被更新。如果找不到该记录，则意味着不存在具有该键的记录，或者自当前进程加载其数据后其他人更新了该记录 => 您将获得异常，您可以尝试刷新数据并再次保存更改。此模式对于更新不多的记录很有用。在你的情况下，它可能会导致另一个麻烦。
• 悲观并发——这种模式使用数据库锁定。当您查询记录时，您将锁定它以进行更新，因此没有其他人也可以锁定它以进行更新或直接更新。不幸的是，这种模式目前在 EF 中没有直接支持，您必须通过原始 SQL 执行它。我写了一个article explaining the pessimistic concurrency及其在 EF 中的用法。即使是悲观并发，对于大负载下的数据库也可能不是一个好的解决方案。

如果您真的构建了一个解决方案，其中许多并发进程始终尝试更新相同的数据，您最终可能会重新设计，因为不会有基于锁定或重新运行失败更新的可靠的高性能解决方案。