2

私optimistic lockingはJPAで勉強し@Version annotationました.DBにバージョン列を追加し、それがどのように管理されているかEntityManagerなど

ドキュメントは、（私自身の言葉で）楽観的ロックはオブジェクトレベルで効果的であると述べています。バージョン定義がエンティティクラスにあるため、確かにそうであることがわかります。

これの意味は：

  1. userA select row_A (db テーブルの行のみ)

  2. userB select row_A

  3. userA は、ユーザー名列の row_A を更新します (ここでバージョンが変更されます)

  4. userB は、username 列の row_A を更新します (optimisticLockException がスローされます)

ここまでは順調ですね。

しかし、ステップ4で考えてみると、

userB update row_A of phoneNumber例えば。

optimisticLockException がまだスローされることはわかっていますが、オブジェクト レベルではなく列レベルでロックする方法はありますか?

私にとっては、列レベルのロックがあればいいのですが、それが可能であっても、それがどのような不利益をもたらすかはわかりません。

4

3 に答える 3

2

受け入れられた答えは完全に真実ではありません。通常の JPA レベルでは当てはまりますが、プロバイダー固有の機能を利用して列レベルのロックを取得できます。たとえば、Glassfish 3.0+ のデフォルト プロバイダである Eclipselink は、楽観的なロック拡張をサポートしており、この分野でより高い柔軟性を提供します。

オプティミスティック・ロックについては、Eclipselink JPA 拡張機能を参照してください。

また

オプティミスティック バージョン ロック ポリシーとカスケーディング

Eclipselink のオプティミスティック フィールド ロック ポリシーの詳細については、

于 2011-08-22T17:11:32.610 に答える
2

いいえ。JPA が行っていることは、オブジェクトを基礎となるリレーショナル データベースにマッピングしているだけであることを思い出してください。したがって、テーブル内の各レコード (行) は、最終的にオブジェクトのインスタンスになります。

データベースは通常、列ではなくレコードをロックします。列全体をロックすることは、テーブルの排他ロックにほとんど似ています。

于 2010-12-29T00:35:32.810 に答える
1

この種のロックの使用はわかりますが、データベース更新の原子性に違反します。人々が残高と当座貸越の制限を持っている銀行アプリケーションを書いていると想像してください。私が始めるとしましょう：

Customer  | Balance | Overdraft Limit
Shirakawa |  -30000 |          -50000

その後、白川さんがやって来て、別々のレジで一度に 2 つの取引を行います。1台で15000円を引き出し、もう1台で当座貸越限度額を40000円に引き下げます。これらの各トランザクションは、それ自体で完全に問題なく、ビジネス ロジックの制約に違反することはありません。しかし、結果は次のとおりです。

Customer  | Balance | Overdraft Limit
Shirakawa |  -45000 |          -40000

ええとああ。

これは不自然な例だと認めます。しかし、これが列レベルの同時更新がサポートされていない一般的な理由です。

ただし、レコードの同時に更新可能な部分を個別のエンティティに分解し、個別に更新することもできます。これを上記の例に当てはめると、上記の口座テーブルと、1 対 1 の関係を持つ当座貸越契約テーブルがあるとします。次に、次のようになります。

Customer  | Balance
Shirakawa |  -45000

Customer  | Overdraft Limit
Shirakawa |          -40000

そして、それらを並行して更新できます。この場合、それは悪い考えですが、役に立つかもしれません。

于 2010-12-29T00:40:44.217 に答える