JPA 和默认锁定模式 [英] JPA and default locking mode

问题描述

使用 JPA，我们可以手动使用 OPTIMISTIC 或 PESSIMISTIC 锁定来处理事务中的实体更改.

With JPA, we can use manually OPTIMISTIC or PESSIMISTIC locking to handle entity changes in transactions.

如果我们不指定这两种模式之一，我想知道 JPA 如何处理锁定?没有使用锁定模式?

I wonder how JPA handles locking if we don't specify one of these 2 modes ? No locking mode is used?

如果不定义显式锁定模式，会不会丢失数据库完整性?

If we don't define an explicit locking mode, can the database integrity be lost?

谢谢

推荐答案

我已经浏览了 Java Persistence API 2.0 Final Release 规范，虽然我找不到任何特定内容(它没有说明 this 是默认值或类似的东西)有一个脚注说明以下内容.

I've scanned through section 3.4.4 Lock Modes of the Java Persistence API 2.0 Final Release specification and while I couldn't find anything specific (it doesn't state that this is the default or anything like that) there is a footnote which says the following.

锁定模式类型 NONE 可以指定为锁定模式的值参数，并为注释提供默认值.

The lock mode type NONE may be specified as a value of lock mode arguments and also provides a default value for annotations.

该部分是关于LockModeType 可用的值及其用法，并描述了哪些方法接受此类参数等等.

The section is about the kinds of LockModeType values available and their usages and describes which methods takes an argument of this kind and whatnot.

所以，正如它所说的，LockModeType.NONE 是注释的默认值(JPA，左右注释)我猜当你使用 EntityManager.find(Class, Object)使用默认的 LockModeType.

So, as it said LockModeType.NONE is default for annotations (JPA, annotations left and right) I guess when you use EntityManager.find(Class, Object) the default LockModeType is used.

还有一些其他的微妙提示可以加强这一点.第 3.1.1 节 EntityManager 接口.

There are some other, subtle, hints to reinforce this. Section 3.1.1 EntityManager interface.

find 方法(前提是它是在没有锁的情况下调用的，或者是用LockModeType.NONE) 和 getReference 方法不需要在事务上下文中调用.

The find method (provided it is invoked without a lock or invoked with LockModeType.NONE) and the getReference method are not required to be invoked within a transaction context.

这是有道理的.例如，如果您使用 MySQL 作为数据库并且您选择的数据库引擎是 InnoDB，那么(默认情况下)您的表将使用 REPEATABLE READ，如果您使用其他 RDBMS 或其他数据库引擎，这可能会改变.

It makes sense. For example if you use MySQL as your database and your database engine of choice is InnoDB then (by default) your tables will use REPEATABLE READ, if you use some other RDBMS or other database engines this could change.

现在我不确定隔离级别是否与 JPA 锁定模式有关(尽管看起来是这样)，但我的观点是不同的数据库系统不同，因此 JPA 无法为您决定(至少根据规范)默认使用哪种锁定模式，因此如果您不另外指示，它将使用 LockModeType.NONE .

Right now I'm not exactly sure that isolation levels has anything to do with JPA lock modes (although it seems that way), but my point is that different database systems differ so JPA can't decide for you (at least according to the specification) what lock mode to use by default, so it'll use LockModeType.NONE if you don't instruct it otherwise.

我还发现了一篇关于隔离级别和锁定模式的文章，你可能想读一读.

I've also found an article regarding isolation levels and lock modes, you might want to read it.

哦，还有回答你的最后一个问题.

Oh, and to answer your last question.

如果我们不定义显式锁定模式，数据库是否可以诚信缺失?

If we don't define an explicit locking mode, can the database integrity be lost?

它取决于，但如果您有并发事务，那么答案可能是是.

It depends, but if you have concurrent transactions then the answer is probably yes.

这篇关于JPA 和默认锁定模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！