JPA锁和数据库隔离级别

Question

JPA锁(乐观/悲观)与数据库隔离级别(例如http://www.postgresql.org/docs/9.1/static/transaction-iso.html)之间有任何相互影响吗？

EJB3.2Spec (8.3.2“隔离级别”)说Bean提供者负责设置事务的隔离级别，所以通常我不应该关心，但无论如何，我仍然感到困惑。例如，在PostgreSQL中，根据提到的源，默认的隔离级别是"read“。这是否意味着，当我不锁定任何实体时，事务隔离级别仍将是"read“吗？

Answer 1

通过在实体上设置@Version列，并且不使用锁定(相当于使用LockModeType.NONE)，您将隐式地使用READ_COMMITED隔离。这是在JPA层中实现的，因为所有更新通常都会推迟到提交时间，或者在出现更新冲突的情况下抛出OptimisticLockException (我仍然假设没有显式锁定)。

它假设..。写入数据库的操作通常只在已调用刷新方法(无论是由应用程序显式调用，还是由持久性提供程序运行时根据刷新模式设置显式调用)时发生。

在数据库层，JPA规范还假定您具有READ_COMMITED隔离。

它假定持久化单元映射到的数据库将由实现使用读提交隔离(或不持有长期读锁的供应商等效)访问。

当然，手动刷新/刷新、查询和刷新类型模式(AUTO、COMMIT)会使情况复杂化。另外，第二级和查询缓存配置也可能起作用。但是，对于所有缺省值，JPA READ_COMMITED的行为都是相当可预测的，按照经验，在db级别与READ_COMMITED隔离一起使用是安全的。

为了用JPA实现REPETABLE_READ，您必须使用锁(但这是另一回事)。

锁定模式的目的是提供一种工具，以支持“可重复读取”语义的效果。