我有一个Web服务，它在我的数据库中生成大量更新。之后，它会做一些其他的事情（比如微积分、调用另一个webservice等等）。最后，它再次与数据库联系。问题是这些表在整个webservice生命周期中都是锁定的。所以如果“其他事情”需要更长时间，我可以´这次我不能和table一起工作。有没有办法只锁定寄存器，而不锁定表？我怎样才能避免这种情况？我´我使用hibernate和mysql。
xt0899hw1#
pro jpa 2的书上说：实际情况是，很少有应用程序真正需要悲观锁定，而那些只在有限的查询子集中需要悲观锁定的>。规则是，如果您认为需要悲观锁定，请三思而后行。如果您在同一对象上具有非常高的写并发度，并且乐观失败的发生率很高，那么您可能需要悲观锁定，因为重试的成本会变得非常昂贵，因此最好采用悲观锁定。如果您绝对不能重试事务，并且愿意为此牺牲一些可伸缩性，这也可能导致您使用悲观锁定。所以我建议你再考虑一下你的需要。我´我在用悲观主义来写hibernate通过使用“select…for update”语句（使用悲观锁时）获取独占锁4:connection.transaction\u repeatable\u read锁定所选数据（在事务期间）。所以你不需要使用悲观锁。悲观锁通常用于可重复读取，而事务隔离不可重复读取（当读取提交时）以下链接描述mysql锁定机制https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.htmlhttps用法：//dev.mysql.com/doc/refman/8.0/en/innodb transaction isolation levels.html#isolevelŠu repeatable-read有没有办法只锁定寄存器，而不锁定表？选定的行应该被锁定，而不是表（检查您的选择）
vlf7wbxs2#
您使用的事务隔离级别是什么？请参阅文档以了解这如何影响锁定以及如何更改。检查你的申请。交易应尽可能短。如果需要，考虑重新设计。你甚至可以考虑用碱代替酸。
2条答案
按热度按时间xt0899hw1#
pro jpa 2的书上说：
实际情况是，很少有应用程序真正需要悲观锁定，而那些只在有限的查询子集中需要悲观锁定的>。规则是，如果您认为需要悲观锁定，请三思而后行。如果您在同一对象上具有非常高的写并发度，并且乐观失败的发生率很高，那么您可能需要悲观锁定，因为重试的成本会变得非常昂贵，因此最好采用悲观锁定。如果您绝对不能重试事务，并且愿意为此牺牲一些可伸缩性，这也可能导致您使用悲观锁定。
所以我建议你再考虑一下你的需要。
我´我在用悲观主义来写
hibernate通过使用“select…for update”语句（使用悲观锁时）获取独占锁
4:connection.transaction\u repeatable\u read锁定所选数据（在事务期间）。所以你不需要使用悲观锁。悲观锁通常用于可重复读取，而事务隔离不可重复读取（当读取提交时）
以下链接描述mysql锁定机制
https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.htmlhttps用法：//dev.mysql.com/doc/refman/8.0/en/innodb transaction isolation levels.html#isolevelŠu repeatable-read
有没有办法只锁定寄存器，而不锁定表？
选定的行应该被锁定，而不是表（检查您的选择）
vlf7wbxs2#
您使用的事务隔离级别是什么？请参阅文档以了解这如何影响锁定以及如何更改。
检查你的申请。交易应尽可能短。如果需要，考虑重新设计。你甚至可以考虑用碱代替酸。