デッドロック

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