![]() |
![]() |
|
|
プログラマのタスク
「キュー・サービスの呼び出し」のステップ 1 〜 3 で、tpenqueue(3c) を使用して、クライアントはアプリケーション・キュー・スペース内の SERVICE1 キューにメッセージを登録します。オプションとして、tpenqueue() の呼び出しに、応答キューおよび異常終了キューの名前を含めることができます。この例では、これらはキュー CLIENT_REPLY1 および FAILURE_Q になっています。クライアントは、メッセージに付ける相関識別子の値を指定することもできます。この値は、キュー間で同じです。そのため、キューのメッセージに対応付けられたどの応答メッセージまたは異常終了メッセージも、応答キューまたは異常終了キューから読み取られるときに識別できます。
クライアントは、デフォルトのキューの順序付け (たとえば、メッセージがキューから取り出せるようになるまでの時間) を使用するか、デフォルトのキューの順序付けを無効にすること (たとえば、メッセージをキューの先頭に置くこと、またはキュー上の別のメッセージの前に置くことを要求すること) ができます。tpenqueue() は、TMQUEUE サーバにメッセージを送信し、そのメッセージはキューに登録され、承認 (ステップ 3) がクライアントに送信されます。肯定応答は、クライアントが直接確認することはできません。ただし、クライアントが正常な戻り値を取得すると、肯定応答が送られたと見なすことができます。異常終了の戻り値には、異常終了の内容についての情報が含まれています。
キュー・マネージャによって割り当てられたメッセージ識別子は、アプリケーションに返されます。この識別子は、特定のメッセージをキューから取り出す場合に使用します。また、この識別子は、別の tpenqueue() 内で使用して、キューに次に登録されるメッセージの前にあるメッセージを識別することができます。
キューに登録されたメッセージをキューから取り出すには、そのメッセージをキューに登録したトランザクションが正常にコミットされている必要があります。
BEA Tuxedo /Q をキュー・サービスの呼び出しに使用している場合に、メッセージがキューの先頭に到達すると、TMQFORWARD サーバはそのメッセージをキューから取り出し、tpcall(3c)を介してキューと同じ名前を持つサービスに転送します。「キュー・サービスの呼び出し」では、このキューとサービスは SERVICE1 という名前で、ステップ 4、5、および 6 がそれを示しています。クライアントの識別子、およびアプリケーションの認証キーは、メッセージをキューに登録したクライアントに設定されます。この 2 つは、キューから取り出されたメッセージがサービスに送信されるときに、そのメッセージに付加されます。
サービスが応答を返すと、TMQFORWARD はその応答 (オプションとしてユーザ戻りコードを伴う) を応答キューに登録します (「キュー・サービスの呼び出し」のステップ 7 を参照)。
その後 (「キュー・サービスの呼び出し」のステップ 8、9、および 10)、クライアントは tpdequeue(3c) を使用して、応答キュー CLIENT_REPLY1 から読み込んで応答メッセージを取得します。
tpdequeue() に TPQPEEK フラグを設定すると、メッセージをキューから削除せずに取り出すことができます。有効期限が過ぎたメッセージ、または管理者によって削除されたメッセージは、直ちにキューから削除されます。
トランザクション管理
トランザクション管理の目的の 1 つは、グローバル・トランザクション内でメッセージをキューに登録したりキューから取り出して、信頼性を確実にすることです。ただし、これとは相反する目的として、関与するトランザクションの数を最小限にして実行のオーバヘッドを減少させることがあります。
呼び出し元は、キュー処理を呼び出し元のトランザクションから分離して、自身が関与しているあらゆるトランザクションとは別のトランザクションで、メッセージをキューに登録することもできます。ただし、この場合のタイムアウトは、メッセージがキューに登録されているかどうかにかかわらず、認識されません。
より良い方法としては、次の図に示すように、呼び出し元のトランザクション内でメッセージをキューに登録します。
トランザクション境界の判定
この図では、クライアントがトランザクションを開始し、メッセージをキューに登録し、トランザクションをコミットしています。メッセージは、TMQFORWARD で開始される 2 番目のトランザクション内でキューから取り出されます。サービスは tpcall(3c) で呼び出されて実行され、応答が同じトランザクション内でキューに登録されます。クライアントは 3 番目のトランザクションを開始し、応答をキューから取り出します。また、別の要求メッセージをキューに登録する場合もあります。次の要求のキューへの登録は、前の要求からの応答をキューから取り出す処理と同じトランザクション内で行うことができます。そのため、実行中の処理では、3 番目と最初のトランザクションを 1 つにまとめることができます。 注記 システムでは、同じトランザクション内で、あるメッセージからの応答をキューから取り出し、次の要求をキューに入れることが可能です。ただし、同じトランザクション内で、要求をキューに入れ、応答をキューから取り出すことはできません。メッセージをキューから取り出すには、要求をキューに登録するトランザクションが正常にコミットされることが必要です。 応答メッセージの処理 応答メッセージは、tpenqueue() の呼び出し時に、アプリケーションによって指定することもしないことも可能です。その場合、それぞれ次のような結果になります。
エラー処理
エラーを処理するには、アプリケーションに起こるエラーの特徴を理解することと、BEA Tuxedo 管理者とアプリケーション・プログラム開発者の注意深い計画と協力が必要です。BEA Tuxedo /Q では、メッセージがトランザクション内でキューから取り出され、そのトランザクションがロールバックされたときに、再試行パラメータが 0 より大きい場合は、メッセージがキューに戻されて、再度取り出しと実行が可能になります。
一時的な障害の場合は、少し時間をおいてから、メッセージの取り出しと実行を再試行します。たとえば、アプリケーション・データベースに対するアクティビティが多数ある場合は、別のトランザクションによってデータベースのロックが解除されるには、少しの時間さえあればよい場合があります。通常、再試行の回数に上限を設定することも、なんらかのアプリケーション不備によってリソースを著しく浪費することを防ぐには有用です。管理者がキューを設定するときに、再試行の回数と遅延時間 (秒単位) の両方を指定できます。再試行の回数 0 は、再試行が行われないことを示します。再試行の回数が上限に達すると、管理者がキュー・スペースに設定するエラー・キューにメッセージが移動されます。
障害が一時的なものではない場合もあります。たとえば、キュー・メッセージが存在しないアカウントに対して操作を要求する場合などです。その場合、再試行してリソースを浪費しないようにします。アプリケーション・プログラマまたは管理者が、特定の操作の失敗が一時的ではないと判断した場合、単に再試行の回数を 0 に設定します。同じサービスに対する障害が、一時的なものであったり、永続的なものであったりする場合がよくあります。管理者およびアプリケーション開発者は、いろいろな方法でエラーに対処できるようにしておきます。
アプリケーションは、直接メッセージをキューから取り出すことも、TMQFORWARD サーバを使用することもできます。また、トランザクションをコミットするようにロジックで指示されている場合に、トランザクションがロールバックされたり、メッセージがキューに再度登録されたりするエラーが発生することがあります。そのため、多様な問題が発生します。このような問題とその対処法については、「BEA Tuxedo /Q の管理」、「BEA Tuxedo /Q の C 言語プログラミング」、および「BEA Tuxedo/Q COBOL 言語プログラミング」を参照してください。
まとめ
BEA Tuxedo /Q によって BEA Tuxedo アプリケーション・プログラマおよび管理者に提供される機能は、次のようにまとめることができます。
キューに登録されたメッセージを使用するアプリケーション・パラダイムは多数あります。このようなパラダイムでは、マシン、サーバ、またはリソースが使用できない場合、または信頼性が低い場合 (広域ネットワークやワイヤレス・ネットワークの場合など) に、要求をキューに登録できます。また、ワーク・フローで、プロセスの次のステップを行うために各ステップでキュー要求を生成できます。さらに、処理に時間がかかるトランザクションのバッチ処理で、発信元が完了を待たなくても、最終的にはメッセージが処理されたことを保証できます。ピア・ツー・ピア関係で、関係がない 2 つのアプリケーション間で、データ・パイプを提供することもできます。
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|