我有一个Web服务，该服务在数据库中产生大量更新。之后，它将执行其他一些操作（例如演算，调用另一个Web服务等）。最后，它再次与数据库联系。
问题在于，表在整个Web服务生命周期中都被锁定。因此，如果“其他事情”花费的时间更长，那么我暂时无法使用表格。
有一种方法可以只锁定寄存器，而不锁定表？
如何避免这种情况？
我正在使用Hibernate和MYSQL。
答案 0 :(得分：0)
您使用的是什么事务隔离级别？请参阅documentation，以了解这如何影响锁定以及如何进行更改。
检查您的应用程序。交易应尽可能短。如果需要，请考虑重新设计。您甚至可以考虑使用BASE instead of ACID。
答案 1 :(得分：0)
Pro JPA 2书说：
现实情况是，实际上很少有应用程序需要悲观锁定，而对于有限的查询子集来说，确实需要悲观锁定。规则是，如果您认为 您需要悲观的锁定，再三考虑。如果你有情况 在同一位置上具有很高的写并发度 对象并且乐观失败的发生率很高，那么您 可能需要悲观的锁定，因为重试的费用可能会变成 如此昂贵，以至于您最好锁定 悲观地。如果您绝对无法重试交易，并且 愿意为此牺牲一些可扩展性，这也 可能会导致您使用悲观锁定。
所以我建议您再考虑一下您的需求。
我正在使用PESSIMISTIC_WRITE
休眠模式通过使用“ SELECT…FOR UPDATE”语句获取排他锁（使用悲观锁时）
4：Connection.TRANSACTION_REPEATABLE_READ锁定您选择的数据（在事务期间）。因此您不需要使用pessimistic_lock。 悲观锁通常用于repeateabe_read，而事务隔离不是repeatable_read（当已提交读时）
以下链接描述了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
有一种方法可以只锁定寄存器，而不锁定表？
应该锁定所选行而不是表（检查您的选择）