什么时候会在 postgres 可序列化隔离级别上使用 Hibernate 乐观锁？

Question

美好的一天，我了解什么是可序列化隔离级别以及它与REPEATABLE READPostgres 中的有何不同。可串行化事务能够检测读写周期，因此只有第一次提交才会成功。

Hibernate's考虑到这一点，使用基于行版本控制的乐观锁定是否有意义？行版本控制的行为方式完全相同，如果版本列已更新，则将引发 Java 异常，从而回滚事务。此外，根据Postgres wiki，如果某些更新是在应用程序级代码之外完成的（例如 psql 运行的纯 sql 查询），则必须创建触发器。因此，以我的拙见，可序列化级别是乐观锁定的替代品，是这样还是有一些用例您更喜欢乐观锁定？

Answer 1

不要混淆REPEATABLE READ和SERIALIZABLE：后者比前者更强，并且前者不会产生额外的性能成本。REPEATABLE READ对于乐观锁来说就足够了。

我通常更喜欢使用数据库技术的乐观锁定，因为这会更便宜。然而，在一种情况下，我更喜欢在应用程序端使用乐观锁定：如果生成的数据库事务需要很长时间。

使用 时REPEATABLE READ，您必须在同一数据库事务中执行SELECT和 最后一个事务。UPDATE现在事务必须很短才能使数据库正常工作，因此如果涉及用户交互，那么使用REPEATABLE READ事务将是行不通的。

如果你想知道长事务有什么坏处REPEATABLE READ：

1. ALTER TABLE它们持有锁，可能会无限期地阻塞并发活动（想象一下您想在此数据库中运行一个）

2. 它们会阻止 autovacuum 的进行，从而使你的表变得臃肿