マルチスレッド - データベースデッドロックの回避と対処

Question

Java 6アプリケーション内からデータベースのデッドロックを処理するための優れた戦略を探しています。複数の並列スレッドが同時に同じテーブルに書き込む可能性があります。データベース（Ingres RDMBS）は、デッドロックが検出された場合、セッションの1つをランダムに終了します。

デッドロック状況に対処するには、次の要件がありますが、どのような技術がありますか？

• 総経過時間が 有意な（測定可能な）を招くであろうセッションを殺す
• 合理的に可能な限り小さく を保つべきである
• 時間スレッドが
  する方法がありませんロールバックすなわち互いに通信 戦略は自律的でなければならない

これまでのところ、私が考えた戦略は次のとおりです。

short attempts = 0; 
boolean success = false; 
long delayMs = 0; 

Random random = new Random(); 
do { 
    try { 
     //insert loads of records in table 'x' 
     success = true; 
    } catch (ConcurrencyFailureException e) { 
     attempts++; 
     success = false; 
     delayMs = 1000*attempts+random.nextInt(1000*attempts); 

     try { 
       Thread.sleep(delayMs); 
      } catch (InterruptedException ie) { 
     } 
    } 
} while (!success); 

どのように改善できますか？例えば一定量（マジックナンバー）秒待つ。 より良い結果が得られる戦略はありますか？

注：デッドロックが実際にはほとんど発生しないように、いくつかのデータベースレベルのテクニックが使用されます。また、アプリケーションは、同じテーブルに同時に書き込むスレッドのスケジューリングを回避しようとします。上記の状況は単なる「最悪のシナリオ」に過ぎません。

注：レコードが挿入されるテーブルは、ヒープパーティションテーブルとして編成され、インデックスはありません。各スレッドはそれ自身のパーティションにレコードを挿入します。

Answer 1

よく使用されるアプローチは、何らかの形の指数バックオフです。 1000*attempts+random aproachではなく、遅延を試行回数の指数関数にします。これは最初の1回か2回の試行で待ち時間を最小限に抑えます。デッドロックが発生したのは不運だったかもしれませんが、接続が実際に輻輳していることが明らかである場合には、

もちろん、デッドロックが発生しにくいようにデータベースアクセスを調整する方法もあります。しかし、あなたのクエリが何をしているのか（そして実行された方法、実行された時）を知らなければ、それができるかどうかは言えません。

Answer 2

これが私たちのやり方です。ループが終了して終了するまでトランザクションを再試行します。

私たちはランダムな遅延を混乱させませんでした。

また、tryブロック内のコミットと例外ハンドラのロールバックを行いました。

複数のロック可能なリソースと複数の同時トランザクションがある場合、デッドロックは避けられません。ロックに対する競合の論理的帰結です。

ロックの競合（つまり、悲観的なテーブルレベルのロック）を回避すると、並行性が妨げられる傾向があります。ロックと競合しないトランザクションを定義できる場合は、デッドロックを避けることができます。ただし、同じテーブルへの同時アクセスは、デッドロックの定義とほぼ同じです。

読み込み時に、挿入（特にHEAPテーブル内）は多くの競合問題なしで並列処理を行うことができます。インデックスの作成を遅らせると、挿入中に他の更新は行われません。

したがって、組織をヒープに変更したり、複数の並行プロセス（またはスレッド、通常は複数のプロセスを持つ方が高速です）をロードしたり、インデックスを構築したりすることができますテーブル）では、デッドロックを回避することができます。

更新や削除を行うときはあまり役に立ちません。

Answer 3

データベースに同時にアクセスする必要がない場合、単純な解決策として、データベースを削除し、タスク処理キューを使用してデータベースを更新し、キュー経由でデータベースへのアクセスをシリアル化することがあります。私はこれがあなたのアプリケーションに非同期要素を導入し、ほとんどのユーザ起動アプリケーションやオンラインWebアプリケーションには適していないが、バッチ/オフラインタイプのアプリケーションを検討する価値があるかもしれないことを認識している。しかし、）。

Answer 4

Ingresのようなデータベースでは常にデッドロックが発生します。挿入、更新、または削除は失敗し、（例のように）再試行戦略が実行されます。 競合が最小限に抑えられ、デッドロックがほとんど発生しないようにデータベースを設計する必要があります。何度も再試行してもトランザクションが継続して失敗する場合は、データベースの大規模な再設計が必要になることを示しています（または、デュアルロックを回避するためにアプリケーションを設計することができるOracleなどのシステムに移行する必要があります行レベルのロック）。

Answer 5

どうですか？

short attempts = 0; 
boolean success = false; 
long delayMs = 0; 

Random random = new Random(); 
do { 
try { 
    synchronized(ClassName.class) { 
     //insert loads of records in table 'x' 
     } 

    success = true; 
} catch (ConcurrencyFailureException e) { 
    attempts++; 
    success = false; 
    delayMs = 1000*attempts+random.nextInt(1000*attempts); 

    try { 
        Thread.sleep(delayMs); 
      } catch (InterruptedException ie) { 
    } 
    } 
} while (!success);