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

问题描述

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

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

解决方法

不要混淆REPEATABLE READ和SERIALIZABLE：后者强于前者，前者不会产生额外的性能成本。 REPEATABLE READ 足以用于乐观锁定。

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

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

如果您想知道长 REPEATABLE READ 交易的缺点：

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

2. 它们会阻止 autovacuum 进程，从而使您的表膨胀