作業論理単位

リカバリー不能と分類されているリソース (Windows® 2000 のシリアル・ファイルなど) を変更すると、その変更結果は比較的永続的になります。コードでも EGL ランタイム・サービスでも、この変更結果を単純に無効にすることはできません。リカバリー可能と分類されているリソース (リレーショナル・データベースなど) を変更すると、コードまたは EGL ランタイム・サービスでは、この変更をコミットして変 更内容を永続的にしたり、最後に変更がコミットされた時点の状態に戻すために変更を ロールバックしたりできます。

リカバリー可能リソースには以下のものがあります。
作業論理単位 により、グループとしてコミットまたはロールバックさ れる入力操作が識別されます。作業単位は、リカバリー可能リソースがコードにより変更された時点で開始され、次のいずれかが初めて発生した時点で終了します。
以降では次の項目について詳細に説明します。

CICS の作業単位

CICS 実行単位では、1 度に 1 つの DB2® UDB データベースのみが使用可能であり、以下の処理が自動的に実行されます。
  • ハード・エラーが原因でプログラムが終了すると、EGL ランタイム・サービスがロールバックを実行し、カーソルを閉じ、ロックを解放する。
  • 実行単位が正常に終了すると、CICS によるコミット、カーソルの終了、ロッ クの解放が、呼び出し側で要求されない場合を除き、これらの操作が実行される。例えば、次のような場合には、これらの操作が実行されない。
    • Java™ コードが EGL 生成の CICS プログラムへアクセスする。
    • 呼び出しに使用されているリンケージ・オプション・パーツにより、Java コード が作業論理単位を処理するように指定されている。この作業論理単位はクライアント作業 単位 と呼ばれる。詳細については、『callLink エレメントの luwControl』を参照。

また、CICS 実行単位では、システム関数 sysLib.connect または VGLib.connectionService (これらは他のデータベースへの動的接続を許可) を呼び出す場合、この呼び出しの前に sysLib.commit または sysLib.rollback を呼び出す必要があります。

Java の作業単位

Java 実行単位では、次のように処理が行われます。
  • ハード・エラーが原因で Java プログラムが終了すると、ロールバックが実行され、カ ーソルが閉じ、ロックが解放された場合と同様の結果となる。
  • 実行単位が完了すると、EGL がコミットを実行し、カーソルを閉じ、ロックを解放する。
  • 複数のデータベースから読み込むために複数の接続を使用している場合には、作業単位では 1 つのデータベースのみを更新する必要があります。これは、シングル・フェーズ・コミットのみが実行可能であるためです。関連情報については、『VGLib.connectionService』を参照してください。
  • EGL 生成の EJB セッション Bean を使用して EGL 生成のプログラムへアクセスすると、EJB セッション Bean のデプロイメント記述子であるトランザクション属性 (コンテナー・トランザクション・タイプとも呼ばれる) が、トランザクション制御に影響することがある。このトランザクション属性がトランザクション制御に影響を及ぼすのは、呼び出しのリンケージ・オプション・パーツである callLink エレメントの remoteComType プロパティーが direct である場合に限る。詳細に ついては、『callLink エレメントの remoteComType』を参照。

    EJB セッション Bean はトランザクション属性 REQUIRED が設定された状態で生成されますが、この値はデプロイメント時に変更できます。このトランザクション属性については、Java の資料を参照してください。

ご利用条件 | フィードバック
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.
(C) Copyright IBM Japan 2005.