BEA ホーム  |  イベント  |  ソリューション  |  パートナ  |  製品  |  サービス  |  ダウンロード  |  ディベロッパ・センタ  |  WebSUPPORT
	e-docs   |   サイト マップ   |   検索   |   PDF版   |   お問い合わせ   |   用語集
Tuxedo ホーム   |   C 言語を使用した BEA Tuxedo アプリケーションのプログラミング   |   先頭へ   |   前へ   |   次へ   |   目次

• 起動フェーズ

• 作業フェーズ

• 完了フェーズ

• 一部のクライアント・スレッドは tpinit() を呼び出して、1 つ以上の BEA Tuxedo アプリケーションに参加します。

• その他のクライアント・スレッドは tpsetctxt(3c) を呼び出して、上記のスレッドによって生成されるコンテキストを共有します。

• 一部のクライアント・スレッドは複数のコンテキストに参加します。

• 一部のクライアント・スレッドは既存のコンテキストに切り替えます。

• すべての対応付けは、BEA Tuxedo システムの同じインストールに対して行う必要があります。

• すべてのアプリケーションとの対応付けは、同じタイプのクライアントから行う必要があります。つまり、次のいずれの条件を満たしている必要があります。

  • すべてのアプリケーションとの対応付けは、ネイテイブ・クライアントから行う必要があります。

  • すべてのアプリケーションとの対応付けは、ワークステーション・クライアントから行う必要があります。

クライアントが複数のコンテキストに参加するには、TPINFO データ型の flags に TPMULTICONTEXTS フラグを設定して、tpinit() 関数を呼び出します。

多くの ATMI 関数はコンテキスト単位で動作します。このような ATMI 関数のリストについては、「マルチスレッド・クライアントでのコンテキスト単位の関数とデータ構造体」を参照してください。コンテキスト単位で動作するには、ターゲット・コンテキストが現在のコンテキストであることが必要です。クライアントは複数のコンテキストに参加できますが、状況とスレッドにかかわらず現在のコンテキストになることができるコンテキストは 1 つだけです。

そのような場合、あるクライアント・スレッドが tpgetctxt(3c) を呼び出し、返された現在のコンテキストを値として持つハンドルを別のクライアント・スレッドに渡します。2 番目のスレッドは tpsetctxt(3c) を呼び出し、最初のスレッドで tpgetctxt(3c) から受け取ったハンドルを指定して、現在のコンテキストとの対応付けを確立します。

目的のコンテキストとの対応付けが確立されると、2 番目のスレッドはコンテキスト単位で動作する ATMI 関数を使用してタスクを実行できるようになります。詳細については、「マルチスレッド・クライアントでのコンテキスト単位の関数とデータ構造体」を参照してください。

• サービスを要求します。

• サービス要求に対する応答を受け取ります。

• 会話を開始して会話に参加します。

• トランザクションの開始、コミット、またはロールバックを行います。

スレッドは、同期要求の場合は tpcall()、非同期要求の場合は tpacall() を呼び出して、サーバに要求を送ります。tpcall() で要求を送った場合、以降操作を行わなくても応答を受け取ることができます。

tpcall() でサービスの非同期要求を送った場合、同じコンテキスト内のスレッドは tpgetrply() を呼び出して応答を受け取ります。このスレッドは、要求を送ったスレッドと同じスレッドではない場合もあります。

アプリケーションの 1 つのスレッドが tpcommit() を呼び出し、それと同時に別のスレッドが RPC 呼び出しまたは会話型呼び出しを行うと、これらの呼び出しは特定の順序で呼び出されたものとして処理されます。アプリケーション・コンテキストは、シングルスレッド・プログラムとシングルコンテキスト・プログラムに対する制約と同じ制約に従って、tpsuspend() を呼び出してトランザクションを一時的に中断し、別のトランザクションを開始します。

• シグナル・ベースの通知は、マルチスレッド・プロセスまたはマルチコンテキスト・プロセスでは使用できません。

