什么时候在postgres可序列化隔离级别上使用Hibernate乐观锁？
日安，我了解什么是可序列化的隔离级别以及它与Postgres中的REPEATABLE READ有何不同。可序列化事务能够检测读写周期，因此只有第一次提交会成功。
考虑到这一点，使用Hibernate基于行版本控制的乐观锁定是否有意义？行版本控制的行为方式完全相同，如果版本列已更新，则将抛出 Java 异常，这将回滚事务。此外，根据Postgres维基，如果某些更新是在应用程序级代码之外完成的（例如由psql运行的纯SQL查询），则必须创建触发器。所以以我的拙见，可序列化级别是乐观锁定的替代品，是这样还是在某些用例中您更喜欢乐观锁定？
共有2个答案
一个用例是长对话，见此处:https://vladihalcea . com/preventing-lost-updates-in-Long-conversations/)
在这种情况下，为了避免更新丢失，(见此处)如果在mysql中使用< code>postgres，除了< code>REPEATABLE READ隔离级别之外，还应该使用乐观锁，我认为需要< code>SERIALIZABLE。
不要混淆可重复读取和可序列化：后者比前者更强，前者不会产生额外的性能成本。可重复读取足以实现乐观锁定。
我通常更喜欢使用数据库技术的乐观锁，因为这样更便宜。然而，在一种情况下，我更喜欢应用程序端的乐观锁定:如果产生的数据库事务需要很长时间。
使用 REPEATABLE READ，您必须在同一数据库事务中执行 SELECT 和最终 UPDATE。现在事务必须简短才能使数据库正常工作，因此，例如，如果涉及用户交互，则使用可重复的读取事务将是一个不启动的过程。
如果您想知道长＜code＞REPEATABLE READ＜/code＞事务的坏处：
>
它们持有锁，可能会无限长地阻塞并发活动（假设您想在此数据库中运行ALTERTABLE）
它们阻止了自动吸尘的进展，从而使您的桌子膨胀
-
我有点理解实体锁定和事务隔离级别的目的，但不能得到悲观锁定和可序列化级别之间的区别。据我所知，在这两种情况下，表都被锁定，其他事务都无法访问它，因此在这两种情况下，防止并发修改的操作都是由DB执行的，看起来没有什么区别。谁能解释一下这里是否真的有区别？
-
以下链接描述了可序列化事务隔离级别。 http://blogs . msdn . com/b/sqlcat/archive/2011/02/20/concurrency-series-basics-of-transaction-isolation-levels . aspx 假设我有一个用户更新表 另一个用户正在更新表 我想序列化这两个更新语句（意味着在第二个语句开始之前等待第一个完成），尽管我们
-
我正在编写一个Web应用程序，其中两个不同的用户可以更新一个事物列表，例如待办事项列表。我开始意识到，乐观锁定机制效果最好，因为我不期望高争用。 我正在查看事务隔离级别，现在我有点困惑。看起来不同的事务隔离级别也解决了类似的问题。 这两个不同的概念是如何相互关联的？如果可能，举一个简单的例子。
-
我需要在SQL服务器中实现一个可序列化的隔离级别，但是我已经尝试了很多方法，但我没有得到它。 我需要在一个事务中锁定 1 行（是否锁定整个表并不重要）。因此，另一个事务甚至无法选择该行（不读取）。 我尝试的最后一件事： 对于交易1: 对于交易2: 我希望事务2一直等到事务1提交操作，但是事务2给了我行。 如果我错过了什么，谁能解释我？
-
我似乎无法找到一个简单的问题的直接答案。如果我在 T-SQL 中创建事务并将隔离级别设置为可序列化，这是否会在我正在修改的表上创建读取锁？
-
问题内容： 我有一个使用hibernate3.6.4版和c3p0 0.9.1.2版进行连接池的应用程序。我的基础RDBMS是MySql 5.0.67版。 我的MySql安装表明默认的事务隔离级别为“ REPEATABLE-READ”（4）： 我尚未在hibernate.cfg.xml或应用程序中的任何位置更改或配置事务隔离级别。在应用程序中，我使用以下代码来打印配置： 我得到以下结果： 因此，我的