JPA を使用すると、手動OPTIMISTIC
またはPESSIMISTIC
ロックを使用して、トランザクション内のエンティティの変更を処理できます。
これら2つのモードのいずれかを指定しない場合、JPAはロックをどのように処理するのだろうか? ロックモードが使用されていませんか?
明示的なロック モードを定義しない場合、データベースの整合性が失われる可能性はありますか?
ありがとう
JPA を使用すると、手動OPTIMISTIC
またはPESSIMISTIC
ロックを使用して、トランザクション内のエンティティの変更を処理できます。
これら2つのモードのいずれかを指定しない場合、JPAはロックをどのように処理するのだろうか? ロックモードが使用されていませんか?
明示的なロック モードを定義しない場合、データベースの整合性が失われる可能性はありますか?
ありがとう
Java Persistence API 2.0 Final Release仕様のセクション 3.4.4 Lock Modesをスキャンしましたが、具体的なものは何も見つかりませんでしたが (これがデフォルトであるとか、そのようなものであるとは述べていません)、脚注があります。は次のように述べています。
ロック モード タイプ NONE は、ロック モード引数の値として指定でき、注釈のデフォルト値も提供します。
このセクションでは、LockModeType
使用可能な値の種類とその使用法について説明し、この種の引数を取るメソッドとその他の方法について説明します。
したがって、LockModeType.NONE
注釈(JPA、注釈の左右)のデフォルトであると言われているようEntityManager.find(Class, Object)
に、デフォルトを使用すると推測LockModeType
されます。
これを強化するための他のいくつかの微妙なヒントがあります。セクション 3.1.1 EntityManager インターフェイス。
find メソッド (ロックなしで呼び出されるか、LockModeType.NONE で呼び出される場合) と getReference メソッドは、トランザクション コンテキスト内で呼び出す必要はありません。
それは理にかなっている。たとえば、MySQL をデータベースとして使用し、選択したデータベース エンジンが InnoDB の場合、(デフォルトで) テーブルは を使用しますがREPEATABLE READ
、他の RDBMS または他のデータベース エンジンを使用する場合、これは変更される可能性があります。
今のところ、分離レベルがJPAロックモードと関係があるかどうかは正確にはわかりませんが(そのように見えますが)、私のポイントは、異なるデータベースシステムが異なるため、JPAがあなたのために決定できないということです(少なくとも仕様)デフォルトで使用するロックモードLockModeType.NONE
。特に指示がない場合は使用されます。
また、分離レベルとロック モードに関する記事も見つけました。ぜひお読みください。
ああ、最後の質問に答えます。
明示的なロック モードを定義しない場合、データベースの整合性が失われる可能性はありますか?
場合によりますが、同時トランザクションがある場合、答えはおそらくイエスです。
JPA 2.1 FRのため
3.2 バージョン属性
Version フィールドまたはプロパティは、パーシスタンス プロバイダが楽観的ロックを実行するために使用します。これは、エンティティ インスタンスでライフサイクル操作を実行する過程で、永続化プロバイダーによってアクセスおよび/または設定されます。バージョン マッピングでマッピングされたプロパティまたはフィールドがある場合、エンティティは楽観的ロックに対して自動的に有効になります。
そのため、@Version が指定されているなど、エンティティがバージョン管理されたオブジェクトである場合、デフォルトの永続化プロバイダーは楽観的ロックを実行します。
仕様persistence_2.0、89ページ:
バージョン管理されたオブジェクトが別の方法で更新または削除された場合、EntityManager.lock への明示的な呼び出しが行われなくても、実装は LockModeType.OPTIMISTIC_FORCE_INCREMENT の要件が満たされていることを確認する必要があります。