• アプリケーションを実行しているプラットフォームで、マルチコンテキストがサポートされていてもマルチスレッドがサポートされていない場合、TPU_THREAD を使用した任意通知型通知の処理を行うことはできません。そのため、イベントの即時通知を受け取ることはできません。

  イベントの即時通知を受け取る必要がある場合は、そのプラットフォームでマルチコンテキストを使用するかどうかを慎重に検討します。

• 専用のスレッド通知は、次のものに対してだけ使用できます。

  • C 言語で記述されたアプリケーション

  • BEA Tuxedo システムでサポートされているマルチスレッド・プラットフォーム

スレッドがサポートされていない BEA Tuxedo システム用プラットフォームで tpinit() が呼び出された場合に、スレッドがサポートされていないプラットフォーム上で TPU_THREAD 通知が要求されたことを示すパラメータが指定されていると、tpinit() は -1 を返して tperrno に TPEINVAL を設定します。UBBCONFIG(5) のデフォルトの NOTIFY オプションが THREAD に設定されている場合に、特定のマシンでスレッドを利用できないと、そのマシンのデフォルトの機能は DIPIN になります。このような動作の相違があるので、スレッドがサポートされているマシンとサポートされていないマシンが混在する環境では、管理者はすべてのマシンにデフォルトを指定できます。ただし、そのマシンで利用できない機能をクライアントが明示的に要求することはできません。

tpsetunsol() がコンテキストに対応付けされていないスレッドから呼び出されると、新しく生成されるすべての tpinit() コンテキストに対して、プロセス単位のデフォルトの任意通知型メッセージ・ハンドラが作成されます。特定のコンテキストは、コンテキストがアクティブのときに tpsetunsol() を再度呼び出して、そのコンテキストの任意通知型メッセージ・ハンドラを変更することができます。プロセス単位のデフォルトの任意通知型メッセージ・ハンドラは、コンテキストに現在対応付けされていないスレッドで tpsetunsol() を再度呼び出すと、変更できます。

プロセスが同じアプリケーションと複数の対応付けを持つ場合、各対応付けに異なる CLIENTID を割り当てられ、任意通知型メッセージを特定のアプリケーションとの対応付けに送信できるようになります。プロセスが同じアプリケーションと複数の対応付けを持つ場合、ブロードキャスト基準を満たすアプリケーションの各対応付けに任意の tpbroadcast() が別々に送信されます。任意通知型メッセージを受信する場合のディップ・イン・チェックでは、カレントのアプリケーションとの対応付けに送信されるメッセージだけが対象となります。

任意通知型メッセージ・ハンドラでは ATMI 関数を利用できるほか、任意通知型メッセージ・ハンドラ内で tpgetctxt(3c) を呼び出すことができます。そのため、任意通知型メッセージ・ハンドラは別のスレッドを生成して、同じコンテキスト内で必要となる実質的な ATMI 作業を行うことができるようになります。

userlog(3c) を使用すると、各アプリケーション内の各スレッドに対して次の識別情報が記録されます。

TM_MIB(5) では、この機能は T_ULOG クラスの TA_THREADID フィールドと TA_CONTEXTID フィールドでサポートされています。

このフェーズでは、クライアント・プロセスの終了時に、カレントのコンテキストおよび対応付けられたすべてのスレッドに代わって 1 つのスレッドが tpterm() を呼び出してそのアプリケーションとの対応付けを終了します。ほかの ATMI 関数と同じように、tpterm() は現在のコンテキストに対して処理を行います。tpterm() は、終了するコンテキストに対応付けされたすべてのスレッドに影響し、これらのスレッドで共有されるすべてのコンテキストを終了します。

• 「マルチスレッドおよびマルチコンテキストとは」

• 「マルチスレッドおよびマルチコンテキスト・アプリケーションの設計上の検討事項」

• 「クライアントでマルチコンテキストを使用するためのコーディング」

• 「マルチスレッド・クライアントのコーディング」

• 「クライアント終了前のスレッドの同期」