hibernate - Hibernate /DB2-913デッドロック

Question

複数のマシンにデプロイされたアプリケーション-同じDBテーブルにアクセスします。MIN行を読み取り、その行を削除します。

これが同時に発生すると、DB2から-913エラーが発生し、デッドロックを示します。

すでに次のオプションを試しました1.行をロックします。2.デッドロックが発生した後、アプリケーションコードでメカニズムを再試行します。

何も機能していないようです。

アイデア/リファレンス/ソリューションはありますか？

TY

Answer 1

SQL0913Nに関連付けられている理由コードを調べて、問題が実際にデッドロック（理由コード2）なのか、単なるロック・タイムアウト（> 2）なのかを判別してください。

問題が本当にデッドロックである場合は、デッドロックのDB2イベント・モニターをアクティブ化することにより、デッドロックに関する詳細なトレース情報を取得できます。Hibernateによって生成された特定のステートメントをまだキャプチャしていない場合は、SQLステートメントイベントモニターを定義してアクティブ化し、可能な限り詳細をキャプチャすることもできます。

Hibernateが使用している分離レベルは、同時実行性に大きな影響を与える可能性があります。通常、アプリケーションは、コミットされていない読み取りの分離を介してダーティ読み取りを実行できる場合、ロックの発生が少なくなりますが、コミットされていないデータを公開し、DB2のACIDプロパティを損なうため、このアプローチは理想的ではありません。ダーティリードをすでに有効にしている場合は、変更がコミットされていない行がロックされるのではなく他の接続から表示されるため、特定の問題の原因になっている可能性があります。

アプリケーションの設計（事実上単一のワークキューであるものへのマルチスレッドアクセス）は理想的ではない可能性があり、リファクタリングの恩恵を受ける可能性があります。食事する哲学者の問題は、競合を減らすためのさまざまな解決策のパターンを提供します。アプリケーションの詳細によっては、ステータスフラグを早い段階で設定するなど、行の処理方法を変更できる場合があります。これにより、他のスレッドは、その特定の行がすでに別のスレッドによって処理されており、スキップできることを理解できます。 。また、トランザクション境界を少し調整してコミットを頻繁に行うことで、問題を軽減できる可能性もあります。

DB2 9.7（2009年6月にリリース）のさらに注目すべき改善点の1つは、現在コミットされているバージョンのロックされた行へのアクセスを提供するカーソル安定性分離の機能拡張です。