我们正在使用Java EE。并且在最坏的情况下，消息队列消息的aloot将来自同一个用户。
因此我们正在寻找Pessimistic，SELECT FOR UPDATE样式锁定。这在理论和fisrt测试中解决了我们的问题。
但我们害怕陷入困境。不是经典的：用户X锁定A，用户Y锁定B.但更多的是如下：系统崩溃，网络问题，......等等。数据库系统锁定，原因不明。我们将使用现代数据库，如：oracle，MS SQL和postgresql。
我们想知道的是生产中使用的悲观锁定以及期望的实际问题？
提前致谢！
答案 0 :(得分：1)
我用悲观锁定看到的最严重的问题是数据库成为不可避免的瓶颈。
换句话说，只要您的代码在应用程序级别防止死锁（正如您在帖子中所述），性能就会成为问题 - 吞吐量会下降，因为一次只有1个用户可以对给定数据集执行更新
如果发生系统异常导致select for update被执行但未提交，则锁定表可能会保持锁定状态，但总的来说这并不常见（尽管这显然取决于您的代码）。我没有看到这种情况发生在基础设施相关的问题上，只是通过应用程序错误。
如果可能，您可以通过批量更新来缓解吞吐量问题，但这实际上取决于您的具体情况。