我有一个在我的数据库中产生大量更新的网络服务。之后，它会做一些其他的事情（比如微积分、调用另一个 web 服务等）。最后，它再次联系数据库。
问题是表在整个 web 服务生命周期内都被锁定。因此，如果“其他事情”需要更长的时间，我这次不能使用这些表格。
有一种方法可以只锁定寄存器，而不是表？
我怎样才能避免这种情况？
我正在使用 Hibernate 和 MYSQL。
【问题讨论】：
标签： mysql hibernate transactions ejb
Pro JPA 2 书说：
现实情况是，真正需要悲观锁定的应用程序很少，而那些确实需要它的应用程序仅用于有限的查询子集。规则是，如果你认为 你需要悲观锁定，再想一想。如果你处于某种情况 您在同一设备上具有非常高的写入并发性 对象和乐观失败的发生率很高，那么你 可能需要悲观锁定，因为重试的成本可能变为 太贵了，你最好锁定 悲观地。如果您绝对无法重试您的交易并且 愿意为此牺牲一些可扩展性，这也 可能会导致您使用悲观锁定。
所以我建议你重新考虑一下你的需求。
我正在使用 PESSIMISTIC_WRITE
hibernate通过使用'SELECT ... FOR UPDATE'语句获取排他锁（使用悲观锁时）
4:Connection.TRANSACTION_REPEATABLE_READ 锁定您选择的数据（在事务期间）。所以你不需要使用pessimistic_lock。 悲观锁通常用于repeateabe_read，而事务隔离不可repeatable_read(何时Read Committed)
以下链接描述了 mysql 锁定机制
https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read
有办法只锁定寄存器而不锁定表吗？
应锁定所选行而不是表（检查您的选择）
【讨论】：
您使用什么事务隔离级别？请参考documentation 了解这对锁定有何影响以及如何更改。
检查您的申请。交易应尽可能短。如果需要，考虑重新设计。您甚至可以考虑使用BASE instead of ACID。
【讨论】：