複数のマシンにデプロイされたアプリケーション - 同じDBテーブルにアクセスします。 MIN行を読み取り、その行を削除します。Hibernate/DB2 -913デッドロック
これが同時に発生すると、デッドロックを意味するDB2から-913エラーが発生します。
すでに次のオプションを試してみました 1.行をロックします。 2.デッドロックが発生した後、アプリケーションコード内のメカニズムを再試行します。
何も動作していないようです。
アイデア/リファレンス/ソリューション
TY
問題が実際にデッドロック（理由コード2）、または単にロック・タイムアウト（> 2）であるかどうかを判断するために、あなたのSQL0913Nに関連付けられた理由コードをチェックしてください。
問題が実際にデッドロックである場合、デッドロックのDB2イベント・モニターを活動化することによって、デッドロックに関する詳細なトレース情報を取り込むことができます。 Hibernateによって生成された特定のステートメントをまだキャプチャしていない場合は、できるだけ詳細を取得するためにSQLステートメントイベントモニタを定義してアクティブ化することもできます。
Hibernateが使用している分離レベルは、並行性に大きな影響を与えます。通常、アプリケーションは、コミットされていない読取り分離によってダーティ・リードを実行できる場合、ロッキングが少なくなりますが、コミットされていないデータを公開し、DB2のACIDプロパティーを損なうため、このアプローチは理想的ではありません。ダーティー読み取りを既に有効にしている場合は、コミットされていない変更がある行がロックされずに他の接続から表示されるため、特定の問題に寄与している可能性があります。
アプリケーションの設計（実際には単一の作業キューにマルチスレッド化されたアクセス）は理想的ではなく、リファクタリングの恩恵を受ける可能性があります。ダイニング哲学者の問題は、競合を減らすためのさまざまな解決策パターンを提供します。アプリケーションの仕様に応じて、状況フラグを早期に設定するなど、行の処理方法を変更できる可能性があります。これは、他のスレッドが特定の行が別のスレッドによってすでに処理されていることを理解し、 。また、トランザクション境界を少し調整してコミット回数を増やすことで、問題を軽減できる可能性があります。
DB2 9.7（2009年6月リリース）のさらに注目すべき機能の1つは、現在ロックされている行のコミット済みバージョンへのアクセスを提供するカーソル安定性の分離です。