37

まず、Hibernate のことは忘れましょう。A と B の 2 つのテーブルがあるとします。2 つのトランザクションがこれら 2 つのテーブルの同じレコードを更新していますが、txn 1 は B を更新してから A を更新し、txn 2 は A を更新してから B を更新します。これは典型的なデッドロックの例です。これを回避する最も一般的な方法は、リソースを取得する順序を事前に定義することです。たとえば、テーブル A を更新してから B を更新する必要があります。

ハイバネートに戻ります。1 つのセッションで多数のエンティティを更新する場合、セッションをフラッシュすると、さまざまなエンティティの変更により、対応する挿入/更新/削除ステートメントが DB に生成されます。Hibernate には、エンティティ間の更新順序を決定するアルゴリズムがありますか? そうでない場合、最初の段落で説明されているデッドロックの状況を防ぐために Hibernate が使用した方法は何ですか?

Hibernate が順序を維持している場合、どうすれば順序を確認または制御できますか? DB での明示的な更新が Hibernate と競合し、デッドロックが発生することは望ましくありません。

4

2 に答える 2

55

あなたが説明した問題はデータベースによって処理されず、私の経験から、Hibernate でも完全に処理されるわけではありません。

問題にならないように、明確な手順を踏む必要があります。

Hibernate がいくつかの作業を行います。前の回答によると、Hibernate は、分離されたフラッシュ内で、挿入、削除、および更新が達成可能な順序で適用されるように順序付けされることを保証します。AbstractFlushingEventListener クラスのperformExecutions(EventSource セッション)を参照してください。

外部キー制約に違反しないように、すべての SQL (および二次キャッシュの更新) を特別な順序で実行します。

  1. 挿入、実行された順序で
  2. アップデート
  3. コレクション要素の削除
  4. コレクション要素の挿入
  5. 実行された順序で削除します

一意の制約がある場合、この順序を知っておくことは非常に重要です。特に、1 対多の子を置き換えたい場合 (古いものを削除/新しいものを挿入)、古い子と新しい子の両方が同じ一意の制約 (たとえば、同じ電子メール アドレス) を共有する場合は特に重要です。 ）。この場合、削除/挿入する代わりに古いエントリを更新するか、削除後にフラッシュしてから挿入を続けることができます。より詳細な例については、この記事を確認してください。

更新の順序は指定されていないことに注意してください。Hibernate コードを調べると、更新順序はエンティティが更新された順序ではなく、永続化コンテキストに追加された順序に依存すると思います。それはあなたのコードでは予測可能かもしれませんが、Hibernate のコードを読んでも、その順序に頼る気がしませんでした。

私が考えることができる3つの解決策があります：

  1. hibernate.order_updatesをtrueに設定してみてください。これは、同じテーブル内の複数の行が更新されている場合のデッドロックを回避するのに役立ちますが、複数のテーブルにわたるデッドロックには役立ちません。
  2. 更新を行う前に、トランザクションがエンティティの 1 つでPESSIMISTIC_WRITEロックを取得するようにします。使用するエンティティは特定の状況によって異なりますが、デッドロックのリスクがある場合に一貫してエンティティが選択されることを保証する限り、ロックが取得されるまで残りのトランザクションがブロックされます。
  3. デッドロックが発生したときにキャッチし、適切な方法で再試行するようにコードを記述します。デッドロックの再試行を管理するコンポーネントは、現在のトランザクション境界の外に配置する必要があります。これは、失敗したセッションを閉じて、関連するトランザクションをロールバックする必要があるためです。この記事では、自動再試行 AOP アスペクトの例を見つけることができます。
于 2014-04-04T11:32:56.830 に答える
-1

最初の例について-この種のものはデータベースによって処理されます（データベースのトランザクション分離レベルとロック戦略について詳しく読んでください）。これにはさまざまな方法があります。

Hibernate に関しては、org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(EventSource) への javadoc は次のように述べています。

外部キー制約に違反しないように、すべての SQL および二次キャッシュの更新を特別な順序で実行します。

  1. 挿入、実行された順序で
  2. 更新 コレクション要素の削除
  3. コレクション要素の挿入
  4. 実行された順序で削除します

Hibernate が実行する SQL クエリの最適化はこれだけだと思います。残りの問題はデータベースによって処理されます。

于 2012-09-27T08:20:48.153 に答える