| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo /Q コンポーネント > BEA Tuxedo /Q の C 言語プログラミング |
|
Tuxedo /Q コンポーネント
|
BEA Tuxedo /Q の C 言語プログラミング
ここでは、次の内容について説明します。
はじめに
ここでは、キューへのメッセージの登録とキューからのメッセージの取り出しを行う ATMI C 言語関数tpenqueue(3c)、tpdequeue(3c)、およびいくつかの補助関数の使用方法について説明します。
必要とされる知識
キュー機能を使用するクライアント・プログラムまたはサーバ・プログラムをコーディングする BEA TUXEDO プログラマには、BEA Tuxedo ATMI にバインドされた C 言語についての知識が必要です。BEA Tuxedo プログラミングに関する全般的な説明については、『C 言語を使用した BEA Tuxedo アプリケーションのプログラミング』を参照してください。ATMI 関数の詳細については、『BEA Tuxedo C リファレンス』を参照してください。
要求の発信元
BEA Tuxedo /Q のキューにメッセージを登録する呼び出しは、アプリケーションに対応付けられているあらゆるクライアント・プロセスまたはサーバ・プロセスから行うことができます。たとえば、次の発信元があります。
デフォルトの場合の注意事項
ここでは、BEA Tuxedo /Q プログラミングについて、キュー・サービスの呼び出し の主に左側部分について説明します。この図では、クライアント (または、クライアントとして機能するプロセス) は tpenqueue(3c) を呼び出し、TMQUEUE(5) サーバを通して利用できるキュー・スペースを指定して、メッセージをキューに登録しています。クライアントは、その後、TMQUEUE への tpdequeue(3c) 呼び出しを介して、応答を取得します。
キュー・サービスの呼び出し では、キューに入れられたメッセージが、サーバ TMQFORWARD(5) によってキューから取り出され、処理のために tpcall(3c) を介してアプリケーション・サーバに送信されています。tpcall() に対する応答が受信されると、TMQFORWARD は応答メッセージをキューに登録します。TMQFORWARD の主な目的は、キュー・スペースと既存のアプリケーション・サービスとの間にインターフェイスを提供することです。そのため、アプリケーションにコードを追加する必要はありません。そのため、ここでは、クライアントとキュー・スペースとの間の処理を中心に説明します。
キュー機能の使い方を簡単に示すサンプルがソフトウェアに提供されています。詳細については、サンプル・アプリケーションを参照してください。
メッセージのキューへの登録
次は、tpenqueue() の構文です。
#include <atmi.h>
int tpenqueue(char *qspace, char *qname, TPQCTL *ctl,
char *data, long len, long flags)
tpenqueue() が呼び出されると、qspace で識別されるキュー・スペース内の qname キューにメッセージを格納するようにシステムが指示されます。メッセージは data が指すバッファ内にあり、その長さは len で示されます。flags にビット設定を行うと、システムに tpenqueue() 呼び出しの処理方法が通知されます。登録されたメッセージおよび応答の処理方法のさらに詳しい情報は、ctl が指す TMQCTL 構造体で定義されます。
tpenqueue(3c) の引数
tpenqueue(3c) の処理を制御するいくつかの重要な引数があります。その一部について、以下に説明します。
tpenqueue():qspace 引数
qspace は、管理者によって既に作成されたキュー・スペースを識別します。サーバがコンフィギュレーション・ファイルの SERVERS セクションで定義されている場合、そのサーバが提供するサービス名は、実際のキュー・スペース名 (GROUPS セクションの OPENINFO パラメータの一部として指定されます) のエイリアスになります。たとえば、アプリケーションがサーバ TMQUEUE を使用する場合、qspace 引数が指す値は、TMQUEUE が宣言するサービス名になります。サービス名のエイリアスが何も定義されていない場合、デフォルトのサービス名はサーバ名 TMQUEUE と同じになります。その場合、コンフィギュレーション・ファイルには次の内容が記述されています。
TMQUEUE
SRVGRP = QUE1 SRVID = 1
GRACE = 0 RESTART = Y CONV = N
CLOPT = "-A"
または
CLOPT = "-s TMQUEUE"
サーバ・グループ QUE1 のエントリには、OPENINFO パラメータを使用して、リソース・マネージャ、デバイスのパス名、およびキュー・スペース名を指定します。クライアント・プログラムにおける qspace 引数は、次のように記述されます。
if (tpenqueue("TMQUEUE", "STRING", (TPQCTL *)&qctl,
(char *)reqstr, 0,0) == -1) {
Error checking
}TMQUEUE(5) リファレンス・ページの例では、サーバを作成してコンフィギュレーション・ファイルで指定する際に、サービスのエイリアスを指定する方法が示されています。サンプル・アプリケーション のサンプル・プログラムでも、サービスのエイリアスが指定されています。
tpenqueue():qname 引数
キュー・スペース内で、キューを使用してサービスを呼び出している場合、メッセージ・キューは要求を処理できるアプリケーション・サービスに従って命名されます。qname は、そのようなアプリケーション・サービスを指すポインタです。それ以外の場合、qname は、アプリケーション (メッセージをキューに登録したアプリケーション、または別のアプリケーション) によってキューから取り出されるまで、メッセージを格納しておく場所を単に示す名前です。
tpenqueue():data および len 引数
data は、処理対象のメッセージが格納されたバッファを指すポインタです。そのバッファは、tpalloc(3c) を呼び出して割り当てられたものであることが必要です。len は、メッセージの長さを指定します。BEA Tuxedo のバッファ・タイプには、メッセージの長さを指定する必要がないのもの (FML など) もあります。その場合、len は無視されます。data は NULL にすることもできます。その場合、len は無視され、メッセージはデータ部分なしでキューに登録されます。
tpenqueue():flags 引数
flags の値は、tpdequeue() 呼び出しの処理方法を BEA Tuxedo システムに通知するために使用されます。次は、有効なフラグです。
TPQCTL 構造体
tpdequeue() の 3 番目の引数は、TPQCTL 型の構造体へのポインタです。TPQCTL 構造体には、アプリケーションで使用されるメンバと BEA Tuxedo システムで使用されるメンバがあり、アプリケーション・プログラムとキュー機能間の両方向でパラメータがやり取りされます。tpenqueue() を呼び出すクライアントは、フラグを設定して、システム側で入力する必要のあるフィールドをマークします。この構造体は、tpdequeue() でも使用されます。一部のフィールドは、アプリケーションが tpdequeue() を呼び出すまで使用されません。次のコード例は、この構造体全体を示しています。
コード リスト 3-1 tpqctl_t 構造体
#define TMQNAMELEN 15
#define TMMSGIDLEN 32
#define TMCORRIDLEN 32
struct tpqctl_t { /* キュー・プリミティブの制御パラメータ */
long flags; /* どの値が設定されるかのかを示します。 */
long deq_time; /* キューから取り出すときの絶対時間/相対時間 */
long priority; /* 登録優先順位 */
long diagnostic; /* 失敗の原因を示します。 */
char msgid[TMMSGIDLEN]; /* 既存メッセージの ID (そのメッセージの前に登録されます) */
char corrid[TMCORRIDLEN]; /* メッセージを識別するときに使用される相関識別子 */
char replyqueue[TMQNAMELEN+1]; /* 応答メッセージ用のキューの名前 */
char failurequeue[TMQNAMELEN+1]; /* 異常終了メッセージを登録するキューの名前 */
CLIENTID cltid; /* 発信元クライアントのクライアント識別子 */
long urcode; /* アプリケーション・ユーザ戻りコード */
long appkey; /* アプリケーション認証クライアント・キー */
long delivery_qos; /* サービスの配信品質 */
long reply_qos; /* サービスの応答メッセージの品質 */
long exp_time; /* 有効期限の時間 */
};
typedef struct tpqctl_t TPQCTL;
以下は、tpdequeue() の入力情報を制御する flags パラメータの有効なフラグです。
また、TPQCTL の urcode フィールドにユーザ戻りコードを設定することができます。この値は、メッセージをキューから取り出すために tpdequeue(3c) を呼び出すアプリケーションに返されます。
tpenqueue() からの出力では、次のフィールドが TPQCTL 構造体に設定されます。
long flags; /* どの値が設定されるかを示します。 */
char msgid[32]; /キューに登録されたメッセージの ID */
long diagnostic; /* 失敗の原因を示します。 */
次は、tpenqueue() からの出力情報を制御する flags パラメータの有効なビットです。tpenqueue() の呼び出し時にこのフラグがオンになっていると、/Q サーバ TMQUEUE(5) は、構造体の対応する要素にメッセージ識別子を挿入します。tpenqueue() の呼び出し時にこのフラグがオフになっていると、TMQUEUE() は、構造体の対応する要素にメッセージ識別子を挿入しません。
制御構造体の残りのメンバは、tpenqueue() への入力では使用されません。
tpdequeue() の呼び出しが異常終了して tperrno(5) に TPEDIAGNOSTIC が設定された場合、失敗の原因を示す値が ctl->diagnostic に返されます。次は、返される値です。
キューの順序の無効化
キューの作成時に、管理者が tpenqueue() 呼び出しでキュー上のメッセージの順序を無効にできるようにした場合、次の 2 つの方法でこの機能を利用できます。この 2 つの方法は、相互に排他的です。flags に TPQTOP を設定すると、メッセージをキューの先頭に置くことができます。または、flags に TPQBEFOREMSGID、ctl->msgid に既存のメッセージの ID を設定して、メッセージを特定の既存のメッセージの前に置くこともできます。この方法では、メッセージ ID を使用できるように、以前の呼び出しで取得されたメッセージ ID が保存されていることが必要です。管理者は、キューでサポートされている方法を通知する必要があります。キューは、この 2 つのいずれかまたは両方を使用できるように、あるいはどちらも使用できないように作成できます。
キューの優先順位の無効化
ctl->priority に値を設定して、メッセージの優先順位を指定することができます。この値は、1 以上 100 以下の範囲でなければなりません。数値が高いほど優先順位も高くなります。キューの順序付けパラメータの中に priority が含まれていない場合、ここで優先順位を設定しても取り出しの順序には影響しません。ただし、優先順位の値は保持されるので、メッセージがキューから取り出されるときに検査されます。
メッセージの使用可能時間の設定
deq_time に、絶対時間またはキューへの登録が完了してからの相対時間として、メッセージが処理されるまで時間を指定できます。flags に、TPQTIME_ABS または TPQTIME_REL のいずれかを設定して、値の処理方法を指定できます。キューは、time を順序付けの基準として作成することができます。その場合、メッセージは使用可能時間によって順序付けされます。
BEA Tuxedo /Q には、gp_mktime(3c) 関数が提供されています。この関数は、tm 構造体の日付と時刻を 1970 年 1 月 1 日から経過した秒数に変換します。time(2) および mktime(3C) 関数を gp_mktime(3c) の代わりに使用することもできます。値は、time_t 型 (typedef'd で指定された long 型) で返されます。キューからメッセージが取り出される絶対時間を設定するには、次の手順に従います。ここでは、2001 年 12 月 9 日正午 12:00 を使用します。
#include <stdio.h>
#include <time.h>
static char *const wday[] = {
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday", "-unknown-"
};
struct tm time_str;
/*...*/
time_str.tm_year = 2001 - 1900;
time_str.tm_mon = 12 - 1;
time_str.tm_mday = 9;
time_str.tm_hour = 12;
time_str.tm_min = 0;
time_str.tm_sec = 1;
time_str.tm_isdst = -1;
#include <atmi.h>
TPQCTL qctl;
if ((qctl->deq_time = (long)gp_mktime(&time_str)) == -1) {
/*エラーのチェック */
}
qctl->flags = TPQTIME_ABS
if (tpenqueue(qspace, qname, qctl, *data,*len,*flags) == -1) {
/*エラーのチェック */
}キューからメッセージを取り出す相対時間、たとえば、キューへの登録操作が完了してから nnn 秒などを指定する場合、deq_time に秒数を指定し、flags に TPQTIME_REL を設定します。
tpenqueue() とトランザクション
tpenqueue() の呼び出し元がトランザクション・モードにある場合に、TPNOTRAN が設定されていないと、キューへの登録は呼び出し元のトランザクション内で行われます。呼び出し元は、TPENQUEUE() が成功したか失敗したかによって、メッセージがキューに登録されたかどうかを判断できます。呼び出しが正常に行われると、メッセージがキューに登録されたことが保証されます。呼び出しが失敗すると、メッセージがキューに登録された部分も含めて、トランザクションがロールバックされます。
tpenqueue() の呼び出し元がトランザクション・モードにない場合、または TPNOTRAN が設定されている場合、メッセージは呼び出し元のトランザクションとは別のトランザクションでキューに登録されます。tpenqueue() への呼び出しが正常な戻り値を返した場合、メッセージがキューに登録されたことが保証されます。tpenqueue() の呼び出しが通信エラーまたはタイムアウトによって失敗した場合は、その障害がメッセージ登録の前に発生したのか後に発生したのか、呼び出し元には判断できません。
呼び出し元がトランザクション・モードにないときに TPNOTRAN を指定しても意味がありません。
メッセージのキューからの取り出し
次は、tpdequeue() の構文です。
#include <atmi.h>
int tpdequeue(char *qspace, char *qname, TPQCTL *ctl, ¥
char **data, long *len, long flags)
この呼び出しが行われると、qspace で識別されるキュー・スペース内の qname キューからメッセージを取り出すようにシステムが指示されます。メッセージは、*data が指すアドレスにあるバッファ (tpalloc(3c) によって割り当てられたもの) に挿入されます。len はデータの長さを示します。tpdequeue() から返された len が 0 の場合、そのメッセージにはデータ部分がないことを示します。flags にビット設定を行うと、システムに tpenqueue() 呼び出しの処理方法が通知されます。ctl が指す TPQCTL 構造体には、この呼び出しの処理方法についての詳細な情報が記述されます。
tpdequeue(3c) の引数
tpdequeue(3c) の処理を制御するいくつかの重要な引数があります。その一部について、以下に説明します。
tpdequeue():qspace 引数
qspace は、管理者によって既に作成されたキュー・スペースを識別します。TMQUEUE サーバがコンフィギュレーション・ファイルの SERVERS セクションで定義されている場合、そのサーバが提供するサービス名は、実際のキュー・スペース名 (GROUPS セクションの OPENINFO パラメータの一部として指定されます) のエイリアスになります。たとえば、アプリケーションがサーバ TMQUEUE を使用する場合、qspace 引数が指す値は、TMQUEUE が宣言するサービス名になります。サービス名のエイリアスが何も定義されていない場合、デフォルトのサービス名はサーバ名 TMQUEUE と同じになります。その場合、コンフィギュレーション・ファイルには次が記述されています。
TMQUEUE
SRVGRP = QUE1 SRVID = 1
GRACE = 0 RESTART = Y CONV = N
CLOPT = "-A"
または
CLOPT = "-s TMQUEUE"
サーバ・グループ QUE1 のエントリには、OPENINFO パラメータを使用して、リソース・マネージャ、デバイスのパス名、およびキュー・スペース名を指定します。クライアント・プログラムにおける qspace 引数は、次のように記述されます。
if (tpdequeue("TMQUEUE", "REPLYQ", (TPQCTL *)&qctl,
(char **)&reqstr, &len,TPNOTIME) == -1) {
Error checking
}TMQUEUE(5) リファレンス・ページの例では、サーバを作成してコンフィギュレーション・ファイルで指定する際に、サービスのエイリアスを指定する方法が示されています。サンプル・アプリケーション のサンプル・プログラムでも、サービスまたはキュー・スペース名のエイリアスが指定されています。
tpdequeue():qname 引数
キュー・スペース内のキュー名は、そのキュー・スペースにアクセスするアプリケーション間で一貫していなければなりません。これは、応答キューでは特に重要です。qname が応答キューを参照する場合、管理者はほかのキューと同じ方法で応答キュー、そして多くの場合、エラー・キューも作成します。qname は、メッセージまたは応答を取り出すキューを指すポインタです。
tpdequeue():data および len 引数
この 2 つの引数は、tpenqueue() で使用される場合と若干意味が異なります。*data は、キューから取り出されたメッセージをシステムが格納するバッファのアドレスを指します。tpdequeue() が呼び出された場合に、この値が NULL であることはエラーです。
tpdequeue() が戻ると、len は取り出されたデータのデータ長情報を持つ long 型を指します。0 は応答にデータがなかったことを示します。アプリケーションによっては、これは正当で正常な応答です。長さ 0 の応答を受信した場合でも、それをキューに登録された要求の正常処理を示すために使用できます。バッファが tpdequeue() 呼び出しの前と比べて変更されているかどうかを確認する場合は、tpdequeue() 呼び出しの前にデータ長を保存し、それを呼び出しが終了した後で len と比較します。
tpdequeue():flags 引数
flags の値は、tpdequeue() 呼び出しの処理方法を BEA Tuxedo システムに通知するために使用されます。次は、有効なフラグです。
TPQCTL 構造体
tpdequeue() の 3 番目の引数は、TPQCTL 型の構造体へのポインタです。TPQCTL 構造体には、アプリケーションで使用されるメンバと BEA Tuxedo システムで使用されるメンバがあり、アプリケーション・プログラムとキュー機能間の両方向でパラメータがやり取りされます。tpdequeue() を呼び出すクライアントはフラグを設定して、システムで値が提供されるべきフィールドをマークします。前述のように、この構造体は tpenqueue() でも使用されます。一部のメンバは、tpenqueue() だけに適用されます。この構造体全体のコード例は、tpqctl_t 構造体 に示されています。
tpdequeue() への入力では、次のフィールドを TPQCTL 構造体に設定します。
long flags; /* どの値が設定されるかを示します。 */
char msgid[32]; /* キューから取り出すメッセージの ID */
char corrid[32]; /* キューから取り出すメッセージの相関識別子 */
次は、tpdequeue() の入力として有効なフラグです。
次は、tpdequeue() からの出力情報を制御する flags パラメータの有効なビットです。どのフラグ・ビットでも、tpdequeue() の呼び出し時にオンになっていると、メッセージがキューに登録されたときに提供された値が、構造体の対応するフィールド (tpqctl_t 構造体 を参照) に格納され、そのビットは設定されたままになります。値が使用できない (つまり、メッセージがキューに登録されたときに値が指定されなかった)場合、または tpdequeue() を呼び出したときにビットが設定されなかった場合、tpdequeue() はフラグがオフの状態で完了します。
flags パラメータの残りのビットは、tpdequeue() が呼び出されるとクリア (0 に設定) されます。これには、TPQTOP、TPQBEFOREMSGID、TPQTIME_ABS、TPQTIME_REL、TPQEXPTIME_ABS、TPQEXPTIME_REL、および TPQEXPTIME_NONE が含まれます。これらのビットは、tpenqueue() の入力情報を制御する flags パラメータの有効なビットです。
tpenqueue() の呼び出しが失敗し、tperrno(5) に TPEDIAGNOSTIC が設定された場合は、失敗の原因を示す値が ctl->diagnostic に返されます。ctl->diagnostic の有効なコードには、TPQCTL 構造体 に示されている tpenqueue() の値 (QMENOSPACE と QMERELEASE を除く) のほかに、次のものがあります。
TPQWAIT の使用
TPQCTL 構造体の flags に TPQWAIT が設定されて tpdequeue() が呼び出された場合に、メッセージをすぐに取り出すことができないと、tpdequeue() が呼び出し元に制御を返す前に、TMQUEUE サーバ は tpdequeue() 要求に一致するメッセージがキューに到着するのを待ちます。TMQUEUE プロセスは待機中の要求を無視し、ほかのプロセスの要求を処理しながら、最初の要求の条件が満たされるのを待ちます。TPQGETBYMSGID や TPQGETBYCORRID も指定されている場合、サーバは指定されたメッセージ識別子や相関識別子を持つメッセージをキューから取り出せるようになるまで待ちます。このどちらのフラグも設定されていない場合、サーバは任意のメッセージがキューに登録されるまで待ちます。呼び出しがトランザクション・モードの場合、サーバの待機時間は、呼び出し元のトランザクション・タイムアウトによって制御されます。呼び出しがトランザクション・モードでない場合、TMQUEUE サーバの CLOPT パラメータに指定される -t オプションで制御されます。
TMQUEUE サーバは、要求を処理するアクション・リソースを利用できる限り、複数の待機中 TPDEQUEUE() 要求を同時に処理できます。十分なアクション・リソースがキュー・スペースに対して設定されていない場合、TPDEQUEUE() は失敗します。使用しているシステムがこれに該当する場合は、キュー・スペースに対するアクション・リソースの数を増やしてください。
TMQFORWARD サービス使用時のエラー処理
キューからのメッセージの取り出しで、エラー処理の最良の方法を考慮する場合、次の 2 種類のエラーを区別しておきます。
デフォルトでは、メッセージがトランザクション内でキューから取り出され、そのトランザクションがロールバックされると、retry パラメータが 0 より大きい場合は、そのメッセージはキューに戻されて、再度キューからの取り出しと実行が可能になります。一時的な障害が解消されるように (たとえば、データベースのロックを別のトランザクションが解除するように) 少し時間をおいてから、メッセージの取り出しと実行を再度試みます。通常、再試行の回数に上限を設定することも、アプリケーション不備によってリソースを著しく浪費することを防ぐために有用です。管理者がキューを設定するときに、再試行の回数と遅延時間 (秒単位) の両方を指定できます。再試行の回数 0 は、再試行が行われないことを示します。再試行の回数が上限に達すると、管理者がキュー・スペースに設定するエラー・キューにメッセージが移動されます。エラー・キューが設定されていない場合、再試行回数の上限に達したメッセージは単に削除されます。エラー・キューにあるメッセージは、管理者によって処理されなければなりません。管理者は、アプリケーションの要件を満たす方法で発信元に通知する必要があります。選択されたメッセージ処理方法は、メッセージをキューに登録した発信元プログラムにほとんど透過的です。メッセージは一度正常にキューに登録されると、tpenqueue() のパラメータおよびキューの属性に従って処理されることが実質的には保証されます。メッセージがエラー・キューに移動されたことの通知は、キューのパラメータを適切に調整されたシステムではほとんどありません。
異常終了キュー (通常、キュー・スペースのエラー・キューとは異なります) は、キューに登録された各メッセージと対応付けられます。このキューは、異常終了メッセージを置く場所として、キューにメッセージを登録する呼び出しで指定されます。特定の要求に対する異常終了メッセージは、アプリケーション生成の相関識別子で識別できます。相関識別子は、キューにメッセージを登録するときに、そのメッセージと対応付けられます。
成功するまで (または事前に定義された回数まで) 再試行を繰り返すというデフォルトの動作は、時間が経過すれば解決されるような一時的な障害が失敗の原因であり、メッセージが後から適切に処理される場合は適しています。
障害が一時的なものではない場合もあります。たとえば、存在しないアカウントでの操作を要求するメッセージがキューに入れられている場合 (アプリケーションも適当な時間に存在していない場合) です。その場合、再試行してリソースを浪費しないようにします。アプリケーション・プログラマまたは管理者が、特定の操作の失敗が一時的ではないと判断した場合、単に再試行回数を 0 に設定します。ただし、この場合、このようなメッセージが入るキュー・スペースのエラー・キューを継続的にクリアするメカニズム (キューを定期的に読み取るバックグラウンドのクライアントなど) が必要です。また、同じサービスに対する障害でも、一時的なもの (データベース・ロックの競合など) であったり、永続的なもの (アカウントが存在しないなど) であったりする場合が多くあります。
メッセージが TMQFORWARD によって処理される (キューから取り出され、tpcall() を介してアプリケーションに渡される) 場合、tpcall() が返す情報には、TPESVCFAIL エラーが一時的な障害と永続的な障害のどちらによって生じたものであるかを示すメカニズムはありません。
キューからの取り出しをアプリケーションが処理する場合、簡単な解決方法はたとえ操作が失敗しても、そのサービスに対して成功を返すことです。つまり、TPSUCCESS を設定して tpreturn を実行します。これにより、トランザクションはコミット可能になり、メッセージはキューから削除されます。応答メッセージが使用されている場合、サービスから返されるバッファの情報によって操作の失敗を示すことができ、メッセージが応答キューに登録されます。tpreturn の rcode 引数も、アプリケーション固有の情報を返すために使用できます。
サービスが失敗し、トランザクションをロールバックする必要がある場合、TMQFORWARD が処理をそれ以上行わずに、2 番目のトランザクションを実行してキューからメッセージを削除するかどうかは明確ではありません。デフォルトでは、TMQFORWARD は失敗したサービスに対するメッセージを削除しません。TMQFORWARD のトランザクションはロールバックされ、メッセージはキューに格納されます。TMQFORWARD にコマンド行オプションを指定すると、サービスが失敗して 0 より長い応答メッセージが返された場合に、メッセージがキューから削除されます。メッセージは、2 番目のトランザクションで削除されます。この処理を行うには、キューに遅延時間および再試行回数を設定する必要があります。メッセージが失敗したキューに対応付けられている場合、メッセージがキューから削除されたトランザクションと同じトランザクションで、応答データが異常終了キューに登録されます。
TMQFORWARD を通して呼び出されたサービスからの応答をキューから取り出す手順
アプリケーションがキューに登録されたメッセージに対する応答を要求している場合、次の手順に従います。
TPQCORRID TPQREPLYQ
TPQFAILUREQ TPQMSGID
TPQCORRID TPQREPLYQ
TPQFAILUREQ TPQMSGID
TPQGETCORRID
TPQCORRID TPQREPLYQ
TPQFAILUREQ TPQMSGID
TPQGETBYCORRID
メッセージの順次処理
メッセージの順次処理は、あるサービスがそのトランザクションがコミットされる前に、連鎖的に次のサービス用にメッセージをキューに登録することによって行われます。最初の発信元のプロセスは、reply_queue に対する一連の TPDEQUEUE() 呼び出しによって順次処理の進行状況をトラッキングできます。ただし、各メンバが同じ相関識別子を使用し、長さ 0 の応答を返すことが必要です。
また、任意通知型通知を使用して、順次処理全体が成功したという通知を最初の発信元に返すこともできます。順次処理の最後のトランザクションが tpcommit で終了したことを確認するには、tpdequeue() から戻された TPQCTL 構造体、またはサービスに渡された TPSVCINFO 構造体で渡されるクライアント識別子を使用して、tpnotify を呼び出す操作を追加します。最初の発信元であるクライアントは、tpsetunsol を呼び出して、使用されている任意通知型メッセージ・ハンドラを指定しておかなければなりません。
ピア・ツー・ピア通信でのキューの使用
キューへのメッセージの登録およびキューからのメッセージの取り出しに関するこれまでの説明では、キューが要求/応答の一形態として使用されていることが暗黙の前提になっていました。メッセージ自体はサービス要求である必要はありません。キュー機能は、あるプロセスから別のプロセスに、サービス要求と同じように効果的にデータを転送できます。アプリケーション間またはクライアント間のこの通信方式は、ピア・ツー・ピア通信と呼ばれます。
使用するアプリケーションが、このような目的で BEA Tuxedo /Q を使用することに適している場合は、管理者に別のキューを作成してもらい、そのキューからメッセージを取り出す独自の受信用プログラムをコーディングします。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||