SYNC_SEND_RECEIVE プログラミング・モデル

IMS™ でトランザクションを実行するために、Java™ アプリケーションは SYNC_SEND_RECEIVE 対話を実行します。アプリケーションでは、execute メソッドによって使用される IMSInteractionSpec オブジェクト の interactionVerb プロパティーに値 SYNC_SEND_RECEIVE を指定し、commitMode プロパティー に値 0 または 1 を指定します。ただし、SYNC_SEND_RECEIVE 対話式処理は、共用可能永続的ソケットと専用永続的ソケットとで異なります。

共用可能永続的ソケットの処理モデル

以下のシナリオは、通常処理、エラー処理、および実行タイムアウトにおける、共用可能永続的ソケットでの SYNC_SEND_RECEIVE 対話を表しています。これらのステップは、コミット・モード 1 とコミット・モード 0 の両方に適用されます。
  • 通常処理シナリオ

    IMS リソース・アダプターは、アプリケーション・サーバーを 使用して、接続プールから使用可能な接続を取得するか、あるいは新規の接続を作成します。 IMS リソース・アダプターは新規接続の初期化の一環として、その接続のための clientID を生成します。生成された clientID により、ソケット接続が識別され、 また、コミット・モード 0 対話では TPIPE および関連の OTMA 非同期保留キューが識別されます。

    IMS リソース・アダプターは、その接続とソケットとの関連付けを確保し、 そのソケットを使用して、入力データを含む要求を IMS Connect に送信します。そして、IMS Connect が IMS にメッセージを送信し、それを受け取った IMS がトランザクションを実行して 出力メッセージを戻します。

    コミット・モード 0 対話では、出力メッセージを受け取った IMS リソース・ アダプターが、内部的に ACK メッセージを IMS に送信します。このメッセージは、IMS に 対して、IMS キューからその出力を廃棄するように指示します。クライアント・アプリケーションが接続を閉じたり終了したりすると、 接続は接続プールに戻され、他のコミット・モード 0 またはコミット・モード 1 対話によって再利用できるようになります。

  • エラー処理シナリオ

    エラーが発生した場合には必ず、リソース例外がクライアント・アプリケーションにスローされます。また、エラーによっては、IMS Connect によってソケットが切断される場合もあります。コミット・モード 0 対話の場合、これは、 出力メッセージをクライアント・アプリケーションに配達できないことを意味します。共用可能な永続的ソケットでコミット・モード 0 対話を行っていたときに配信されなかった出力メッセージは、 自動生成された clientID を使用して TPIPE にキューイングされることはありません。 この動作は、通常のコミット・モード 0 処理の場合とは異なります。

    配信されなかった 出力メッセージの処理には、いくつかのオプションがあります。共用可能な 永続的ソケットでコミット・モード 0 対話を行っていたときに配信されなかった 出力メッセージをパージする場合は、IMSInteractionSpec プロパティーの purgeAsyncOutput を TRUE に設定する必要があります。このプロパティーは、IMS Connect が配信されなかった入出力 PCB 出力をパージするかどうかを決定します。これは、共用可能な永続的ソケット接続でのみ有効です。purgeAsyncOutput が TRUE の場合、次の出力メッセージがパージされます。
    • 1 次 IMS アプリケーション・プログラムによって入出力 PCB に挿入された、配信されなかった出力メッセージ。
    • プログラム間の切り替えが起動した 2 次 IMS アプリケーション・プログラムに よって入出力 PCB に挿入された出力メッセージ。
    purgeAsyncOutput プロパティーが SYNC_SEND_RECEIVE 対話で指定されていない場合、デフォルトは TRUE です。

    配信されなかった出力メッセージの別の 処理方法は、非同期出力を別の宛先に転送することです。配信されなかった出力メッセージを転送する場合は、IMSInteractionSpec プロパティーの reRoute を TRUE に設定する必要があります。reRoute が TRUE の場合は、 非同期出力は、生成された clientID の TPIPE にキューイングされない代わりに、 クライアントによって指定された宛先にキューイングされます。この宛先は、IMSInteractionSpec プロパティーの reRouteName で指定されます。このプロパティーは、共用可能な永続的ソケットでの SYNC_SEND_RECEIVE 対話でのみ 有効です。また、purgeAsyncOutput と reRoute の両方を TRUE に設定すると、 例外がスローされます。

  • ExecutionTimeout シナリオ

    実行タイムアウトが発生した場合、ソケット接続はオープンしたままになります。コミット・モード 0 対話では、配信されなかった出力メッセージは、 自動生成された clientID を使用して TPIPE にキューイングされるか、reRoute 宛先に キューイングされます。コミット・モード 1 対話では、配信されなかった出力は回復可能ではありません。

    クライアント・アプリケーションが接続を閉じたり終了したりすると、接続は接続プールに戻され、 他のコミット・モード 0 またはコミット・モード 1 対話によって再利用できるようになります。

