JPA锁和数据库隔离级别

JPA锁（乐观/悲观）和数据库隔离级别（示例中）之间是否存在相互影响

---

EJB3.2规范（8.3.2“隔离级别”）说Bean提供者负责设置事务的隔离级别，所以一般来说我不应该在意，但无论如何我还是感到困惑。在PostgreSQL中的示例中，根据前面提到的源代码，默认隔离级别为“ReadCommitted”。这是否意味着，当我不锁定任何实体时，事务隔离级别仍将是“读取提交的”

通过在实体上设置

@Version

列并使用无锁定（相当于使用

LockModeType.NONE

）可以隐式使用读取提交的隔离。这是在JPA层中实现的，因为所有更新通常会推迟到提交时间，或者在更新冲突的情况下抛出

OptimisticLockException

（我仍然假设没有显式锁定）

它假定。。。写入数据库 通常仅当应用程序已显式调用flush方法时才会发生， 或者由持久性提供程序运行时根据刷新模式设置执行

在数据库层上，JPA规范还假设您已经读取了提交的隔离

它假定数据库 映射的持久性单元将由使用读提交隔离的实现访问 （或不持有长期读锁的同等供应商）

当然，手动刷新/刷新、查询和刷新类型模式（

AUTO

，

COMMIT

）会使情况复杂化。第二级和查询缓存配置也可能发挥作用。然而，在所有默认情况下，JPA READ_Committed的行为都是可以预测的，根据经验，在db级别伴随READ_Committed隔离是安全的

为了使用JPA实现可重复读取，您必须使用锁（但这是另一回事）

锁定模式旨在提供一种工具，实现“可重复读取”语义的效果

---

只有部分答案，还有一点不清楚。。。您能否更新答案并说明如何准确调用，例如

connection.setTransactionIsolation（connection.READ_UNCOMMITTED）不同于调用，如
entityManager.lock（entity，LockModeType.悲观_WRITE）？一个是使用另一个实现的吗？哪些是用代码实现的，哪些是使用DB提供程序（例如MySQL）锁的？