トランザクションアプリケーションを作成する上で、注意すべき点があります。これら作成上の誤りによりInterstageまたはアプリケーションが動作不良となることがあります。
データ領域の獲得／解放について
シグナルについて
コンパイルとリンクについて
インタフェース情報が異なる場合に動作不良となる
アプリケーションで受信した文字列型データが不完全となる
アプリケーション間連携時にアプリケーションが動作不良となる
プロセスバインド機能を使用した場合、レスポンスが悪くなる場合がある
標準コード変換(FSUNiconv)の使用について
下記に記す機能を使用して、これらの問題回避または検証を行うことをお勧めします。
1) データ領域の獲得／解放について
以下のデータ型を用いる場合は、各データ型に応じた専用の関数により領域獲得を行う必要があります。専用の関数で獲得していない場合は、アプリケーション動作時にメモリアクセスエラーを引き起こす要因となります。また、クライアントおよびスタブ内で動的に獲得した領域は、不要になった時点で各データ型に応じた解放関数により、明示的な解放操作が基本的に必要です。解放漏れの場合、アプリケーションプロセスでのメモリリークの要因となります。
- 文字列型、ワイド文字列型、シーケンス型、構造体、配列
以下のデータ型を用いる場合、クライアントアプリケーションのinパラメタ、inoutパラメタ、およびサーバアプリケーションのoutパラメタ、inoutパラメタ、復帰値として、NULLポインタは設定できません。誤って設定した場合、メモリアクセスエラーを招く要因となります。
- 文字列型、シーケンス型、構造体、共用体、配列
COBOLアプリケーションにおいて以下の型のデータ設定・取得操作は必ず専用APIを使用してください。各APIの詳細については“リファレンスマニュアル(API編)”の該当する記事を参照してください。
データ型 | データ設定API | データ取得API |
|---|---|---|
文字列型 | TDSTRINGSET | TDSTRINGGET |
ワイド文字列型 | TDWSTRINGSET | TDWSTRINGGET |
シーケンス型 | TDSEQUENCEELEMENTSET | TDSEQUENCEELEMENTGET |
2) シグナルについて
トランザクションアプリケーションでは、シグナル処理は使用できません。
シグナルを受信した場合、アプリプロセスの異常終了等の誤動作となる可能性があります。なお、明にシグナル処理を行わない場合でも、使用する連携製品のライブラリなどで暗にシグナル処理を行う可能性もあるため注意してください。
3) コンパイルとリンクついて
トランザクションアプリケーションには、サーバアプリケーションプロセスの形態として、『プロセスモード』と『スレッドモード』の2つのモードがあります。そのため、リンク時に指定するライブラリ群も各モード用に分けて提供されています。
実行モジュールにおいて、プロセスモード用ライブラリとスレッドモード用ライブラリが混在してリンクされていた場合、アプリケーションの動作が不定となり、場合によっては、アプリケーションが異常終了する可能性があります。
4) インタフェース情報が異なる場合に動作不良となる
クライアントアプリケーションを作成する際に、IDL定義をIDLコンパイラでコンパイルすることによりスタブファイルを生成します。また、CORBA通信を可能とするために、トランザクションアプリケーションが動作するサーバが参照するインタフェースリポジトリにインタフェース情報を登録します。
このとき使用するIDL定義は本来同じものを使用しなければなりません。
しかし、下記のような場合、これらの関係に差異が生じることがあります。
IDL定義の修正を要するアプリケーションの変更があったが、一部の操作端末でクライアントアプリケーションの入れ替えが行われていない場合
上記条件でクライアントから処理要求を行うと、Interstageが下記の現象により動作不良となります。
サーバアプリケーションで受信した、クライアントアプリケーションからの要求データが不当な値となる
メモリ不足エラーが発生する
処理要求が無応答となる
Interstageが異常終了する
これを回避するため、Interstageではインタフェース情報チェック機能を提供します。
インタフェース情報チェック機能については、“OLTPサーバ運用ガイド”の“インタフェース情報チェック機能を使用した運用”を参照してください。
5) アプリケーションで受信した文字列型データが不完全となる
クライアントアプリケーションからサーバアプリケーションへ、またはサーバアプリケーションからクライアントアプリケーションへ処理要求を行った場合に、IDL定義に文字列型で定義をしたデータが途切れることがあります。
これは文字列型と定義されているデータに0x00が含まれているために、Interstageのデータ解析処理が、0x00を終端文字と認識することにより、以降のデータを不要と判断して切り捨てるために発生します。
本現象が発生した場合には、スナップショットでデータを確認するなどし、アプリケーションを修正してください。
本現象となる処理イメージ図とプログラム例を以下に示します。
上記の理由より、データの切り捨てが発生した場合には、IDL定義にて文字列型で定義するのではなく、構造体型として各データ項目を定義するなどし、現象を回避してください。
6) アプリケーション間連携時にアプリケーションが動作不良となる
サーバアプリケーション間連携時には、以下の処理が考えられます。
クライアントからの要求データを中継アプリケーションで受信し、さらにサーバアプリケーションへデータを通知する
中継アプリケーションは、クライアントとなるCORBAアプリケーションからはトランザクションアプリケーションとして、中継先のトランザクションアプリケーションからはCORBAアプリケーションとして位置づけられます。
このとき、クライアントからのデータを受信したデータは、コンポーネントトランザクションサービスが管理する領域に格納されます。このデータをサーバアプリケーションへ通知する場合には、CORBAサービスが管理する領域に一度複写する必要があります。
これを行わずコンポーネントトランザクションサービスが管理する領域を、CORBAサービスのリクエストのパラメタに設定すると、以下の現象が発生します。
アプリケーションに通知するデータが不当な値となる
アプリケーションが異常終了する
下図に示すように、連携用サーバアプリケーションは、トランザクションアプリケーションとCORBAアプリケーションから構成されます。これらは同一オブジェクト上で動作しますが、トランザクションアプリケーション論理で獲得した領域(A)を、CORBAアプリケーションで発行するオペレーション(OP2)のパラメタに指定することはできません。必ずCORBAアプリケーション論理で獲得した領域(B)に複写し、オペレーションのパラメタに指定してください。
7) プロセスバインド機能を使用した場合、レスポンスが悪くなる場合がある
プロセスバインド機能では、セション開始要求を受け取ったサーバアプリケーションプロセスに、そのセションIDに対する処理がバインドされます。通常、セション開始要求は、ワークユニット内で最後に要求待ちとなったサーバアプリケーションプロセスに振り分けられます。そのため、クライアントからの要求数が少ない場合、すべてのクライアントが特定のプロセスにバインドされ、その結果、1プロセスにセションが集中して性能劣化を引き起こすことがあります。
これを回避するためには、“セション開始要求(初回呼び出し)のプロセスへの振り分け方式”を参照してください。
8) 標準コード変換(FSUNiconv)の使用について
コード変換関数は、OSのlibc.soにも存在します。そのため、アプリケーションから富士通の標準コード変換(FSUNiconv)を使用してコード変換する場合、以下の対処を実施してください。
CまたはCOBOLのアプリケーションの場合
tdlinknormapmコマンドを使用してFSUNiconvがリンクされたextp_apmTDNORMを再作成する必要が有ります。
“リファレンスマニュアル（コマンド編）”より“コンポーネントトランザクションサービス運用コマンド”の“tdlinknormapm”を参照し、extp_apmTDNORMを再作成してください。
以下にコマンドの使用例を示します。
tdlinknormapm -t thread -p "-L/opt/FSUNiconv/lib -licv" -o TDNORMICV |
上記の場合、-oオプションで指定した"TDNORMICV"をワークユニット定義の“APM”ステートメントに設定する必要があります。
なお、-oオプションを指定しない場合は、"TDNORM"が指定されたものと見なし、標準の extp_apmTDNORMが置き換えられます。そのため、あらかじめextp_apmTDNORMをバックアップしておく必要があります。
C++のアプリケーションの場合
アプリケーションのリンク時に、“libicv.so”が“libc.so”より先にリンクされるようにリンクオプションを指定してください。