専用永続的ソケットの処理モデル

専用永続的ソケット接続は、 コミット・モード 0 対話でのみ使用することができます。以下のシナリオは、通常処理、エラー処理、および実行タイムアウトにおける、専用永続的ソケットでのコミット・モード 0 SYNC_SEND_RECEIVE 対話を表しています。
  • 通常処理シナリオ

    通常の環境では、 コミット・モード 0 SYNC_SEND_RECEIVE 対話がクライアント・アプリケーションによって実行されると、 アプリケーション・サーバーは、ユーザー指定の clientID が割り当てられた既存の接続を戻すか、 あるいはユーザー指定の clientID を使用して新規の接続を作成します。ユーザー指定の clientID により、ソケット接続が識別され、 また、TPIPE および関連の OTMA 非同期保留キューが識別されます。

    IMS リソース・アダプターは、その接続とソケットとの関連付けを確保し、 そのソケットを使用して、入力データを含む要求を IMS Connect に送信します。そして、IMS Connect が IMS に メッセージを送信し、それを受け取った IMS が トランザクションを実行して出力メッセージを戻します。 IMS リソース・アダプターは、出力メッセージを受け取ると、内部的に ACK を IMS に送信します。この ACK は、IMS キューからその出力を廃棄するように指示します。接続が閉じたりアプリケーションが終了したりすると、接続が接続プールに戻され、 同じユーザー指定の clientID でコミット・モード 0 対話を実行している別のアプリケーションによって再利用されるようになります。

  • エラー処理シナリオ

    エラーが発生した場合には必ず、リソース例外がクライアント・アプリケーションにスローされます。また、エラーによっては、IMS Connect によってソケットが切断される場合もあります。コミット・モード 0 対話の場合、これは、 出力メッセージをクライアント・アプリケーションに配達できないことを意味します。配信されなかった出力は、ユーザー指定の clientID と関連付けられた TPIPE にキューイングされます。

    プロパティー purgeAsyncOutput および reRoute は、専用永続的ソケットには 適用できません。配信されなかった出力メッセージを専用永続的ソケットで パージまたは転送することはできません。

  • ExecutionTimeout シナリオ

    実行タイムアウトが発生した場合、ソケットはオープンしたままになり、コミット・モード 0 対話からの出力は、 そのユーザー指定の clientID に関連した TPIPE にキューイングされ、後でリトリーブされます。 接続が閉じられるか、アプリケーションが終了すると、IMSManagedConnection オブジェクトが接続プールに戻され、同じユーザー指定の clientID でコミット・モード 0 対話を実行している別のアプリケーションによって再利用されます。

関連概念
コミット・モードの処理の概要
SYNC_SEND プログラミング・モデル
非同期出力の検索
関連タスク
出力メッセージ・カウントの表示
ご利用条件 | フィードバック
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.
(C) Copyright IBM Japan 2005.