web-dev-qa-db-ja.com

Spring @TransactionalおよびHibernate @LockModeアノテーションはどのように関連していますか

トランザクションとロックの関係を知りたい。

具体的には、Springの@Transactional HibernateのLockModeに関連します。 https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html 。 http://docs.spring.io/autorepo/docs/spring/4.2.x/spring-framework-reference/html/transaction.html

セッションオブジェクトの作成中にロックを指定しない場合、@TransactionalをreadOnlyとしてfalseとして、私は悲観的並行制御を使用していますか。

誰かが（楽観的/悲観的）同時実行制御とトランザクションの関係を教えてくれれば、とても助かります。

ありがとう、Vivek

javaspringhibernatetransactionslocking
14
vivek4348

@Transactionalアノテーションと@LockModeアノテーションの間にdirect関係はありません。

この投稿 で説明されているように、@Transcationalは、RESOURCE_LOCALまたはJTAトランザクションの明示的な境界をマークするために使用されます。必要な理由は、 すべてのデータベースステートメントがトランザクションコンテキストで実行される であり、トランザクション境界を設定しない場合、ステートメントごとに1つのトランザクションを取得するか、自動コミットするためです。

一方、@LockModeは明示的なロックオプションを設定するためのものです。設定しない場合、暗黙的なロックメカニズムが使用されます。

  • 2PLデータベースエンジンとMVCCデータベースエンジンの両方で、変更されたすべての行で明示的なロックが取得されます。 SerializableでRepeatable Readを使用すると、2PLエンジンの読み取りレコードで共有ロックが取得されます。
  • @Versionプロパティを定義した場合、 implicit楽観的ロックメカニズムが使用されます 。

したがって、@LockModeはロックオプションを明示的に設定するためのものであり、次のオプションを使用できます。

PESSIMISTICロックモードは、ロックされたエンティティに関連付けられているテーブル行のデータベースロックを常に取得します。 OPTIMISTICロックモードは、現在実行中の永続コンテキストでエンティティが変更されていない場合でも、エンティティバージョンを上げる方法を提供することを目的としています。 親エンティティバージョンを使用して複数の子エンティティを調整する が必要な場合、これは非常に便利なメカニズムです。

この回答で提供したリンクには多くの例がありますので、時間をかけてすべてを読んでください。これらの概念をすべて詳しく理解できます。

18
Vlad Mihalcea

春の@TransactionalとHibernateのLockModeクラスは異なります。

Spring Transaction Management

@Transactionalは、宣言的なトランザクション管理、つまりデータベーストランザクション内で一緒に実行されるSQLステートメントを定義するためのSpringアノテーションです。 readOnly属性を使用すると、たとえば、読み取り専用トランザクション内に行を挿入しようとした場合にSpringが例外をスローできます。

ただし、ロックに関しては、読み取り/書き込み（readOnly = false）トランザクション。データを変更しようとするためです。

悲観的ロック

HibernateのLockModeは、悲観的なロックに使用されます。 LockMode.UPGRADEは実際にSELECT...FOR UPDATEステートメント、およびエンティティに対応するデータベース内の行をロックします。

悲観的ロックは、同時トランザクションが互いに競合することを想定しており、読み取り後にリソースをロックし、アプリケーションがデータの使用を終了した後にのみロックを解除する必要があります。

楽観的ロック

Hibernateのオプティミスティック同時実行制御は、通常、データベースのバージョンまたはタイムスタンプ列を使用します。ここでの考え方は、複数のトランザクションが行を同時に変更しようとすると、最初にコミットされたトランザクション以外はすべて、バージョン番号が変更されたことを検出し、ロールバックを実行することです。

楽観的ロックは、複数のトランザクションが相互に影響を与えることなく完了することができるため、トランザクションが影響するデータリソースをロックすることなく続行できることを前提としています。コミットする前に、各トランザクションは、他のトランザクションがそのデータを変更していないことを確認します。チェックにより変更の競合が明らかになった場合、コミットしているトランザクションはロールバックします。

上記の引用は： https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html

3
ck1