1

我们正在使用 Java EE。并且正在做一个应用程序，在最坏的情况下，大量的消息队列消息将来自同一个用户。

因此，我们正在寻找悲观的、SELECT FOR UPDATE 风格的锁定。这在理论上和第一次测试解决了我们的问题。

但我们害怕僵局。不是经典的：用户 X 锁定 A，用户 Y 锁定 B。但更多的场景如：系统崩溃，网络问题，......等等。数据库系统锁定，原因不明。我们将使用现代数据库，例如：oracle、MS SQL 和 postgresql。

我们想知道的是生产中使用的悲观锁定以及期望的实际问题？

提前致谢！

4

1 回答 1

1

我见过的悲观锁定最严重的问题是数据库不可避免的瓶颈。

换句话说，只要您的代码在应用程序级别防止死锁（正如您在帖子中所说），性能就会成为问题 - 吞吐量下降，因为一次只有一个用户可以对给定的数据集执行更新。

如果发生系统异常以select for update执行但未提交，则锁定表可能保持锁定状态，但总的来说这并不常见（尽管这显然取决于您的代码）。我没有看到这种情况是通过与基础设施相关的问题发生的，只是通过应用程序错误。

如果可能，您可以通过批量更新来缓解吞吐量问题，但这实际上取决于您的特定情况。

于 2013-03-21T09:24:55.913 回答