Database design 锁定来处理并发性——一个好主意？

为了处理并发问题，锁定——任何形式的锁定，无论是行、表还是数据库锁定，都是一个好的解决方案吗

---

如果没有，如何处理并发问题？

我认为没有，因为它一直处于“关闭”状态，使应用程序更加复杂。大多数语言都有优秀的并发处理技术，即使如此，最好的方法还是编写能够“本机”处理并发的代码

有关Java中并发性的更多信息：

---

您的意思是处理应用程序中的并发，还是解决数据库中的并发问题。如果是前者，我觉得这不是一个好方法。如果是后者，这可能是您在不重新设计模式的情况下的唯一答案。

数据库锁定——与表或行锁定相反——是处理并发性的一种糟糕方法；它排除了并发性。

您必须首先定义您的目标。在并发请求的情况下，您希望赢得最后一个用户还是第一个用户。

---

数据库锁定肯定是一种糟糕的方式。尽可能晚地锁定表/行，并尽快释放锁。

除了自己编写某种类型的DMBS锁定代码外，还有许多合理的选择。请记住，某种类型的锁定确实总是在发生（原子操作等），但关键是，如果不需要的话，您不想去那里。如果没有必要，你也不想和哲学家一起吃饭。事务是绕过锁定的一种方法，但这主要用于提交。使用标记/指示记录脏的字段（脏位模式）是另一种方法，只需确保您是以原子访问方式这样做的。正如前面的文章所提到的，该语言通常有一个合适的解决方案，但是该语言通常只支持应用程序、进程到进程、级别并发，有时并发必须在数据库中。我不想假设您有一个丰富的应用程序层，但如果您有很多抽象层来处理这个问题。Oracle提供的TopLink是免费的，并且是Hibernate更健壮的兄弟，这两种技术都可以通过抽象、脏位、缓存和延迟锁定来帮助您管理数据库并发挑战。你真的不想自己实现这些，除非你是为学校或个人项目编写代码。理解问题，但站在巨人的肩膀上。

如果你相信甲骨文，不，一点也不相信。那是因为甲骨文竭尽全力避免了它

问题是，读卡器可以阻止编写器，而编写器也可以阻止读卡器，编写器必须等到所有读卡器都处理完一行后才能进行编写。这会延迟编写过程及其调用方。独占锁（用于写入）保留到事务结束时，以防事务必须回滚-这会停止其他事务看到新值，直到事务提交

在实践中，如果没有太多争用，锁定通常是好的，这与任何并发编程都是一样的。如果对行/页/表有太多争用（没有多少数据库服务器执行整个数据库锁定），则会导致事务依次执行，而不是并发执行

Oracle使用行版本控制，不锁定行来写入，而是创建行的新版本。需要重复阅读的读者会记住他们阅读的行的版本。但是，如果正在记忆其读取内容的读卡器尝试更新自该事务读取以来已由另一个写入器更新的行，则会发生错误；这是为了阻止丢失的更新。为了确保您可以更新一行，您必须说SELECT用于更新；如果您这样做，它需要一个锁-一次只有一个事务可以保存一行进行更新，并且冲突的事务必须等待

SQL Server 2005及更高版本支持快照隔离，这是行版本控制的名称。同样，如果您需要更新刚刚在SQL Server中读取的某些数据，则应该请求更新锁，并与（UPDLOCK）一起使用

锁定的另一个问题是死锁的可能性。这只是两个事务各自持有另一方所需资源的锁，或者通常一个事务周期持有另一方所需的锁。数据库服务器通常会检测到这个死锁，并杀死其中一个事务，然后将其回滚—然后需要重试该操作。在任何情况下，如果有多个并发事务修改同一行，都有可能出现死锁。如果按不同的顺序触摸行，则会发生死锁；很难强制执行数据库服务器将使用的顺序（通常您希望优化器选择最快的顺序，这在不同的查询中不一定是一致的）

---

一般来说，我建议使用与线程相同的方法—使用锁，直到您能够证明它们导致了可伸缩性问题，然后解决如何使最关键的部分无锁。

可以“本机”处理并发的代码。。。有什么建议吗？我想他指的是使用编程语言或库的特性，比如java.util.concurrent.Yes。你能详细说明你的答案吗？这是一种不好的处理方法，因为它阻止了它？我认为他的观点是你锁定了数据库，你没有并发性，因为它被锁定了。@dok1:Mitchel说得对。如果锁定数据库（以独占模式），则根本没有并发访问。如果以只读模式锁定数据库，则可以让多人读取该数据库，但没有人可以修改它。（我知道有一个DBMS在数据库上提供独占锁。）继续：我不知道有一个DBMS在数据库上提供只读共享锁——但我并没有那么努力地寻找。不过，DBMS通常希望数据库随着时间的推移而变化。