Oracle Tuxedoシステムでは、
TP-STATUS IN TPSTATUS-RECを使用して、ルーチンが失敗した場合にプロセスに情報が渡されます。すべてのATMI呼出しは、
TP-STATUSにエラーの内容を示す値を設定します。サービス・ルーチンを終了させるために使用する
TPRETURNや
TPFORWARなど、呼出し側に戻らない関数の場合、成功か失敗かを確認する唯一の方法はリクエスタの
TP-STATUS変数です。
APPL-RETURN-CODEは、ユーザー定義の条件だけを通知します。
APPL-RETURN-CODEには、
TPRETURN時に
APPL-CODE IN TPSVCRET-RECの値が設定されます。
TPRETURNエラーまたはトランザクション・タイムアウトが発生しないかぎり、
APPL-RETURN-CODE IN TPSTATUS-RECの値に関係なく、
APPL-RETURN-CODEに値が設定されます。
TP-STATUSに戻されるコードはエラーの種類を表し、
表11-1はそのエラーの種類を示しています。
|
|
|
|
|
|
|
|
|
|
|
|
|
TPESVCFAIL、 TPESVCERR、 TPEBLOCK、および TPGOTSIG
|
|
TPEHAZARD2および TPEHEURISTIC2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注1にあるように、
TP-STATUSによって通知される4種類のエラーは、すべてのATMI関数で発生するエラーです。それ以外のエラーの種類は、特定のATMI呼び出しだけで発生します。以下に、一部のエラーの種類について詳しく説明します。
Oracle Tuxedoのシステム・エラーは、問題がアプリケーション・レベルではなく
システム・レベルで発生していることを示します。Oracle Tuxedoのシステム・エラーが発生すると、エラーの原因を示すメッセージが中央イベント・ログに書き込まれ、
TP-STATUSに
TPESYSTEMが返されます。詳細は、
11-21ページの「中央イベント・ログ」を参照してください。これらのエラーは、アプリケーションではなくシステムで発生するので、エラーの修正についてはシステム管理者に問い合せてください。
通信ハンドルのエラーは、通信ハンドルの数が上限値を超えている場合、または無効な値を参照している場合に発生します。非同期呼び出しや会話型呼出しでは、未処理の通信ハンドルの数が上限値を超えると、
TPELIMITが返されます。操作に対して無効な通信ハンドルの値が指定されている場合は、
TPEBADDESCが返されます。
通信ハンドルのエラーが発生するのは、非同期呼び出しまたは会話型呼出しを行った場合だけです。(呼出し記述子は同期呼出しには使用されません。)非同期呼出しでは、通信ハンドルを使用して対応するリクエストに応答が関連付けられます。会話型送受信用のルーチンは、通信ハンドルを使用して接続を識別します。つまり、接続を開始する呼出しでは、通信ハンドルを使用できることが大切です。
通信ハンドルのエラーのトラブルシューティングは、アプリケーション・レベルで特定のエラーを調べて行います。
システムでは、コンテキスト(またはOracle Tuxedoアプリケーションへの関連付け)ごとに未処理の通信ハンドル(応答)を50個まで使用できます。この上限値はシステムで定義されているので、アプリケーションで再定義することはできません。
会話型接続を同時に行う場合の通信ハンドルに関する制限は、応答時の制限ほど厳しくありません。上限値は、アプリケーション管理者が構成ファイルに定義します。アプリケーションが実行中ではない場合、管理者は構成ファイルの
RESOURCESセクションの
MAXCONVパラメータを変更できます。アプリケーションが実行中の場合も、
MACHINESセクションは動的に変更できます。詳細は、
『Oracle Tuxedoコマンド・リファレンス』の
「tmconfig、wtmconfig(1)」を参照してください。
通信ハンドルは無効になることがあります。無効な通信ハンドルが参照されると、次の場合に
TP-STATUSにエラーが返されます。
•
|
通信ハンドルを使用してメッセージを取得したが、それがエラー・メッセージの場合( TPEBADDESC)
|
•
|
無効になった通信ハンドルの再利用を試みた場合( TPEBADDESC)
|
通信ハンドルが無効になるのは、以下のような場合です。
•
|
アプリケーションで TPABORTまたは TPCOMMITを呼び出したとき、 TPNOTRANフラグを設定せずに送信されたトランザクション応答が取得されずに残っている場合。
|
•
|
トランザクションがタイムアウトになった場合。 TPGETRPLYの呼出しでタイムアウトが通知された場合、指定されたハンドルを使用してメッセージを取得することはできず、ハンドルは無効になります。
|
会話型サービスで不明なハンドルが指定されると、
TPSEND、
TPRECV、および
TPDISCONルーチンは
TPEBADDESCを返します。
会話型接続の確立後に
TPSENDと
TPRECVが
TPEEVENTエラーで失敗した場合、イベントが発生します。
TPSENDでデータを送信できるかどうかは、発生したイベントによって決まります。システムは、
TPSTATUS-RECの
TPEVENTメンバーの
TPEEVENTを返します。行われる処理は、発生したイベントによって異なります。
会話型イベントの詳細は、
『C言語を使用したOracle Tuxedo ATMIアプリケーションのプログラミング』の
「会話型通信イベントの理解」を参照してください。
処理の結果として複製オブジェクトが生成されるような操作が試みられると、
TP-STATUSに
TPEMATCHエラー・コードが返されます。次の表は、
TPEMATCHエラー・コードを返すルーチンとその原因を示しています。
|
|
|
指定された svcnameは、既にサーバーに対して通知されています。ただし、その処理は func以外の関数で行われています。この関数は失敗しても、 svcnameは現在の関数で通知されたままになります。つまり、 funcは現在の関数名を置き換えません。
|
|
tranidは、別のプロセスがすでに再開したトランザクション識別子を指しています。その場合、呼出し側のトランザクションの状態は変化しません。
|
|
指定されたサブスクリプション情報は、すでにイベント・ブローカに登録されています。
|
これらのルーチンの詳細は、『Oracle Tuxedo ATMI COBOL関数リファレンス』
を参照してください。
一般的な通信呼出しのエラーは、呼出しが同期または非同期で行われたかどうかに関係なく、どのような通信呼出しでも発生する可能性があります。
TP-STATUSには、
TPESVCFAIL、
TPESVCERR、
TPEBLOCK、または
TPGOTSIGが返されます。
TPESVCFAILおよびTPESVCERRエラー
TPCALLまたは
TPGETRPLYを呼び出した結果、通信の応答部分が失敗すると、
TP-STATUSに
TPESVCERRまたは
TPSEVCFAILが返されます。
TPRETURNに渡された引数でエラーが判別され、この呼出しで実行する処理が決定されます。
引数の処理中に
TPRETURNでエラーが発生すると、システムはエラーを元のリクエスタに返し、
TP-STATUSに
TPESVCERRを設定します。受信側では、
TP-STATUSの値を調べてエラーの発生を確認します。システムでは、
TPRETURN呼出しからのデータ送信は行われず、
TPGETRPLYでエラーが発生した場合は、呼出しハンドルが無効なものとみなされます。
TPRETURNで
TPESVCERRエラーが発生していない場合、
TP-RETURN-VALに返された値で呼出しが成功したか失敗したかを判断できます。アプリケーションで、
TP-RETURN-VALに
TPFAILが指定されると、システムは
TP-STATUSに
TPESVCFAILを返し、呼出し側にデータ・メッセージを送信します。
TP-RETURN-VALに
TPSUCCESSが設定されると、呼出し側に制御が正常に戻り、
TP-STATUSは設定されず、呼出し側がデータを受信します。
TPEBLOCKおよび
TPGOTSIGエラー・コードは、メッセージのリクエスト側に返される場合も応答側に返される場合もあるので、すべての通信呼出しに対して返される可能性があります。
ブロッキング状態が発生している場合に、リクエストを同期または非同期に送信するプロセスでブロッキング状態を無視するように
TPPNOBLOCKが設定されていると、システムは
TPEBLOCKを返します。たとえば、システムのキューがすべていっぱいになっている場合、リクエストが送信されるとブロッキング状態になります。
TPCALLがブロッキング状態を示していない場合は、通信の送信部分だけに影響します。リクエストの送信に成功すると、その呼出しが応答を待っている間にブロッキング状態が存在したとしても、
TPEBLOCKは返されません。
TPNOBLOCKを設定して呼出しを行った場合、
TPGETRPLYが応答を待っている間にブロッキング状態が発生すると、
TPGETRPLYに
TPEBLOCKが返されます。この状況は、メッセージがその時点で使用できない場合などに発生します。
TPGOTSIGエラーは、シグナルによってシステム・コールに割込みが発生したことを示します。このような状況は、実際にはエラーではありません。
TPSIGRSTRTが設定されていると、呼出しは失敗せず、
TP-STATUSに
TPGOTSIGエラー・コードが返されます。
無効な引数によるエラーは、ルーチンに渡された引数が無効であることを示しています。引数を取るATMI呼出しは、無効な引数が渡されると失敗します。呼出し側に制御が戻る呼出しの場合、関数は失敗して、
TP-STATUSに
TPEINVALが設定されます。
TPRETURNまたは
TPFORWARの場合、リクエストを開始して結果を待っている
TPCALLまたは
TPGETRPLYに対して、
TP-STATUSに
TPESVCERRが設定されます。
ルーチンに有効な引数だけを渡すようにすると、無効な引数によるアプリケーション・レベルでのエラーを修正できます。
レコード・タイプを識別するためのデータ構造体やシステム表にエントリがないと、エラーが発生します。エントリ・タイプのエラーを示す
TPENOENTの意味は、そのエラーを戻す呼出しによって異なります。
表11-2は、このエラーを戻す呼出しとエラーの様々な原因を示しています。
|
|
|
エントリ用の領域が掲示板に残っていないため、呼出し側プロセスがアプリケーションに参加できません。システム管理者に問い合せてください。
|
|
呼出し側プロセスが参照しているサービス SERVICE-NAME IN TPSVCDEF-RECは、掲示板にエントリがないため、システムに認識されせん。アプリケーション・レベルでサービスを正しく参照しなければなりません。正しく参照していない場合は、システム管理者に問い合せてください。
|
|
指定されたサービスに接続できません。そのようなサービス名が存在していないか、または会話型サービスではありません。
|
|
リクエストが行われていないにもかかわらず、呼出し側プロセスがリクエストの優先度を調べています。これは、アプリケーション・レベルのエラーです。
|
|
SERVICE-NAME IN TPSVCDEF-RECの通知を解除することができません。この名前は、呼出し側プロセスによって現在通知されていません。
|
オペレーティング・システムのエラーは、オペレーティング・システム・コールが失敗したことを示します。
TP-STATUSに
TPEOSが返されます。UNIXシステムの場合、失敗したシステム・コールを識別する整数値がグローバル変数
Uunixerrに返されます。オペレーティング・システム・エラーを修正するには、システム管理者に問い合せてください。
呼出し側プロセスに、アプリケーションに参加するために必要なパーミッションが設定されていない場合、
TPINITIALIZE呼出しは失敗して、
TP-STATUSに
TPEPERMが返されます。パーミッションは、構成ファイルに設定されるもので、アプリケーションには設定されません。このエラーが発生した場合は、アプリケーション管理者に問い合せて、必要なパーミッションが構成ファイルに設定されていることを確認してください。
ATMI呼出しが間違った順序で行われた場合、または間違ったプロセスを使用して行われた場合、プロトコル・エラーが発生します。たとえば、アプリケーションに参加する前に、クライアントがサーバーとの通信の開始を試みると、このエラーが発生します。また、イニシエータではなくトランザクションの参加リソースによって
TPCOMMITが呼び出された場合も、このエラーが発生します。
ATMI呼出しを正しい順序で正しく使用すると、アプリケーション・レベルでプロトコル・エラーを修正できます。
プロトコル・エラーの原因を特定するには、次の事柄を確認してください。
•
|
正しいプロセスによって呼出しが行われているかどうか
|
プロトコル・エラーでは、
TP-STATUSに
TPEPROTO値が返されます。
詳細は、
『Oracle Tuxedo ATMI COBOL関数リファレンス』のCOBOLアプリケーション・トランザクション・モニター・インタフェースの概要に関する項を参照してください。
特定のキューへの登録またはキューからの取出しに失敗した場合、
TPENQUEUE(3cbl)または
TPDEQUEUE(3cbl)ルーチンは
TP-STATUSに
TPEDIAGNOSTICを戻します。処理が失敗した原因は、
ctlレコードを介して戻される診断値によって判別できます。有効な
ctlフラグのリストは、
『Oracle Tuxedo ATMI COBOL関数リファレンス』の
「TPENQUEUE(3cbl)」または
「TPDEQUEUE(3cbl)」を参照してください。
アプリケーション・ドメインに参加するOracle Tuxedoシステムのリリース間で互換性に問題がある場合、Oracle Tuxedoシステムは
TP-STATUSに
TPERELEASEを返します。
たとえば、
TPNOTIFY(3cbl)ルーチンを呼び出す際に、呼出し側がターゲット・クライアントから承認メッセージを受け取るまでブロックすることを示す
TPACKフラグが設定されている場合、
TPACK承認プロトコルがサポートされていない旧バージョンのOracle Tuxedoシステムをターゲット・クライアントが使用していると、
TPERELEASEエラーが返されます。
リソース・マネージャ・エラーは
TPOPEN(3cbl)および
TPCOSE(3cbl)を呼び出したときに発生し、
TP-STATUSに
TPERMERRの値が戻されます。リソース・マネージャを正しくオープンできなかった場合、
TPOPENでこのエラー・コードが戻されます。同じように、リソース・マネージャを正しくクローズできなかった場合は、
TPCLOSEでこのエラー・コードが戻されます。Oracle Tuxedoシステムでは、移植性を保つために、この種類のエラーでは詳細な情報は返されません。リソース・マネージャ・エラーの正確な性質を判断するには、リソース・マネージャに問い合せる必要があります。
Oracle Tuxedoシステムでは、タイムアウト・エラーがサポートされており、アプリケーションがサービス・リクエストまたはトランザクションを待つ時間に制限があります。Oracle Tuxedoシステムでサポートされている設定可能なタイムアウト機構は、ブロッキング・タイムアウトとトランザクション・タイムアウトの2種類です。
ブロッキング・タイムアウトは、アプリケーションがサービス・リクエストに対する応答を待つ時間の上限値を指定します。アプリケーション管理者は、構成ファイルにシステムのブロッキング・タイムアウトを設定します。
トランザクション・タイムアウトは、トランザクション(その中で複数のサービス・リクエストが行われる場合もあります)の有効期間を定義します。アプリケーションのトランザクション・タイムアウトを定義するには、
TPBEGINに
T-OUT引数を渡します。
通信呼出しでは、ブロッキング・タイムアウトまたはトランザクション・タイムアウトのいずれかが返され、
TPCOMMITではトランザクション・タイムアウトだけが返されます。いずれの場合も、トランザクション・モードのプロセスで呼出しが失敗して
TPETIMEが返された場合は、トランザクション・タイムアウトが発生しています。
デフォルトでは、プロセスがトランザクション・モードではない場合、ブロッキング・タイムアウトが実行されます。
プロセスがトランザクション・モードではない場合に、非同期呼出しでブロッキング・タイムアウトが発生すると、ブロックされている通信呼出しは失敗します。ただし、呼出し記述子は有効なままであり、再度呼出しを行う場合に使用できます。ほかの通信には影響ありません。
トランザクション・タイムアウトが発生すると、非同期トランザクション応答の通信ハンドル(
TPNOTRANフラグが指定されていないもの)は無効になり、参照できなくなります。
呼出しがトランザクション・モードで行われていない場合、またはTPNOBLOCKが設定されていない場合、TPETIMEは通信呼出しでブロッキング・タイムアウトが発生したことを示します。
注意:
|
TPNOBLOCKが設定されている場合、ブロッキング状態が存在すると呼出しは直ちに戻るので、ブロッキング・タイムアウトは発生しません。
|
プロセスに対するリクエストまたは応答が不明なタイプのレコードで送信された場合、型付きレコードのエラーが返されます。リクエスト・データ・レコードの送信先のサービスでレコード・タイプが認識されない場合、
TPCALLおよび
TPACALL呼出しは
TPEITYPEを返します。
プロセスで認識されるレコード・タイプは、構成ファイルとプロセスにリンクされているOracle Tuxedoシステム・ライブラリの両方で識別されるものです。これらのライブラリは、プロセスで認識される型付きレコードを識別するデータ構造体を定義および初期化します。プロセスごとにライブラリを作成するか、またはレコード・タイプが定義されたアプリケーション固有のファイルのコピーをアプリケーションで用意することができます。アプリケーションでは、レコード・タイプ・スイッチと呼ばれるレコード・タイプ・データ構造体をプロセスごとに設定できます。詳細は、
『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の
「tuxtypes(5)」および
「typesw(5)」を参照してください。
呼出し側で認識されないか、または使用できないレコードで応答メッセージが送信されると、
TPCALLおよび
TPGETRPLY呼出しは
TPEOTYPEを返します。呼出し側で使用できないレコードの場合、そのレコード・タイプはタイプ・スイッチに含まれています。ただし、返されたタイプは応答の受信用に割り当てられたレコードと一致せず、また呼出し側は異なるレコード・タイプを使用することはできません。呼出し側は、
TPNOCHANGEを設定して、このプリファレンスを示します。その場合、厳密なタイプ・チェックが行われ、違反が見つかると
TPEOTYPEが返されます。デフォルトでは、緩やかなタイプ・チェックが行われます。その場合、呼出し側で認識される限り、最初に割り当てられたタイプ以外のレコード・タイプが返されることもあります。応答の送信では、応答レコードは呼出し側で認識できるものでなければなりません。また、厳密なタイプ・チェックが指定されている場合は、それに従う必要があります。
アプリケーション内では、
TPRETURNの
rcode引数を使用して、呼出し側のプログラムにユーザー定義のエラーに関する情報を渡すことができます。また、
APPL-RETURN-CODEには、
TPRETURN時に
APPL-CODE IN TPSVCRET-RECの値が設定されます。
TPRETURN(3cbl)の詳細は、
『Oracle Tuxedo ATMI COBOL関数リファレンス』を参照してください。
アプリケーションのロジックは、戻り値がある呼出しのエラー条件を調べ、エラー発生時に適切な処理を行うように設計します。
次のサンプル・コードは、エラーの一般的な処理方法を示しています。この例では、
ATMICALL(3)は、一般的なATMI呼出しを表しています。
. . .
CALL "TPINITIALIZE" USING TPINFDEF-REC
USR-DATA-REC
TPSTATUS-REC.
IF NOT TPOK
error message, EXIT PROGRAM
CALL "TPBEGIN" USING TPTRXDEF-REC
TPSTATUS-REC.
IF NOT TPOK
error message, EXIT PROGRAM
Make atmi calls
Check return values
IF TPEINVAL
DISPLAY "Invalid arguments were given."
IF TPEPROTO
DISPLAY "A call was made in an improper context."
. . .
Include all error cases described in the ATMICALL(3)
reference page. Other return codes are not possible,
so there is no need to test them.
. . .
continue
TP-STATUSの値は、各問題の詳細を示し、どのレベルで問題の解決が可能かを示しています。アプリケーションで、ある処理に特定のエラー条件が定義されている場合、
APPL-RETURN-CODE IN TPSTATUS-RECの値にも同じことが言えます。
以下の項では、各種のプログラミング機能がトランザクション・モードでどのように動作するかについて説明します。まず、トランザクション・モードのコーディングで従うべき基本的な通信規則について説明します。
トランザクション・モードで実行するコードを記述する場合は、以下の基本的な通信規則に従います。
•
|
同じトランザクションに参加するプロセスでは、すべてのリクエストで応答が必要です。応答を必要としないリクエストを含めるには、 TPACALLに TPNOTRANまたは TPNOREPLYを設定します。
|
•
|
サービスは、 TPRETURNまたは TPFORWARを呼び出す前に、すべての非同期トランザクション応答を取得する必要があります。この規則には、コードをトランザクション・モードで実行するかどうかに関係なく従います。
|
•
|
イニシエータは、 TPCOMMITを呼び出す前に、すべての非同期トランザクション応答( TPNOTRANが指定されていないもの)を取得する必要があります。
|
•
|
トランザクションの参加リソース以外からの応答を必要とする非同期呼出しには、応答を取得する必要があります。つまり、応答が抑制されたのではなくトランザクションが抑制された TPACALLで行ったリクエストに対する応答を取得する必要があります。
|
•
|
トランザクションがタイムアウトになっていなくても、「中断のみ」としてマークされている場合、以降の通信では TPNOTRANを設定して、トランザクションがロールバックされた後でも通信の結果が保持されるようにします。
|
•
|
トランザクションがタイムアウトになると、以下のようになります。
|
•
|
タイムアウトになった呼出しのハンドルは無効になり、以降このハンドルを参照すると、 TPEBADDESCが返されます。
|
•
|
未処理のハンドルの TPGETRPLYまたは TPRECVを呼び出すと、トランザクション・タイムアウトについてのグローバル状態が返され、 TP-STATUSに TPETIMEが設定されます。
|
•
|
非同期呼出しは、 TPACALLに TPNOREPLY、 TPNOBLOCK、または TPNOTRANを設定して行うことができます。
|
•
|
タイムアウト以外の理由でトランザクションが一度「中断のみ」とマークされると、 TPGETRPLYの呼出しでは、呼出しのローカル状態を表す値が戻され、ローカル条件を反映する成功コードまたはエラー・コードのいずれかが戻されます。
|
•
|
応答を取得するために TPGETRPLYで一度ハンドルを使用した場合、またはエラー条件を通知するために TPSENDまたは TPRECVで一度ハンドルを使用した場合、そのハンドルは無効になり、以降このハンドルを参照すると TPEBADDESCが返されます。この規則には、コードをトランザクション・モードで実行するかどうかに関係なく従います。
|
•
|
トランザクションが一度中断されると、未処理のトランザクションの呼出しハンドル( TPNOTRANフラグが設定されていないもの)はすべて無効になり、以降このハンドルを参照すると TPEBADDESCが返されます。
|
以下の項では、トランザクションに関連するエラーについて説明します。
トランザクション・エラーが発生すると、
TP-STATUSに
TPETRANが返されます。ただし、このようなエラーの意味は、そのエラーを返す呼出しによって異なります。
表11-3は、トランザクション・エラーを返す呼出しと、考えられるエラーの原因を示しています。
|
|
|
通常は、トランザクションの開始を試みたときに発生する一時的なシステム・エラーが原因で起こります。呼出しを繰り返し行うと、問題が解決します。
|
|
トランザクションから呼び出された場合に、 TPETRANを返します。
|
|
呼出し側が、1つ以上のリソース・マネージャとグローバル・トランザクション外の作業に関与しているため、Oracle Tuxedoシステムがグローバル・トランザクションを再開できません。そのような作業はすべて、グローバル・トランザクションを再開する前に完了している必要があります。ローカル・トランザクションについての呼出し側の状態は、変更されません。
|
TPCONNECT、 TPCALL、および TPACALL
|
トランザクションがサポートされていないサービスに対して、トランザクション・モードで呼出しが行われました。サービスには、データベース管理システム(DBMS)にアクセスし、その結果トランザクションがサポートされるサーバー・グループに属するものがあります。そのようなグループに属さないサービスもあります。また、トランザクションがサポートされたサービスには、トランザクションがサポートされていないソフトウェアとの相互運用を必要とするものがあります。たとえば、フォームを出力するサービスの処理が、トランザクションがサポートされていないプリンタで行われる場合があります。トランザクションがサポートされていないサービスは、トランザクションの参加リソースとして動作できない場合があります。
サービスをサーバーやサーバー・グループにグループ分けする作業は、管理タスクの1つです。どのサービスでトランザクションがサポートされているかを確認するには、アプリケーション管理者に問い合せてください。
トランザクション・レベルのエラーをアプリケーション・レベルで修正するには、 TPSVCDEF-REFを有効にするか、またはトランザクション外でエラーが返されたサービスにアクセスします。
|
致命的なトランザクション・エラーが発生した場合、アプリケーションでは、イニシエータで
TPABORTを呼び出してトランザクションを明示的に中断しなければなりません。そのため、トランザクションにとって致命的なエラーを認識することが大切です。次の3つの場合、トランザクションは失敗します。
•
|
トランザクションのイニシエータまたは参加リソースが、次のいずれかの理由により「中断のみ」にマークされました。
|
•
|
TPRETURNの引数の処理でエラーが発生しました。 TP-STATUSに TPESVCERRが設定されます。
|
•
|
TPRETURNの TP-RETURN-VALに TPFAILが設定されました。つまり、 TP-STATUSに TPESVCFAILが設定されました。
|
•
|
応答レコードのタイプが不明であるか、または呼出し側で使用できないので、成功したか失敗したかを判断できません。 TP-STATUSに TPEOTYPEが設定されます。
|
•
|
トランザクションがタイムアウトになりました。 TP-STATUSに TPETIMEが設定されます。
|
•
|
TPCOMMITが、トランザクションの開始元ではなく参加リソースによって呼び出されています。 TP-STATUSに TPEPROTOが設定されます。
|
トランザクションにとって致命的なプロトコル・エラーが発生するのは、トランザクションの不正な参加リソースから
TPCOMMITが呼び出された場合だけです。このエラーは、アプリケーション内で開発段階に修正できます。
イニシエータまたは参加リソースで障害が発生した後、またはトランザクションがタイムアウトになった後で、
TPCOMMITが呼び出されると、暗黙的な中断エラーになります。その場合、コミットは失敗するので、トランザクションを中断する必要があります。
通信呼出しで
TPESVCERR、
TPESVCFAIL、
TPEOTYPE、または
TPETIMEが返された場合、
TPABORTを呼び出してトランザクションを明示的に中断しなければなりません。トランザクションを明示的に中断する前に、未処理の通信ハンドルを待つ必要はありません。ただし、これらの通信ハンドルは、呼出しが中断された後は無効とみなされるので、トランザクション終了後にこれらのハンドルへのアクセスを試みると、
TPEBADDESCが返されます。
TPESVCERR、
TPESVCFAILおよび
TPEOTYPEの場合、トランザクションがタイムアウトにならないかぎり、引き続き通信呼出しを行うことができます。これらのエラーが戻された場合、トランザクションは「中断のみ」にマークされます。これ以降の処理の結果を保持するには、
TPNOTRANを設定して通信用の関数を呼び出します。このフラグを設定すると、「中断のみ」にマークされたトランザクションで実行された処理は、トランザクションが中断してもロールバックされません。
トランザクション・タイムアウトが発生しても通信を続けることはできますが、次のような通信リクエストを行うことはできません。
したがって、非同期呼出しを行うには、
TPNOREPLY、
TPNOBLOCK、または
TPNOTRANを設定する必要があります。
TPCOMMIT呼出しは、
TP-COMMIT-CONTROLの設定に応じて、
TPEHAZARDまたは
TPEHEURISTICを返します。
TP-COMMIT-CONTROLに
TP-CMT-LOGGEDを設定すると、2フェーズ・コミットの第2フェーズの実行前にアプリケーションに制御が移ります。その場合、第2フェーズ中に発生したヒューリスティックな判断がアプリケーションで認識されないことがあります。
TPEHAZARDまたは
TPEHEURISTICは1フェーズ・コミットで返すことができます。ただし、これが可能なのは、トランザクションに関与しているリソース・マネージャが1つだけで、1フェーズ・コミットでこのリソース・マネージャがヒューリスティックな判断を返すか、なんらかの障害の発生を示す場合です。
TP_COMMIT_CONTROLに
TP_CMT_COMPLETEを設定すると、リソース・マネージャがヒューリスティックな判断を通知する場合は
TPEHEURISTICが返され、リソース・マネージャがなんらかの障害を通知する場合は
TPEHAZARDが返されます。
TPEHAZARDは、コミットの第2フェーズ(または1フェーズ・コミット)で参加リソースになんらかの障害が発生し、トランザクションが正常終了したかどうかがわからない状況を示します。
TPCOMMITを呼び出した後でタイムアウトが発生した場合、トランザクションはどのような状態になるでしょうか。トランザクションがタイムアウトになり、そのトランザクションが中断されたことがシステムで認識されると、システムは
TP-STATUSに
TPEABORTを設定して、そのようなイベントの発生を通知します。トランザクションのステータスが不明な場合は、エラー・コードに
TPETIMEを設定します。
トランザクションの状態が明確ではない場合、リソース・マネージャに問い合せる必要があります。まず、トランザクションによって行われた変更が適用されたかどうかを確認します。これにより、トランザクションがコミットされたか、または中断されたかを判断できます。
トランザクション・モードのプロセスで、
TPNOTRANを設定して通信呼出しを行うと、呼び出されたサービスは現在のトランザクションに参加できません。サービス・リクエストの成功や失敗は、トランザクションの結果に影響しません。トランザクションは、サービスがトランザクションに参加しているかどうかには関係なく、そのサービスから応答が返されるのを待つ間にタイムアウトになる場合もあります。
トランザクション・モードで実行中にプロセスを呼び出すと、
TPRETURNおよび
TPFORWARは、トランザクションのサービス部分をそのトランザクションの完了時にコミットまたは中断できる状態にします。同じトランザクションでサービスを何度も呼び出すことができます。システムは、トランザクションのイニシエータによって
TPCOMMITまたは
TPABORTが呼び出されないかぎり、トランザクションを完全にはコミットまたは中断しません。
サービス内で行われた通信呼出しのすべての未処理のハンドルが取得されるまで、
TPRETURNまたは
TPFORWARを呼び出すことはできません。
TP-RETURN-VALに
TPSUCCESSを設定して、未処理のハンドルで
TPRETURNを呼び出すと、プロトコル・エラーが発生し、
TPGETRPLYを待機中のプロセスに
TPESVCERRが戻されます。そのプロセスがトランザクション・モードになっている場合、呼出し側は「中断のみ」にマークされます。トランザクションのイニシエータが
TPCOMMITを呼び出した場合も、トランザクションが暗黙的に中断されます。
TP-RETURN-VALに
TPFAILを設定して、未処理のハンドルで
TPRETURNを呼び出すと、
TPGETRPLYを待機中のプロセスに
TPESVCFAILが戻されます。トランザクションへの影響は同じです。
トランザクション・モードで実行中に
TPRETURNを呼び出すと、TPRETURNで発生したプロセス・エラー、またはアプリケーションによって
TP-RETURN-VALに設定された値で示されるエラーにより、トランザクションの結果に影響することがあります。
TPFORWARを使用すると、ある時点までは要求が正しく処理されていることを示すことができます。アプリケーション・エラーが検出されない場合、システムは
TPFORWARを呼び出します。アプリケーション・エラーが検出された場合、システムは
TPFAILを設定して
TPRETURNを呼び出します。
TPFORWARを正しく呼び出さないと、システムはその呼出しをプロセス・エラーと見なし、エラー・メッセージをリクエスタに返します。
TPTERM呼出しは、アプリケーションからクライアント・コンテキストを削除します。
クライアント・コンテキストがトランザクション・モードになっている場合、呼出しは失敗して、
TP-STATUSに
TPEPROTOが返されます。クライアント・コンテキストは、トランザクション・モードでアプリケーションの一部として残ります。
呼出しが成功すると、現在の実行スレッドはアプリケーション内に存在しなくなるため、クライアント・コンテキストは、トランザクションと通信したりトランザクションに参加できなくなります。
ATMI呼出しを使用してトランザクションを定義すると、Oracle Tuxedoシステムによって内部呼出しが実行され、トランザクションに参加している各リソース・マネージャにグローバル・トランザクション情報が渡されます。
TPCOMMITや
TPABORTなど呼び出すと、各リソース・マネージャに対して内部呼出しが行われ、呼出し側のグローバル・トランザクションのために行われていた作業がコミットまたは中断されます。
グローバル・トランザクションが開始された場合(明示的でも暗黙的でも)、アプリケーション・コードでリソース・マネージャのトランザクション呼出しを明示的に実行することはできません。このトランザクション規則に従わないと、不安定な結果が生じます。
TPGETLEV呼出しを使用すると、リソース・マネージャのトランザクション呼出しを実行する前に、グローバル・トランザクション内にすでにプロセスがあるかどうかを確認できます。
リソース・マネージャによっては、トランザクションの整合性レベルなど、特定のパラメータをプログラマが設定できるものがあります。その場合、リソース・マネージャ間のインタフェースで使用可能なオプションを指定します。そのようなオプションは、次の2つの方法で使用できるようになります。
•
|
リソース・マネージャ固有の関数呼出し。分散アプリケーションのプログラマは、これらの関数を使用してオプションを設定することができます。
|
•
|
ハードコーディングされたオプション。リソース・マネージャのプロバイダで提供されるトランザクション・インタフェースに組み込まれています。
|
詳細は、リソース・マネージャのドキュメントを参照してください。
オプションの設定方法はリソース・マネージャによって異なります。たとえば、Oracle TuxedoシステムのSQLリソース・マネージャの場合、
set transaction文を使用して、Oracle Tuxedoシステムによってすでに開始されているトランザクションに対する特定のオプション(整合性レベルとアクセス・モード)が決まります。
以降の項では、次のトランザクションについて説明します。
トランザクション・モードになっている呼出し側が、現在のトランザクションに参加するために別のサービスを呼び出した場合、次のようになります。
•
|
TPRETURNと TPFORWARは、トランザクションに参加しているサービスから呼び出されると、そのトランザクションのサービス部分をイニシエータによって中断またはコミットできる状態にします。
|
•
|
呼び出されたプロセスの成功や失敗は、現在のトランザクションに影響します。参加リソースで致命的なトランザクション・エラーが発生すると、現在のトランザクションは「中断のみ」にマークされます。
|
•
|
正常終了した参加リソースによって行われた処理が適用されるかどうかは、トランザクションの結果に依存します。つまり、トランザクションが中断された場合は、すべての参加リソースの処理は適用されません。
|
•
|
現在のトランザクションに参加するために別のサービスを呼び出すときに、TPNOREPLYを使用することはできません。
|
AUTOTRANが設定された別のトランザクションでのサービス呼出し
TPNOTRANを設定して通信呼出しを行い、呼び出されたときにトランザクションが自動的に開始するようにサービスが設定されている場合、呼出し側プロセスと呼び出されたプロセスはどちらもトランザクション・モードになります。ただし、この2つは別々のトランザクションを構成します。この状況では、次の処理が行われます。
•
|
TPRETURNは、トランザクションのイニシエータの役割を果たします。つまり、トランザクションが自動的に開始されたサービスで、トランザクションを終了します。または、 TPFORWARによって終了するサービスでトランザクションが自動的に開始された場合、転送チェーンの最後のサービスで発行された TPRETURN呼出しが、トランザクションのイニシエータの役割を果たします。つまり、トランザクションを終了します。(例については、 11-20ページの「AUTOTRANが設定されたTPFORWARとTPRETURNのトランザクションでの役割」を参照してください。)
|
•
|
TPRETURNはトランザクション・モードなので、トランザクションの参加リソースの障害やトランザクション・タイムアウトなどの影響を受けます。その場合、エラー・メッセージが返されます。
|
•
|
呼出し側のトランザクションの状態は、呼出し側に戻されるエラー・メッセージやアプリケーション障害の影響を受けません。
|
•
|
呼出し側のトランザクションは、呼出し側が応答を待っている間にタイムアウトになることがあります。
|
•
|
応答が必要ない場合、呼出し側のトランザクションは、通信呼出しによる影響を受けません。
|
新しい明示的なトランザクションを開始するサービスの呼出し
TPNOTRANを設定して通信呼出しを行い、呼び出されたサービスが自動的にトランザクション・モードにならないように設定されている場合、
TPBEGIN、
TPCOMMIT、および
TPABORTを明示的に呼び出すと、サービスで複数のトランザクションを定義できます。その結果、
TPRETURNが呼び出される前にトランザクションを完了できます。
•
|
TPRETURNはトランザクションの役割は果たしません。つまり、サービス・ルーチンにトランザクションが明示的に定義されているかどうかにかかわらず、 TPRETURNの役割は常に同じです。
|
•
|
トランザクションの結果に関係なく、 TPRETURNは TP-RETURN-VALに任意の値を返します。
|
•
|
通常、システムはプロセス・エラー、レコード・タイプ・エラー、またはアプリケーション障害を返し、 TPESVCFAIL、 TPEITYPE/ TPEOTYPE、および TPESVCERRの一般的な規則に従います。
|
•
|
呼出し側のトランザクションの状態は、呼出し側に戻されるエラー・メッセージやアプリケーション障害の影響を受けません。
|
•
|
呼出し側は、応答を待っている間にトランザクションがタイムアウトになることがあります。
|
•
|
応答が必要ない場合、呼出し側のトランザクションは、通信呼出しによる影響を受けません。
|
Oracle Tuxedoシステムで提供されるサブルーチン
Oracle Tuxedoシステムで提供されるサブルーチン
TPSVRINITおよび
TPSVRDONEは、トランザクションで使用される場合は特定の規則に従う必要があります。
Oracle Tuxedoシステム・サーバーは、初期化時に
TPSVRINITを呼び出します。特に、
TPSVRINITは、呼出し側プロセスがサーバーになった後、サービス・リクエストの処理を開始する前に呼び出されます。
TPSVRINITで非同期通信を実行した場合、関数が戻る前にすべての応答が取得されなければなりません。この処理が行われなかった場合、システムは保留中の応答があっても無視して、サーバーを終了します。
TPSVRINITでトランザクションを定義した場合、関数が戻る前にすべての非同期応答を取得して、トランザクションを終了しなければなりません。この処理が行われなかった場合、システムは未処理の応答が残っていてもトランザクションを中断し、それらの応答をすべて無視します。その場合、サーバーは正常に終了します。
Oracle Tuxedoシステム・サーバーの抽象化では、サービス・リクエストの処理が完了した後、終了する前に
TPSVRDONEを呼び出します。この時点で、サーバーのサービスの通知は取り消されますが、サーバー自体はアプリケーションから分離していません。
TPSVRDONEで通信を開始した場合、この関数は未処理の応答をすべて取得してから戻る必要がありますが、この処理が行われなかった場合、システムは保留中の応答があっても無視して、サーバーを終了します。
TPSVRDONE内でトランザクションを開始した場合は、未処理のすべての応答を取得してから終了する必要がありますが、この処理が行われなかった場合、システムはトランザクションを中断し、応答を無視します。この場合もサーバーは終了します。
中央イベント・ログには、Oracle Tuxedoアプリケーションで発生する重要なイベントが記録されます。これらのイベントに関するメッセージは、アプリケーション・クライアントとサービスによって
USERLOG(3cbl)ルーチンを介してログに送信されます。
中央イベント・ログの分析は、アプリケーションで行う必要があります。
USERLOG(3cbl)に記録するイベントに関しては、厳密なガイドラインを定義しておく必要があります。ほとんど問題にならないようなメッセージを記録しないようにすると、アプリケーションのデバッグが簡単になります。
Windows 2003プラットフォームの中央イベント・ログの設定の詳細は、『WindowsでのOracle Tuxedo ATMIの使用』
を参照してください。
アプリケーション管理者は、構成ファイルに、各マシン上のエラー・メッセージ・ファイル名の接頭辞として使用する絶対パス名を定義します。
USERLOG(3cbl)ルーチンは、月、日、年を表す
mmddyyの形式で日付を生成し、この日付をパス名の接頭辞に付加して中央イベント・ログの完全なファイル名を構成します。毎日、新しいファイルが作成されます。そのため、中央イベント・ログに数日間にわたってメッセージが送信された場合、メッセージはそれぞれ異なるファイルに書き込まれます。
•
|
マシン名。たとえば、UNIXシステムでは、 uname(1)コマンドから返される名前が使用されます。
|
•
|
USERLOG(3cbl)を呼び出したスレッドのスレッドID (スレッドがサポートされていないプラットフォーム上では0)、プロセスID、および名前。
|
•
|
USERLOG(3cbl)を呼び出したスレッドのコンテキストID。
|
各メッセージの本文の前には、そのメッセージのカタログ名と番号が付きます。
たとえば、
mach1 (
unameコマンドから返される名前)というUNIXマシン上で、セキュリティ・プログラムが午後
4:22:14に次のような呼出しを行ったとします。
01
LOG-REC PIC X(15) VALUE "UNKNOWN USER ".
01
LOGREC-LEN PIC S9(9) VALUES IS 13.
CALL "USERLOG" USING
LOG-REC LOGREC-LEN TPSTATUS-REC.
162214.mach1!security.23451: UNKNOWN USER
この例では、セキュリティのプロセスIDは
23451です。
前述のメッセージが、アプリケーションではなくOracle Tuxedoシステムによって生成された場合は、次のようになります。
162214.mach1!security.23451: COBAPI_CAT: 999: UNKNOWN USER
この例では、メッセージのカタログ名は
COBAPI_CAT、メッセージ番号は
999です。
プロセスがトランザクション・モードのときにメッセージが中央イベント・ログに送られると、ユーザー・ログ・エントリのタグにはそのほかの要素が付加されます。これらの要素は、リテラル文字列の
gtridと、それに続く3桁のlong型の16進数で構成されます。これらの整数はグローバル・トランザクションをユニークに識別するもので、グローバル・トランザクション識別子、つまり
gtridと呼ばれます。この識別子は主に管理上の目的で使用されます。また、中央イベント・ログでメッセージの前に付加されるタグの中に挿入されます。システムがトランザクション・モードで中央イベント・ログにメッセージを書き込むと、ログ・エントリは次のようになります。
162214.mach1!security.23451: gtrid x2 x24e1b803 x239:
UNKNOWN USER
イベント・ログにメッセージを書き込むには、次の手順に従います。
•
|
ログに書き込むエラー・メッセージをレコードに割り当て、そのレコード名を呼出しの引数として使用します。
|
•
|
メッセージのリテラル文字列を二重引用符で囲み、次の例のように USERLOG(3cbl)呼出しの引数として指定します。
|
01 TPSTATUS-REC.
COPY TPSTATUS.
01 LOGMSG PIC X(50).
01 LOGMSG-LEN PIC S9(9) COMP-5.
. . .
CALL "TPOPEN" USING TPSTSTUS-REC.
IF NOT TPOK
MOVE "TPSVRINIT: Cannot Open Data Base" TO LOGMSG
MOVE 43 LOGMSG-LEN
CALL "USERLOG" USING LOGMSG
LOGMSG-LEN
TPSTATUS-REC.
. . .
この例では、
TPOPEN(3cbl)が
-1を返した場合、メッセージが中央イベント・ログに送られます。