2

最近、私はデータベーストランザクションを研究しており、次のような記事の引用があります。

JPA は、@Version アノテーションを介して行のバージョン管理の自動サポートを提供します。 @Version アノテーションが付けられたフィールドまたはプロパティを持つエンティティがある場合、楽観的ロックが自動的に有効になります。

私の理解では、データベースの分離レベル戦略は、次のようなさまざまなロックを使用して維持されます

  1. コミットされていない読み取り: 排他的書き込みロックで実装
  2. 読み取りコミット: 共有読み取りロックと排他的書き込みロックを使用して実装されます。

すぐ。したがって、トランザクションの分離は、悲観的ロックを使用して推測される別のロックによって実装されます。

私の質問は、フィールドが @Version 注釈付きとして宣言されている場合、それは基になるデフォルトの分離レベルをオーバーライドし、楽観的ロックが行われるのですか?

4

2 に答える 2

3

いいえ、それらは別のものです。デフォルトでは、read-commitedトランザクションがコミットされるまで変更を読み取ることができないように分離レベルが設定されています。

を使用して楽観的ロックを使用することにした場合@Version、分離レベルはまったく変更されませんが、使用するread-commited意味がないと思うかread-uncommited、read-serialized楽観的ロックを使用しているときに分離レベルを使用することを前提としていますが、できる。

トランザクションの作成時に分離レベルを定義します。通常は、読み取り専用モード、分離レベル、伝播モード、およびトランザクションの名前を指定します。

楽観的ロックは ORM インフラストラクチャによって制御され、永続化するときにオブジェクトの適切な番号のバージョンを処理します。したがって、それらは異なるものです。

それが役に立てば幸い！

于 2015-12-23T07:52:54.807 に答える
2

いいえ、基礎となるデータベースの分離レベルを JPA の楽観的ロックでオーバーライドすることはできません。

どういうわけかそれができたとしても、それをしてもダメです。

ほとんどのデータベースは、デフォルトとしてREAD_COMMITED分離レベルを採用しています。

READ_COMMITED分離レベルで次のシナリオを検討してください。

  • Product2 つの Manager がエンティティをロードします
  • どちらも価格を上げてから節約することにしました。
  • 1 つの価格更新が他の価格更新より先にコミットされます。
  • したがって、1 つのマネージャーの価格は、マネージャーがそれを知ることなく、他のマネージャーの価格から上書きされます。

このシナリオは些細なことですが、この種のことは、重要なシナリオで発生する可能性があります。

この意図しないシナリオは、データベースのデフォルトの分離レベルで楽観的ロックを使用することで回避できた可能性があります。

お役に立てれば。

于 2015-12-23T09:57:07.453 に答える