デッドロッキング

IMS アプリケーションにはデッドロッキングが発生する場合があります。この状況は、複数のプログラムが同じデータ リソースへの同時アクセス (ただし順序は異なる) により発生するロッキングの競合のために、処理を進行できないことを意味します。次に例を示します。

プログラム-1 がセグメント-A にアクセスし、次にセグメント-B にアクセス

同時に、

プログラム-2 がセグメント-B にアクセスし、次にセグメント-A にアクセス

この場合 AB-BA デッドロッキングが発生し、両方のアプリケーションの進行が停止します。

また 3 つ以上のプログラムによるさらに複雑なシナリオも考えられます。

デッドロッキング問題の解決

デッドロッキングに対する最も有力な防御は、アプリケーションにコーディング デッドロッキングのシナリオが入り込む余地を回避することです。

ただしデッドロッキングが発生したときは、IMS データベースのデータの競合により生じたデッドロッキングを検出する IMS データベース制御が役に立ちます。

注:IMS データベース制御は、IMS DB と SQL 間のデータ制約など複数のリソース マネージャーが関わるデッドロッキングは検出しません。

デッドロッキングが発生すると、データベース制御は敗者を選び、DLI 呼び出しを終了して FD ステータス コードを返します。この FD ステータス コードは、システムにより発行された ROLLBACK 操作をアプリケーション プログラムの代わりにトリガーします。IMS BMP および CICS プログラムは DLI 呼び出しに応えて FD ステータス コードを受信します。IMS トランザクションは自動的に再起動します。

デッドロッキングの敗者は、アプリケーション タイプ、DLI 呼び出し数、および実行時間に基づいて選ばれます。IMS MPP は CICS トランザクションの前に選ばれ、CICS トランザクションは BMP の前に選ばれます。デッドロッキングに関与するセッションがすべて同じプログラム タイプのとき、現在の作業単位の DLI 呼び出し数を比較して、最も少ない数を含むセッションが敗者に選ばれます。現在の UOW での DLI 呼び出し数が同じ場合、最短の時間のセッションが敗者に選ばれます。

ES_IMS_DEADLOCK_WAIT 環境変数を設定することで、デッドロッキングをテストするアルゴリズムを遅らせることができます。これにより、データベース制御スレッドがすべてのデータ競合ポイントで CPU サイクルを消費しないことが保証されます。

 ES_IMS_DEADLOCK_WAIT=n

ここで n は、1 ~ 65535 の範囲のミリ秒数になります。デフォルト値は 1000 ミリ秒です。

アプリケーションのデッドロッキングを診断できるようにするために、デッドロッキングが検出されると次の環境変数がシステム ダンプをトリガーします。

 ES_IMS_DUMP_ON_DEADLOCK=1