(WTC)アプリケーションのパフォーマンスを最大にする方法について説明します。ServerアプリケーションとTuxedoサービスの相互運用性が実現されます。(EJBs)を呼出すことができます。Connectorに関する項を参照してください。Connectorの構成を行う際には、次のガイドラインに従ってください。構成には複数のWTCサービスを設定できます。1つのサーバー・インスタンスにはWTCサービスを1つだけターゲット指定できます。WTCでは接続プール機能がサポートされません。WTCではリクエストは多重化されますが、単一の物理的接続を使用します。構成の変更は次のように実装されます。セッション/接続の確立前に、セッション/接続構成(ローカルAP、リモートAP、パスワード、およびリソース)を変更。変更は受け入れられ、新しいセッションまたは接続に実装されます。接続/セッションの確立後に、セッション/接続構成(ローカルAP、リモートAP、パスワードおよびリソース)を変更。変更は受け入れられますが、接続を切離して再接続しないかぎり既存の接続/セッションに実装されません。Server管理コンソール・ヘルプのWTCサービスのサーバーへの割当てに関する項を参照してください。インポート済みサービスやエクスポート済みサービスの構成を変更した場合。変更は受け入れられ、次回のインバウンド・リクエストまたはアウトバウンド・リクエストに実装されます。この方法は、処理中のリクエストが不明な状態のままになるためお薦めしません。tBridgeの構成を変更。デプロイされたWTCサービスを変更すると常に例外が発生します。tBridgeの構成を変更する前には、必ずWTCサービスのターゲット指定を解除するようにします。ターゲット指定を解除して構成を変更したら、WTCサービスをターゲット指定して変更を実装します。ベスト・プラクティス次の項では、WTC使用時のベスト・プラクティスを紹介します。接続ポリシーを構成するときに、ON_STARTUPおよびINCOMING_ONLYを使用します。ON_STARTUPおよびINCOMING_ONLYは、常に組合せられています。WTCのリモート・アクセス・ポイントがON_STARTUPを使用して構成されている場合、Tuxedoドメイン構成のDM_TDOMAINのセクションは、リモート・アクセス・ポイントをINCOMING_ONLYとして構成する必要があります。この場合は、WTCは、常にセッション・イニシエータとして機能します。Connector管理ガイド』のアクセス・ポイント間の接続の構成に関する項を参照してください。ON_DEMANDの接続ポリシーを使用しないでください。望ましい接続ポリシーは、ON_STARTUPとINCOMING_ONLYです。これにより、ON_DEMANDのルーティング・セマンティクスによるサービス・リクエストの失敗の可能性が低減します。Connector管理ガイド』のアクセス・ポイント間の接続の構成に関する項を参照してください。アプリケーションを設計するときに、リンク・レベル・フェイルオーバー、サービス・レベル・フェイルオーバーおよびロード・バランシングなどのWTC機能の使用を考慮してください。Connector管理ガイド』のフェイルオーバーとフェイルバックの構成に関する項を参照してください。Serverクラスタを使用した追加的なロード・バランシングおよびフェイルオーバーの使用を検討します。Serverクラスタ内で使用する方法は以下のとおりです。ServerクラスタのすべてのノードにWTCインスタンスを構成します。各クラスタ・ノードの各WTCインスタンスで同じ構成にする必要があります。Connectorのクラスタリングされた環境での管理方法に関する項を参照してください。WTCからTuxedoへの接続にインターネットを使用する場合、次のセキュリティ設定を使用します。「セキュリティ」の値をDM_PWに設定します。Connector管理ガイド』のリモート・アクセス・ポイントの認証に関する項を参照してください。Link-level暗号化を有効にして、min-encrypt-bitsパラメータを40に設定し、max-encrypt-bitsを128に設定します。Connector管理ガイド』のLink-Level暗号化に関する項を参照してください。エラー条件をアプリケーションで管理し解釈するメカニズムをアプリケーション・ロジックで提供する必要があります。アプリケーション・エラー管理に関する項を参照してください。Connector管理ガイド』のシステム・レベル・デバッグ設定に関する項を参照してください。TypedFML32バッファ内に埋め込まれたTypedFML32バッファを使用しないでください。ConnectorにおけるFMLの使用に関する項を参照してください。アプリケーションへの負荷が大きい場合、より多くのリモートTuxedoアクセス・ポイントを構成し、そのアクセス・ポイント間でWTCの作業負荷をロード・バランスしてください。Connector管理ガイド』のフェイルオーバーとフェイルバックの構成に関する項を参照してください。トランザクション・アプリケーションを使用するときに、同じリモート・アクセス・ポイントから利用可能な同じトランザクションにリモート・サービスを含めるようにしてください。JATMIトランザクションに関する項を参照してください。ゲートウェイからサービスをディスパッチするときに利用可能なクライアント・スレッド数によって、同時に実行しているサービス数が制限される場合があります。Connector属性は存在しません。サービスを呼出すときに適切なスレッド・モデルを使用します。Serverサーバー環境の構成』のスレッド管理に関する項およびワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください。Serverのリリース9.2以降には高度なルーティング・アルゴリズムがあり、トランザクションのパフォーマンスを向上させることができます。2フェーズ・コミット(2PC)トランザクションに複数のTuxedoサービス・リクエストが関与する場合、パフォーマンスが向上します。Serverコマンド・ライン・パラメータを設定してこの機能を無効にできます。-Dweblogic.wtc.xaAffinity=falseコンストラクタTypedFML32をバッファ内のオブジェクトの最大数を使用して呼び出します。最大数の予測が困難な場合でも、適切な数を指定するとパフォーマンスが向上します。フィールド数に1.33を乗算すると、およその最大数を算出できます。注意:このパフォーマンスに関するヒントはTypedFMLバッファ・タイプには当てはまりません。例:TypedFML32バッファ・タイプにフィールドが50ある場合、最大数は63になります。50)を呼び出す方がTypedFML32()を呼び出すよりもパフォーマンスが良くなります。50)を呼び出す方がTypedFML32()を呼び出すよりもパフォーマンスが良くなります。WTCクライアントと相互運用するサーバーとして働くTuxedoアプリケーションを構成する場合、並行処理の実施を検討します。並行処理は、様々なTuxedoマシン上に様々なサーバーを入念に構成すると可能になる場合があります。Tuxedoアプリケーションにおけるデータベース・アクセスのデッドロックの可能性に注意します。デッドロックはTuxedoアプリケーションを注意深く構成することで回避できます。WTCのロード・バランシングまたはサービス・レベルのフェイルオーバーを使用している場合、WTCトランザクション・アフィニティを無効化しないことを推奨します。発信リクエストをロード・バランシングする場合、インポート済みサービスを複数のエントリと共に異なるキーを使用して構成します。インポート済みサービスでは、各レコードが固有であるかどうかを複合キーを使用して判断します。複合キーは「サービス名+ローカル・アクセス・ポイント+リモート・アクセス・ポイント・リストのプライマリ・ルート」で構成されています。次の例に、service1に対するリクエストをTDomainSession(WDOM1,TUXDOM1)とTDomainSession(WDOM1,TUXDOM2)の間で適切にロード・バランシングするよう構成する方法を示します。ロード・バランシングの正しい構成の例ResourceNameLocalAccessPointRemoteAccessPointListRemoteNameservice1WDOM1TUXDOM1TOLOWERservice1WDOM1TUXDOM2TOLOWER2次の例は、ロード・バランシングのリクエストを不適切に構成した場合です。この構成では、service1に対して同じ複合キーが使用されます。reserved.法律上の注意点ライブラリ。