Cosminexus V11 アプリケーションサーバ 機能解説 互換編

解説書

3021-3-J12-50

前書き

対象製品

マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」の前書きの対象製品の説明を参照してください。

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

HITACHI，Cosminexus，DABroker，HiRDB，JP1，OpenTP1，TPBroker，uCosminexus，XDMは，株式会社 日立製作所の商標または登録商標です。

AIXは，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

EclipseおよびJakartaは，Eclipse Foundation, Inc.の商標です。

IBMは，世界の多くの国で登録されたInternational Business Machines Corporationの商標です。

Linuxは，Linus Torvalds氏の米国およびその他の国における登録商標です。

Microsoft，Active Directory，Azure，SQL Server，Windows，Windows Server は，マイクロソフト 企業グループの商標です。

Oracle(R)，Java ，MySQL及びNetSuite は，Oracle，その子会社及び関連会社の米国及びその他の国における登録商標です。

Red Hat, and Red Hat Enterprise Linux are registered trademarks of Red Hat, Inc. in the United States and other countries. Linux(R) is the registered trademark of Linus Torvalds in the U.S. and other countries.

Red Hat，およびRed Hat Enterprise Linuxは，米国およびその他の国におけるRed Hat, Inc.の登録商標です。Linux(R)は，米国およびその他の国におけるLinus Torvalds氏の登録商標です。

UNIXは，The Open Groupの登録商標です。

その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

Eclipseは，開発ツールプロバイダのオープンコミュニティであるEclipse Foundation, Inc.により構築された開発ツール統合のためのオープンプラットフォームです。

This product includes software developed by the Apache Software Foundation (http://www.apache.org/).

発行

2024年 2月 3021-3-J12-50

著作権

All Rights Reserved. Copyright (C) 2020, 2024, Hitachi, Ltd.

変更内容

変更内容(3021-3-J12-50) uCosminexus Application Server 11-40，uCosminexus Client 11-40，uCosminexus Developer 11-40，uCosminexus Service Architect 11-40，uCosminexus Service Platform 11-40

追加・変更内容

変更個所

アプリケーションサーバ11-40での主な機能変更についての説明を追加した。

1.3

JDK11またはJDK17を使用する環境ごとに，指定できるモード（推奨モードまたはV9互換モード）についての説明を追加した。

2.2

@OneToOneおよび@ManyToOneでのLAZYフェッチを使用する場合の注意事項について説明を変更した。

8.20.1

マニュアル訂正の内容を反映した。

-

単なる誤字・脱字などはお断りなく訂正しました。

はじめに

このマニュアルをお読みになる際の前提情報については，マニュアル「アプリケーションサーバ & BPM/ESB基盤 概説」のはじめにの説明を参照してください。

第1編　アプリケーションサーバの機能

1　アプリケーションサーバの機能

この章では，アプリケーションサーバの機能の分類と目的，および機能とマニュアルの対応について説明します。また，このバージョンで変更した機能についても説明しています。

1.1　機能の分類

アプリケーションサーバは，Java EE 8に対応したJ2EEサーバを中心としたアプリケーションの実行環境を構築したり，実行環境上で動作するアプリケーションを開発したりするための製品です。Java EEの標準仕様に準拠した機能や，アプリケーションサーバで独自に拡張された機能など，多様な機能を使用できます。目的や用途に応じた機能を選択して使用することで，信頼性の高いシステムや，処理性能に優れたシステムを構築・運用できます。

アプリケーションサーバの機能は，大きく分けて，次の二つに分類できます。

アプリケーションの実行基盤としての機能

アプリケーションの実行基盤を運用・保守するための機能

二つの分類は，機能の位置づけや用途によって，さらに詳細に分類できます。アプリケーションサーバのマニュアルは，機能の分類に合わせて提供しています。

アプリケーションサーバの機能の分類と対応するマニュアルについて，次の図に示します。

図1‒1　アプリケーションサーバの機能の分類と対応するマニュアル

注※1

マニュアル名称の「アプリケーションサーバ」を省略しています。

注※2

アプリケーションサーバでは，SOAP WebサービスとRESTful Webサービスを実行できます。目的によっては，マニュアル「アプリケーションサーバ Webサービス開発ガイド」以外の次のマニュアルも参照してください。

SOAPアプリケーションを開発・実行する場合

アプリケーションサーバ SOAPアプリケーション開発の手引

SOAP WebサービスやSOAPアプリケーションのセキュリティを確保する場合

XML Security - Core ユーザーズガイド

アプリケーションサーバ Webサービスセキュリティ構築ガイド

XMLの処理について詳細を知りたい場合

XML Processor ユーザーズガイド

ここでは，機能の分類について，マニュアルとの対応と併せて説明します。

1.1.1　アプリケーションの実行基盤としての機能

アプリケーションとして実装されたオンライン業務やバッチ業務を実行する基盤となる機能です。システムの用途や求められる要件に応じて，使用する機能を選択します。

アプリケーションの実行基盤としての機能を使用するかどうかは，システム構築やアプリケーション開発よりも前に検討する必要があります。

アプリケーションの実行基盤としての機能について，分類ごとに説明します。

(1)　アプリケーションを動作させるための基本的な機能（基本・開発機能）

アプリケーション（J2EEアプリケーション）を動作させるための基本的な機能が該当します。主にJ2EEサーバの機能が該当します。

アプリケーションサーバでは，Java EE 8に対応したJ2EEサーバを提供しています。J2EEサーバでは，標準仕様に準拠した機能のほか，アプリケーションサーバ独自の機能も提供しています。

基本・開発機能は，機能を使用するJ2EEアプリケーションの形態に応じて，さらに三つに分類できます。アプリケーションサーバの機能解説のマニュアルは，この分類に応じて分冊されています。

それぞれの分類の概要を説明します。

Webアプリケーションを実行するための機能（Webコンテナ）

Webアプリケーションの実行基盤であるWebコンテナの機能，およびWebコンテナとWebサーバが連携して実現する機能が該当します。

Enterprise Beanを実行するための機能（EJBコンテナ）

Enterprise Beanの実行基盤であるEJBコンテナの機能が該当します。また，Enterprise Beanを呼び出すEJBクライアントの機能も該当します。

WebアプリケーションとEnterprise Beanの両方で使用する機能（コンテナ共通機能）

Webコンテナ上で動作するWebアプリケーションおよびEJBコンテナ上で動作するEnterprise Beanの両方で使用できる機能が該当します。

(2)　Webサービスを開発するための機能

Webサービスの実行環境および開発環境としての機能が該当します。

アプリケーションサーバでは，次のエンジンを提供しています。

JAX-WS仕様に従ったSOAPメッセージのバインディングを実現するJAX-WSエンジン

JAX-RS仕様に従ったRESTful HTTPメッセージのバインディングを実現するJAX-RSエンジン

(3)　信頼性や性能などを向上させるために拡張されたアプリケーションサーバ独自の機能（拡張機能）

アプリケーションサーバで独自に拡張された機能が該当します。バッチサーバ，CTM，データベースなど，J2EEサーバ以外のプロセスを使用して実現する機能も含まれます。

アプリケーションサーバでは，システムの信頼性を高め，安定稼働を実現するための多様な機能が拡張されています。また，J2EEアプリケーション以外のアプリケーション（バッチアプリケーション）をJavaの環境で動作させる機能も拡張しています。

(4)　システムのセキュリティを確保するための機能（セキュリティ管理機能）

アプリケーションサーバを中心としたシステムのセキュリティを確保するための機能が該当します。不正なユーザからのアクセスを防止するための認証機能や，通信路での情報漏えいを防止するための暗号化機能などがあります。

1.1.2　アプリケーションの実行基盤を運用・保守するための機能

アプリケーションの実行基盤を効率良く運用したり，保守したりするための機能です。システムの運用開始後に，必要に応じて使用します。ただし，機能によっては，あらかじめ設定やアプリケーションの実装が必要なものがあります。

アプリケーションの実行基盤を運用・保守するための機能について，分類ごとに説明します。

(1)　システムの起動・停止など日常的な運用をするための機能（運用機能）

システムの起動や停止，アプリケーションの開始や停止，入れ替えなどの，日常運用で使用する機能が該当します。

(2)　システムの利用状況を監視するための機能（監視機能）

システムの稼働状態や，リソースの枯渇状態などを監視するための機能が該当します。また，システムの操作履歴など，監査で使用する情報を出力する機能も該当します。

(3)　ほかの製品と連携して運用するための機能（連携機能）

JP1やクラスタソフトウェアなど，ほかの製品と連携して実現する機能が該当します。

(4)　トラブル発生時などに対処するための機能（保守機能）

トラブルシューティングのための機能が該当します。トラブルシューティング時に参照する情報を出力するための機能も含みます。

(5)　旧バージョンの製品から移行するための機能（移行機能）

旧バージョンのアプリケーションサーバから新しいバージョンのアプリケーションサーバに移行するための機能が該当します。

(6)　旧バージョンの製品との互換のための機能（互換機能）

旧バージョンのアプリケーションサーバとの互換用の機能が該当します。なお，互換機能については，対応する推奨機能に移行することをお勧めします。

1.1.3　機能とマニュアルの対応

アプリケーションサーバの機能解説のマニュアルは，機能の分類に合わせて分冊されています。

機能の分類と，それぞれの機能について説明しているマニュアルとの対応を次の表に示します。

表1‒1　機能の分類と機能解説のマニュアルの対応

分類

機能

マニュアル※1

基本・開発機能

Webコンテナ

基本・開発編(Webコンテナ)

JSFおよびJSTLの利用

JAX-RS 2.1の利用

WebSocket

NIO HTTPサーバ

サーブレットおよびJSPの実装

セッションマネージャの指定機能

EJBコンテナ

基本・開発編(EJBコンテナ)

EJBクライアント

Enterprise Bean実装時の注意事項

ネーミング管理

基本・開発編(コンテナ共通機能)

リソース接続とトランザクション管理

OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）

JPA 2.2の利用

CJMSプロバイダ

JavaMailの利用

アプリケーションサーバでのCDIの利用

アプリケーションサーバでのBean Validationの利用

Java Batch

JSON-P

JSON-B

Concurrency Utilities

アプリケーションの属性管理

アノテーションの使用

J2EEアプリケーションの形式とデプロイ

コンテナ拡張ライブラリ

ライブラリ競合回避機能

パッケージ名変換機能

拡張機能

バッチサーバによるアプリケーションの実行

拡張編

CTMによるリクエストのスケジューリングと負荷分散

バッチアプリケーションのスケジューリング

J2EEサーバ間のセッション情報の引き継ぎ（セッションフェイルオーバ機能）

データベースセッションフェイルオーバ機能

明示管理ヒープ機能を使用したFullGCの抑止

アプリケーションのユーザログ出力

CORBA/OTMゲートウェイ機能

セキュリティ管理機能

統合ユーザ管理による認証

セキュリティ管理機能編

アプリケーションの設定による認証

SSL/TLS通信でのTLSv1.2の使用

APIによる直接接続を使用する負荷分散機の運用管理機能からの制御

運用機能

システムの起動と停止

運用／監視／連携編

J2EEアプリケーションの運用

監視機能

稼働情報の監視（稼働情報収集機能）

リソースの枯渇監視

監査ログ出力機能

データベース監査証跡連携機能

運用管理コマンドによる稼働情報の出力

Managementイベントの通知とManagementアクションによる処理の自動実行

CTMの稼働統計情報の収集

コンソールログの出力

連携機能

JP1と連携したシステムの運用

システムの集中監視（JP1/IMとの連携）

ジョブによるシステムの自動運転（JP1/AJSとの連携）

クラスタソフトウェアとの連携

ホスト単位管理モデルを対象にした系切り替えシステム（クラスタソフトウェアとの連携）

1:1系切り替えシステム（クラスタソフトウェアとの連携）

相互系切り替えシステム（クラスタソフトウェアとの連携）

N:1リカバリシステム（クラスタソフトウェアとの連携）

保守機能

トラブルシューティング関連機能

保守／移行編

性能解析トレースを使用した性能解析

製品のJavaVM（以降，JavaVMと略す場合があります）の機能

移行機能

旧バージョンのアプリケーションサーバからの移行

推奨機能への移行

互換機能

基本・開発機能の互換機能

互換編※2

拡張機能の互換機能

注※1　マニュアル名称の「アプリケーションサーバ 機能解説」を省略しています。

注※2　このマニュアルです。

1.2　このマニュアルに記載している機能の説明

ここでは，このマニュアルで機能を説明するときの分類の意味と，分類を示す表の例について説明します。

1.2.1　分類の意味

このマニュアルでは，各機能について，次の五つに分類して説明しています。マニュアルを参照する目的によって，必要な個所を選択して読むことができます。

解説

機能の解説です。機能の目的，特長，仕組みなどについて説明しています。機能の概要について知りたい場合にお読みください。

実装

コーディングの方法やDDの記載方法などについて説明しています。アプリケーションを開発する場合にお読みください。

設定

システム構築時に必要となるプロパティなどの設定方法について説明しています。システムを構築する場合にお読みください。

運用

運用方法の説明です。運用時の手順や使用するコマンドの実行例などについて説明しています。システムを運用する場合にお読みください。

注意事項

機能を使用するときの全般的な注意事項について説明しています。注意事項の説明は必ずお読みください。

1.2.2　分類を示す表の例

機能説明の分類については，表で説明しています。表のタイトルは，「この章の構成」または「この節の構成」となっています。

次に，機能説明の分類を示す表の例を示します。

機能説明の分類を示す表の例

表X-1　この章の構成（○○機能）

分類

タイトル

参照先

解説

○○機能とは

X.1

実装

アプリケーションの実装

X.2

DDおよびcosminexus.xml※での定義

X.3

設定

実行環境での設定

X.4

運用

○○機能を使用した運用

X.5

注意事項

○○機能使用時の注意事項

X.6

注※

cosminexus.xmlについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「16.　アプリケーションの属性管理」を参照してください。

ポイント

cosminexus.xmlを含まないアプリケーションのプロパティ設定

cosminexus.xmlを含まないアプリケーションでは，実行環境へのインポート後にプロパティを設定，または変更します。設定済みのプロパティも実行環境で変更できます。

実行環境でのアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。サーバ管理コマンドおよび属性ファイルでのアプリケーションの設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.5.2　J2EEアプリケーションのプロパティの設定手順」を参照してください。

属性ファイルで指定するタグは，DDまたはcosminexus.xmlと対応しています。DDまたはcosminexus.xmlと属性ファイルのタグの対応についてはマニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「2.　アプリケーション属性ファイル（cosminexus.xml）」を参照してください。

なお，各属性ファイルで設定するプロパティは，アプリケーション統合属性ファイルでも設定できます。

1.3　アプリケーションサーバ 11-40での主な機能変更

この節では，アプリケーションサーバ 11-40での主な機能の変更について，変更目的ごとに説明します。

説明内容は次のとおりです。

アプリケーションサーバ 11-40で変更になった主な機能と，その概要を説明しています。機能の詳細については参照先の記述を確認してください。「参照先マニュアル」および「参照個所」には，その機能についての主な記載個所を記載しています。

「参照先マニュアル」に示したマニュアル名の「アプリケーションサーバ」は省略しています。

1.3.1　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表1‒2　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Java SE 17への対応

Java SE 17の機能が使用できるようになりました。

システム設計ガイド

2.1

機能解説 保守／移行編

9章

メモリ管理方式にZGCを追加

メモリ管理方式にZGCを追加しました。

システム設計ガイド

7.17

接続できるデータベースにAzure SQL Databaseを追加

DB Connectorを使用して接続できるデータベースにAzure SQL Databaseを追加しました。

機能解説 基本・開発編(コンテナ共通機能)

3.6.17

第2編　V9互換モード

2　V9互換モードの概要

Version9以前との互換性を重視するシステム向けの，「V9互換モード」の概要について説明します。

2.1　V9互換モードと推奨モード

アプリケーションサーバ 11-00では，Servlet 3.1やWebSocket 1.0などのJava EE 7新仕様の対応に当たり，09-87以前との互換性を維持できない機能変更をしています。そのため，09-87以前に設計されたシステムを11-00以降に移行する場合，幾つかの設計変更が必要です。

そこで，11-00の新機能は使用しないで，09-87以前との互換性を重視するシステム向けに，「V9互換モード」を提供しています。V9互換モードでセットアップされたJ2EEサーバでは，09-87相当の動作となり，11-00以降で廃止された機能も一部を除き使用できます。

なお，V9互換モードを使用しないモードは「推奨モード」と表記します。推奨モードでは，11-00の新機能が使用できますが，11-00以降で廃止された機能は使用できません。

2.2　インストール環境によって使用できるモード

アプリケーションサーバでは，インストール環境によって使用できるモードが異なります。インストール環境によって使用できるモードについて，次の表に示します。

表2-1 インストール環境によって使用できるモード

インストール環境

推奨モード

V9互換モード

JDK11を使用する環境

○

○

JDK17を使用する環境

○

×

（凡例）

○：使用できる

×：使用できない

3　V9互換モードの使用方法

V9互換モードを使用するには，次に示す二つの方法があります。

・J2EEサーバの新規作成時にV9互換モードを指定する方法

・アプリケーションサーバ 09-87以前で作成済みの，既存のJ2EEサーバを更新インストールで移行する方法

この章では，これらの使用方法について説明します。

3.1　J2EEサーバの新規作成時にV9互換モードを指定する方法

J2EEサーバの新規作成時にV9互換モードを指定する方法には，次の四つの場合があります。

Smart Composer機能を使用する場合

運用管理ポータルを使用する場合

J2EEサーバのコマンドを使用する場合

開発環境インスタントセットアップ機能を使用する場合

3.1.1　Smart Composer機能を使用する場合

Smart Composer機能を使用して，V9互換モードの論理J2EEサーバを含むシステムを新規作成する場合は，簡易構築定義ファイルの論理J2EEサーバに指定するパラメタで，J2EEサーバの互換モードを設定するパラメタ「manager.j2ee.compat」の値に「V9」を指定してください。

簡易構築定義ファイルでの指定例を次に示します。

（簡易構築定義ファイルでの指定例）

<?xml version="1.0" encoding="UTF-8"?>
<model-definition
xmlns="http://www.cosminexus.com/mngsvr/schema/ModelDefinition-2.5">
  <web-system>
    <name>MyCompatWebSystem</name>
    <tier>
         ：
      <configuration>
        <logical-server-type>j2ee-server</logical-server-type>
        <param>
          <param-name>manager.j2ee.compat</param-name>
          <param-value>V9</param-value>
        </param>
          ：

詳細は，マニュアル「アプリケーションサーバ リファレンス定義編(サーバ定義)」の「4.11.1　J2EEサーバの互換モードを設定するパラメタ」を参照してください。

3.1.2　運用管理ポータルを使用する場合

運用管理ポータルを使用して，V9互換モードの論理J2EEサーバを新規作成する場合は，［運用管理ドメインの構成定義］の［J2EEサーバの追加］画面で，［互換モード］に「V9互換モード」を指定してください。

［運用管理ドメインの構成定義］の［J2EEサーバの追加］画面を次に示します。

詳細は，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」の「9.9.1　J2EEサーバの追加」を参照してください。

3.1.3　J2EEサーバのコマンドを使用する場合

J2EEサーバのセットアップをするcjsetupコマンドを使用して，V9互換モードのJ2EEサーバを新規作成する場合は，cjsetupコマンドのコマンドライン引数に「-compat V9」を指定してください。

cjsetupコマンドの実行例を次に示します。

（cjsetupコマンドの実行例）

cjsetup MyCompatJ2EEServer -compat V9

詳細は，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「2.2　J2EEサーバを操作するコマンド」の「cjsetup（J2EEサーバのセットアップとアンセットアップ）」を参照してください。

3.1.4　開発環境インスタントセットアップ機能を使用する場合

uCosminexus DeveloperまたはuCosminexus Service Architectの開発環境インスタントセットアップ機能を使用して，V9互換モードのJ2EEサーバを用いた開発環境をセットアップする場合は，次の手順でV9互換モードを指定してください。

［セットアップの種類の選択］ページで「カスタム」を選択し，［次へ］をクリックします。

［デバッグ環境の選択］ページが表示されます。

［デバッグ環境の選択］ページで［J2EEサーバモードの選択］の「V9互換モード」を選択し，［次へ］をクリックします。

以降の手順は，推奨モードの場合と同じです。詳細は，マニュアル「アプリケーションサーバ アプリケーション開発ガイド」の「2.3.5　デバッグ環境のカスタムセットアップ」を参照してください。

3.2　既存のJ2EEサーバを更新インストールで移行する方法

09-87以前にJ2EEサーバがセットアップ済みの状態から，11-00以降に更新インストールをした場合，セットアップ済みの既存のJ2EEサーバは自動的にV9互換モードとなります。

更新インストールによる旧バージョンからの移行作業については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「10.2.2　更新インストールの場合」を参照してください。

3.3　J2EEサーバの互換モードを確認する方法

セットアップ済みのJ2EEサーバがどのモードで動作しているかは，J2EEサーバの起動時にメッセージログに出力されるメッセージKDJE60001-Iで確認できます。推奨モードの場合とV9互換モードの場合のメッセージKDJE60001-Iを次に示します。

推奨モードの場合

KDJE60001-I
The J2EE server will start as 'Java EE Container Mode'. (container version = V11)

V9互換モードの場合

KDJE60001-I
The J2EE server will start as 'Java EE Container Mode'. (container version = V9)

3.4　使用上の注意事項

セットアップ済みのJ2EEサーバに対して，推奨モードからV9互換モードへの切り替えや，V9互換モードから推奨モードへの切り替えはできません。J2EEサーバをアンセットアップしてから再度セットアップしてください。

Smart Composer機能や運用管理ポータルを用いて構築したシステムから論理J2EEサーバだけを削除し，実サーバ名が同一でモードが異なる論理J2EEサーバを作成する場合は，論理J2EEサーバを作成する前にcjsetupコマンドを使用して，J2EEサーバをアンセットアップしてください。

cjsetupコマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「2.2　J2EEサーバを操作するコマンド」の「cjsetup（J2EEサーバのセットアップとアンセットアップ）」を参照してください。

4　V9互換モードと推奨モードの機能

V9互換モードと推奨モードの機能について説明します。

4.1　V9互換モードと推奨モードの機能差異

アプリケーションサーバ 11-00以降で，V9互換モードだけで使用できる互換機能と，推奨モードだけで使用できる新機能を次に示します。ここに記載していない機能は，V9互換モードと推奨モードの両方で使用できます。

表4‒1　各機能のモードごとの使用可否

機能名

推奨モード

V9互換モード

記載個所

NIO HTTPサーバ機能

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「7.　NIO HTTPサーバ」

Webサーバ連携機能（リダイレクタ機能）

×

〇

このマニュアルの「5.　Webサーバ連携」

インプロセスHTTPサーバ機能

×

〇

このマニュアルの「6.　インプロセスHTTPサーバ」

Servlet 3.0非同期サーブレット機能

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「8.　サーブレットおよびJSPの実装」

Servlet 3.1/Servlet 4.0

〇

×

WebSocket 1.1

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「5.　WebSocket」

Java Batch 1.0

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「11.　Java Batch」

Concurrency Utilities for Java EE 1.0

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「14.　Concurrency Utilities」

JSON-P 1.1

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「12.　JSON-P」

JSON-B 1.0

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「13.　JSON-B」

CDI 2.0

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「9.　アプリケーションサーバでのCDIの利用」

Bean Validation 2.0

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「10.　アプリケーションサーバでのBean Validationの利用」

JSF 2.3

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「3.　JSFおよびJSTLの利用」

JAX-RS 2.1

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「4.　JAX-RS 2.1の利用」

Cosminexus JAX-RSエンジン（JAX-RS 1.1）

×

〇

このマニュアルの「7.　Cosminexus JAX-RSエンジン（JAX-RS 1.1）」

JPA 2.2対応プロバイダ

〇

×

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「6.　JPA 2.2の利用」

JPA 1.0対応プロバイダ（CJPAプロバイダ機能）

×

〇

このマニュアルの「8.　CJPAプロバイダ」

HTTPレスポンス圧縮機能

×

〇

このマニュアルの「9.2　HTTPレスポンス圧縮機能」

EJB 2.1とServlet 2.4でのアノテーションの利用

△

△

このマニュアルの「18.　基本・開発機能の互換機能（EJB 2.1とServlet 2.4でのアノテーションの利用）」

クラスタコネクションプール機能

△

△

このマニュアルの「19.　クラスタコネクションプール機能を使用するための設定」

スレッドの非同期並行処理

△

△

このマニュアルの「20.　スレッドの非同期並行処理」

（凡例）

○：使用できます。

△：使用できますが，互換機能のため推奨しません。

×：使用できません。

5　Webサーバ連携

この章では，Webサーバ連携に関する機能について説明します。

5.1　この章の構成

アプリケーションサーバでは，Webサーバと連携するためのリダイレクタの機能を提供しています。リダイレクタとは，Webコンテナで提供しているライブラリです。リダイレクタをWebサーバに登録することで，WebサーバあてのHTTPリクエストのうち特定のリクエストを，指定したWebコンテナに処理させたり，複数のWebコンテナにリクエストを振り分けて処理させたりできるようになります。

Webサーバ連携に関する機能と参照先を次の表に示します。

表5‒1　Webサーバ連携に関する機能と参照先

機能

参照先

Webサーバ（リダイレクタ）によるリクエストの振り分け

5.2

URLパターンでのリクエストの振り分け

5.3

ラウンドロビン方式によるリクエストの振り分け

5.4

POSTデータサイズでのリクエストの振り分け

5.5

通信タイムアウト（Webサーバ連携）

5.6

IPアドレス指定（Webサーバ連携）

5.7

エラーページのカスタマイズ（Webサーバ連携）※

5.8

ドメイン名指定でのトップページの表示

5.9

Webコンテナへのゲートウェイ情報の通知

5.10

Webコンテナ単位での同時実行スレッド数の制御

5.11

リダイレクタとの通信用オブジェクト

5.12

Explicitヒープのチューニング

5.13

注※

WebサーバとしてHTTP Serverを使用する場合だけ使用できる機能です。Microsoft IISを使用する場合，この機能は使用できません。

また，Webサーバと連携した場合，HTTP ServerのSSLによる認証やデータ暗号化，およびMicrosoft IISのSSLによる認証やデータ暗号化の機能も使用できます。HTTP ServerのSSLによる認証やデータ暗号化については，マニュアル「アプリケーションサーバ機能解説 セキュリティ管理機能編」の「7.2.2　HTTP ServerのSSLの設定」を参照してください。Microsoft IISのSSLの設定方法については，Microsoft IISのSSLのヘルプを参照してください。なお，この機能が使用できるのはWebリダイレクタ環境でだけです。

Webサーバと連携する場合に必要な環境設定

Webサーバと連携する場合，次に示す環境設定が必要です。

Smart Composerを使用する場合

「付録D　HTTP Serverの設定に関する注意事項」を参照して，HTTP Serverの環境設定をしてください。

Smart Composerを使用しない場合

次のどちらかのWebサーバの環境を設定してください。

HTTP Server（付録D）

Microsoft IIS（付録E）

5.2　Webサーバ（リダイレクタ）によるリクエストの振り分け

この節では，リダイレクタを使用したリクエストの振り分けについて説明します。

この機能は，Webサーバ連携機能を使用する場合に使用できます。リクエストの振り分けをするには，Webサーバ/リダイレクタが動作しているホストに対して，振り分けを定義する必要があります。

この節の構成を次の表に示します。

表5‒2　この節の構成（Webサーバ（リダイレクタ）によるリクエストの振り分け）

分類

タイトル

参照先

解説

リダイレクタを使用したリクエスト振り分けの仕組み

5.2.1

リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用する場合）

5.2.2

リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用しない場合）

5.2.3

注意事項

Webサーバ連携時の注意事項

5.2.4

注　「実装」，「設定」，および「運用」について，この機能固有の説明はありません。

なお，使用するWebサーバの種類によって，必要な定義が異なります。また，Webサーバの種類がHTTP Serverの場合は，使用するシステムの構築支援機能の種類によっても定義が異なります。使用するWebサーバの種類と定義を次の表に示します。

表5‒3　使用するWebサーバの種類と定義

Webサーバの種類

システムの構築支援機能の種類

定義

HTTP Server

Smart Composer機能

簡易構築定義ファイルの定義

workers.propertiesの定義

mod_jk.confの定義

Smart Composer機能以外

workers.propertiesの定義

mod_jk.confの定義

Microsoft IIS

−

workers.propertiesの定義

uriworkermap.propertiesの定義

isapi_redirect.confの定義

（凡例）−：該当しない

インプロセスHTTPサーバを使用する場合のリダイレクトによるリクエストの振り分けについては，「6.7　リダイレクトによるリクエストの振り分け」を参照してください。

5.2.1　リダイレクタを使用したリクエスト振り分けの仕組み

リダイレクタを使用すると，WebサーバあてのHTTPリクエストのうち，特定のリクエストを，指定したWebコンテナに処理させたり，複数のWebコンテナにリクエストを振り分けて処理させたりできます。

リダイレクタを使用してリクエストを振り分ける場合，ワーカプロセス※というWebサーバの背後で動作するWebコンテナの実行プロセスを使用します。ワーカプロセスは，リダイレクタを経由して，サーブレット，JSPを含むリクエストを処理するプロセスです。Webサーバとワーカプロセスとの間のデータ交換は，TCP/IPに基づき，ユーザが設定する特定のポート番号を通じて実行されます。リダイレクタの設定は，ワーカというWebコンテナを抽象化した設定単位を使用して行います。ワーカには，単体のJ2EEサーバを表すワーカと，クラスタ構成のJ2EEサーバを表すワーカがあります。J2EEサーバへリクエストを転送するワーカを転送先ワーカと呼びます。転送先ワーカはワーカタイプがajp13のワーカです。

注※

ワーカプロセスは，実際には，J2EEサーバとなります。

(1)　リクエストの転送パターン

リダイレクタからワーカプロセスへのリクエストの転送には，次に示すパターンがあります。

一つのWebサーバから一つのワーカプロセスへの転送

一つのWebサーバから複数のワーカプロセスへの転送

なお，Webサーバとワーカプロセスは，同一のマシン上にあっても，異なるマシン上にあってもかまいません。

リダイレクタからワーカプロセスへのリクエスト転送パターンを次の図に示します。

図5‒1　一つのWebサーバから一つのワーカプロセスへの転送

図5‒2　一つのWebサーバから複数のワーカプロセスへの転送

複数のWebコンテナへリクエストを振り分けるには，Webサーバに登録したリダイレクタに，複数のWebコンテナのワーカプロセスを振り分け先として定義します。

(2)　リクエストの振り分け方法

リダイレクタを使用してリクエストを振り分ける方法には，次の3種類があります。

URLパターンによって振り分ける方法

一つのWebコンテナに特定の処理をさせたい場合，および複数のWebコンテナに処理を振り分けたい場合に使用します。

ワーカプロセスが一つの場合と複数の場合に使用できます。

ロードバランサを使用してラウンドロビン方式で振り分ける方法

複数のWebコンテナに処理を振り分けたい場合に使用します。

POSTデータサイズによって振り分ける方法

複数のWebコンテナに処理を振り分けたい場合に使用します。この振り分け方法は，WebサーバにHTTP Serverを使用している場合にだけ設定できます。

なお，次の機能を使用している場合，この振り分け方法は適用できません。

セッションフェイルオーバ機能

ラウンドロビン方式によるリクエストの振り分け

ワーカプロセスを作成するには，ワーカ定義ファイルと呼ばれるファイル（workers.properties）に，次の属性を定義します。

ワーカ名

ワーカのタイプ

ワーカが動作しているホスト名，またはIPアドレス

ワーカが受け付けるポート番号

標準で提供されるworkers.propertiesには，あらかじめ次に示すワーカが定義されています。WebサーバとWebコンテナを同一のホスト上で動作させる場合には，これらのパラメタを変更する必要はありません。

ワーカの属性

パラメタ

ワーカ名

worker1

ワーカのタイプ

ajp13

ホスト名

localhost

ポート番号

8007

ワーカプロセスの定義方法の詳細については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。

5.2.2　リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用する場合）

リクエストを振り分けるためには，次のユーザ定義ファイルをテキストエディタなどで編集して，ワーカ，URLパターンとワーカのマッピング，リダイレクタの動作を設定します。

簡易構築定義ファイル

ワーカの定義，およびワーカごとのパラメタ，URLパターンとワーカのマッピングを設定します。URLパターンでのリクエスト振り分けを設定する場合に使用します。

ラウンドロビン方式によるリクエスト振り分け，およびPOSTデータサイズでのリクエスト振り分けの場合，簡易構築定義ファイルでは設定できません。ラウンドロビン方式によるリスクエスト振り分け，およびPOSTデータサイズでのリクエスト振り分けを設定したワーカを含む環境を運用管理ポータルで構築後，cmx_export_modelコマンドで簡易構築定義ファイルを出力した場合，設定内容として出力される物理ティアの種類はfree-tierとなります。

workers.properties（ワーカ定義ファイル）

ワーカの定義，およびワーカごとのパラメタを設定します。ラウンドロビン方式によるリクエスト振り分け，およびPOSTデータサイズでのリクエスト振り分けを設定する場合に使用します。

mod_jk.conf（リダイレクタ動作定義ファイル）

HTTP ServerへのリクエストでどのURLパターンがWebコンテナへ転送されるかというURLパターンとワーカのマッピング，リダイレクタの動作を設定します。ラウンドロビン方式によるリクエスト振り分け，およびPOSTデータサイズでのリクエスト振り分けを設定する場合に使用します。

簡易構築定義ファイルの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。ワーカ定義ファイルの詳細については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。リダイレクタ動作定義ファイルの詳細については，「13.2.1　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。

5.2.3　リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用しない場合）

リクエストを振り分けるためには，次のユーザ定義ファイルをテキストエディタなどで編集して，ワーカ，URLパターンとワーカのマッピング，リダイレクタの動作を設定します。

設定するファイルは，使用するWebサーバによって異なります。共通のユーザ定義ファイルと，Webサーバごとのユーザ定義ファイルを分けて説明します。なお，ユーザ定義ファイルのうち，httpsd.confの詳細については，マニュアル「HTTP Server」を参照してください。ほかのユーザ定義ファイルの詳細については，「第3編　リファレンス（V9互換モード）」を参照してください。

(1)　共通のユーザ定義ファイル

HTTP Server，Microsoft IISを使用する場合で共通のユーザ定義ファイルを次に示します。

workers.properties（ワーカ定義ファイル）

ワーカの定義，およびワーカごとのパラメタを設定します。

ファイルの格納場所を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥workers.properties

UNIXの場合

/opt/Cosminexus/CC/web/redirector/workers.properties

usrconf.properties（ユーザプロパティファイル）

リダイレクタからのリクエストをWebコンテナで受信するときの通信タイムアウトを設定します。

ファイルの格納場所を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥usrconf.properties

UNIXの場合

/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/usrconf.properties

(2)　HTTP Serverを使用する場合のユーザ定義ファイル

HTTP Serverを使用する場合のユーザ定義ファイルを次に示します。

mod_jk.conf（リダイレクタ動作定義ファイル）

HTTP Serverでのリダイレクタの動作を設定します。

ファイルの格納場所を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥mod_jk.conf

UNIXの場合

/opt/Cosminexus/CC/web/redirector/mod_jk.conf

httpsd.conf（HTTP Server定義ファイル）

HTTP Serverの動作環境を定義するディレクティブ（Webサーバの実行環境を定義するパラメタ）を設定します。

ファイルの格納場所を次に示します。

Windowsの場合

<Application Serverのインストールディレクトリ>¥httpsd¥conf¥httpsd.conf

UNIXの場合

/opt/hitachi/httpsd/conf/httpsd.conf

(3)　Microsoft IISを使用する場合のユーザ定義ファイル

Microsoft IISを使用する場合のユーザ定義ファイルを次に示します。

uriworkermap.properties（マッピング定義ファイル）

Microsoft IISでのURLパターンとワーカのマッピングを設定します。

ファイルの格納場所を次に示します。

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥uriworkermap.properties

isapi_redirect.conf（リダイレクタ動作定義ファイル）

Microsoft IISでのリダイレクタの動作を設定します。

ファイルの格納場所を次に示します。

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.conf

(4)　注意事項

ユーザ定義ファイルに関する注意事項を次に示します。

上書きインストールの場合，ユーザ定義ファイルは上書きされません。

アップグレードインストールの場合のワーカ定義ファイル，およびWebサーバ定義ファイルの処理については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「10.　旧バージョンのアプリケーションサーバからの移行（J2EEサーバモードの場合）」を参照してください。

リダイレクタの定義ファイルの1行の最大文字数は，1,023文字です。この文字数内で定義してください。

次のユーザ定義ファイルで，同じ名称のパラメタが複数指定されている場合は，最初に指定されたパラメタの値を使用して動作します。

isapi_redirect.conf

workers.properties

uriworkermap.properties

5.2.4　Webサーバ連携時の注意事項

Webサーバと連携するときの注意事項について説明します。

(1)　Webコンテナが送受信できるリクエストヘッダおよびレスポンスヘッダの上限値

Webサーバと連携する場合，Webコンテナで送受信できるリクエストヘッダおよびレスポンスヘッダには上限があります。上限はそれぞれ16KBです。16KBを超えるヘッダの送受信はできないので注意してください。

(2)　HTTP Serverを使用するときの注意事項

Webサーバ連携時は，HTTP Serverの仮想ホスト機能を使用できません。

仮想ホストごとに別のリダイレクトを行いたい場合は，運用管理ポータルまたはSmart Composerを使用して，同一ホスト上に複数のHTTP Serverを構築し，それぞれでリダイレクタを設定してください。

(3)　Microsoft IISを使用するときの注意事項

Microsoft IISを使用するときの注意事項を説明します。

Microsoft IISで複数のWebサイトを構築している場合，これらのWebサイトと同時に連携することはできません。複数のWebサイトを構築している場合は，Webサイトごとにリダイレクタの設定をしてください。

Microsoft IIS用リダイレクタでは，Webコンテナに転送するリクエストについては，リクエストURL情報を変更します。変更したリクエストURLはISAPIフィルタ内で使用します。

このため，Microsoft IIS用リダイレクタ以降に実行されるISAPIフィルタでは，Microsoft IISが最初に受信したリクエストURLを取得できません。Microsoft IISが受信したリクエストURLをISAPIフィルタで取得したい場合は，ISAPIフィルタの優先順位をMicrosoft IIS用リダイレクタよりも高く設定する必要があります。なお，優先順位を調整するために，Microsoft IIS用リダイレクタの優先順位を「中」または「低」に変更する必要がある場合は，Microsoft IIS用リダイレクタ動作定義ファイルのfilter_priorityキーで指定します。filter_priorityキーについては，「13.2.1　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。

Microsoft IISと連携する場合，次のHTTPリクエストヘッダはWebクライアントで指定していても，Webアプリケーションでは受信できません。

tomcaturl

tomcatquery

tomcatworker

tomcattranslate

これらのHTTPリクエストヘッダはリダイレクタで使用されます。

Microsoft IISと連携する場合，POSTデータサイズによるリクエストの振り分けは設定できません。

5.3　URLパターンでのリクエストの振り分け

この節では，URLパターンでのリクエストの振り分けについて説明します。

HTTPリクエストに含まれるURLパターンによって，リクエストを振り分けます。これによって，特定の処理だけをWebコンテナに実行させたり，複数のWebコンテナに処理内容に応じて処理を振り分けたりできます。

この節の構成を次の表に示します。

表5‒4　この節の構成（URLパターンでのリクエストの振り分け）

分類

タイトル

参照先

解説

URLパターンでのリクエストの振り分けの概要

5.3.1

URLパターンの種類と適用されるパターンの優先順位

5.3.2

設定

実行環境での設定（Smart Composer機能を使用する場合）

5.3.3

実行環境での設定（Smart Composer機能を使用しない場合）

5.3.4

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

5.3.1　URLパターンでのリクエストの振り分けの概要

Webコンテナに転送するリクエストは，URLパターンとワーカプロセスのマッピングによって定義します。リダイレクタは設定されたURLパターンに従って，リクエストを転送するWebコンテナを切り替えます。

例えば，「『/examples/』というURLを含むHTTPリクエストをWebコンテナで処理する」という定義や，「『/examples1/』というURLを含むHTTPリクエストはWebコンテナAで，『/examples2/』というURLを含むHTTPリクエストはWebコンテナBで処理する」などの定義ができます。

リダイレクタによるリクエストの振り分けの例を，次の図に示します。

図5‒3　リダイレクタによるリクエストの振り分け（特定のリクエストをWebコンテナに転送する場合）

図5‒4　リダイレクタによるリクエストの振り分け（リクエストを複数のWebコンテナに振り分けて転送する場合）

5.3.2　URLパターンの種類と適用されるパターンの優先順位

リダイレクタのURLマッピングで指定できるURLパターンの種類，および適用されるパターンの優先順位について説明します。

(1)　URLパターンの種類

リダイレクタのURLマッピングには次の4種類のURLパターンを指定できます。

完全パス指定

完全に一致するパターンです。

URLの形式：

/<パス>

ルートだけ指定する場合は，「/」。

/<パス>に指定できる文字：

次の文字を使用した，1文字以上の文字列を指定します。

半角英数字，「/」，「*」，「-」，「.」，「_」，「~」，「!」，「$」，「&」，「'」，「(」，「)」，「+」，「,」，「=」，「:」，「@」

例：

URLパターンが"/examples/jsp/index.jsp"で，URLが"/examples/jsp/index.jsp"の場合，一致となります。

パス指定

パスが一致するパターンです。

URLの形式：

/<パス>/*

すべてのリクエストを対象にする場合の形式は，「/*」。

/<パス>に指定できる文字：

次の文字を使用した，1文字以上の文字列を指定します。

半角英数字，「/」，「*」，「-」，「.」，「_」，「~」，「!」，「$」，「&」，「'」，「(」，「)」，「+」，「,」，「=」，「:」，「@」

例：

URLパターンが"/examples/*"で，URLが"/examples/jsp/index.jsp"などの場合，一致となります。

拡張子指定

拡張子が一致するパターンです。指定されたパス以下のすべての階層に適用されます。

URLの形式：

/<パス>/*.<拡張子>

すべてのパスを対象にする場合の形式は，「/*.<拡張子>」。

<パス>，および<拡張子>に指定できる文字：

次の文字を使用した，1文字以上の文字列を指定します。

半角英数字，「/」，「*」，「-」，「.」，「_」，「~」，「!」，「$」，「&」，「'」，「(」，「)」，「+」，「,」，「=」，「:」，「@」

例：

URLパターンが"/examples/*.jsp"で，URLが"/examples/jsp/index.jsp"などの場合，一致となります。

サフィックス指定

サフィックスが一致するパターンです。指定されたパス以下のすべての階層に適用されます。

URLの形式：

/<パス>/*<サフィックス>

すべてのパスを対象にする場合の形式は，「/*<サフィックス>」。

<パス>，および<サフィックス>に指定できる文字：

次の文字を使用した，1文字以上の文字列を指定します。

半角英数字，「/」，「*」，「-」，「.」，「_」，「~」，「!」，「$」，「&」，「'」，「(」，「)」，「+」，「,」，「=」，「:」，「@」

例：

URLパターンが"/examples/servlet/*Servlet"で，URLが"/examples/servlet/HelloServlet"などの場合，一致となります。

注意事項

URLパターンの指定に関する注意事項を次に示します。

URLパターンの先頭に「/」以外を指定しないでください。URLパターンの先頭に「/」以外を指定した場合，WindowsではKDJE41012-Eが出力され，そのマッピングは無視されます。それ以外のOSでは，メッセージが出力されて，HTTP Serverの開始に失敗します。

「*」をワイルドカードとして使用する場合，URLパターンの「/*」より前には指定できません。URLパターン内で最初の「*」の直前の文字が「/」ではない場合，そのURLパターンは「完全パス指定」として扱われます。その場合，URL内に「/*」となる個所があっても，ワイルドカードとして扱われません。

同じURLパターンのマッピングを複数記述しないでください。複数記述した場合，次のような動作となります。

「完全パス指定」，および「パス指定」の場合，先に書いたURLパターンのマッピングが有効となります。「拡張子指定」，または「サフィックス指定」の場合は，あとに書いたものが有効となります。

<パス>，<拡張子>，<サフィックス>には，指定できる文字以外の文字を使用しないでください。指定できる文字以外の文字がURLパターンに含まれる場合，文字の種類によってはWebコンテナに転送されないことがあります。

<拡張子>または<サフィックス>の文字列の長さは1文字以上で指定してください。1文字以上でない場合，「拡張子指定」ではKDJE41041-Wが出力され，そのマッピングは無視されます。「サフィックス指定」では，「パス指定」のURLパターンとして扱われます。

(2)　適用されるURLパターンの優先順位

四つのURLパターンへのマッピングのうち，最優先されるURLパターンは，「完全パス指定」です。「完全パス指定」に一致しない場合，次に示す順序でパスの一致が判定され，適用されるURLパターンが決定します。

「完全パス指定」に一致しない場合

「パス指定」「拡張子指定」「サフィックス指定」のうち，最長一致のものが適用されます。最長一致とは，先頭(「/」)から「*」の上位パスまでができるだけ長いものに一致することを示します。

次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/* worker1

/examples/jsp/* worker2

この場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用され，URLが"/examples/test/index.jsp"の場合にはworker1のマッピングが適用されます。

1.の条件に加えて，最長一致する「パス指定」「拡張子指定」「サフィックス指定」が複数存在する場合

「パス指定」より，「拡張子指定」または「サフィックス指定」が優先されます。

次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/jsp/* worker1

/examples/jsp/*.jsp worker2

この場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用され，URLが"/examples/jsp/test.html"の場合にはworker1のマッピングが適用されます。

1.および2.の条件に加えて，最長一致する「拡張子指定」「サフィックス指定」が複数存在する場合

あとに指定したURLパターンが優先されます。

次のように二つのマッピングが定義されている場合を例に，説明します。

マッピング定義：

/examples/*.jsp worker1

/examples/*jsp worker2

この順番に指定されていた場合，URLが"/examples/jsp/index.jsp"の場合にはworker2のマッピングが適用されます。

注意事項

適用されるパターンの優先順位の判定に関する注意事項を次に示します。

リクエストURLにクエリ（URLの「?」以降の文字列）がある場合，その部分はURLパターンとの比較には使用されません。

例：

リクエストURLが"/examples/jsp/index.jsp?query=foo"の場合，比較に使用されるURLは"/examples/jsp/index.jsp"となります。

リクエストURLにパスパラメタ（URLの「;」以降の文字列）がある場合，その部分はURLパターンとの比較には使用されません。

例：

リクエストURLが"/examples/jsp/index.jsp;jsessionid=0000"の場合，比較に使用されるURLは"/examples/jsp/index.jsp"となります。

リクエストURLはパスの正規化をしてから，URLパターンとの一致が判定されます。

例：

リクエストURLが"/examples/../examples/./jsp//index.jsp"の場合，比較に使用されるURLは"/examples/jsp/index.jsp"となります。

URLパターンの正規化はしません。そのため，「./」，「../」などを含むURLパターンを定義しても，リクエストと一致することはありません。

Windowsの場合，「拡張子指定」のURLパターンの拡張子について，大文字小文字は区別されないで判定されます。

5.3.3　実行環境での設定（Smart Composer機能を使用する場合）

HTTPリクエストに含まれるURLパターンによってリクエストを振り分けることで，特定の処理だけをWebコンテナに実行させたり，複数のWebコンテナに処理内容に応じて振り分けたりできます。なお，URLパターンによる振り分けは，原則としてWebアプリケーション単位で振り分けます。URLパターンは，リダイレクタの動作として定義します。

(1)　設定の手順

URLパターンによるリクエストの振り分けは，次の手順で設定します。

簡易構築定義ファイルで，ワーカ，およびURLパターンとワーカのマッピングを定義します。

ワーカ名のリスト，ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名などを設定します。

また，すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

Webサーバの環境を設定して，Webサーバを再起動します。

Webサーバの設定については，「付録D　HTTP Serverの設定に関する注意事項」を参照してください。

(2)　簡易構築定義ファイルでの設定

URLパターンによるリクエストの振り分けの定義は，簡易構築定義ファイルで，論理Webサーバ（web-server）の<configuration>タグ内に定義します。

簡易構築定義ファイルでのURLパターンによるリクエストの振り分けの定義について次の表に示します。

表5‒5　簡易構築定義ファイルでのURLパターンによるリクエストの振り分けの定義

分類

パラメタ

説明

ワーカの定義

worker.list

一つまたは複数のワーカ名のリストを指定します。

worker.<ワーカ名>.host

ワーカのホスト名，またはIPアドレスを指定します。

worker.<ワーカ名>.port

ワーカのポート番号を指定します。

worker.<ワーカ名>.type

ワーカのタイプ（ajp13，lbまたはpost_size_lb）を指定します。

worker.<ワーカ名>.cachesize

リダイレクタで再利用するワーカのコネクション数を指定します。

Windowsの場合にだけ指定できます。

worker.<ワーカ名>.receive_timeout

通信タイムアウト値を指定します。

worker.<ワーカ名>.delegate_error_code

エラーページの作成をWebサーバに委任する場合に利用するエラーステータスコードを指定します。

URLパターンとワーカのマッピングの定義

JkMount

URLパターンと，worker.listで指定されているワーカのどれかとの組み合わせを指定します。

注　<ワーカ名>には，worker.listパラメタで指定したワーカの名称を定義します。

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(3)　設定例

URLパターンでのリクエスト振り分けの例を次の図に示します。

図5‒5　URLパターンでのリクエスト振り分けの例

この例では，ホストAにはWebアプリケーション「app1」，ホストBにはWebアプリケーション「app2」がそれぞれデプロイされています。処理したいWebアプリケーション名をリクエストのURLパターンに含めることで，「/app1/*」というURLパターンを持つリクエストはホストAで，「/app2/*」というURLパターンを持つリクエストはホストBで処理できるようにします。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。

簡易構築定義ファイルの例を次に示します。ここでは，複数のWebコンテナへリクエストを振り分けるので，Webサーバに登録したリダイレクタに，複数のWebコンテナのワーカを振り分け先として指定します。また，「/app1/*」というURLパターンと「worker1」，「/app2/*」というURLパターンと「worker2」とをマッピングします。

なお，この構成を実現するためには，複数のWebシステムに分割して構築する必要があります。

簡易構築定義ファイルの例

：
<param>
  <param-name>JkMount</param-name>
  <param-value>/app1/* worker1</param-value>
  <param-value>/app2/* worker2</param-value>
</param>
<param>
  <param-name>worker.list</param-name>
  <param-value>worker1,worker2</param-value>
</param>
<param>
  <param-name>worker.worker1.port</param-name>
  <param-value>8007</param-value>
</param>
<param>
  <param-name>worker.worker1.host</param-name>
  <param-value>hostA</param-value>
</param>
<param>
  <param-name>worker.worker1.type</param-name>
  <param-value>ajp13</param-value>
</param>
<param>
  <param-name>worker.worker1.cachesize</param-name>
  <param-value>64</param-value>
</param>
<param>
  <param-name>worker.worker2.port</param-name>
  <param-value>8007</param-value>
</param>
<param>
  <param-name>worker.worker2.host</param-name>
  <param-value>hostB</param-value>
</param>
<param>
  <param-name>worker.worker2.type</param-name>
  <param-value>ajp13</param-value>
</param>
<param>
  <param-name>worker.worker2.cachesize</param-name>
  <param-value>64</param-value>
</param>
：

5.3.4　実行環境での設定（Smart Composer機能を使用しない場合）

HTTPリクエストに含まれるURLパターンによってリクエストを振り分けることで，特定の処理だけをWebコンテナに実行させたり，複数のWebコンテナに処理内容に応じて振り分けたりできます。なお，URLパターンによる振り分けは，原則としてWebアプリケーション単位で振り分けます。URLパターンは，リダイレクタの動作として定義します。

(1)　設定の手順

URLパターンによるリクエストの振り分けは，次の手順で設定します。

workers.propertiesでワーカを定義します。

ワーカ名のリスト，ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

workers.properties（ワーカ定義ファイル）については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。

HTTP Serverを使用する場合は，mod_jk.confでURLパターンとワーカのマッピングを定義します。Microsoft IISを使用する場合は，uriworkermap.propertiesでURLパターンとワーカのマッピングを定義します。

すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）については，「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）については，「13.2.3　uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）」を参照してください。

Webサーバの環境を設定して，Webサーバを再起動します。

Webサーバの設定については，「付録D　HTTP Serverの設定に関する注意事項」，または「付録E　Microsoft IISの設定」を参照してください。

(2)　設定例

URLパターンでのリクエスト振り分けの例を次の図に示します。

図5‒6　URLパターンでのリクエスト振り分けの例

この例では，ホストAにはWebアプリケーション「app1」，ホストBにはWebアプリケーション「app2」がそれぞれデプロイされています。処理したいWebアプリケーション名をリクエストのURLパターンに含めることで，「/app1/*」というURLパターンを持つリクエストはホストAで，「/app2/*」というURLパターンを持つリクエストはホストBで処理できるようにします。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。

workers.propertiesの例を次に示します。ここでは，複数のWebコンテナへリクエストを振り分けるので，Webサーバに登録したリダイレクタに，複数のWebコンテナのワーカを振り分け先として指定します。

workers.propertiesの例（Windowsの場合）

worker.list=worker1,worker2

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64

workers.propertiesの例（UNIXの場合）

worker.list=worker1,worker2

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13

mod_jk.confおよびuriworkermap.propertiesの例を次に示します。ここでは，「/app1/*」というURLパターンと「worker1」，「/app2/*」というURLパターンと「worker2」とをマッピングします。

mod_jk.confの例（HTTP Serverの場合）

JkMount /app1/* worker1
JkMount /app2/* worker2

uriworkermap.propertiesの例（Microsoft IISの場合）

/app1/*=worker1
/app2/*=worker2

5.4　ラウンドロビン方式によるリクエストの振り分け

この節では，ラウンドロビン方式によるリクエストの振り分けについて説明します。

この節の構成を次の表に示します。

表5‒6　この節の構成（ラウンドロビン方式によるリクエストの振り分け）

分類

タイトル

参照先

解説

ラウンドロビン方式によるリクエストの振り分けの概要

5.4.1

ラウンドロビン方式によるリクエストの振り分けの例

5.4.2

ラウンドロビン方式によるリクエストの振り分けの定義

5.4.3

設定

実行環境での設定（Smart Composer機能を使用する場合）

5.4.4

実行環境での設定（Smart Composer機能を使用しない場合）

5.4.5

注意事項

ラウンドロビン方式によるリクエストの振り分けに関する注意事項

5.4.6

注　「実装」および「運用」について，この機能固有の説明はありません。

Webコンテナがクラスタ構成で配置されている場合，リダイレクタを使用して，ラウンドロビン方式でそれぞれのWebコンテナにリクエストを振り分けられます。リダイレクタは，各リクエストに付けられたセッションIDを参照することで，同一のWebクライアントから来たリクエストが常に同一のWebコンテナへ転送されるように，リクエストを振り分けます。ただし，セッションのクッキー名をデフォルトの「JSESSIONID」からほかの名称に変更した場合，同一のWebクライアントから来たリクエストを同一のWebコンテナに転送する動作は保証されません。

また，振り分け先のWebコンテナの処理性能が異なる場合などには，負荷パラメタを定義することで，ホストごとの負荷の割合を調整することもできます。この方式でリクエストを振り分ける場合は，振り分け処理をする各Webコンテナに，それぞれ同じWebアプリケーションがデプロイされていることが前提になります。

5.4.1　ラウンドロビン方式によるリクエストの振り分けの概要

クラスタ構成でのラウンドロビン方式によるリクエスト振り分けには，ロードバランサというワーカ定義を使用します。ロードバランサには，振り分け先となるワーカプロセスのリストが定義されています。この定義を基に，ワーカプロセスに対するラウンドロビン方式の振り分けが実行されます。

振り分けはHTTPリクエスト単位で実行されます。ただし，同じセッションに属するHTTPリクエストは，前回の振り分け先と同じワーカに振り分けられます。

参考

Webサーバ連携時に，リダイレクタの設定でラウンドロビン方式によるリクエストの振り分けを指定すると，HttpSessionのセッションIDにワーカ名が付加されます。また，サーバIDを付加するかどうかの設定に関係なく，HttpSessionのセッションIDにサーバIDは付加されません。

5.4.2　ラウンドロビン方式によるリクエストの振り分けの例

ロードバランサを使用したリクエストの振り分けの例を次の図に示します。

図5‒7　ロードバランサを使用したリクエストの振り分けの例

5.4.3　ラウンドロビン方式によるリクエストの振り分けの定義

標準で提供されるworkers.propertiesには，あらかじめ次に示すロードバランサが定義されています。

#worker.list=loadbalancer1

#worker.loadbalancer1.type=lb
#worker.loadbalancer1.balanced_workers=worker1,worker2

worker.loadbalancer1.typeでは，ワーカのタイプを設定します。worker.loadbalancer1.balanced_workersでは，振り分け対象となるワーカプロセス名を設定します。workers.propertiesには，loadbalancer1として，それぞれ「lb」と「worker1，worker2」が定義されています。

ただし，この定義はコメントとして記述されています。このため，上記のロードバランサを利用する場合は，workers.propertiesの該当する行の先頭の「#」を削除してください。

リクエスト振り分けの比率は，振り分け対象となる各ワーカ定義のlbfactorパラメタに定義できます。lbfactorが大きければ大きいほどそのワーカプロセスに転送されるリクエストの割合は大きくなります。

例えば，worker1とworker2という二つのワーカプロセスでリクエストを振り分ける場合，ワーカ定義のlbfactorパラメタに次に示すように定義されているとします。

worker1のlbfactorパラメタ：2.0

worker2のlbfactorパラメタ：1.0

この場合，worker1はworker2の2倍の数のWebクライアントを担当することになります。

5.4.4　実行環境での設定（Smart Composer機能を使用する場合）

振り分け先となるワーカのリストをロードバランサに定義することで，ラウンドロビン方式でワーカにリクエストを振り分けます。

振り分け先となる各ワーカに負荷分散値を設定して，リクエスト振り分けの比率を定義すると，ホストごとの負荷の割合を調整できます。リダイレクタは，この比率でHTTPリクエスト単位にラウンドロビンでリクエストを振り分けるので，比率が高いワーカほど転送されるリクエストの割合が多くなります。ただし，同じセッションに属するHTTPリクエストは前回と同じワーカに振り分けられます。

(1)　設定の手順

ラウンドロビン方式によるリクエスト振り分けは，次の手順で設定します。

workers.propertiesでロードバランサ，およびワーカを定義します。

ロードバランサの定義

ワーカ名のリスト，ワーカのタイプ（「lb」を設定），負荷分散の対象となるワーカのリストなどを設定します。

各ワーカの定義

ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名，負荷分散値などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

workers.properties（ワーカ定義ファイル）については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。

mod_jk.confでURLパターンとワーカのマッピングを定義します。

すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）については，「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

Webサーバの環境を設定して，Webサーバを再起動します。

Webサーバの設定については，「付録D　HTTP Serverの設定に関する注意事項」を参照してください。

(a)　注意事項

リダイレクタで負荷分散を使用する場合に，あるワーカで障害を検出すると，障害を検出してから60秒間はそのワーカはリダイレクト先ワーカの選択肢から除外されます。そのため，障害が回復しても，最大で60秒間はそのワーカが使用されない場合があります。

UNIXの場合，HTTP Serverのサーバプロセスを負荷に応じて生成・消滅させているときは，workers.propertiesの最初に定義したワーカによって多く割り振られます。また，サーバプロセス数を固定にしても，リクエストがどのサーバプロセスに割り振られるかは不定のため，同じ負荷分散値を指定してもラウンドロビンにならないことがあります。サーバプロセスは，消滅しなければ負荷に応じて増えてもよいため，サーバプロセスが短時間で生成・消滅しないようにディレクティブを指定する必要があります。

HTTP Serverのhttpsd.confのディレクティブが次に示す条件を満たすように，指定してください。

条件

意味

MaxSpareServers ≧ MaxClients

サーバプロセスはMaxClientsまで増加し，処理終了後も常駐します。

MaxRequestsPerChild 10000

HTTPリクエストを10,000回処理後，リフレッシュのためにサーバプロセスを終了させます（10,000は推奨値）。振り分け先のJ2EEサーバ数に対して十分に大きな値を指定します。

StartServers = MaxClients

最初に全サーバプロセスを起動しておく場合に指定します。

(b)　ディレクティブの指定例

StartServers 256
MaxClients 256
MaxSpareServers 256
MaxRequestsPerChild 10000

(2)　workers.propertiesおよびmod_jk.confでの設定

ラウンドロビン方式によるリクエストの振り分けの設定は，workers.propertiesおよびmod_jk.confで定義します。workers.propertiesおよびmod_jk.confで定義するキーを次の表に示します。

表5‒7　workers.propertiesおよびmod_jk.confで定義するキー（ラウンドロビン方式によるリクエストの振り分けの場合）

ファイルの種類

キー名

説明

workers.properties

worker.list

一つまたは複数のワーカ名のリストを指定します。

worker.<ワーカ名>.host

ワーカのホスト名，またはIPアドレスを指定します。

worker.<ワーカ名>.port

ワーカのポート番号を指定します。

worker.<ワーカ名>.type

ワーカのタイプを指定します。ロードバランサには「lb」を，負荷分散の対象となるワーカには「ajp13」を指定します。

worker.<ワーカ名>.balanced_workers

負荷分散の対象となるワーカのリストを指定します。

worker.<ワーカ名>.lbfactor

負荷分散値を指定します。

worker.<ワーカ名>.cachesize

リダイレクタで再利用するワーカのコネクション数を指定します。

Windowsの場合にだけ指定できます。

worker.<ワーカ名>.receive_timeout

通信タイムアウト値を指定します。

worker.<ワーカ名>.delegate_error_code

エラーページの作成をWebサーバに委任する場合に利用するエラーステータスコードを指定します。

mod_jk.conf

JkMount

URLパターンと，worker.listで指定されているワーカのどれかとの組み合わせを指定します。

注　<ワーカ名>には，worker.listキー，またはworker.<ワーカ名>.balanced_workersキーで指定したワーカの名称を定義します。

ワーカの種類ごとに指定できるパラメタを次の表に示します。

表5‒8　ワーカの種類ごとに指定できるキー

キー名

ワーカの種類（worker.<ワーカ名>.typeキーの指定値）

ロードバランサ

（「lb」を指定）

ワーカ

（「ajp13」を指定）

worker.<ワーカ名>.host

×

○

worker.<ワーカ名>.port

×

○

worker.<ワーカ名>.type

○

○

worker.<ワーカ名>.balanced_workers

○

×

worker.<ワーカ名>.lbfactor

×

△

worker.<ワーカ名>.cachesize

×

△

worker.<ワーカ名>.receive_timeout

×

△

worker.<ワーカ名>.delegate_error_code

×

△

（凡例）○：指定できる　×：指定できない　△：任意に指定できる

(3)　設定例

ラウンドロビン方式によるリクエスト振り分けの例を次の図に示します。

図5‒8　ラウンドロビン方式によるリクエスト振り分けの例

この例では，「/examples」以下のリクエストがホストA，ホストBに同じ比率で振り分けます。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。

workers.propertiesの例を次に示します。ここでは，ロードバランサとワーカを定義します。リクエストを同じ比率で振り分けるので，「worker1」と「worker2」の負荷分散値はどちらも「1」を指定します。

workers.propertiesの例（Windowsの場合）

worker.list=loadbalancer1

worker.loadbalancer1.balanced_workers=worker1,worker2
worker.loadbalancer1.type=lb

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64
worker.worker1.lbfactor=1

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64
worker.worker2.lbfactor=1

workers.propertiesの例（UNIXの場合）

worker.list=loadbalancer1

worker.loadbalancer1.balanced_workers=worker1,worker2
worker.loadbalancer1.type=lb

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.lbfactor=1

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.lbfactor=1

mod_jk.confの例を次に示します。ここでは，ロードバランサ名「loadbalancer1」を指定します。

mod_jk.confの例

JkMount /examples/* loadbalancer1

5.4.5　実行環境での設定（Smart Composer機能を使用しない場合）

振り分け先となるワーカのリストをロードバランサに定義することで，ラウンドロビン方式でワーカにリクエストを振り分けます。

振り分け先となる各ワーカに負荷分散値を設定して，リクエスト振り分けの比率を定義すると，ホストごとの負荷の割合を調整できます。リダイレクタは，この比率でHTTPリクエスト単位にラウンドロビンでリクエストを振り分けるので，比率が高いワーカほど転送されるリクエストの割合が多くなります。ただし，同じセッションに属するHTTPリクエストは前回と同じワーカに振り分けられます。

(1)　設定の手順

ラウンドロビン方式によるリクエスト振り分けは，次の手順で設定します。

workers.propertiesでロードバランサ，およびワーカを定義します。

ロードバランサの定義

ワーカ名のリスト，ワーカのタイプ（「lb」を設定），負荷分散の対象となるワーカのリストなどを設定します。

各ワーカの定義

ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名，負荷分散値などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

workers.properties（ワーカ定義ファイル）については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。

HTTP Serverを使用する場合は，mod_jk.confでURLパターンとワーカのマッピングを定義します。Microsoft IISを使用する場合は，uriworkermap.propertiesでURLパターンとワーカのマッピングを定義します。

すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）については「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）については，「13.2.3　uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）」を参照してください。

Webサーバの環境を設定して，Webサーバを再起動します。

Webサーバの設定については，「付録D　HTTP Serverの設定に関する注意事項」，または「付録E　Microsoft IISの設定」を参照してください。

(a)　注意事項

リダイレクタで負荷分散を使用する場合に，あるワーカで障害を検出すると，障害を検出してから60秒間はそのワーカはリダイレクト先ワーカの選択肢から除外されます。そのため，障害が回復しても，最大で60秒間はそのワーカが使用されない場合があります。

Microsoft IISを使用してリダイレクタが動作するワーカプロセスを複数に設定した場合，ワーカを2以上に設定していると，最初のリダイレクト先がworkers.propertiesの最初に定義したワーカに多く割り振られることがあります。

また，リクエストがどのワーカプロセスに割り振られるかはMicrosoft IISの制御によるため，同じ負荷分散値を指定してもラウンドロビンにならないことがあります。

この場合，アプリケーションプールの数を一つにすることで，最初のリダイレクトの割り振り先もラウンドロビンになります。

UNIXの場合，HTTP Serverのサーバプロセスを負荷に応じて生成・消滅させているときは，workers.propertiesの最初に定義したワーカによって多く割り振られます。また，サーバプロセス数を固定にしても，リクエストがどのサーバプロセスに割り振られるかは不定のため，同じ負荷分散値を指定してもラウンドロビンにならないことがあります。サーバプロセスは，消滅しなければ負荷に応じて増えてもよいため，サーバプロセスが短時間で生成・消滅しないようにディレクティブを指定する必要があります。

HTTP Serverのhttpsd.confのディレクティブが次に示す条件を満たすように，指定してください。

条件

意味

MaxSpareServers ≧ MaxClients

サーバプロセスはMaxClientsまで増加し，処理終了後も常駐します。

MaxRequestsPerChild 10000

HTTPリクエストを10,000回処理後，リフレッシュのためにサーバプロセスを終了させます（10,000は推奨値）。振り分け先のJ2EEサーバ数に対して十分に大きな値を指定します。

StartServers = MaxClients

最初に全サーバプロセスを起動しておく場合に指定します。

(b)　ディレクティブの指定例

StartServers 256
MaxClients 256
MaxSpareServers 256
MaxRequestsPerChild 10000

(2)　workers.propertiesおよびmod_jk.confでの設定

workers.propertiesおよびmod_jk.confでの設定については，Smart Composerを使用する場合と同様です。「5.4.4(2)　workers.propertiesおよびmod_jk.confでの設定」を参照してください。

(3)　設定例

ラウンドロビン方式によるリクエスト振り分けの例を次の図に示します。

図5‒9　ラウンドロビン方式によるリクエスト振り分けの例

この例では，「/examples」以下のリクエストがホストA，ホストBに同じ比率で振り分けます。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。

workers.propertiesの例を次に示します。ここでは，ロードバランサとワーカを定義します。リクエストを同じ比率で振り分けるので，「worker1」と「worker2」の負荷分散値はどちらも「1」を指定します。

workers.propertiesの例（Windowsの場合）

worker.list=loadbalancer1

worker.loadbalancer1.balanced_workers=worker1,worker2
worker.loadbalancer1.type=lb

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64
worker.worker1.lbfactor=1

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64
worker.worker2.lbfactor=1

workers.propertiesの例（UNIXの場合）

worker.list=loadbalancer1

worker.loadbalancer1.balanced_workers=worker1,worker2
worker.loadbalancer1.type=lb

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.lbfactor=1

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.lbfactor=1

mod_jk.confおよびuriworkermap.propertiesの例を次に示します。ここでは，ロードバランサ名「loadbalancer1」を指定します。

mod_jk.confの例（HTTP Serverの場合）

JkMount /examples/* loadbalancer1

uriworkermap.propertiesの例（Microsoft IISの場合）

/examples/*=loadbalancer1

5.4.6　ラウンドロビン方式によるリクエストの振り分けに関する注意事項

リダイレクタのラウンドロビン方式によるリクエストの振り分けに関する注意事項を次に示します。

J2EEアプリケーション停止中のWebコンテナへのリクエストの送信

ラウンドロビン方式でリクエストを振り分ける場合，J2EEアプリケーションが停止中であってもWebコンテナへリクエストが送信されます。このため，J2EEアプリケーションの変更は，すべてのWebコンテナをシステムから隔離した状態で実施する必要があります。

負荷分散機によるヘルスチェックの無効

負荷分散機と，ラウンドロビン方式によるリクエストの振り分けを併用した場合，J2EEサーバに障害が発生したときも，リダイレクタで正常なWebコンテナへ転送されます。このため，負荷分散機でJ2EEサーバの障害が検知できなくなり，Webコンテナの監視が行えません。

5.5　POSTデータサイズでのリクエストの振り分け

この節では，POSTデータサイズでのリクエストの振り分けについて説明します。

この節の構成を次の表に示します。

表5‒9　この節の構成（POSTデータサイズでのリクエストの振り分け）

分類

タイトル

参照先

解説

POSTデータサイズでのリクエストの振り分けの概要

5.5.1

POSTデータサイズによるリクエストの振り分けの例

5.5.2

リクエストの振り分け条件

5.5.3

POSTデータサイズによるリクエストの振り分けの定義

5.5.4

設定

実行環境での設定（Smart Composer機能を使用する場合）

5.5.5

実行環境での設定（Smart Composer機能を使用しない場合）

5.5.6

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

5.5.1　POSTデータサイズでのリクエストの振り分けの概要

Webコンテナがクラスタ構成で配置されている場合，リダイレクタを使用して，POSTデータサイズごとにそれぞれのWebコンテナにリクエストを振り分けられます。この機能を使用すると，処理に時間が掛かる長大なPOSTデータのリクエストを，特定のWebコンテナに転送できます。これによって，長大なPOSTデータ以外のリクエストのスループットの低下や，レスポンス時間の低下を防ぐことができます。この方式でリクエストを振り分ける場合は，振り分け処理をする各Webコンテナに，それぞれWebアプリケーションがデプロイされていることが前提になります。ただし，各J2EEサーバにデプロイするWebアプリケーションが同一である必要はありません。

クラスタ構成でのPOSTデータサイズによるリクエストの振り分けには，POSTリクエスト振り分けワーカというワーカ定義を使用します。POSTリクエスト振り分けワーカには，振り分け先となるワーカプロセスのリストが定義されています。この定義を基に，ワーカプロセスに対するPOSTデータサイズの振り分けが実行されます。POSTリクエスト振り分けワーカの振り分け先となるワーカプロセスをPOSTリクエスト転送先ワーカといいます。

POSTリクエスト転送先ワーカへの振り分けは，HTTPリクエスト単位で実行されます。

注意事項

HTTP CookieまたはURL書き換えによる制御でセッションが管理されている場合でも，POSTデータサイズによる振り分けを設定しているときは，POSTデータサイズによって，リクエストの振り分け先が決定されます。このため，同一クライアントからのリクエストの場合でも，HttpSessionのセッションIDは引き継がれません。

例えば，J2EEサーバ1でHttpSessionのセッションIDを生成したあと，J2EEサーバ2へリクエストが転送された場合，J2EEサーバ2で新たにHttpSessionのセッションIDが生成されます。この場合，再度J2EEサーバ1にアクセスすると，クライアントではJ2EEサーバ2で生成されたHttpSessionのセッションIDを使用しているため，J2EEサーバ1で新たにHttpSessionのセッションIDが生成されます。このため，HttpSessionのセッションは引き継がれません。

なお，J2EEサーバ1でHttpSessionのセッションIDを生成したあと，J2EEサーバ2へリクエストが転送されても，J2EEサーバ2でHttpSessionのセッションIDが生成されない場合，再度J2EEサーバ1にアクセスすると，J2EEサーバ1で生成済みのHttpSessionのセッションIDがそのまま使用されます。

5.5.2　POSTデータサイズによるリクエストの振り分けの例

POSTデータサイズでリクエストを振り分ける場合，POSTリクエスト振り分けワーカに転送されるリクエストが限定できるかどうかによって，POSTデータサイズの上限値に設定する値が異なります。

POSTリクエスト振り分けワーカに転送されるリクエストが限定できる場合

ここでは，次の条件を満たすリクエストが，POSTリクエスト振り分けワーカに転送されるものとして説明します。

POSTデータのリクエストである。

リクエストのPOSTデータサイズが200メガバイト未満である。

リクエストが限定できる場合，処理したい長大なPOSTデータの範囲も限定できます。長大なPOSTデータのリクエストを処理するワーカに，特定のPOSTデータサイズのリクエストが転送されるように，それぞれのリクエスト転送先ワーカで上限値を設定します。

リクエストが限定できる場合の，POSTデータサイズによるリクエストの振り分けの例を次の図に示します。

図5‒10　POSTデータサイズによるリクエストの振り分けの例（リクエストが限定できる場合）

この図では，POSTリクエスト転送先ワーカを二つ用意し，POSTデータサイズが100メガバイト以上200メガバイト未満のリクエストがワーカプロセスBに転送されるように，それぞれにPOSTデータサイズの上限値を設定しています。リクエストのPOSTデータサイズが上限値未満の場合に，それぞれのPOSTリクエスト転送先ワーカに振り分けられます。リクエストのPOSTデータサイズが，複数のPOSTリクエスト転送先ワーカに当てはまる場合，POSTデータサイズの上限値が最も小さいPOSTリクエスト転送先ワーカに，リクエストは振り分けられます。例えば，POSTデータサイズが80メガバイトのリクエストの場合は，どちらのワーカにも該当しますが，ワーカプロセスAに振り分けられます。

POSTリクエスト振り分けワーカに転送されるリクエストが限定できない場合

リクエストを限定できない場合，長大なPOSTデータを処理するワーカのPOSTデータサイズの上限値には，最大値を設定します。

リクエストが限定できない場合の，POSTデータサイズによるリクエストの振り分けの例を次の図に示します。

図5‒11　POSTデータサイズによるリクエストの振り分けの例（リクエストが限定できない場合）

この図では，POSTリクエスト転送先ワーカを二つ用意し，それぞれにPOSTデータサイズの上限値を設定しています。長大なPOSTデータのリクエストすべてをワーカプロセスBで処理するように，ワーカプロセスBのPOSTデータサイズの上限値には最大値を設定しています。ワーカプロセスAの上限値以上（100メガバイト以上）のPOSTデータのリクエストは，すべてワーカプロセスBに転送されます。なお，この場合，POSTデータ以外のリクエストや，POSTデータサイズが参照できないリクエストなどが転送されると，リクエスト振り分けワーカで振り分けられないため，リダイレクタによってエラーステータスコード400が返されてエラーとなります。

POSTデータサイズでリクエストを振り分ける場合，リクエストの振り分け条件に満たないリクエストがPOSTリクエスト振り分けワーカに転送されると，リダイレクタによってエラーステータスコード400が返されてエラーとなります。リクエストの振り分け条件については，「5.5.3　リクエストの振り分け条件」を参照してください。

リクエストの振り分け条件に満たないリクエストも処理したい場合は，そのリクエストを転送するワーカプロセスを設定する必要があります。リクエストの振り分け条件に満たないリクエストを転送するワーカプロセスをデフォルトワーカといいます。なお，デフォルトワーカの設定は任意です。

リクエストが限定できない場合に，リクエストの振り分け条件に満たないリクエストをデフォルトワーカに転送する例を次の図に示します。

図5‒12　POSTデータサイズによるリクエストの振り分けの例（デフォルトワーカを設定した場合）

この図では，リクエストの振り分け条件に満たないリクエストを，デフォルトワーカのワーカプロセスAに転送するように設定しています。

5.5.3　リクエストの振り分け条件

POSTリクエスト転送先ワーカに振り分けられるリクエストは，次の条件を満たしている必要があります。

POSTリクエスト転送先ワーカに振り分けられるリクエストの条件

リクエストのメソッドがPOSTであること。

リクエストにContent-Lengthヘッダがある（ボディデータがチャンク形式でない）こと。

リクエストのContent-Lengthヘッダの値が，ワーカに設定しているPOSTデータサイズ未満であること。

どれか一つでも条件を満たさないリクエストは，デフォルトワーカに振り分けられます。デフォルトワーカが設定されていない場合は，エラーとなり，エラーステータスコード400のエラーが返されます。

5.5.4　POSTデータサイズによるリクエストの振り分けの定義

標準で提供されるworkers.propertiesには，あらかじめ次に示すPOSTリクエスト割り分けワーカが定義されています。

#worker.list=postsizelb1
#worker.postsizelb1.type=post_size_lb
#worker.postsizelb1.post_size_workers=worker1,worker2
#worker.postsizelb1.default_worker=worker1

worker.postsizelb1.typeでは，ワーカのタイプを設定します。worker.postsizelb1.post_size_workersでは，振り分け対象となるPOSTリクエスト転送先ワーカのワーカプロセス名を設定します。worker.postsizelb1.default_workerでは，デフォルトワーカを設定します。workers.propertiesには，postsizelb1として，ワーカのタイプに「post_size_lb」，POSTリクエスト転送先ワーカに「worker1，worker2」，デフォルトワーカに「worker1」が定義されています。

ただし，この定義はコメントとして記述されています。このため，この定義のPOSTリクエスト割り分けワーカを利用する場合は，workers.propertiesの該当する行の先頭の「#」を削除してください。

リクエストを振り分けるPOSTデータサイズは，workers.propertiesのワーカ定義のpost_dataパラメタで設定します。

例えば，標準提供のpostsizelb1の定義を利用して，worker1とworker2という二つのPOSTリクエスト転送先ワーカに，それぞれ次のようにPOSTデータサイズを定義しているとします。

worker1のpost_dataパラメタ：100m

worker2のpost_dataパラメタ：200m

この場合，worker1には100メガバイト未満のリクエストが，worker2には100メガバイト以上200メガバイト未満のリクエストが振り分けられます。リクエスト振り分けワーカが，200メガバイト以上のリクエストを振り分けた場合，そのリクエストはデフォルトワーカに設定されているworker1に転送されます。

5.5.5　実行環境での設定（Smart Composer機能を使用する場合）

振り分け先となるワーカのリストをPOSTリクエスト振り分けワーカに定義することで，POSTデータサイズでワーカにリクエストを振り分けます。

振り分け先となるPOSTリクエスト転送先ワーカに，POSTデータサイズの上限値を設定して，リクエスト振り分け先を定義します。これによって，特定のホストに，処理に時間が掛かる長大なPOSTデータサイズのリクエストの処理を振り分けられます。リダイレクタは，HTTPリクエスト単位にPOSTデータサイズの上限値で振り分けるので，長大なPOSTデータ以外のリクエストのスループットの低下や，レスポンス時間の低下を防ぐことができます。なお，POSTデータサイズの上限値が設定されている場合は，同じセッションに属するHTTPリクエストであっても，POSTデータサイズの値が優先されます。

(1)　設定の手順

POSTデータサイズでのリクエスト振り分けは，次の手順で設定します。

workers.propertiesでPOSTリクエスト振り分けワーカ，およびPOSTリクエスト転送先ワーカを定義します。

POSTリクエスト振り分けワーカの定義

ワーカ名のリスト，ワーカのタイプ（「post_size_lb」を設定），POSTデータサイズによる振り分けの対象となるワーカのリストなどを設定します。必要に応じて，デフォルトワーカも設定します。

各POSTリクエスト転送先ワーカの定義

ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名，POSTデータサイズの上限値などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

workers.properties（ワーカ定義ファイル）については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。

mod_jk.confでURLパターンとワーカのマッピングを定義します。

すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）については，「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

Webサーバの環境を設定して，Webサーバを再起動します。

Webサーバの設定については，「付録D　HTTP Serverの設定に関する注意事項」を参照してください。

(2)　workers.propertiesおよびmod_jk.confでの設定

POSTデータサイズでのリクエストの振り分けの設定は，workers.propertiesおよびmod_jk.confで定義します。workers.propertiesおよびmod_jk.confで定義するキーを次の表に示します。

表5‒10　workers.propertiesおよびmod_jk.confで定義するキー（POSTデータサイズでのリクエストの振り分けの場合）

ファイルの種類

キー名

説明

workers.properties

worker.list

一つまたは複数のワーカ名のリストを指定します。

worker.<ワーカ名>.host

ワーカのホスト名，またはIPアドレスを指定します。

worker.<ワーカ名>.port

ワーカのポート番号を指定します。

worker.<ワーカ名>.type

ワーカのタイプを指定します。POSTリクエスト振り分けワーカには「post_size_lb」を，振り分け対象となるPOSTリクエスト転送先ワーカには「ajp13」を指定します。

worker.<ワーカ名>.post_size_workers

POSTデータサイズによる振り分けの対象となるワーカのリストを指定します。

worker.<ワーカ名>.post_data

リクエストのPOSTデータサイズの上限値（バイト単位）を指定します。

worker.<ワーカ名>.default_worker

リクエストの振り分け先に該当するワーカが，クラスタ構成内のPOSTリクエスト転送先ワーカにない場合に，リクエストを転送するワーカ（デフォルトワーカ）を指定します。

worker.<ワーカ名>.cachesize

リダイレクタで再利用するワーカのコネクション数を指定します。

Windowsの場合にだけ指定できます。

worker.<ワーカ名>.receive_timeout

通信タイムアウト値を指定します。

worker.<ワーカ名>.delegate_error_code

エラーページの作成をWebサーバに委任する場合に利用するエラーステータスコードを指定します。

mod_jk.conf

JkMount

URLパターンと，worker.listで指定されているワーカのどれかとの組み合わせを指定します。

注　<ワーカ名>には，worker.listキー，またはworker.<ワーカ名>.post_size_workersキーで指定したワーカの名称を定義します。

ワーカの種類ごとに指定できるキーを次の表に示します。

表5‒11　ワーカの種類ごとに指定できるキー

キー名

ワーカの種類（worker.<ワーカ名>.typeキーの指定値）

POSTリクエスト振り分けワーカ

（「post_size_lb」を指定）

POSTリクエスト転送先ワーカ

（「ajp13」を指定）

worker.<ワーカ名>.host

×

○

worker.<ワーカ名>.port

×

○

worker.<ワーカ名>.type

○

○

worker.<ワーカ名>.post_size_workers

○

×

worker.<ワーカ名>.post_data

×

○

worker.<ワーカ名>.default_worker

△

×

worker.<ワーカ名>.cachesize

×

△

worker.<ワーカ名>.receive_timeout

×

△

worker.<ワーカ名>.delegate_error_code

×

△

（凡例）○：指定できる。　×：指定できない。　△：任意に指定できる。

(3)　設定例

POSTデータサイズでのリクエスト振り分けの例を次の図に示します。ここでは，リクエストを限定できない場合を例に説明します。

図5‒13　POSTデータサイズでのリクエスト振り分けの例

この例では，「/examples」以下のリクエストのうち，POSTデータサイズが100メガバイト未満のリクエストをホストA，POSTデータサイズが100メガバイト以上200メガバイト未満のリクエストをホストBに振り分けます。リクエストの振り分け条件に満たないリクエストは，デフォルトワーカに設定したホストAに振り分けます。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。リクエストの振り分け条件については，「5.5.3　リクエストの振り分け条件」を参照してください。

workers.propertiesの例を次に示します。ここでは，POSTリクエスト振り分けワーカ，POSTリクエスト転送先ワーカおよびデフォルトワーカを定義します。POSTデータサイズの上限値は，「worker1」に「100m」，「worker2」に「2048m」（POSTデータサイズの上限値の最大値）を指定します。デフォルトワーカには，「worker1」を指定します。

workers.propertiesの例（Windowsの場合）

worker.list=postsizelb1

worker.postsizelb1.post_size_workers=worker1,worker2
worker.postsizelb1.type=post_size_lb
worker.postsizelb1.default_worker=worker1

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64
worker.worker1.post_data=100m

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64
worker.worker2.post_data=2048m

workers.propertiesの例（UNIXの場合）

worker.list=postsizelb1

worker.postsizelb1.post_size_workers=worker1,worker2
worker.postsizelb1.type=post_size_lb
worker.postsizelb1.default_worker=worker1

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.post_data=100m

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.post_data=2048m

mod_jk.confの例を次に示します。ここでは，POSTリクエスト振り分けワーカ「postsizelb1」を指定します。

mod_jk.confの例

JkMount /examples/* postsizelb1

参考

POSTデータサイズの上限値は，httpsd.conf（HTTP Server定義ファイル）のLimitRequestBodyディレクティブでも設定できます。LimitRequestBodyディレクティブの詳細については，マニュアル「HTTP Server」を参照してください。

5.5.6　実行環境での設定（Smart Composer機能を使用しない場合）

振り分け先となるワーカのリストをPOSTリクエスト振り分けワーカに定義することで，POSTデータサイズでワーカにリクエストを振り分けます。

振り分け先となるPOSTリクエスト転送先ワーカに，POSTデータサイズの上限値を設定して，リクエスト振り分け先を定義します。これによって，特定のホストに，処理に時間が掛かる長大なPOSTデータサイズのリクエストの処理を振り分けられます。リダイレクタは，HTTPリクエスト単位にPOSTデータサイズの上限値で振り分けるので，長大なPOSTデータ以外のリクエストのスループットの低下や，レスポンス時間の低下を防ぐことができます。なお，POSTデータサイズの上限値が設定されている場合は，同じセッションに属するHTTPリクエストであっても，POSTデータサイズの値が優先されます。

注意事項

Microsoft IISと連携する場合，POSTデータサイズによるリクエストの振り分けは設定できません。

(1)　設定の手順

POSTデータサイズでのリクエスト振り分けは，次の手順で設定します。

workers.propertiesでPOSTリクエスト振り分けワーカ，およびPOSTリクエスト転送先ワーカを定義します。

POSTリクエスト振り分けワーカの定義

ワーカ名のリスト，ワーカのタイプ（「post_size_lb」を設定），POSTデータサイズによる振り分けの対象となるワーカのリストなどを設定します。

必要に応じて，デフォルトワーカも設定します。

各POSTリクエスト転送先ワーカの定義

ワーカのタイプ（「ajp13」を設定），ポート番号，ホスト名，POSTデータサイズの上限値などを設定します。

標準で提供されるworkers.propertiesには，デフォルト値が定義されています。コメントとして定義されているデフォルトの定義を使用する場合は，該当する行の先頭の「#」を削除してください。

workers.properties（ワーカ定義ファイル）については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。

mod_jk.confでURLパターンとワーカのマッピングを定義します。

すでにマッピングが定義されている場合は，定義を削除，または置き換えてください。

mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）については，「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

Webサーバの環境を設定して，Webサーバを再起動します。

Webサーバの設定については，「付録D　HTTP Serverの設定に関する注意事項」を参照してください。

(2)　設定例

POSTデータサイズでのリクエスト振り分けの例を次の図に示します。ここでは，リクエストを限定できない場合を例に説明します。

図5‒14　POSTデータサイズでのリクエスト振り分けの例

この例では，「/examples」以下のリクエストのうち，POSTデータサイズが100メガバイト未満のリクエストをホストA，POSTデータサイズが100メガバイト以上200メガバイト未満のリクエストをホストBに振り分けます。リクエストの振り分け条件に満たないリクエストは，デフォルトワーカに設定したホストAに振り分けます。ホストAのワーカ名は「worker1」，ホストBのワーカ名は「worker2」です。リクエストの振り分け条件については，「5.5.3　リクエストの振り分け条件」を参照してください。

workers.propertiesの例を次に示します。ここでは，POSTリクエスト振り分けワーカ，POSTリクエスト転送先ワーカおよびデフォルトワーカを定義します。POSTデータサイズの上限値は，「worker1」に「100m」，「worker2」に「2048m」（POSTデータサイズの上限値の最大値）を指定します。デフォルトワーカには，「worker1」を指定します。

workers.propertiesの例（Windowsの場合）

worker.list=postsizelb1

worker.postsizelb1.post_size_workers=worker1,worker2
worker.postsizelb1.type=post_size_lb
worker.postsizelb1.default_worker=worker1

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.cachesize=64
worker.worker1.post_data=100m

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.cachesize=64
worker.worker2.post_data=2048m

workers.propertiesの例（UNIXの場合）

worker.list=postsizelb1

worker.postsizelb1.post_size_workers=worker1,worker2
worker.postsizelb1.type=post_size_lb
worker.postsizelb1.default_worker=worker1

worker.worker1.port=8007
worker.worker1.host=hostA
worker.worker1.type=ajp13
worker.worker1.post_data=100m

worker.worker2.port=8007
worker.worker2.host=hostB
worker.worker2.type=ajp13
worker.worker2.post_data=2048m

mod_jk.confの例を次に示します。ここでは，POSTリクエスト振り分けワーカ「postsizelb1」を指定します。

mod_jk.confの例

JkMount /examples/* postsizelb1

参考

POSTデータサイズの上限値は，httpsd.conf（HTTP Server定義ファイル）のLimitRequestBodyディレクティブでも設定できます。LimitRequestBodyディレクティブの詳細については，マニュアル「HTTP Server」を参照してください。

5.6　通信タイムアウト（Webサーバ連携）

この節では，Webサーバ連携での通信タイムアウトについて説明します。

Webサーバ連携機能を使用する場合，クライアント−Webサーバ間，およびWebサーバ−Webコンテナ間での，リクエスト受信およびレスポンス送信に，通信のタイムアウトを設定できます。ネットワークの障害やアプリケーションの障害発生などで応答待ち状態になった場合，通信タイムアウトを設定していると，タイムアウトの発生によって障害の発生を検知できます。

この節の構成を次の表に示します。

表5‒12　この節の構成（通信タイムアウト（Webサーバ連携））

分類

タイトル

参照先

解説

リクエスト送受信時の通信タイムアウト

5.6.1

レスポンス送受信時の通信タイムアウト

5.6.2

設定

通信タイムアウトの設定

5.6.3

リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

5.6.4

リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

5.6.5

レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

5.6.6

レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

5.6.7

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

Webサーバ連携機能を使用する場合，通信タイムアウトは，次に示す図中の四つの矢印が示す通信に対して設定します。さらに，リダイレクタ−Webコンテナ間の通信では，リダイレクタ側，Webコンテナ側の両方で通信タイムアウトを設定できます。リクエスト送信の場合は，リダイレクタ側でのリクエスト送信時およびWebコンテナ側でのリクエスト受信時に設定できます。また，レスポンス送信の場合は，Webコンテナ側でのレスポンス送信時およびリダイレクタ側でのレスポンス受信時に設定できます。タイムアウトを設定できる通信について次の図に示します。

図5‒15　タイムアウトを設定できる通信

通信タイムアウトの設定について，リクエストの受信とレスポンスの送信に分けて説明します。

5.6.1　リクエスト送受信時の通信タイムアウト

ここでは，Webサーバ連携機能を使用する場合のリクエスト送受信時の通信タイムアウト設定について説明します。リクエスト送受信時の，通信タイムアウトの設定場所を次の図に示します。

図5‒16　リクエスト送受信時の通信タイムアウトの設定場所

Webサーバ連携機能を使用する場合，図中の○印の場所に通信タイムアウトを設定します。通信タイムアウトを設定する場所について説明します。なお，図中の項番は次の説明の項番と対応しています。

Webサーバでのリクエスト受信時（クライアント−Webサーバ）

クライアントからのリクエストを，Webサーバで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webサーバで設定します。

Webサーバでのリクエスト受信時に通信タイムアウトを設定することによって検知できる障害については，「5.6.1(1)　Webサーバでのリクエスト受信時」を参照してください。

リダイレクタでのリクエスト送信時（リダイレクタ−Webコンテナ）

リダイレクタからWebコンテナにリクエストを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，リダイレクタで設定します。

リダイレクタでのリクエスト送信時に通信タイムアウトを設定することによって検知できる障害については，「5.6.1(2)　リダイレクタでのリクエスト送信時」を参照してください。

Webコンテナでのリクエスト受信時（リダイレクタ−Webコンテナ）

リダイレクタからのリクエストを，Webコンテナで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webコンテナで設定します。

Webコンテナでのリクエスト受信時に通信タイムアウトを設定することによって検知できる障害については，「5.6.1(3)　Webコンテナでのリクエスト受信時」を参照してください。

(1)　Webサーバでのリクエスト受信時

Webサーバでは，クライアントから転送されたリクエストの受信処理に，タイムアウト時間を設定できます。設定した通信タイムアウトによって，クライアント側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

クライアントが稼働するホストがダウンした

クライアント−Webサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

(2)　リダイレクタでのリクエスト送信時

リダイレクタでは，Webコンテナへのリクエスト送信処理にタイムアウト時間を設定できます。設定したタイムアウト時間を超えてタイムアウトが発生した場合にはHTTP Serverのエラーログにメッセージが出力されます。

(a)　設定できる通信タイムアウトと検知できる障害

リダイレクタでのリクエスト送信処理では，次に示す二つの時間にタイムアウトが設定できます。

Webコンテナにリクエストを送信するための，コネクションを確立する時間

Webコンテナにリクエストを送信する時間

設定した通信タイムアウトによって，Webコンテナ側またはネットワーク上で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webコンテナが稼働するホストがダウンした

リダイレクタ−Webコンテナ間でネットワーク障害が発生した

(b)　リクエスト送信処理のリトライ

リダイレクタからのリクエスト送信処理が一時的にできなくなった場合，リクエスト送信処理のリトライができます。一時的にリクエスト送信ができない場合とは次のような場合です。

ネットワークの一時的な障害が発生した場合

コネクション確立時に，Webコンテナにリクエストが集中している状態で，確立要求が一時的にリスンキューからあふれた場合

Webコンテナの起動完了を待っている場合

リトライできる処理は，コネクションの確立処理，およびリクエストヘッダの送信処理となります。リトライ処理の流れを次の図に示します。

図5‒17　Webコンテナへのリクエスト送信時のリトライ処理の流れ

リトライは，図中のAまたはBでタイムアウトが発生した場合に実施されます。図中CまたはDの部分で処理に失敗し，タイムアウトが発生した場合，リトライは実施されません。コネクションはクローズされ，クライアントにエラーが返ります。なお，図中CまたはDの部分で処理の失敗とは，Webサーバからのリクエストボディの受信に失敗した場合，またはWebコンテナへのリクエストボディの送信に失敗した場合を指します。

ポイント

図中のCまたはDの処理では，Webコンテナ側ですでにリクエストに対する処理が開始されている可能性があります。Webサーバからのリクエストボディの受信に失敗した場合，およびWebコンテナへのリクエストボディの送信に失敗した場合は，リトライを実施すると二重送信となるおそれがあるため，リトライはされません。

次に，図中Aおよび図中Bで処理に失敗した場合のリトライについて説明します。

図中Aの部分で処理に失敗した場合のリトライ

リダイレクタからWebコンテナにコネクションの確立要求を出したあと，Webコンテナが稼働するホストの電源が切断されたり，ネットワーク障害が発生したりした場合，次のように動作します。

設定したタイムアウトの時間が経過すると，コネクション確立でタイムアウトが発生したことを示すメッセージが出力されます。

指定した回数だけコネクションの確立をリトライします。

なお，リトライ回数分実施してもコネクションの確立ができなかった場合，リクエスト送信に失敗したことを示すメッセージが出力され，クライアントにエラー（ステータスコード500）が返されます。

図中Bの部分で処理に失敗した場合のリトライ

コネクションの確立が成功したあと，またはWebコンテナにリクエストヘッダの送信をしたあと，Webコンテナが稼働するホストの電源が切断されたり，ネットワーク障害が発生したりした場合，次のように動作します。

設定したタイムアウトの時間が経過すると，リクエスト送信でタイムアウトが発生したことを示すメッセージが出力されます。

リクエストヘッダの送信処理に使用されたコネクションをクローズします。

指定した回数だけリクエストヘッダの送信をリトライします。

なお，このとき，コネクションキャッシュにコネクションがあるかどうかで動作が異なります。

・コネクションキャッシュにコネクションがある場合

コネクションキャッシュ中のコネクションを使用して，リクエストヘッダの送信処理からリトライします。

・コネクションキャッシュにコネクションがない場合

再度，コネクションの確立を実施してから，リクエストヘッダの送信処理をリトライします。

なお，リトライ回数分実施してもリクエストヘッダの送信ができなかった場合，リクエスト送信に失敗したことを示すメッセージが出力され，クライアントにステータスコード500が返されます。

ロードバランサを使用してリクエストの振り分けをしている場合のリトライ動作

ロードバランサを使用したリクエストの振り分けをしている場合のリトライ動作について，次の図で説明します。

なお，この図では，リクエストは，Webコンテナ1，Webコンテナ2の順で振り分けられ，リトライ回数は3回が設定されていることとします。

図5‒18　ロードバランサを使用してリクエストの振り分けをしている場合のリトライ動作

図のリトライ動作について説明します。

Webコンテナ1へのリクエスト送信

リクエストはWebコンテナ1に送信されます。Webコンテナ1へのコネクションの確立またはリクエストヘッダの送信処理に失敗すると，リトライをします。リトライは3回まで実施されます。

Webコンテナ2へのリクエスト送信

Webコンテナ1でのリトライに3回失敗すると，リクエストはWebコンテナ2に転送されます。リクエストが転送されると，リトライは再度1からカウントされるため，Webコンテナ2に対しても，最大で3回リトライが実行されます。

クライアントへのエラー通知

Webコンテナ2に対しても，コネクションの確立またはリクエストヘッダの送信処理が3回失敗すると，クライアントにエラー（ステータスコード500）が返ります。

参考

リクエストの転送は，設定されているWebコンテナの数だけ実施されます。

(3)　Webコンテナでのリクエスト受信時

Webコンテナでは，リダイレクタから転送されたリクエストの受信処理に，タイムアウト時間を設定できます。設定した通信タイムアウトによって，リダイレクタ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webサーバが稼働するホストがダウンした

Webサーバ−Webコンテナ間のネットワーク障害が発生した

クライアント−Webサーバ間での処理が終わる前に，Webコンテナ側でタイムアウトが発生した

これは，Webコンテナが要求したデータサイズ分の読み込みを，クライアント−Webサーバ間で行っているときに，クライアント−Webサーバ間の通信速度が十分ではないなどの理由によって，データの読み込みが終了する前に，Webコンテナで設定した通信タイムアウトが発生したことを意味します。

通信タイムアウトが発生する条件と発生後の動作について次の表に示します。

表5‒13　通信タイムアウトが発生する条件と発生後の動作

通信タイムアウトが発生する条件

発生後の動作

リクエスト受信時に次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

ボディデータの形式がチャンク形式ではない。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ−Webコンテナ間のネットワークに障害が発生した。

リクエスト処理は実行されない。

メッセージログにKDJE39188-Eのメッセージを出力する。

サーブレット(JSP)内でのAPI※使用時に，次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

ボディデータの形式がチャンク形式ではない。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ−Webコンテナ間のネットワークに障害が発生した。

java.lang.IllegalStateExceptionが発生する。

リダイレクタとのコネクションがクローズされ，それ以降のデータの読み込み，書き込みができなくなる。

メッセージログにKDJE39188-Eのメッセージを出力する。

サーブレット(JSP)内でjavax.servlet.ServletInputStreamクラスまたはjavax.servlet.ServletRequestクラスのgetReaderメソッドによって得られたjava.io.BufferedReaderクラスを使用してPOSTデータを読み込んだ際に，次の条件をすべて満たしている場合

リクエストにボディデータが存在する。

読み込み処理に入ったあとで，リダイレクタが稼働するホスト，またはリダイレクタ−Webコンテナ間のネットワークに障害が発生した。

java.net.SocketTimeoutExceptionが発生する。

リダイレクタとのコネクションがクローズされ，それ以降のデータの読み込み，書き込みができなくなる。

メッセージログにKDJE39188-Eのメッセージを出力する。

注※

javax.servlet.ServletRequestの，getParameterメソッド，getParameterMapメソッド，getParameterNamesメソッド，getParameterValuesメソッドを使用している場合を指します。

5.6.2　レスポンス送受信時の通信タイムアウト

ここでは，Webサーバ連携機能を使用する場合のレスポンス送受信時の通信タイムアウト設定について説明します。レスポンス送受信時の，通信タイムアウトの設定場所を次の図に示します。

図5‒19　レスポンス送信時の通信タイムアウトの設定場所（Webサーバ連携機能を使用する場合）

Webサーバ連携機能を使用する場合，図中の○印の場所に通信タイムアウトを設定します。通信タイムアウトを設定する場所について説明します。なお，図中の項番は次の説明の項番と対応しています。

Webコンテナでのレスポンス送信時（Webコンテナ−リダイレクタ）

Webコンテナからリダイレクタにレスポンスを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webコンテナで設定します。

Webコンテナでのレスポンス送信時に通信にタイムアウトを設定することによって検知できる障害については，「5.6.2(1)　Webコンテナでのレスポンス送信時」を参照してください。

リダイレクタでのレスポンス受信時（Webコンテナ−リダイレクタ）

Webコンテナからのレスポンスを，リダイレクタで受信するときに，通信タイムアウトを設定します。通信タイムアウトは，リダイレクタで設定します。

リダイレクタでのレスポンス受信時に通信タイムアウトを設定することによって検知できる障害については，「5.6.2(2)　リダイレクタでのレスポンス受信時」を参照してください。

Webサーバでのレスポンス送信時（Webサーバ−クライアント）

Webサーバからクライアントにレスポンスを送信するときに，通信タイムアウトを設定します。通信タイムアウトは，Webサーバで設定します。

Webサーバでのレスポンス送信時に通信にタイムアウトを設定することによって検知できる障害については，「5.6.2(3)　Webサーバでのレスポンス送信時」を参照してください。

(1)　Webコンテナでのレスポンス送信時

Webコンテナでは，リダイレクタへのレスポンス送信処理に対して，タイムアウト時間を設定できます。設定した通信タイムアウトによって，リダイレクタ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

リダイレクタが稼働するホストがダウンした

Webコンテナ−リダイレクタ間でネットワーク障害が発生した

また，通信タイムアウトが発生すると，KDJE39507-E（レスポンス送信処理でタイムアウト発生）がメッセージログに出力されます。通信タイムアウトが発生する条件と発生後の動作について次の表に示します。

表5‒14　通信タイムアウトが発生する条件と発生後の動作

通信タイムアウトが発生するタイミング

通信タイムアウト発生後のメソッドの動作

通信タイムアウト発生後のサーブレットまたはJSPの動作

サーブレット内で，javax.servlet.ServletResponseクラスのgetOutputStreamメソッドによって得られたjavax.servlet.ServletOutputStreamクラスのメソッドを使用してレスポンスデータをクライアントに送信したとき

java.net.SocketTimeoutExceptionの例外が発生する。

リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

サーブレット内で，javax.servlet.ServletResponseクラスのgetWriterメソッドによって得られたjava.io.PrintWriterクラスのメソッドを使用して，レスポンスデータをクライアントに送信したとき

送信処理が中断されて，リターンする。

java.io.PrintWriterクラスのcheckErrorメソッドがtrueを返す。

リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

JSP内で，javax.servlet.jsp.JspWriterクラスのメソッドを使用してレスポンスデータをクライアントに送信したとき

java.net.SocketTimeoutExceptionの例外が発生する。

リダイレクタとのコネクションがクローズされるため，リクエストデータおよびレスポンスデータの送受信ができなくなる。

静的コンテンツのレスポンスデータをクライアントに送信したとき

−

−

（凡例）−：該当しない

(2)　リダイレクタでのレスポンス受信時

リダイレクタは，Webコンテナにリクエストを送信すると，Webコンテナからのレスポンスを待ちます。このレスポンスの待ち時間に，タイムアウトを設定できます。設定した通信タイムアウトによって，Webコンテナ側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

Webコンテナが稼働するホストがダウンした

Webコンテナ−リダイレクタ間でネットワーク障害が発生した

Webコンテナ内のWebアプリケーションで障害が発生した

Webアプリケーションで発生する障害には次のようなものがあります。

Webアプリケーションで発生する障害

サーブレット/JSP処理内の無限ループによって，レスポンスが返されない

サーブレット/JSPの延長でEnterprise Bean，データベースなどが呼び出され，それによる応答待ちをしている

Webアプリケーションでデッドロックが発生している

アクセスピーク時にサーバの処理が追いつかないで滞っている

リダイレクタでの通信タイムアウト後の動作

通信タイムアウトが発生すると，リダイレクタは，Webコンテナとのコネクションを切断し，クライアントにステータスコード500のエラーを返します。

ポイント

アプリケーション処理中にタイムアウトが発生したときの動作

Webコンテナでの処理中にリダイレクタがタイムアウトしていても，Webコンテナでは，リダイレクタがタイムアウトしていることを検知できません。

リダイレクタでのタイムアウトを検知できるのは，Webコンテナの処理が完了し，リダイレクタへレスポンスを転送するときとなります。しかし，この時点では，すでにリダイレクタがWebコンテナとのコネクションを切断しているため，レスポンス送信はエラーとなります。アプリケーション処理中にタイムアウトが発生したときの動作について次の図に示します。

図5‒20　アプリケーション処理中にタイムアウトが発生したときの動作

図について説明します。

リダイレクタでタイムアウトが発生すると，Webコンテナとのコネクションを切断する要求を出します。

リダイレクタはWebサーバに対して，エラーコードを送信します。

Webコンテナでのアプリケーションの処理が完了すると，リダイレクタに対して，レスポンスを送信しますが，1.で，すでにリダイレクタとWebコンテナのコネクションは切断されているため，通信エラーが発生します。

(3)　Webサーバでのレスポンス送信時

Webサーバでは，クライアントへのデータ送信処理に対して，タイムアウト時間を設定できます。設定した通信タイムアウトによって，クライアント側で障害が発生したことを検知できます。検知できる障害を次に示します。

検知できる障害

クライアントが稼働するホストがダウンした

クライアント−Webサーバ間のネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

5.6.3　通信タイムアウトの設定

ここでは，クライアント−Webサーバ間，およびWebサーバ（リダイレクタ）−Webコンテナ間の通信タイムアウトの設定について説明します。

通信タイムアウトは，リクエストの送受信時，またはレスポンスの送受信時に設定します。通信タイムアウトの設定は，Smart Composerの使用の有無によって設定方法が異なります。通信タイムアウトの設定方法の参照先について，次の表に示します。

表5‒15　通信タイムアウト（Webサーバ連携）の設定方法の参照先

設定するタイミング

Smart Composerの使用

使用する

使用しない

リクエスト送受信時

5.6.4

5.6.5

レスポンスの送受信時

5.6.6

5.6.7

なお，通信タイムアウトは，EJBを呼び出すEJBクライアント側でも設定できます。EJBクライアント側での設定は，J2EEアプリケーション開発時に設定します。設定方法については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(EJBコンテナ)」の「2.11.5　RMI-IIOP通信のタイムアウト」を参照してください。

5.6.4　リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

リクエスト送受信時の通信タイムアウトは，クライアント−Webサーバ間，リダイレクタ−Webコンテナ間に設定します。

それぞれの場合での通信タイムアウトの設定方法について説明します。

(1)　Webサーバでのリクエスト受信時の設定

クライアントからのリクエストをWebサーバで受信するときの通信タイムアウトは，Webサーバに設定します。Webサーバには，HTTP Serverを使用できます。

(a)　設定方法

クライアントから転送されたリクエストの受信処理の通信タイムアウトを，httpsd.confに設定してください。

リクエスト受信処理の待ち時間

Timeoutディレクティブに，クライアントからのリクエスト受信処理の待ち時間（秒）を設定します。Timeoutディレクティブのデフォルト値は300秒です。なお，ここに設定する値は，クライアントへのデータ送信処理に対する通信タイムアウトと共用です。クライアントへのデータ送信処理に対する通信タイムアウトについては，「5.6.6(3)　Webサーバでのレスポンス送信時の設定」を参照してください。

(b)　設定時の注意

Webサーバでのリクエスト受信時に設定するタイムアウト値については，クライアント−Webサーバ間のネットワーク構成，およびトラフィックの状態を考慮し，障害が発生したと判断できる時間を設定してください。

(2)　リダイレクタでのリクエスト送信時の設定

リダイレクタからWebコンテナにリクエストを送信するときには，Webコンテナとのコネクションを確立してからリクエストを送信します。リダイレクタからWebコンテナにリクエストを送信するときの通信タイムアウトは，コネクション確立時，およびリクエスト送信時に設定できます。また，コネクションの確立およびリクエストヘッダの送信に失敗した場合のリトライ回数を設定できます。

(a)　設定方法

リダイレクタからの，コネクション確立およびリクエスト送信処理の通信タイムアウトおよびリトライ回数を，簡易構築定義ファイルに設定してください。

コネクション確立の通信タイムアウト

論理Webサーバ（web-server）の<configuration>タグ内に，JkConnectTimeoutパラメタで，Webコンテナへのコネクション確立処理の待ち時間（秒）を設定します。JkConnectTimeoutパラメタのデフォルト値は30秒です。

リクエスト送信処理のタイムアウト

論理Webサーバ（web-server）の<configuration>タグ内に，JkSendTimeoutパラメタで，Webコンテナへのリクエスト送信処理の待ち時間（秒）を設定します。JkSendTimeoutパラメタのデフォルト値は100秒です。

コネクション確立およびリクエスト送信のリトライ回数

論理Webサーバ（web-server）の<configuration>タグ内に，JkRequestRetryCountパラメタで，Webコンテナへのコネクション確立およびリクエスト送信のリトライ回数を設定します。JkRequestRetryCountパラメタのデフォルト値は3回です。

(b)　設定時の注意

リダイレクタでのリクエスト送信時に設定する通信タイムアウト値，およびリトライ回数については，次の点に考慮して設定してください。

リトライ回数には，初回のコネクション確立およびリクエスト送信が含まれます。このため，初回のコネクション確立またはリクエスト送信処理で失敗した場合，コネクション確立またはリクエスト送信処理のリトライは，2回目としてカウントされます。

コネクション確立およびリクエスト送信処理の通信タイムアウト時間に0を指定した場合，またはTCPが持つコネクション確立およびデータ送信の再送タイマより長い時間を設定した場合は，通信タイムアウト時間はTCPの持つタイムアウト時間が適用されます。

(3)　Webコンテナでのリクエスト受信時の設定

リダイレクタからのリクエストをWebコンテナで受信するときの通信タイムアウトは，Webコンテナに設定します。

(a)　設定方法

リダイレクタから転送されたリクエストの受信処理の通信タイムアウトを，簡易構築定義ファイルに設定してください。

リクエスト受信処理のタイムアウト

論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.connector.ajp13.receive_timeoutパラメタで，リダイレクタからのリクエスト受信処理の待ち時間（秒）を設定します。パラメタのデフォルト値は100秒です。

(b)　設定時の注意

Webコンテナでのリクエスト受信時に設定するタイムアウト値については，次の点に考慮して設定してください。

Webサーバのリクエスト受信時のタイムアウトに設定した時間より，大きい値を設定してください。

Webサーバのリクエスト受信時のタイムアウトに設定した時間より，小さい値を設定しているときに，クライアントや，クライアント−Webサーバ間でネットワーク障害が発生すると，Webサーバより先にWebコンテナでタイムアウトが発生してしまいます。この場合，障害が発生したのが，Webサーバ側であるのか，クライアント側であるのかが判別できなくなります。

クライアントからのデータ受信が必要な場合，クライアントとの通信速度を考慮して，データ受信ができる時間を設定してください。

リダイレクタでのWebコンテナへのデータの送信時に障害が発生した場合，TCPの再送タイマでのタイムアウトによって障害が検知されます。

なお，UNIXの場合，タイムアウトまでの時間は，OSによって異なります。

5.6.5　リクエスト送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

リクエスト送受信時の通信タイムアウトは，クライアント−Webサーバ間，リダイレクタ−Webコンテナ間に設定します。

それぞれの場合での通信タイムアウトの設定方法について説明します。

(1)　Webサーバでのリクエスト受信時の設定

クライアントからのリクエストをWebサーバで受信するときの通信タイムアウトは，Webサーバに設定します。Webサーバには，HTTP ServerまたはMicrosoft IISのどちらかを使用できます。

(a)　設定方法

クライアントから転送されたリクエストの受信処理の通信タイムアウトを，次のファイルに設定してください。

httpsd.conf（HTTP Serverの場合）

Timeoutディレクティブに，クライアントからのリクエスト受信処理の待ち時間（秒）を設定します。Timeoutディレクティブのデフォルト値は300秒です。なお，ここに設定する値は，クライアントへのデータ送信処理に対する通信タイムアウトと共用です。クライアントへのデータ送信処理に対する通信タイムアウトについては，「5.6.6(3)　Webサーバでのレスポンス送信時の設定」を参照してください。

isapi_redirect.conf（Microsoft IISの場合）

receive_client_timeoutキーに，クライアントからのリクエスト受信処理の待ち時間（秒）を設定します。

(b)　設定時の注意

Webサーバでのリクエスト受信時に設定するタイムアウト値については，クライアント−Webサーバ間のネットワーク構成，およびトラフィックの状態を考慮し，障害が発生したと判断できる時間を設定してください。

(2)　リダイレクタでのリクエスト送信時の設定

リダイレクタからWebコンテナにリクエストを送信するときには，Webコンテナとのコネクションを確立してからリクエストを送信します。リダイレクタからWebコンテナにリクエストを送信するときの通信タイムアウトは，コネクション確立時，およびリクエスト送信時に設定できます。また，コネクションの確立およびリクエストヘッダの送信に失敗した場合のリトライ回数を設定できます。

(a)　設定方法

リダイレクタからの，コネクション確立およびリクエスト送信処理の通信タイムアウトおよびリトライ回数を，次のファイルに設定してください。

mod_jk.conf（HTTP Serverの場合）

コネクション確立の通信タイムアウト

JkConnectTimeoutキーに，Webコンテナへのコネクション確立処理の待ち時間（秒）を設定します。JkConnectTimeoutキーのデフォルト値は30秒です。

リクエスト送信処理のタイムアウト

JkSendTimeoutキーに，Webコンテナへのリクエスト送信処理の待ち時間（秒）を設定します。JkSendTimeoutキーのデフォルト値は100秒です。

コネクション確立およびリクエスト送信のリトライ回数

JkRequestRetryCountキーに，Webコンテナへのコネクション確立およびリクエスト送信のリトライ回数を設定します。JkRequestRetryCountキーのデフォルト値は3回です。

isapi_redirect.conf（Microsoft IISの場合）

コネクション確立処理の通信タイムアウト

connect_timeoutキーに，Webコンテナへのコネクション確立処理の待ち時間（秒）を設定します。connect_timeoutキーのデフォルト値は30秒です。

リクエスト送信処理のタイムアウト

send_timeoutキーに，Webコンテナへのリクエスト送信処理の待ち時間（秒）を設定します。send_timeoutキーのデフォルト値は100秒です。

コネクション確立およびリクエスト送信のリトライ回数

request_retry_countキーに，Webコンテナへのコネクション確立およびリクエスト送信のリトライ回数を設定します。request_retry_countキーのデフォルト値は3回です。

(b)　設定時の注意

リダイレクタでのリクエスト送信時に設定する通信タイムアウト値，およびリトライ回数については，次の点に考慮して設定してください。

リトライ回数には，初回のコネクション確立およびリクエスト送信が含まれます。このため，初回のコネクション確立またはリクエスト送信処理で失敗した場合，コネクション確立またはリクエスト送信処理のリトライは，2回目としてカウントされます。

コネクション確立およびリクエスト送信処理の通信タイムアウト時間に0を指定した場合，またはTCPが持つコネクション確立およびデータ送信の再送タイマより長い時間を設定した場合は，通信タイムアウト時間はTCPの持つタイムアウト時間が適用されます。

(3)　Webコンテナでのリクエスト受信時の設定

リダイレクタからのリクエストをWebコンテナで受信するときの通信タイムアウトは，Webコンテナに設定します。

(a)　設定方法

リダイレクタから転送されたリクエストの受信処理の通信タイムアウトを，次のファイルに設定してください。

usrconf.properties

webserver.connector.ajp13.receive_timeoutキーに，リダイレクタからのリクエスト受信処理の待ち時間（秒）を設定します。

(b)　設定時の注意

Webコンテナでのリクエスト受信時に設定するタイムアウト値については，次の点に考慮して設定してください。

Webサーバのリクエスト受信時のタイムアウトに設定した時間より，大きい値を設定してください。

Webサーバのリクエスト受信時のタイムアウトに設定した時間より，小さい値を設定しているときに，クライアントや，クライアント−Webサーバ間でネットワーク障害が発生すると，Webサーバより先にWebコンテナでタイムアウトが発生してしまいます。この場合，障害が発生したのが，Webサーバ側であるのか，クライアント側であるのかが判別できなくなります。

クライアントからのデータ受信が必要な場合，クライアントとの通信速度を考慮して，データ受信ができる時間を設定してください。

リダイレクタでのWebコンテナへのデータの送信時に障害が発生した場合，TCPの再送タイマでのタイムアウトによって障害が検知されます。

なお，UNIXの場合，タイムアウトまでの時間は，OSによって異なります。

5.6.6　レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用する場合）

レスポンス送受信時の通信タイムアウトは，Webコンテナ−リダイレクタ間，Webサーバ−クライアント間に設定します。

それぞれの場合での通信タイムアウトの設定方法について説明します。

(1)　Webコンテナでのレスポンス送信時の設定

Webコンテナからリダイレクタにレスポンス送信処理するときの通信タイムアウトは，Webコンテナに設定します。Webコンテナからのレスポンス送信時の待ち時間は，簡易構築定義ファイルに設定してください。

レスポンス送信処理のタイムアウト

論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.connector.ajp13.send_timeoutパラメタで，Webコンテナからのレスポンス送信時のタイムアウト時間（秒）を設定します。パラメタのデフォルト値は600秒です。

(2)　リダイレクタでのレスポンス受信時の設定

Webコンテナからのレスポンスを受信するときの通信タイムアウトをリダイレクタに設定します。

(a)　設定方法

Webコンテナからのレスポンス待ち時間を，簡易構築定義ファイルに設定してください。

レスポンス受信処理のタイムアウト

論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，worker.<ワーカ名>.receive_timeoutパラメタで，ワーカごとのレスポンス待ち時間（秒）を設定します。パラメタのデフォルト値は3600秒です。J2EEアプリケーション単位で通信タイムアウトを設定したい場合は，J2EEアプリケーションごとにワーカを定義してマッピングしてください。

(b)　設定時の注意

リダイレクタでのレスポンス受信時のタイムアウトでは，Webアプリケーションの障害を検知できます。そのため，運用状況によっては，Webアプリケーションの処理に必要となる時間を考慮して，障害検知と判断できる値を通信タイムアウトに設定する必要があります。

リダイレクタでのレスポンス受信時に設定するタイムアウト値については，次の点に考慮して設定してください。

通信タイムアウトには，Webアプリケーションの処理に必要な時間より長い時間を設定してください。

設定したタイムアウトの時間が，Webアプリケーションの処理時間より短い場合，Webアプリケーションは正常に処理されていても，リダイレクタ側ではタイムアウトが発生したと判断して，クライアントにエラーが返されます。

Webコンテナのピーク時の，同時実行スレッド数の制御による待ち時間を考慮してください。

同時実行スレッド数の制御によって，Webコンテナのピーク時には，処理待ちリクエストの発生が考えられます。このため，同時実行スレッド数の制御を設定している場合，リクエストの処理時間が延長されることも考慮して，通信タイムアウトを設定しておく必要があります。Webコンテナ単位の同時実行スレッド数の制御の設定については，「5.11　Webコンテナ単位での同時実行スレッド数の制御」を，Webアプリケーション単位やURLグループ単位の同時実行スレッド数の制御の設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.15　Webアプリケーション単位での同時実行スレッド数の制御」や「2.16　URLグループ単位での同時実行スレッド数の制御」を参照してください。

Webコンテナでのリダイレクタへのデータの送信時に障害が発生した場合，TCPの再送タイマでのタイムアウトによって障害が検知されます。

なお，UNIXの場合，タイムアウトまでの時間は，OSによって異なります。

(3)　Webサーバでのレスポンス送信時の設定

クライアントにレスポンスを送信するときの通信タイムアウトは，Webサーバに設定します。

(a)　設定方法

クライアントからのレスポンス待ち時間を，httpsd.confに設定してください。

データ送信処理の通信タイムアウト

Timeoutディレクティブに通信タイムアウトを設定してください。なお，Timeoutディレクティブで指定する通信タイムアウトは，リクエスト受信処理に対する通信タイムアウトおよびレスポンス送信処理に対する通信タイムアウトの両方の時間として指定します。このため，リクエスト受信処理の通信タイムアウトとレスポンス送信処理の通信タイムアウトで異なる時間を設定することはできません。

クライアントからのリクエスト受信処理に対する通信タイムアウトについては，「5.6.4(1)　Webサーバでのリクエスト受信時の設定」を参照してください。

(b)　設定時の注意

Webサーバでのレスポンス送信時に設定するタイムアウト値については，クライアント−Webサーバ間のネットワーク構成，およびトラフィックの状態を考慮し，クライアントとデータの送受信をするのに十分な時間を設定してください。

また，Webサーバでのレスポンス送信時のタイムアウトは，Webコンテナでのレスポンス送信時のタイムアウト値よりも小さな値を設定してください。Webサーバでのレスポンス送信時のタイムアウトを，Webコンテナでのレスポンス送受信時のタイムアウト値よりも大きな値を設定しているときに，クライアント−Webサーバ間で障害が発生すると，Webサーバでのクライアントへのレスポンス送信のタイムアウトよりも先に，Webコンテナでのリダイレクタへのレスポンス送信でタイムアウトが発生するおそれがあります。この場合，障害が発生したのが，クライアント−Webサーバ間か，リダイレクタ−Webコンテナ間か判別できなくなります。

5.6.7　レスポンス送受信時の通信タイムアウトの設定（Smart Composer機能を使用しない場合）

レスポンス送受信時の通信タイムアウトは，Webコンテナ−リダイレクタ間，Webサーバ−クライアント間に設定します。

それぞれの場合での通信タイムアウトの設定方法について説明します。

(1)　Webコンテナでのレスポンス送信時の設定

Webコンテナからリダイレクタにレスポンス送信処理するときの通信タイムアウトは，Webコンテナに設定します。Webコンテナからのレスポンス送信時の待ち時間は，次のファイルに，を設定してください。

usrconf.properties

webserver.connector.ajp13.send_timeoutキーに，Webコンテナからのレスポンス送信時のタイムアウト時間（秒）を設定します。デフォルト値は600秒です。

(2)　リダイレクタでのレスポンス受信時の設定

Webコンテナからのレスポンスを受信するときの通信タイムアウトをリダイレクタに設定します。

(a)　設定方法

次のファイルに，Webコンテナからのレスポンス待ち時間を設定してください。

workers.properties

worker.<ワーカ名>.receive_timeoutキーに，ワーカごとのレスポンス待ち時間（秒）を設定します。J2EEアプリケーション単位で通信タイムアウトを設定したい場合は，J2EEアプリケーションごとにワーカを定義してマッピングしてください。

(b)　設定時の注意

リダイレクタでのレスポンス受信時のタイムアウトでは，Webアプリケーションの障害を検知できます。そのため，運用状況によっては，Webアプリケーションの処理に必要となる時間を考慮して，障害検知と判断できる値を通信タイムアウトに設定する必要があります。

リダイレクタでのレスポンス受信時に設定するタイムアウト値については，次の点に考慮して設定してください。

通信タイムアウトには，Webアプリケーションの処理に必要な時間より長い時間を設定してください。

設定したタイムアウトの時間が，Webアプリケーションの処理時間より短い場合，Webアプリケーションは正常に処理されていても，リダイレクタ側ではタイムアウトが発生したと判断して，クライアントにエラーが返されます。

Webコンテナのピーク時の，同時実行スレッド数の制御による待ち時間を考慮してください。

同時実行スレッド数の制御によって，Webコンテナのピーク時には，処理待ちリクエストの発生が考えられます。このため，サーバ管理コマンドを使用して同時実行スレッド数の制御を設定している場合，リクエストの処理時間が延長されることも考慮して，通信タイムアウトを設定しておく必要があります。Webコンテナ単位の同時実行スレッド数の制御の設定については，「5.11　Webコンテナ単位での同時実行スレッド数の制御」を，Webアプリケーション単位やURLグループ単位の同時実行スレッド数の制御の設定については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.15　Webアプリケーション単位での同時実行スレッド数の制御」や「2.16　URLグループ単位での同時実行スレッド数の制御」を参照してください。

Webコンテナでのリダイレクタへのデータの送信時に障害が発生した場合，TCPの再送タイマでのタイムアウトによって障害が検知されます。

なお，UNIXの場合，タイムアウトまでの時間は，OSによって異なります。

(3)　Webサーバでのレスポンス送信時の設定

クライアントにレスポンスを送信するときの通信タイムアウトをWebサーバに設定できます。

(a)　設定方法

次のファイルに，クライアントからのレスポンス待ち時間を設定してください。

httpsd.conf（HTTP Serverの場合）

Timeoutディレクティブに通信タイムアウトを設定してください。なお，Timeoutディレクティブで指定する通信タイムアウトは，リクエスト受信処理に対する通信タイムアウトおよびレスポンス送信処理に対する通信タイムアウトの両方の時間として指定します。このため，リクエスト受信処理の通信タイムアウトとレスポンス送信処理の通信タイムアウトで異なる時間を設定することはできません。

クライアントからのリクエスト受信処理に対する通信タイムアウトについては，「5.6.4(1)　Webサーバでのリクエスト受信時の設定」を参照してください。

MinFileBytesPerSecプロパティ（Microsoft IISの場合）

MinFileBytesPerSecプロパティに通信タイムアウトを設定してください。MinFileBytesPerSecプロパティには，Webサーバからクライアントへ送信するレスポンスデータのスループット（バイト/秒）を指定します。レスポンスデータのスループットがMinFileBytesPerSecに設定した値を下回った場合に，通信タイムアウトが発生します。なお，通信タイムアウトのデフォルトは240バイト/秒です。

設定の詳細については，Microsoft IISのマニュアルを参照してください。

(b)　設定時の注意

Webサーバでのレスポンス送信時に設定するタイムアウト値については，クライアント−Webサーバ間のネットワーク構成，およびトラフィックの状態を考慮し，クライアントとデータの送受信をするのに十分な時間を設定してください。

また，Webサーバでのレスポンス送信時のタイムアウトは，Webコンテナでのレスポンス送信時のタイムアウト値よりも小さな値を設定してください。Webサーバでのレスポンス送信時のタイムアウトを，Webコンテナでのレスポンス送受信時のタイムアウト値よりも大きな値を設定しているときに，クライアント−Webサーバ間で障害が発生すると，Webサーバでのクライアントへのレスポンス送信のタイムアウトよりも先に，Webコンテナでのリダイレクタへのレスポンス送信でタイムアウトが発生するおそれがあります。この場合，障害が発生したのが，クライアント−Webサーバ間か，リダイレクタ−Webコンテナ間か判別できなくなります。

5.7　IPアドレス指定（Webサーバ連携）

この節では，Webサーバ連携でのIPアドレス指定によるWebクライアントとの通信制御について説明します。

この節の構成を次の表に示します。

表5‒16　この節の構成（IPアドレス指定（Webサーバ連携））

分類

タイトル

参照先

解説

バインド先アドレス設定機能

5.7.1

設定

実行環境での設定（J2EEサーバの設定）

5.7.2

注意事項

Webサーバ連携でのIPアドレス指定をする場合の注意事項

5.7.3

注　「実装」および「運用」について，この機能固有の説明はありません。

5.7.1　バインド先アドレス設定機能

Webコンテナでは，Webサーバ連携で利用するIPアドレスを明示的に指定できます。これを，バインド先アドレス設定機能といいます。この機能を使用することで，複数の物理ネットワークインタフェースを持つホスト，または一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，特定の一つのIPアドレスだけを使用するよう設定できます。

バインドするIPアドレスは，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「5.7.2　実行環境での設定（J2EEサーバの設定）」を参照してください。

5.7.2　実行環境での設定（J2EEサーバの設定）

Webサーバ連携でのIPアドレス指定を使用する場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webサーバ連携でのIPアドレス指定の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.ajp13.bind_host

Webサーバ連携機能を使用する場合のIPアドレスまたはホスト名を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

5.7.3　Webサーバ連携でのIPアドレス指定をする場合の注意事項

Webサーバ連携でのIPアドレス指定をする場合の注意事項を次に示します。

ホスト名またはIPアドレスを設定した場合は，指定されたIPアドレスへの接続要求しか受け付けません。IPアドレスを設定する代わりに，ワイルドカードアドレスを指定することで，そのホスト上の任意のIPアドレスへの接続を受け付けることができます。デフォルトでは，ワイルドカードアドレスを使用する設定になっています。なお，ワイルドカードアドレスを使用する場合は，次のことに注意してください。

指定されたホスト名が，hostsファイルまたはDNSなどで解決できない場合は，ワイルドカードアドレスを使用してサーバを起動します。

指定されたホスト名，またはIPアドレスがリモートホストの場合，ワイルドカードアドレスを使用してサーバを起動します。

5.8　エラーページのカスタマイズ（Webサーバ連携）

クライアントから，存在しないリソースや例外が発生したサーブレットなどにアクセスがあると，Webコンテナはエラーステータスコードを返します。クライアント側では，Webコンテナから返されたエラーステータスコードに対応するエラーページが表示されます。アプリケーションサーバでは，クライアントで表示されるエラーページの代わりに，ユーザが作成したページをクライアントに表示させることができます。これを，エラーページのカスタマイズと呼びます。

この節では，Webサーバと連携した場合の，Webサーバの機能を使用したエラーページのカスタマイズについて説明します。

この節の構成を次の表に示します。

表5‒17　この節の構成（エラーページのカスタマイズ（Webサーバ連携））

分類

タイトル

参照先

解説

エラーページのカスタマイズの概要

5.8.1

エラーページのカスタマイズの仕組み

5.8.2

設定

実行環境での設定（Smart Composer機能を使用する場合）

5.8.3

実行環境での設定（Smart Composer機能を使用しない場合）

5.8.4

注意事項

エラーページのカスタマイズの注意事項

5.8.5

注　「実装」および「運用」について，この機能固有の説明はありません。

注意事項

Webサーバの機能を使用したエラーページのカスタマイズは，Webサーバ連携機能を使用する場合に使用できる機能です。WebサーバがHTTP Serverの場合だけ使用できます。Microsoft IISの場合は使用できません。

5.8.1　エラーページのカスタマイズの概要

エラーページをカスタマイズするには，Servlet仕様で規定されているweb.xmlの<error-page>タグを使用する方法と，Webサーバの機能を使用する方法があります。ただし，リダイレクタがWebコンテナとの通信に失敗した場合など，リダイレクタがエラーを返す場合のエラーページは，web.xmlの<error-page>タグを使用する方法ではカスタマイズできません。リダイレクタがエラーを返す場合のエラーページのカスタマイズは，Webサーバの機能を使用する方法で行ってください。エラー発生場所とエラーページのカスタマイズ方法の対応を表に示します。

表5‒18　エラー発生場所とエラーページのカスタマイズ方法の対応

エラー発生場所

カスタマイズ方法

Webサーバの機能を使用する方法

web.xmlの<error-page>タグを使用する方法

Webコンテナ

○

○

リダイレクタ

○

×

（凡例）　○：カスタマイズできる　×：カスタマイズできない

なお，Webコンテナでエラーが発生する条件と，対応するエラーステータスコードについては「付録C　エラーステータスコード」を参照してください。

5.8.2　エラーページのカスタマイズの仕組み

エラーページのカスタマイズの処理の仕組みを，Webコンテナでエラーが発生した場合，およびリダイレクタでエラーが発生した場合のそれぞれについて説明します。

Webコンテナでエラーが発生した場合

Webコンテナからのエラーステータスコードは，リダイレクタが受信します。リダイレクタは，エラーページの作成をWebサーバに委任し，Webサーバでエラーステータスコードに対応したユーザ作成のページをクライアントに送信します。これによって，クライアントでは，ユーザが作成したページが表示されます。

エラーページのカスタマイズの処理の流れを次の図に示します。

図5‒21　ユーザ作成のエラーページ表示の流れ（Webサーバの機能を使用する場合）

図中の1.〜3.について説明します。

クライアントから存在しないリソースへのアクセスがあると，Webコンテナでは，404エラーをWebサーバに返します。

リダイレクタは404エラーを受け取ると，設定情報※を基にして，404エラーに対応するエラーページの生成をWebサーバに依頼します。

Webサーバでは，設定情報※を基に404エラーに対応するエラーページ「missing.html」を，クライアントに返します。

リダイレクタでエラーが発生した場合

リダイレクタでエラーが発生すると，リダイレクタは設定情報を基にして，発生したエラーに対応するエラーページの生成をWebサーバに依頼します。Webサーバでは，設定情報※を基にエラーステータスコードに対応したユーザ作成のページをクライアントに送信します。これによって，クライアントでは，ユーザが作成したページが表示されます。

注※

エラーページをカスタマイズするためには，あらかじめ，エラーステータスコードとエラーページの対応づけをしておく必要があります。

対応づけの概要を次の図に示します。

図5‒22　エラーステータスコードとエラーページの対応づけ（Webサーバの機能を使用する場合）

エラーが発生したときに，エラーステータスコードが表示されたエラーページの代わりにユーザが作成したエラーページを表示させるためには，ユーザが作成したエラーページを特定のエラーステータスコードと対応づけます。該当するエラーステータスコードのエラーが発生した場合には，Webサーバ（HTTP Server）に設定された情報を基に，エラーステータスコードに対応したエラーページをクライアントに送信します。

5.8.3　実行環境での設定（Smart Composer機能を使用する場合）

ここでは，エラーページのカスタマイズの設定について説明します。

(1)　設定方法

エラーステータスコードとエラーページとの対応づけは，次のファイルで定義します。

簡易構築定義ファイル

論理Webサーバ（web-server）の<configuration>タグ内に，worker.<ワーカ名>.delegate_error_codeパラメタで，エラーページに対応づけたいエラーステータスコードを設定します。

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

httpsd.conf

ErrorDocumentディレクティブで，エラーステータスコードと，対応するエラーページのファイル名を対応づけます。

httpsd.conf（HTTP Server定義ファイル）については，マニュアル「HTTP Server」を参照してください。

(a)　エラーステータスコード設定時の注意事項

簡易構築定義ファイルでエラーステータスコードを指定する場合の注意事項を次に示します。

エラーステータスコードは，ワーカ単位で指定します。

エラーステータスコードを指定できるワーカのタイプは，「ajp13」だけです。ワーカのタイプが「lb」（ラウンドロビンに基づく負荷分散をするときの設定），および「post_size_lb」（POSTデータサイズに基づく振り分けをするときの設定）の場合，指定した内容は無視されます。

指定できるエラーステータスコードは，次の表のとおりです。これ以外のエラーステータスコードにエラーページを対応づけることはできません。

表5‒19　エラーページと対応づけできるエラーステータスコード

エラーステータスコード

説明句

400

Bad Request

401

Unauthorized

402

Payment Required

403

Forbidden

404

Not Found

405

Method Not Allowed

406

Not Acceptable

407

Proxy Authentication Required

408

Request Time-out

409

Conflict

410

Gone

411

Length Required

412

Precondition Failed

413

Request Entity Too Large

414

Request-URI Too Long

415

Unsupported Media Type

416

Requested Range Not Satisfiable

417

Expectation Failed

422

Unprocessible Entity

423

Locked

424

Failed Dependency

500

Internal Server Error

501

Not Implemented

502

Bad Gateway

503

Service Unavailable

504

Gateway Time-out

505

HTTP Version not supported

507

Insufficient Storage

510

Not Extended

(b)　ErrorDocumentディレクティブ指定時の注意事項

httpsd.confでErrorDocumentディレクティブを指定する場合の注意事項を次に示します。

ErrorDocumentディレクティブにローカルURLを使用する場合には，リダイレクタがWebコンテナに転送しないURLを指定する必要があります。

ルートコンテキストの使用時など，リダイレクタの設定で「/*」というURLパターンをワーカにマッピングしている場合，すべてのリクエストがWebコンテナに転送されます。そのため，ErrorDocumentディレクティブには，Webコンテナ上のリソースを，完全URLを使用して設定してください。

ルートコンテキストを使用する場合で，エラーステータスコード404発生時に，Webコンテナ上のルートコンテキスト配下のerror404.jspを表示させるための設定例を次に示します。hostAは，Webサーバ稼働ホストです。

（例）

ErrorDocument 404 http://hostA/error404.jsp

また，このときWebコンテナが停止している場合には，リダイレクタはエラーステータスコード500のエラーを返します。このため，Webコンテナが停止している際のエラーページをカスタマイズするには，ErrorDocumentディレクティブで，エラーステータスコード500に対して別のWebサーバのリソースを，完全URLで指定する必要があります。

(2)　設定例

エラーページのカスタマイズの例を次に示します。

簡易構築定義ファイルの例

：
<param>
  <param-name>worker.list</param-name>
  <param-value>worker1</param-value>
</param>
<param>
  <param-name>worker.worker1.type</param-name>
  <param-value>ajp13</param-value>
</param>
<param>
  <param-name>worker.worker1.host</param-name>
  <param-value>host1</param-value>
</param>
<param>
  <param-name>worker.worker1.delegate_error_code</param-name>
  <param-value>404</param-value>
</param>
：

worker.<ワーカ名>.delegate_error_codeパラメタに，エラーステータスコード「404（Not Found）」を定義しています。

httpsd.confの例

# httpsd.confの記述#
#　　　　　：
ErrorDocument 404 /missing.html

エラーステータスコードと，対応するエラーページのファイル名を対応づけます。エラーステータスコード「404（Not Found）」のエラーが発生した場合に，missing.htmlファイルを表示するようになります。

ErrorDocumentディレクティブの詳細については，マニュアル「HTTP Server」を参照してください。

5.8.4　実行環境での設定（Smart Composer機能を使用しない場合）

ここでは，エラーページのカスタマイズの設定について説明します。

(1)　設定方法

エラーステータスコードとエラーページとの対応づけは，次のファイルで定義します。

workers.properties

worker.<ワーカ名>.delegate_error_codeキーに，エラーページに対応づけたい，エラーステータスコードを設定します。

workers.properties（ワーカ定義ファイル）については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。

httpsd.conf

ErrorDocumentディレクティブで，エラーステータスコードと，対応するエラーページのファイル名を対応づけます。

httpsd.conf（HTTP Server定義ファイル）については，マニュアル「HTTP Server」を参照してください。

workers.properties設定時の注意事項

エラーステータスコードは，ワーカ単位で指定します。

エラーステータスコードを指定できるワーカのタイプは，「ajp13」だけです。ワーカのタイプが「lb」（ラウンドロビンに基づく負荷分散をするときの設定）の場合，指定した内容は無視されます。

指定できるエラーステータスコードは，次の表のとおりです。これ以外のエラーステータスコードにエラーページを対応づけることはできません。

表5‒20　エラーページと対応づけできるエラーステータスコード

エラーステータスコード

説明句

400

Bad Request

401

Unauthorized

402

Payment Required

403

Forbidden

404

Not Found

405

Method Not Allowed

406

Not Acceptable

407

Proxy Authentication Required

408

Request Time-out

409

Conflict

410

Gone

411

Length Required

412

Precondition Failed

413

Request Entity Too Large

414

Request-URI Too Long

415

Unsupported Media Type

416

Requested Range Not Satisfiable

417

Expectation Failed

422

Unprocessible Entity

423

Locked

424

Failed Dependency

500

Internal Server Error

501

Not Implemented

502

Bad Gateway

503

Service Unavailable

504

Gateway Time-out

505

HTTP Version not supported

507

Insufficient Storage

510

Not Extended

ErrorDocumentディレクティブ指定時の注意事項

ErrorDocumentディレクティブにローカルURLを使用する場合には，リダイレクタがWebコンテナに転送しないURLを指定する必要があります。

ルートコンテキストの使用時など，リダイレクタの設定で「/*」というURLパターンをワーカにマッピングしている場合，すべてのリクエストがWebコンテナに転送されます。そのため，ErrorDocumentディレクティブには，Webコンテナ上のリソースを，完全URLを使用して設定してください。

ルートコンテキストを使用する場合で，エラーステータスコード404発生時に，Webコンテナ上のルートコンテキスト配下のerror404.jspを表示させるための設定例を次に示します。hostAは，Webサーバ稼働ホストです。

ErrorDocument 404 http://hostA/error404.jsp

また，このときWebコンテナが停止している場合には，リダイレクタはエラーステータスコード500のエラーを返します。このため，Webコンテナが停止している際のエラーページをカスタマイズするには，ErrorDocumentディレクティブで，エラーステータスコード500に対して別のWebサーバのリソースを，完全URLで指定する必要があります。

(2)　設定例

エラーページのカスタマイズの例を次に示します。

workers.propertiesの例

# ワーカ定義ファイルの記述
worker.list=worker1

worker.worker1.type=ajp13
worker.worker1.host=host1
worker.worker1.port=8007
worker.worker1.delegate_error_code=404

worker.<ワーカ名>.delegate_error_codeキーに，エラーステータスコード「404（Not Found）」を定義しています。

httpsd.confの例

# httpsd.confの記述#
#　　　　　：
ErrorDocument 404 /missing.html

エラーステータスコードと，対応するエラーページのファイル名を対応づけます。エラーステータスコード「404（Not Found）」のエラーが発生した場合に，missing.htmlファイルを表示するようになります。

ErrorDocumentディレクティブの詳細については，マニュアル「HTTP Server」を参照してください。

5.8.5　エラーページのカスタマイズの注意事項

Webサーバ連携機能を使用する場合に，Webサーバの機能を使用してエラーページをカスタマイズするときの注意事項を次に示します。

エラーページのカスタマイズは，WebサーバがHTTP Serverの場合だけ使用できます。このため，Microsoft IISと連携している場合に，workers.propertiesにエラーページのカスタマイズを設定しても，無効となります。

Servlet 2.3仕様に対応したWebアプリケーションでは，サーブレットの仕様で規定されているweb.xmlの<error-page>タグによるエラーページのカスタマイズ機能を使用している場合，Webコンテナは<error-page>タグに記述されているページへのアクセス結果をステータスコードとして返却します。このため，<error-page>タグに記述されているページへのアクセスでエラーが発生しない場合には，この機能は動作しません。

エラーページのカスタマイズをするための設定が，ワーカ定義（workers.propertiesまたは簡易構築定義ファイル）またはhttpsd.confのどちらか一方にしかない場合，設定されているエラーがWebコンテナで発生しても，ユーザが設定したファイルは表示されません。

エラーページの生成を委任するエラーステータスコードがワーカ定義だけに指定されている（httpsd.confのErrorDocumentディレクティブを定義していない）場合，そのエラーステータスコードのエラーが発生したときに返却されるエラーページは，HTTP Serverが自動生成したページになります。

5.9　ドメイン名指定でのトップページの表示

デプロイしたWebアプリケーションにアクセスするとき，URLにドメイン名を指定するだけで，index.htmlやindex.jspなどの，Webアプリケーションのトップページを表示させることができます。この機能は，Webサーバ連携機能を使用する場合に使用できます。ここでは，index.htmlやindex.jspなどのファイルを，welcomeファイルと呼びます。

この節では，ドメイン名指定でのトップページの表示について説明します。

この節の構成を次の表に示します。

表5‒21　この節の構成（ドメイン名指定でのトップページの表示）

分類

タイトル

参照先

解説

ドメイン名指定でのトップページの表示について

5.9.1

設定

実行環境での設定（Smart Composer機能を使用する場合）

5.9.2

実行環境での設定（Smart Composer機能を使用しない場合）

5.9.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

5.9.1　ドメイン名指定でのトップページの表示について

ドメイン名だけでトップページを表示させるには，welcomeファイルをルートコンテキストに配置する必要があります。ルートコンテキストとは，コンテキストルート※が空文字（コンテキストルートに名称が指定されていない）のコンテキストです。

注※

Webアプリケーションをまとめた管理単位を，コンテキストといいます。このコンテキストのルートパスをコンテキストルートといいます。Webアプリケーションにアクセスするときは，コンテキストルートをURL上に指定します。

コンテキストとコンテキストルートについて，次の図に示します。

図5‒23　コンテキストとコンテキストルート

ドメイン名だけでトップページを表示させるには，次の設定が必要になります。

リダイレクタの設定

ルートコンテキストには，Webサーバ経由でアクセスします。このため，リダイレクタのURLマッピング定義で，該当するURLがリダイレクトされるように設定する必要があります。mod_jk.conf（HTTP Serverの場合）またはuriworkermap.properties（Microsoft IISの場合）に設定します。

アプリケーションの設定

インポートしたJ2EEアプリケーションのコンテキストルートに空文字を指定します。

(1)　注意事項

ドメイン名指定でのトップページの表示機能を使用する上での注意事項を次に示します。

コンテキストルートとルートコンテキストが同じ階層を持つ場合にアクセスされる階層

コンテキストルートとルートコンテキストが同じ階層を持つ場合，コンテキストルートの階層にアクセスされます。例を次に示します。

例

WebアプリケーションAがコンテキストルートexampleを持ち，WebアプリケーションBのコンテキストルートが空文字で，両方のWebアプリケーション内に「example」という階層を持つ場合の例を説明します。

図5‒24　コンテキストルートとルートコンテキストが同じ階層を持つ場合にアクセスされる階層を持つ例

この場合，「http://<ホスト名>/example」にアクセスすると，コンテキストルートを持つ，WebアプリケーションAのexample/index.jspが実行されます。

ただし，ディレクトリ内に，forwardやincludeがある場合で，例えばディレクトリ内のforwardにアクセスすると，ルートコンテキストのindex.jspにforwardされます。

Webアプリケーション内の構成

URLの先頭に「ejb」や「web」を使用することはできません。

使用できない例

http://<ホスト名>:<ポート番号>/ejb/

http://<ホスト名>:<ポート番号>/web/

このため，ルートコンテキストとしてデプロイするWebアプリケーションでは，「ejb」または「web」が先頭になるような構成にしないでください。

メッセージ本文での表示方法

コンソールやログファイルに出力されるメッセージでは，コンテキストルートは空文字で表示されます。

5.9.2　実行環境での設定（Smart Composer機能を使用する場合）

ここでは，ドメイン名指定でトップページを表示するための設定について説明します。

デプロイしたWebアプリケーションにアクセスするとき，URLにドメイン名を指定するだけで，index.htmlやindex.jspなどの，Webアプリケーションのトップページを表示させることができます。

(1)　設定方法

ドメイン名指定でトップページを表示するための設定方法を次に示します。

ルートコンテキストを設定します。

ルートコンテキストとは，コンテキストルートに名称が指定されていないコンテキストのことです。ルートコンテキストの指定は，動作モードによって異なります。

J2EEアプリケーションのコンテキストルート定義については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「9.11.1　J2EEアプリケーションのコンテキストルート定義」を参照してください。

リダイレクタで，ルートコンテキストへのリクエストの振り分けを設定します。

ルートコンテキストへのリクエストの振り分けは，簡易構築定義ファイルに指定します。

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　設定例

ルートコンテキストへのリクエストの振り分けの設定例について説明します。

URLにドメイン名を指定するだけで，Webアプリケーションのトップページを表示させるためには，リダイレクタのURLマッピング定義で，ルートコンテキストにリクエストが振り分けられるように設定してください。例えば，ルートコンテキストは「worker1」に，「/examples」はworker2に振り分ける場合には，次のように指定します。

簡易構築定義ファイルの例

：
<param>
  <param-name>JkMount</param-name>
  <param-value>/* worker1</param-value>
  <param-value>/examples/* worker2</param-value>
</param>
：

5.9.3　実行環境での設定（Smart Composer機能を使用しない場合）

ここでは，ドメイン名指定でトップページを表示するための設定について説明します。

デプロイしたWebアプリケーションにアクセスするとき，URLにドメイン名を指定するだけで，index.htmlやindex.jspなどの，Webアプリケーションのトップページを表示させることができます。

(1)　設定方法

ドメイン名指定でトップページを表示するための設定方法を次に示します。

ルートコンテキストを設定します。

ルートコンテキストとは，コンテキストルートに名称が指定されていないコンテキストのことです。ルートコンテキストの指定は，動作モードによって異なります。

サーバ管理コマンドを使用してJ2EEアプリケーションのプロパティを定義するときにルートコンテキストを指定します。コンテキストルートとしてルートコンテキストを設定する場合は，空文字を指定します。J2EEアプリケーションのコンテキストルート定義については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「9.11.1　J2EEアプリケーションのコンテキストルート定義」を参照してください。

リダイレクタで，ルートコンテキストへのリクエストの振り分けを設定します。

ルートコンテキストへのリクエストの振り分けは，WebサーバにHTTP Serverを使用している場合はmod_jk.confに，Microsoft IISを使用している場合はuriworkermap.propertiesに指定します。

mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）については，「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）については，「13.2.3　uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）」を参照してください。

(2)　設定例

ルートコンテキストへのリクエストの振り分けの設定例について説明します。

URLにドメイン名を指定するだけで，Webアプリケーションのトップページを表示させるためには，リダイレクタのURLマッピング定義で，ルートコンテキストにリクエストが振り分けられるように設定してください。例えば，ルートコンテキストは「worker1」に，「/examples」はworker2に振り分ける場合には，次のように指定します。

mod_jk.confの例（HTTP Serverの場合）

JkMount /* worker1
JkMount /examples/* worker2

uriworkermap.propertiesの例（Microsoft IISの場合）

/*=worker1
/examples/*=worker2

5.10　Webコンテナへのゲートウェイ情報の通知

この節では，Webコンテナへのゲートウェイ情報の通知について説明します。

ゲートウェイ指定機能によって，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようになります。

この節の構成を次の表に示します。

表5‒22　この節の構成（Webコンテナへのゲートウェイ情報の通知）

分類

タイトル

参照先

解説

ゲートウェイ指定機能

5.10.1

設定

実行環境での設定（Smart Composer機能を使用する場合）

5.10.2

実行環境での設定（Smart Composer機能を使用しない場合）

5.10.3

注意事項

Webコンテナにゲートウェイ情報を通知する場合の注意事項

5.10.4

注　「実装」および「運用」について，この機能固有の説明はありません。

5.10.1　ゲートウェイ指定機能

クライアントと，Webサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合で，welcomeファイルやForm認証画面への遷移時などにWebコンテナが自動的にリダイレクトするとき，Webコンテナではゲートウェイの情報を得ることができず，転送先のURLを正しく作成できないことがあります。

これを解決するために，ゲートウェイ指定機能を使用します。ゲートウェイ指定機能によって，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようになります。

ゲートウェイ指定機能は次のような場合に使用できます。

クライアントと，Webサーバとの間にSSLアクセラレータを配置する場合

クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，welcomeファイルやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。

この場合，ゲートウェイ指定機能を使用して，スキームを常にhttpsと見なすように指定することで，正しくリダイレクトできるようになります。

Hostヘッダのないリクエストに対して，リクエストを受けたWebサーバ以外へリダイレクトする必要がある場合

Hostヘッダのないリクエストをリダイレクトする場合，リダイレクト先URLのホスト名・ポート番号は，リクエストを受けたWebサーバのホスト名・ポート番号となります。

ゲートウェイ指定機能は，Webサーバの前に負荷分散機を配置している場合などで，クライアントがアクセスするURLのホスト名・ポート番号が，リクエストを受けたWebサーバと異なるときに使用します。これによって，クライアントからアクセスするホスト名・ポート番号が指定されるので，正しくリダイレクトできるようになります。

なお，Webサーバと連携する場合で，かつ一つのリダイレクタに複数の異なる経路でアクセスする場合（複数のゲートウェイからWebコンテナにHTTPリクエストが転送される場合など），ゲートウェイ指定機能を使用できません。Webサーバと連携する場合，ゲートウェイ指定機能を使用するには，Webコンテナへのアクセス経路は一つになる構成にする必要があります。

5.10.2　実行環境での設定（Smart Composer機能を使用する場合）

ここは，ゲートウェイ指定機能を使用するための設定について説明します。

クライアントとWebサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合，ゲートウェイ指定機能を使用することで，Webコンテナにゲートウェイ情報を通知し，WebアプリケーションのトップページやForm認証画面に正しくリダイレクトできるようになります。

(1)　設定方法

ゲートウェイ指定機能を使用するための設定方法を次に示します。

ゲートウェイのホスト名・ポート番号・リダイレクト先URLのスキームを，リダイレクタごとに指定します。

Webサーバを再起動します。

なお，ゲートウェイのホスト名・ポート番号・リダイレクト先URLのスキームは，簡易構築定義ファイルに指定します。論理Webサーバ（web-server）の<configuration>タグ内に，次のパラメタで指定します。

ホスト名：JkGatewayHost

ポート番号：JkGatewayPort

リダイレクト先URLのスキーム：JkGatewayHttpsScheme

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　設定例

ゲートウェイ指定機能の設定例を次に示します。

図5‒25　ゲートウェイ指定機能の設定例

この例では，クライアントとWebサーバの間にSSLアクセラレータを配置しています。クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，WebアプリケーションのトップページやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。この場合，ゲートウェイ指定機能を使用して，スキームを常にHTTPSと見なすように指定することで，正しくリダイレクトできるようになります。

簡易構築定義ファイルの例を次に示します。ここでは，リダイレクト先URLのスキームを常にHTTPSと見なすようにJkGatewayHttpsSchemeパラメタで「On」を指定します。

簡易構築定義ファイルの例

：
<param>
  <param-name>JkGatewayHost</param-name>
  <param-value>host1</param-value>
</param>
<param>
  <param-name>JkGatewayPort</param-name>
  <param-value>4443</param-value>
</param>
<param>
  <param-name>JkGatewayHttpsScheme</param-name>
  <param-value>On</param-value>
</param>
：

5.10.3　実行環境での設定（Smart Composer機能を使用しない場合）

ここでは，ゲートウェイ指定機能を使用するための設定について説明します。

クライアントとWebサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合，ゲートウェイ指定機能を使用することで，Webコンテナにゲートウェイ情報を通知し，WebアプリケーションのトップページやForm認証画面に正しくリダイレクトできるようになります。

(1)　設定方法

ゲートウェイ指定機能を使用するための設定方法を次に示します。

ゲートウェイのホスト名・ポート番号・リダイレクト先URLのスキームを，リダイレクタごとに指定します。

Webサーバを再起動します。

なお，ゲートウェイのホスト名・ポート番号・リダイレクト先URLのスキームは，WebサーバにHTTP Serverを使用している場合はmod_jk.confに，Microsoft IISを使用している場合はisapi_redirect.confに指定します。指定するキーはそれぞれ次のとおりです。

mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）については，「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）については，「13.2.1　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。

mod_jk.confの場合

ホスト名：JkGatewayHostキー

ポート番号：JkGatewayPortキー

リダイレクト先URLのスキーム：JkGatewayHttpsSchemeキー

isapi_redirect.confの場合

ホスト名：gateway_hostキー

ポート番号：gateway_portキー

リダイレクト先URLのスキーム：gateway_https_schemeキー

(2)　設定例

ゲートウェイ指定機能の設定例を次に示します。

図5‒26　ゲートウェイ指定機能の設定例

この例では，クライアントとWebサーバの間にSSLアクセラレータを配置しています。クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，WebアプリケーションのトップページやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。この場合，ゲートウェイ指定機能を使用して，スキームを常にHTTPSと見なすように指定することで，正しくリダイレクトできるようになります。

mod_jk.conf，およびisapi_redirect.confの例を次に示します。ここでは，リダイレクト先URLのスキームを常にHTTPSと見なすようにmod_jk.confのJkGatewayHttpsSchemeキーで「On」，isapi_redirect.confのgateway_https_schemeキーで「true」を指定します。

mod_jk.confの例（HTTP Serverの場合）

JkGatewayHost host1

JkGatewayPort 4443

JkGatewayHttpsScheme On

isapi_redirect.confの例（Microsoft IISの場合）

gateway_host=host1

gateway_port=4443

gateway_https_scheme=true

5.10.4　Webコンテナにゲートウェイ情報を通知する場合の注意事項

ゲートウェイ指定機能を使用する上での注意事項を次に示します。

リダイレクト先URLのホスト名，およびポート番号の指定について

通常，ブラウザはHostヘッダを付けてリクエストを送信するため，リダイレクト先URLのホスト名やポート番号を指定する必要はありません。

なお，リクエストにHostヘッダがあるかどうかは，javax.servlet.http.HttpServletRequestクラスのgetHeaderメソッドに，引数「Host」を指定して呼び出すことで確認できます。

サーブレットAPIの動作について

ゲートウェイ指定機能の利用によって，一部のサーブレットAPIの動作が変わります。WebアプリケーションでAPIを利用するときには注意が必要です。

なお，動作が変わるサーブレットAPIについては，「9.4.2(1)　ゲートウェイ指定機能を使用する場合の注意」を参照してください。

web.xmlの<transport-guarantee>タグについて

ゲートウェイ指定機能でスキームをHTTPSと見なすように設定した場合，WebサーバへのリクエストがHTTPであってもHTTPSであると見なされます。このため，web.xmlの<transport-guarantee>タグでINTEGRALやCONFIDENTIALを指定してもHTTPSのURLへリダイレクトされないので注意してください。

CookieのSecure属性について

ゲートウェイ指定機能でスキームをHTTPSと見なすように設定している場合に，Webコンテナが生成したセッションIDを，Cookieによってクライアントに返すとき，そのCookieにはSecure属性が付与されます。

ゲートウェイを通さないWebサーバへの通信

リダイレクタでゲートウェイ指定機能を有効にした場合，そのWebサーバにSSLアクセラレータや負荷分散機などのゲートウェイを通さないとき，直接HTTP通信はできません。

5.11　Webコンテナ単位での同時実行スレッド数の制御

この節では，Webコンテナ単位での同時実行スレッド数の制御について説明します。

この節の構成を次の表に示します。

表5‒23　この節の構成（Webコンテナ単位での同時実行スレッド数の制御）

分類

タイトル

参照先

解説

同時実行スレッド数の制御の仕組み（Webコンテナ単位）

5.11.1

設定

実行環境での設定（J2EEサーバの設定）

5.11.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

5.11.1　同時実行スレッド数の制御の仕組み（Webコンテナ単位）

Webコンテナ単位での同時実行スレッド数の制御の仕組みについて，次の図で説明します。

図5‒27　Webコンテナ単位での同時実行スレッド数制御

例えば，Webコンテナに二つのWebアプリケーションがデプロイされていて，同時実行スレッド数に「5」を設定している場合，二つのWebアプリケーションで同時に実行できるスレッド数は5となります。

Webコンテナ単位に同時実行スレッド数を設定することで，Webコンテナにデプロイされた複数のWebアプリケーションのうち，一つのWebアプリケーションにアクセスが集中した場合でも，アクセスが集中しているWebアプリケーションにスレッドを割り当てることができます。この仕組みについて次の図で説明します。

図5‒28　アクセスが集中したときのスレッドの扱い（Webコンテナ単位の場合）

図のように，WebコンテナにWebアプリケーションが二つデプロイされていて，同時実行スレッド数に「5」が設定されている場合に，Webアプリケーション1にリクエストが集中すると，5スレッドすべてがWebアプリケーション1に割り当てられます。

一方，Webアプリケーション2に対するリクエストは，Webアプリケーション1のリクエスト処理が完了するまで，Webコンテナ単位の実行待ちキューにためられます。なお，Webコンテナ単位の実行待ちキューにためられたリクエストは，リクエスト処理の完了後，順次実行されます。

5.11.2　実行環境での設定（J2EEサーバの設定）

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webコンテナ単位での同時実行スレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のどちらかのパラメタを指定します。

webserver.connector.ajp13.max_threads

Webコンテナ全体の最大同時実行スレッド数を指定します。このパラメタはWebサーバ連携の場合に指定します。

webserver.connector.inprocess_http.max_execute_threads

Webコンテナ全体の最大同時実行スレッド数を指定します。このパラメタはインプロセスHTTPサーバを使用する場合に指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

5.12　リダイレクタとの通信用オブジェクト

Explicitメモリブロック領域の確保や解放は，Webコンテナによって実行されます。Webコンテナとリダイレクタ間の通信に使用する通信用オブジェクトは，通常は常設コネクションとして使い回され，Webサーバが起動している間は保持されます。

Webコンテナとリダイレクタの間で障害が発生した場合などに通信の切断・再接続が発生すると，通信用オブジェクトは破棄・再生成されます。このとき，破棄された通信用オブジェクトがTenured領域に残ります。

これを防ぐため，J2EEサーバでは，Webコンテナとリダイレクタ間の通信用オブジェクトをExplicitヒープに配置します。これによって，不要なオブジェクトがTenured領域に残ることを防ぎ，FullGCの発生を抑止します。

通信の確立と切断のタイミングに対応するExplicitメモリブロックの配置の流れについて説明します。

通信が確立されたとき

通信が確立されると，コネクション1個に対して1個のExplicitメモリブロックが作成されます。作成されたExplicitメモリブロックに，リダイレクタとの通信用オブジェクトが配置されます。

通信が切断されたとき

通信が切断されると，Explicitメモリブロック内に配置されたリダイレクタとの通信用オブジェクトごと，1個のExplicitメモリブロックの解放が予約されます。

通信が切断された直後は，解放が予約された状態です。解放が予約されたExplicitメモリブロックは，そのあとでCopyGCまたはFullGCが実行されたときに実際に解放されます。このとき，解放が予約されたすべての領域が解放されます。

5.13　Explicitヒープのチューニング

ここでは，Explicitヒープのチューニングについて説明します。

5.13.1　Explicitヒープのメモリサイズの見積もり（J2EEサーバが使用するメモリサイズの見積もり）

Explicitヒープをチューニングする前提として，明示管理ヒープ機能を使用するための設定が必要です。明示管理ヒープ機能は，JavaVMの起動オプションとして-XX:+HitachiUseExplicitMemoryが指定されている場合に有効になります。J2EEサーバの場合，明示管理ヒープ機能はデフォルトで使用される設定になっています。また，Tenured領域のメモリサイズ増加の要因となるオブジェクトがExplicitヒープに配置されるように設定されています。このため，J2EEサーバが配置するオブジェクトに必要なExplicitヒープのメモリサイズを必ず見積もってください。

明示管理ヒープ機能は，Explicitヒープのメモリサイズを適切に見積もった上で使用しないと，効果が出ません。

J2EEサーバでは，Tenured領域のメモリサイズ増加の要因になる，次のオブジェクトをExplicitヒープに配置します。

リダイレクタとの通信用オブジェクト

HTTPセッションに関するオブジェクト

リダイレクタとの通信用オブジェクトが利用するExplicitヒープのメモリサイズは，定義ファイルでの設定値から算出できます。見積もり方法については，「5.13.2　リダイレクタとの通信用オブジェクトで利用するメモリサイズ」を参照してください。

HTTPセッションに関するオブジェクトが利用するExplicitヒープのメモリサイズは，実際にアプリケーションを動作させて情報を取得した上で見積もります。見積もり方法については，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.11.2　HTTPセッションに関するオブジェクトで利用するメモリサイズ」を参照してください。

Explicitヒープのメモリサイズを見積もった結果，HTTPセッションに関するオブジェクトが利用するExplicitヒープのメモリサイズが極端に大きい場合は，マニュアル「アプリケーションサーバ システム設計ガイド」の「付録A　HTTPセッションで利用するExplicitヒープの効率的な利用」を参考にして，アプリケーションの設計を見直してください。V9互換モードでHTTPセッションを見積もる際には，リダイレクタとの通信用オブジェクトをExplicitヒープに配置しないように，J2EEサーバのユーザプロパティ「ejbserver.server.eheap.ajp13.enabled」にfalseを指定してください。

5.13.2　リダイレクタとの通信用オブジェクトで利用するメモリサイズ

リダイレクタとの通信用オブジェクトで利用するExplicitヒープのメモリサイズは，次の式で見積もります。

リダイレクタとの通信用オブジェクトで利用するExplicitヒープのメモリサイズ
=1コネクションで使用するメモリサイズ※×リダイレクタとのコネクション数

注※

1コネクションで使用するメモリサイズは，明示管理ヒープ機能の自動配置機能の使用の有無によって異なります。明示管理ヒープ機能の自動配置機能の使用の有無による1コネクションで使用するメモリサイズを次に示します。

表5‒24　明示管理ヒープ機能の自動配置機能の使用の有無による1コネクションで使用するメモリサイズ

項番

明示管理ヒープ機能の自動配置機能使用の有無

1コネクションで使用するメモリサイズ

1

○

144キロバイト

2

×

128キロバイト

（凡例）

○：明示管理ヒープ機能の自動配置機能を使用する。

×：明示管理ヒープ機能の自動配置機能を使用しない。

WebサーバとWebコンテナが1：1のシステム構成では，「リダイレクタとのコネクション数」として，Webサーバで設定する最大接続数を使用してください。

最大接続数の設定個所は，Webサーバおよび使用するOSの種類によって異なります。設定個所を次の表に示します。

表5‒25　最大接続数の設定個所

Webサーバ

OS

設定個所

HTTP Server

Windows

httpsd.conf（HTTP Server定義ファイル）のThreadsPerChildディレクティブ

UNIX

httpsd.conf（HTTP Server定義ファイル）のMaxClientsディレクティブ

Microsoft IIS

Windows

Webサイトのプロパティの「パフォーマンス」タブで設定する「最大接続数」

5.13.3　稼働情報による見積もり

J2EEサーバのテストを実施する場合，または運用開始後のJ2EEサーバによる実際のExplicitヒープ使用状況は，稼働情報で確認できます。ここでは，稼働情報による確認手順について説明します。

稼働情報の出力内容，出力するための設定，および稼働情報ファイルの出力先については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「3.3　稼働情報ファイルの出力機能」を参照してください。

(1)　稼働情報を使用した見積もりの考え方

稼働情報を使用した見積もりでは，システムに必要なExplicitヒープ領域のメモリサイズは次のようになります。

HTTPセッションで使用するExplicitヒープ領域のメモリサイズ

1.の領域を除いた，内部（コンテナ）で使用するExplicitヒープ領域のメモリサイズ

アプリケーションおよびJavaVMで使用するExplicitヒープ領域のメモリサイズ

JavaVMがExplicitメモリブロックを管理するために使用するExplicitヒープ領域のメモリサイズ（JavaヒープのSurvivor領域のサイズ×2）

1.〜3.のメモリサイズは，稼働情報で確認できます。4.は，明示管理ヒープの自動解放機能が有効な場合に，「JavaヒープのSurvivor領域のサイズ×2」のメモリサイズを使用します。

1.〜3.で示す各Explicitヒープ領域を使用するものの例を表で示します。なお，1.〜3.は表中の項番1〜3に対応しています。

表5‒26　Explicitヒープ領域を使用するものの具体例

項番

Explicitヒープ領域

Explicitヒープ領域を使用するものの具体例

1

HTTPセッションで使用するExplicitヒープ領域

HTTPセッション

2

コンテナで使用するExplicitヒープ領域

リダイレクタとの通信用オブジェクト

HTTPセッション管理用オブジェクト

3

アプリケーションおよびJavaVMで使用するExplicitヒープ領域

アプリケーション

JavaVM

(2)　見積もりに使用する稼働情報取得時の注意

見積もりに使用する稼働情報は，本番環境，または本番環境と同等の環境で取得してください。

次に示す項目が本番環境と異なる場合は，稼働情報を使って適切なメモリサイズを見積もることはできません。

各定義ファイルに設定するプロパティ，およびオプションに指定する値

サーバに登録されているWebアプリケーションの数

リダイレクタとのコネクションの数

業務アプリケーションが処理するデータのサイズ

一定時間内に処理するデータの数

また，見積もりのために稼働情報を取得する場合，Explicitヒープ領域を使い切った状態にならないようExplicitヒープ領域サイズの最大値を設定するオプションを指定してください。

Explicitヒープ領域の最大サイズが不十分な状態で稼働情報を取得した場合，Explicitヒープ領域を使い切った状態になるおそれがあります。Explicitヒープ領域を使い切った状態で取得した稼働情報では，適切な見積もりはできません。Explicitヒープ領域を使い切った状態かどうかは，稼働情報のEHeapSize.HighWaterMarkの値が，Explicitヒープ領域の最大サイズの値と同じ値になっているかどうかで確認できます。稼働情報のEHeapSize.HighWaterMarkの値とExplicitヒープ領域の最大サイズの値が同じだった場合，Explicitヒープ領域を使い切っている状態となります。

(3)　見積もり方法

稼働情報を基にした見積もり方法を次に示します。

(a)　HTTPセッションで利用するExplicitヒープ領域のメモリサイズ

HTTPセッションで利用するメモリサイズは，マニュアル「アプリケーションサーバ システム設計ガイド」の「7.11.2　HTTPセッションに関するオブジェクトで利用するメモリサイズ」で示したHTTPセッションで利用するExplicitヒープのメモリサイズの式で求めます。このとき，式に含まれる「1セッションで使用するメモリサイズ」を稼働情報で確認できます。

1セッションで使用するメモリサイズは，稼働情報に出力された「Explicitメモリブロックの最大サイズ」に該当します。「Explicitメモリブロックの最大サイズ」には，稼働情報収集間隔の間に解放されたExplicitメモリブロックのうち，最大のものの利用済みサイズが出力されます。そのため，Explicitヒープを見積もる際は，64キロバイト単位で切り上げて見積もってください。さらに，明示管理ヒープ機能の自動配置機能を使用する場合は，16キロバイトを加算して見積もってください。

また，見積もりをする際は，次に示す値を参考にしてください。なお，システムで必要なセッション数は，「Explicitメモリブロックの個数」に該当します。

HTTPセッションで取得したExplicitメモリブロックの最大サイズ（HTTPSessionEMemoryBlockMaxSize.HighWaterMarkの値）

HTTPセッションで取得したExplicitメモリブロックの個数（HTTPSessionEMemoryBlockCount.HighWaterMarkの値）

(b)　コンテナで利用するExplicitヒープ領域のメモリサイズ

コンテナで使用するExplicitヒープ領域のメモリサイズは，稼働情報の「コンテナで利用するExplicitヒープサイズ」が該当します。見積もりに使用する稼働情報は取得した値の中で最大値（ContainerEHeapSize.HighWaterMarkの値）を使用してください。

(c)　アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズ

アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズは，稼働情報の「アプリケーションで利用するExplicitヒープサイズ」の値が該当します。見積もりに使用する稼働情報は取得した値の中で最大値（ApplicationEHeapSize.HighWaterMark）を使用してください。

(4)　稼働情報の確認手順

稼働情報の確認手順について説明します。ここでは，(3)による稼働情報の見積もり式を例に説明します。なお，稼働情報ファイルの出力内容については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「3.3　稼働情報ファイルの出力機能」を参照してください。

見積もり式

必要なExplicitヒープ領域のメモリサイズ
＝(HTTPSessionEMemoryBlockMaxSize.HighWaterMarkを64キロバイト単位に切り上げた値
×HTTPSessionEMemoryBlockCount.HighWaterMark)
＋ContainerEHeapSize.HighWaterMark
＋ApplicationEHeapSize.HighWaterMark
＋JavaヒープのSurvivor領域のサイズ
×2(明示管理ヒープ自動解放機能が有効な場合だけ)

それぞれの値の確認方法について説明します。

(a)　HTTPセッションで利用するExplicitヒープ領域のメモリサイズ

HTTPセッションで利用するExplicitヒープ領域のメモリサイズは，JavaVMの稼働情報ファイルに出力されるHTTPSessionEMemoryBlockMaxSize.HighWaterMark，およびHTTPSessionEMemoryBlockCount.HighWaterMarkの値を使って確認します。

HTTPセッションで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例を次の図に示します。

図5‒29　HTTPセッションで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例

HTTPSessionEMemoryBlockMaxSize.HighWaterMarkの最大値は，図中1.で示している11:00:31に取得した410472バイト（400.85キロバイト）です。

この値を64キロバイト単位に切り上げると，448キロバイトとなります。HTTPSessionEMemoryBlockCount.HighWaterMarkの最大値は図中2.で示している11:04:31に取得した57です。

これら二つの値を掛け合わせた値が，HTTPセッションで利用するExplicitヒープ領域のメモリサイズとなります。

(b)　コンテナで利用するExplicitヒープ領域のメモリサイズ

コンテナで利用するExplicitヒープ領域のメモリサイズは，JavaVMの稼働情報ファイルに出力されるContainerEHeapSize.HighWaterMarkの値を使って確認します。

コンテナで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例を次の図に示します。

図5‒30　コンテナで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例

ContainerEHeapSize.HighWaterMarkの最大値は図中1.で示している10:50:31以降に取得している6815744バイト（6656キロバイト）です。

これがコンテナで利用するExplicitヒープ領域のメモリサイズとなります。

(c)　アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズ

アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズはJavaVMの稼働情報ファイルに出力されるApplicationEHeapSize.HighWaterMarkの値を使って確認します。

アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例を次の図に示します。

図5‒31　アプリケーションおよびJavaVMで利用するExplicitヒープ領域のメモリサイズの稼働情報の出力例

ApplicationEHeapSize.HighWaterMarkの最大値は図中1.で示している10:53:31に取得した2424832バイト（2368キロバイト）です。

(d)　必要なExplicitヒープ領域のメモリサイズ

(a)〜(c)で示した稼働情報から求められる，必要なExplicitヒープ領域のメモリサイズは次のようになります。

448(キロバイト)× 57 ＋ 6656(キロバイト) ＋ 2368(キロバイト)
＝ 34560(キロバイト)≒ 34メガバイト

明示管理ヒープの自動解放機能が有効な場合，「JavaヒープのSurvivor領域のサイズ×2」を加算した値が，最終的なExplicitヒープ領域の見積もりサイズとなります。

6　インプロセスHTTPサーバ

この章では，インプロセスHTTPサーバ機能の設定について説明します。

6.1　この章の構成

アプリケーションサーバでは，Webサーバ機能としてインプロセスHTTPサーバを提供しています。インプロセスHTTPサーバとは，J2EEサーバのプロセス内で提供されるWebサーバ機能です。Webサーバを経由しないで，HTTPリクエストをJ2EEサーバのプロセスが直接受信することによって，Webサーバ連携時よりも優れた処理性能でWebサーバの機能を利用できます。

インプロセスHTTPサーバの機能と参照先を次の表に示します。

表6‒1　インプロセスHTTPサーバの機能と参照先

機能

参照先

インプロセスHTTPサーバの概要

6.2

Webクライアントからの接続数の制御

6.3

リクエスト処理スレッド数の制御

6.4

Webクライアントからの同時接続数の制御によるリクエストの流量制御

6.5

同時実行スレッド数の制御によるリクエストの流量制御

6.6

リダイレクトによるリクエストの振り分け

6.7

Persistent ConnectionによるWebクライアントとの通信制御

6.8

通信タイムアウト（インプロセスHTTPサーバ）

6.9

IPアドレス指定（インプロセスHTTPサーバ）

6.10

アクセスを許可するホストの制限によるアクセス制御

6.11

リクエストデータのサイズの制限によるアクセス制御

6.12

有効なHTTPメソッドの制限によるアクセス制御

6.13

HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ

6.14

エラーページのカスタマイズ（インプロセスHTTPサーバ）

6.15

Webコンテナへのゲートウェイ情報の通知

6.16

ログ・トレースの出力

6.17

URIのデコード機能

6.18

インプロセスHTTPサーバのログ取得の設定

6.19

cjtracesync（インプロセスHTTPサーバ用トレースファイルの同期）

6.20

SOAPアプリケーション運用時の注意事項

6.21

6.2　インプロセスHTTPサーバの概要

この節では，インプロセスHTTPサーバの概要について説明します。

この節の構成を次の表に示します。

表6‒2　この節の構成（インプロセスHTTPサーバの概要）

分類

タイトル

参照先

解説

インプロセスHTTPサーバの使用

6.2.1

インプロセスHTTPサーバで使用できる機能

6.2.2

設定

実行環境での設定（J2EEサーバの設定）

6.2.3

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.2.1　インプロセスHTTPサーバの使用

インプロセスHTTPサーバは，J2EEサーバのプロセス内で提供されるWebサーバ機能です。

Webサーバを経由しないで，HTTPリクエストをJ2EEサーバのプロセスが直接受信することによって，Webサーバ連携時よりも優れた処理性能でWebサーバの機能を利用できます。このため，性能を重視したシステムでは，インプロセスHTTPサーバを使用することを推奨します。

ただし，HTTP ServerおよびMicrosoft IISと比べて提供機能に差異があるため，機能差異を確認した上で，インプロセスHTTPサーバを使用するかどうか検討してください。また，インプロセスHTTPサーバとWebサーバ連携機能を同時に使用することはできません。システム設計時に，あらかじめどちらの機能を使用するか選択しておく必要があります。

なお，インプロセスHTTPサーバを使用する場合，次のことが前提となります。

インプロセスHTTPサーバは不正アクセスが想定される外部ネットワークからのアクセスが可能なDMZに配置しないで，ファイアウォール内の内部ネットワークに配置する必要があります。インターネットなどの外部ネットワークからアクセスされるシステムでは，DMZにプロキシサーバを配置して，内部ネットワークのインプロセスHTTPサーバに転送するようにシステムを構築する必要があります。

インプロセスHTTPサーバでは，HTTPだけがサポートされています。HTTPSはサポートされていません。HTTPSを使用する場合，SSLアクセラレータ，またはHTTP Serverのリバースプロキシを使用することが前提となります。

インプロセスHTTPサーバを使用してアクセスできるのは，J2EEサーバ上にデプロイされたWebアプリケーションだけです。なお，静的コンテンツだけをデプロイすることはできませんが，リダイレクトによるリクエストの振り分け，およびエラーページのカスタマイズを実行する場合だけ，Webアプリケーションに含まれない静的コンテンツを指定できます。

また，インプロセスHTTPサーバを使用する場合，次のことに注意してください。

WebクライアントとインプロセスHTTPサーバとのTCPコネクションの接続中に，cjstopsvコマンドを実行してJ2EEサーバを停止した場合，WebクライアントがインプロセスHTTPサーバとのTCPコネクションを切断するか，usrconf.properties（J2EEサーバ用ユーザプロパティファイル）のwebserver.connector.inprocess_http.persistent_connection.timeoutキーで指定するタイムアウトが発生するまで，J2EEサーバが停止しません。WebクライアントからのTCPコネクション切断や，タイムアウト時間に関係なくJ2EEサーバを停止したい場合は，cjstopsvコマンドに「-f」オプションを指定してJ2EEサーバを強制停止してください。

リクエストヘッダに含まれる次のヘッダは非サポートです。※1

Cookie2

Expect※2

Keep-Alive

Trailer

注※1

インプロセスHTTPサーバではヘッダを読み込みますが，非サポートのヘッダの名前や値に応じた個別の処理はしないで，そのままJ2EEアプリケーションの処理を継続します。

注※2

Expectヘッダの値が""100-continue""のリクエストを受信した場合，HTTPステータスコード100のレスポンスを返さないで，そのままJ2EEアプリケーションの処理を継続します。

リクエストヘッダに含まれるCookieヘッダの値が""（ダブルクォーテーション）で囲まれている場合，""（ダブルクォーテーション）も値の一部として扱います。

リクエストヘッダに含まれるTransfer-Encodingヘッダの値の""gzip""は非サポートです。受信したリクエストのTransfer-Encodingヘッダの該当する値は無視します。

インプロセスHTTPサーバの設定は，J2EEサーバのプロパティをカスタマイズして設定します。J2EEサーバの動作設定のカスタマイズについては，「6.2.3　実行環境での設定（J2EEサーバの設定）」を参照してください。

ポイント

インプロセスHTTPサーバは，デフォルトでは使用しない設定になっています。

6.2.2　インプロセスHTTPサーバで使用できる機能

インプロセスHTTPサーバで使用できる機能と参照先を次の表に示します。

表6‒3　インプロセスHTTPサーバで使用できる機能と参照先

機能名

参照先

Webクライアントからの接続数の制御

6.3

Webクライアントからのリクエスト処理スレッド数の制御

6.4

リクエストの流量制御

Webクライアントからの同時接続数の制御

6.5

同時実行スレッド数の制御※

6.6

リダイレクトによるリクエストの振り分け

6.7

Webクライアントとの通信制御

Persistent Connectionによる通信制御

6.8

インプロセスHTTPサーバで設定できる通信タイムアウト

6.9

インプロセスHTTPサーバで利用するIPアドレス指定※

6.10

Webクライアントからのアクセス制御

アクセスを許可するホストの制限

6.11

リクエストデータのサイズ制限

6.12

有効なHTTPメソッドの制限

6.13

Webクライアントへのレスポンスのカスタマイズ

HTTPレスポンスヘッダのカスタマイズ

6.14

エラーページのカスタマイズ

6.15

Webコンテナへのゲートウェイ情報の通知※

6.16

ログ・トレースの出力

6.17

注※

インプロセスHTTPサーバを使用しない場合（Webサーバ連携機能を使用する場合）との機能差異はありません。

6.2.3　実行環境での設定（J2EEサーバの設定）

ここでは，インプロセスHTTPサーバの設定手順について説明します。

J2EEサーバのプロセス内で提供されるWebサーバ機能を使用して，HTTPリクエストを受信するためには，インプロセスHTTPサーバ機能を使用する構成でシステムを構築する必要があります。

設定手順を次に示します。

インプロセスHTTPサーバ機能の使用を有効にします。

インプロセスHTTPサーバの仕様の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.enabledパラメタで「true」を指定します。デフォルトでは「false」が指定されています。簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

Webクライアントからの接続数の制御とリクエスト処理スレッド数の制御を設定します。

サーバを稼働するホストの性能やクライアントからのアクセス状況に合わせてリクエスト処理スレッド数を調節することで，インプロセスHTTPサーバのパフォーマンスを向上できます。設定については，「6.3　Webクライアントからの接続数の制御」および「6.4　リクエスト処理スレッド数の制御」を参照してください。

設定時の留意点を次に示します。

サーバ起動直後から大量のリクエストを処理する必要がある場合は，サーバ起動時に作成するリクエスト処理スレッド数に大きな値を指定してください。

予備スレッドの最大数を大きくすると急なアクセス増加にも迅速に対応できますが，リソースを多く消費するため注意してください。

Webクライアントからのアクセス制御の設定をします。

クライアントからの接続や送信されるリクエストに対するセキュリティを強化することで，外部からの不正アクセスやサーバへの攻撃を防ぐことができます。設定については，「6.11　アクセスを許可するホストの制限によるアクセス制御」，「6.12　リクエストデータのサイズの制限によるアクセス制御」，および「6.13　有効なHTTPメソッドの制限によるアクセス制御」を参照してください。

必要に応じて，インプロセスHTTPサーバで使用できる各機能についても設定してください。

インプロセスHTTPサーバで使用できる機能については，「6.2.2　インプロセスHTTPサーバで使用できる機能」を参照してください。

6.3　Webクライアントからの接続数の制御

Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。リクエスト処理スレッド数の制御については，「6.4　リクエスト処理スレッド数の制御」を参照してください。

この節では，Webクライアントからの接続数の制御について説明します。

この節の構成を次の表に示します。

表6‒4　この節の構成（Webクライアントからの接続数の制御）

分類

タイトル

参照先

解説

Webクライアントからの接続数の制御の概要

6.3.1

設定

実行環境での設定（J2EEサーバの設定）

6.3.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

インプロセスHTTPサーバでは，一度に接続できるWebクライアントの数を設定することで，インプロセスHTTPサーバで作成するリクエスト処理スレッド数を制御できます。また，処理を実行していないリクエスト処理スレッドを予備スレッドとして一定数プールしておくことで，リクエスト処理スレッドの追加・削除に掛かる処理を最小限に抑えられます。

6.3.1　Webクライアントからの接続数の制御の概要

インプロセスHTTPサーバでは，一度に接続するWebクライアントやプロキシサーバの数の最大値を設定して，リクエスト処理スレッド数を制御します。インプロセスHTTPサーバではWebクライアントからの接続数分のリクエスト処理スレッドを作成するため，Webクライアントからの接続数の最大値は，インプロセスHTTPサーバで作成するリクエスト処理スレッド数の上限となります。

なお，クライアントからの接続要求は，TCP/IPのListenキューに登録されて，リクエスト処理スレッドに渡されます。接続数の上限を超えたクライアントからの接続要求は，Listenキューに蓄えられます。Listenキューに蓄えられたクライアントからの接続要求が指定した最大値を超えた場合，クライアントはサーバへの接続に失敗します。

Webクライアントからの接続数の制御の概要を次の図に示します。

図6‒1　Webクライアントからの接続数の制御の概要

6.3.2　実行環境での設定（J2EEサーバの設定）

Webクライアントからの接続数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのWebクライアントからの接続数の制御の定義について次の表に示します。

表6‒5　簡易構築定義ファイルでのWebクライアントからの接続数の制御の定義

指定するパラメタ

設定内容

webserver.connector.inprocess_http.max_connections

Webクライアントやプロキシサーバとの接続数の最大値を指定します。インプロセスHTTPサーバでは，Webクライアントからの接続数分のリクエスト処理スレッドを作成するため，ここで指定した値がリクエスト処理スレッド数の上限になります。

webserver.connector.inprocess_http.backlog

Webクライアントからの接続数の上限を超えたHTTPリクエストは，Listenキューに蓄えられます。ここでは，Listenキューの登録数の最大値を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

6.4　リクエスト処理スレッド数の制御

Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。Webクライアントからの接続数の制御については，「6.3　Webクライアントからの接続数の制御」を参照してください。

この節では，リクエスト処理スレッド数の制御について説明します。この節の構成を次の表に示します。

表6‒6　この節の構成（リクエスト処理スレッド数の制御）

分類

タイトル

参照先

解説

リクエスト処理スレッド数の制御の概要

6.4.1

設定

実行環境での設定（J2EEサーバの設定）

6.4.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.4.1　リクエスト処理スレッド数の制御の概要

インプロセスHTTPサーバでは，起動時にリクエスト処理スレッドを作成したあと，リクエスト処理スレッドの状態，およびスレッド数を定期的に監視します。インプロセスHTTPサーバにリクエストが集中している場合は，リクエスト処理スレッドを追加して十分な予備スレッドをプールしておき，リクエストが少ない場合は余分にプールしている予備スレッドを削除します。

リクエスト処理スレッド数の制御は次のように実行します。

J2EEサーバ起動時に，指定した数分のリクエスト処理スレッドを作成します。

J2EEサーバの稼働中はリクエスト処理スレッド数を監視します。

監視のタイミングで，予備スレッド数が指定した最小値より少ない場合は，リクエスト処理スレッドを追加して予備スレッドとしてプールします。また，予備スレッド数が指定した最大値より多い場合は，余分な予備スレッドを削除します。

なお，J2EEサーバ起動時に作成したスレッド数を維持することもできます。起動時に作成したスレッド数を維持する場合，リクエスト処理スレッドと予備スレッドの総数が起動時に作成したスレッド数以下の場合，予備スレッド数が最大値を超えていても予備スレッドは削除されません。例えば，起動時に作成したスレッド数が8で，予備スレッド数の最大値が5の場合，リクエスト処理スレッドが2で，予備スレッド数が6のときは，予備スレッドは削除されません。

次に，リクエスト処理スレッド数の遷移について，例を使用して説明します。

遷移例1

次の内容が設定されていることとします。

Webクライアントからの最大接続数：15

Listenキューの登録数：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：5

予備スレッドの最大値：10

J2EEサーバ起動時に作成したスレッド数の維持：無効

リクエスト処理スレッド数の遷移例を次の図に示します。

図6‒2　リクエスト処理スレッド数の遷移例

図中の項番1〜7について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

4リクエストを受信した時点で，予備スレッドが4スレッドとなり，最小値より少ないため1スレッド追加します。

4リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値より少なく，最小値より多いため現状を維持します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，Webクライアントからの最大接続数に達しているため，予備スレッドを1スレッドだけ追加します。

13リクエストの処理が終了した時点で，予備スレッド数が最大値を超えているため，4スレッド削除します。

7リクエストを受信した時点で，予備スレッド数が最小値より少ないため，2スレッド追加します。

8リクエストの処理が終了した時点で，予備スレッド数が最大値を超えているため，3スレッド削除します。

遷移例2

予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にすることによって，一度作成したリクエスト処理スレッドを削除しないで使い続けることができます。

予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例について説明します。

なお，ここでは，次の内容が設定されていることとします。

Webクライアントからの接続数の最大値：15

Listenキューの登録数の最大値：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：5

予備スレッドの最大値：15

J2EEサーバ起動時に作成したスレッド数の維持：無効

予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例を次の図に示します。

図6‒3　予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にした場合のリクエスト処理スレッド数の遷移例

図中の項番1〜7について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

4リクエストを受信した時点で，予備スレッドが4スレッドとなり，最小値より少ないため1スレッド追加します。

4リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値より少なく，最小値より多いため現状を維持します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，リクエスト処理スレッドの総数がWebクライアントからの接続数の最大値を超えないように，予備スレッドを1スレッドだけ追加します。

13リクエストの処理が終了した時点で，予備スレッドが14スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

7リクエストを受信した時点で，予備スレッドが7スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

8リクエストの処理が終了した時点で，予備スレッド数が15スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

設定例3

サーバ起動時に作成されたスレッド数を維持する場合のリクエスト処理スレッド数の遷移例について説明します。

なお，ここでは，次の内容が設定されていることとします。

Webクライアントからの接続数の最大値：15

Listenキューの登録数の最大値：100

J2EEサーバ起動時に作成するリクエスト処理スレッド数：8

予備スレッドの最小値：3

予備スレッドの最大値：5

J2EEサーバ起動時に作成したスレッド数の維持：有効

サーバ起動時に作成されたスレッド数を維持する場合のリクエスト処理スレッド数の遷移例を次の図に示します。

図6‒4　J2EEサーバ起動時に作成したスレッドを維持する場合のリクエスト処理スレッド数の遷移例

図中の項番1〜8について説明します。

J2EEサーバ起動時に，指定した数分（8スレッド）のリクエスト処理スレッドを作成します。

6リクエストを受信した時点で，予備スレッドが2スレッドとなり，最小値より少ないため1スレッド追加します。

6リクエストの処理が終了した時点で，予備スレッドが9スレッドとなり，最大値を超えていますが，サーバ起動時に作成したスレッド数を維持するため，1スレッドだけ削除します。

14リクエストを受信した時点で，予備スレッド数が最小値より少なくなっていますが，リクエスト処理スレッドの総数がWebクライアントからの接続数の最大値を超えないように，予備スレッドを1スレッドだけ追加します。

7リクエストの処理が終了した時点で，予備スレッドが8スレッドとなり，最大値を超えたため，3スレッド削除します。

3リクエストを受信した時点で，予備スレッドが2スレッドとなり，最小値より少ないため，1スレッド追加します。

1リクエストの処理が終了した時点で，予備スレッド数が4スレッドとなりましたが，最大値より少なく，最小値より多いため現状を維持します。

9リクエストの処理が終了した時点で，予備スレッド数が13スレッドとなり，最大値より多くなっていますが，J2EEサーバ起動時のスレッド数を維持するため，5スレッドだけ削除します。

6.4.2　実行環境での設定（J2EEサーバの設定）

リクエスト処理スレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリクエスト処理スレッド数の制御の定義について次の表に示します。

表6‒7　簡易構築定義ファイルでのリクエスト処理スレッド数の制御の定義

指定するパラメタ

設定内容

webserver.connector.inprocess_http.init_threads

J2EEサーバ起動時に作成するリクエスト処理スレッド数を指定します。

webserver.connector.inprocess_http.min_spare_threads

予備スレッドの最小値を指定します。予備スレッド数が指定した最小値より少ない場合は，リクエスト処理スレッドが追加されて予備スレッドとしてプールされます。

webserver.connector.inprocess_http.max_spare_threads

予備スレッドの最大値を指定します。予備スレッド数が指定した最大値より多い場合は，余分な予備スレッドが削除されます。予備スレッドの最大値をWebクライアントからの接続数の最大値と同じ値にすることによって，一度作成したリクエスト処理スレッドを削除しないで使い続けることができます。

webserver.connector.inprocess_http.keep_start_threads

J2EEサーバ起動時に作成したリクエスト処理スレッドを維持するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

6.5　Webクライアントからの同時接続数の制御によるリクエストの流量制御

この節では，Webクライアントからの同時接続数の制御によるリクエストの流量制御について説明します。

この節の構成を次の表に示します。

表6‒8　この節の構成（Webクライアントからの同時接続数の制御によるリクエストの流量制御）

分類

タイトル

参照先

解説

Webクライアントからの同時接続数の制御

6.5.1

設定

実行環境での設定（J2EEサーバの設定）

6.5.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.5.1　Webクライアントからの同時接続数の制御

インプロセスHTTPサーバでは，Webクライアントからの最大接続数の設定とあわせて，接続を拒否するリクエスト数を設定することによって，Webクライアントからの同時接続数を制御します。

Webクライアントからの接続数の増加や，J2EEアプリケーションなどの影響でJ2EEサーバの負荷が高くなった場合に，Webクライアントからのリクエストの受け付けを拒否して，即座にエラーを返すことで，Webクライアントは即座にレスポンスを受信できます。これによって，J2EEサーバの負荷を一定に抑え，リクエストに対するレスポンスタイムを維持できます。

Webクライアントからの最大接続数から接続を拒否するリクエスト数を引いた値が，Webクライアントからの接続を承諾する数となります。

Webクライアントからの同時接続数の制御の概要を，次の図に示します。

図6‒5　Webクライアントからの同時接続数の制御の概要

例えば，Webクライアントからの最大接続数を40として，接続を拒否するリクエスト数を1とする場合，インプロセスHTTPサーバに接続し同時にリクエストを処理できるWebクライアントの数は39となります。リクエスト処理中のスレッド数が39になると，残りの1スレッドは処理中のリクエスト処理スレッド数が減るまで受信したリクエストに対してエラーを返し続けます。Webクライアントからの同時接続数の制御の例を次の図に示します。

図6‒6　Webクライアントからの同時接続数の制御の例

Webクライアントからの同時接続数の制御によって，接続を拒否したリクエストに対しては，ステータスコード503のエラーをWebクライアントに返します。このときクライアントに返すエラーページをカスタマイズすると，レスポンスメッセージのカスタマイズや，ほかのサーバへのリダイレクトができます。

Webクライアントへのレスポンスのカスタマイズ（インプロセスHTTPサーバの場合）の設定については，「6.14　HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ」，および「6.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）」を参照してください。

注意事項

フレームを使用したページや，画像を挿入したページを表示する際，Webクライアントから複数のリクエストを受信する場合があります。その場合，Webクライアントからの同時接続数の制御によって表示されるページが部分的にエラーになることがあります。

6.5.2　実行環境での設定（J2EEサーバの設定）

Webクライアントからの同時接続数の制御をする場合，J2EEサーバの設定が必要です。

Webクライアントからの同時接続数の制御の設定方法および設定例について説明します。

(1)　設定方法

Webクライアントからの同時接続数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.rejection_threads

接続を拒否するリクエスト数を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

注意事項

フレームを使用したページや，画像を挿入したページを表示する際，Webクライアントから複数のリクエストを受信する場合があります。その場合，Webクライアントからの同時接続数の制御によって表示されるページが部分的にエラーになることがあります。

(2)　設定例

Webクライアントからの同時接続数の制御の設定例について説明します。

次に，リクエスト処理スレッド数の上限が40，接続を拒否するリクエスト処理スレッド数が1の場合の設定例を示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.max_connections</param-name>
  <param-value>40</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.rejection_threads</param-name>
  <param-value>1</param-value>
</param>
：

この設定例では，接続後に同時にリクエストを処理できるWebクライアントの数は39となります。リクエスト処理中のスレッド数が39に達すると，残りの1スレッドはWebクライアントに対してエラーを返し続けます。

Webクライアントからの同時接続数の制御によって，接続を拒否したリクエストに対しては，ステータスコード503（Service Unavailable）のエラーをWebクライアントに返します。このときクライアントに返すエラーページをカスタマイズすると，レスポンスメッセージのカスタマイズや，ほかのサーバへのリダイレクトができます。それぞれの場合の設定例を次に示します。なお，エラーページのカスタマイズについては，「6.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）」を参照してください。

レスポンスメッセージをカスタマイズする場合

Webクライアントからの接続を拒否した場合に，レスポンスボディとして特定のファイルをWebクライアントに返すための設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.rejection_threads</param-name>
  <param-value>3</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.list</param-name>
  <param-value>REJECTION_1</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.status</param-name>
  <param-value>503</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.file</param-name>
  <param-value>C:/data/busy.html</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.file.content_type=text/html; charset</param-name>
  <param-value>ISO-8859-1</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.request_url</param-name>
  <param-value>/*</param-value>
</param>
：

この設定例では，エラーステータスコードに「503」，対応するエラーページのファイルに「C:/data/busy.html」，レスポンスのContent-Typeヘッダに「text/html; charset=ISO-8859-1（Media-Typeはtext/htmlで，ISO-8859-1文字セットを使用）」，URLパターンに「/*」を指定しています。このため，エラーステータスコード「503」が発生した場合には，リクエストのURIに関係なく，「C:/data/busy.html」のファイルの内容をレスポンスとして返します。

ほかのサーバへリダイレクトする場合

接続を拒否したリクエストをほかのサーバへリダイレクトする場合の設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.rejection_threads</param-name>
  <param-value>3</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.list</param-name>
  <param-value>REJECTION_1</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.status</param-name>
  <param-value>503</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.redirect_url</param-name>
  <param-value>http://host1/busy.html</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.REJECTION_1.request_url</param-name>
  <param-value>/*</param-value>
</param>
<param>
：

この設定例では，エラーステータスコードに「503」，対応するエラーページのファイルに「http://host1/busy.html」，URLパターンに「/*」を指定しています。このため，エラーステータスコード「503」が発生した場合には，リクエストのURIに関係なく，すべてのリクエストが「http://host1/busy.html」のURLにリダイレクトされます。

6.6　同時実行スレッド数の制御によるリクエストの流量制御

この節では，同時実行スレッド数の制御によるリクエストの流量制御について説明します。

この節の構成を次の表に示します。

表6‒9　この節の構成（同時実行スレッド数の制御によるリクエストの流量制御）

分類

タイトル

参照先

解説

同時実行スレッド数の制御によるリクエストの流量制御の概要

6.6.1

設定

実行環境での設定（J2EEサーバの設定）

6.6.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.6.1　同時実行スレッド数の制御によるリクエストの流量制御の概要

Webコンテナでは，マルチスレッドでサーブレットのリクエストを処理します。このとき，同時に実行できるスレッド数に上限を設定することで，スラッシングなどによるパフォーマンスの低下を防止できます。また，適切なスレッド数を設定することで，アクセス状況に従ったパフォーマンスのチューニングができます。

6.6.2　実行環境での設定（J2EEサーバの設定）

Webコンテナでの同時実行スレッド数の制御をする場合，J2EEサーバの設定が必要です。

ここでは，Webコンテナでの同時実行スレッド数の制御の設定について説明します。

同時に実行するスレッド数を制御するには，Webコンテナ単位で制御する方法，Webアプリケーション単位で制御する方法，およびURLグループ単位で制御する方法の3種類あります。

(1)　Webコンテナ単位での制御

Webコンテナ単位で同時実行スレッド数を制御する場合，Webコンテナ全体で同時に実行できるスレッドの最大数を設定します。ここで設定したスレッド数は，WebコンテナにデプロイされているすべてのWebアプリケーションで共用するスレッド数となります。

Webコンテナ単位での同時実行スレッド数の制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.max_execute_threads

Webコンテナ全体で同時に実行できるスレッドの最大数を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

(2)　Webアプリケーション単位での制御

Webアプリケーション単位で同時実行スレッド数を制御する場合，Webコンテナでのスレッド数制御も同時に設定する必要があります。

Webアプリケーション単位での同時実行スレッド数の制御は，簡易構築定義ファイルおよびサーバ管理コマンドで設定します。設定方法は，Webサーバ連携機能を使用する場合と同じです。Webサーバ連携機能を使用する場合の，Webアプリケーション単位での同時実行スレッド数の設定方法については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Web コンテナ)」の「2.15　Webアプリケーション単位での同時実行スレッド数の制御」を参照してください。

(3)　URLグループ単位での制御

URLグループ単位で同時実行スレッド数を制御する場合，Webアプリケーション単位での同時実行スレッド数制御，およびWebコンテナでのスレッド数制御も同時に設定する必要があります。

URLグループ単位での同時実行スレッド数の制御は，サーバ管理コマンドで設定します。設定方法は，Webサーバ連携機能を使用する場合と同じです。Webサーバ連携機能を使用する場合の，URLグループ単位での同時実行スレッド数の設定方法については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Web コンテナ)」の「2.16　URLグループ単位での同時実行スレッド数の制御」を参照してください。

6.7　リダイレクトによるリクエストの振り分け

この節では，リダイレクトによるリクエストの振り分けについて説明します。

インプロセスHTTPサーバでは，HTTPリクエストに含まれるURLパターンによってリクエストを振り分けます。また，振り分けたリクエストに対するレスポンスをカスタマイズしてクライアントに返すこともできます。

URLパターンによるリクエストの振り分けと，レスポンスのカスタマイズの処理について説明します。また，リダイレクトによるリクエストの振り分けの設定の概要についても説明します。

この節の構成を次の表に示します。

表6‒10　この節の構成（リダイレクトによるリクエストの振り分け）

分類

タイトル

参照先

解説

URLパターンによるリクエストの振り分け

6.7.1

レスポンスのカスタマイズ

6.7.2

設定

実行環境での設定（J2EEサーバの設定）

6.7.3

注意事項

リダイレクトによるリクエストの振り分けに関する注意事項

6.7.4

注　「実装」および「運用」について，この機能固有の説明はありません。

6.7.1　URLパターンによるリクエストの振り分け

インプロセスHTTPサーバでは，インプロセスHTTPサーバあてのHTTPリクエストのうち，特定のURLへのリクエストを，指定したWebコンテナに振り分けて処理させることができます。これによって，システム構成の変更などの理由でWebアプリケーションを別なJ2EEサーバに移動する場合に，変更前のURLへのリクエストを，変更後のURLに転送できます。

また，インプロセスHTTPサーバでのリダイレクトによる振り分けでは，特定のWebアプリケーション，およびWebアプリケーション内の特定のサーブレット/JSPに対するリクエストを，一時的にほかのWebサーバにリダイレクトする場合にも使用できます。インプロセスHTTPサーバでは，リクエストされたサーブレット/JSPなどのリソースが実際にあるかどうかに関係なく，リダイレクトを実行します。リダイレクトは，サーブレット/JSPよりも優先されます。そのため，サーブレット/JSPへのリクエストがリダイレクトされるURLと一致した場合，サーブレット/JSPは実行されません。

6.7.2　レスポンスのカスタマイズ

特定のURLへのリクエストに対して，特定のファイルをレスポンスとして返すようにカスタマイズすることもできます。リダイレクトするURLへのリクエストに対するレスポンスのステータスコードが300〜307の場合，レスポンスボディを自動生成してクライアントにレスポンスを返します。また，指定したファイルをレスポンスボディとして使用することもできます。ファイルを指定する場合，レスポンスのContent-Typeヘッダもあわせて指定します。

レスポンスボディが自動生成されるステータスコードの詳細，およびリダイレクトによるリクエストの振り分けの設定（インプロセスHTTPサーバの場合）については，「6.7.3　実行環境での設定（J2EEサーバの設定）」を参照してください。

6.7.3　実行環境での設定（J2EEサーバの設定）

ここでは，リダイレクトによるリクエストの振り分けの設定について説明します。

(1)　概要

インプロセスHTTPサーバでは，HTTPリクエストに含まれるURLパターンによってリクエストを振り分けることができます。また，振り分けたリクエストに対するレスポンスをカスタマイズして特定のファイルをクライアントに返すこともできます。リダイレクトするURLへのリクエストに対するレスポンスのステータスコードが300番台の場合，レスポンスボディを自動生成してクライアントにレスポンスを返します。また，指定したファイルをレスポンスボディとして使用することもできます。ファイルを指定する場合，レスポンスのContent-Typeヘッダもあわせて指定します。

自動生成されるレスポンスボディを次に示します。

<HTML><HEAD>
<TITLE>ステータスコードおよび説明句</TITLE>
</HEAD><BODY>
<H1>ステータスコードおよび説明句</H1>
</BODY></HTML>

レスポンスボディが自動生成されるステータスコードおよび説明句を次に示します。

300 Multiple Choices

301 Moved Permanently

302 Found

303 See Other

305 Use Proxy

307 Temporary Redirect

リクエスト処理時にレスポンスボディとして使用するファイルの読み込みに失敗した場合，ステータスコードに300番台が指定されていれば，レスポンスボディを自動生成してクライアントに返します。ステータスコードに200が指定されていれば，ステータス500エラーをクライアントに返します。

(2)　設定方法

リダイレクトによるリクエストの振り分けの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリダイレクトによるリクエストの振り分けの定義について次の表に示します。

表6‒11　簡易構築定義ファイルでのリダイレクトによるリクエストの振り分けの定義

指定するパラメタ

設定内容

webserver.connector.inprocess_http.redirect.list

リダイレクト定義名を指定します。

webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.request_url

リダイレクトするリクエストのURLを「/」（スラッシュ）で始まる絶対パスで指定します。

webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.redirect_url

リクエストのリダイレクト先のURLを指定します。なお，ステータスコードに200を指定した場合は，URLを指定できません。

webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.status

リダイレクトを実行する場合のレスポンスのステータスコードを指定します。

webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.file

特定のファイルをレスポンスとしてクライアントに返す場合にレスポンスボディとして使用するファイルを指定します。なお，ステータスコードに200を指定した場合は，使用するファイルを指定する必要があります。

webserver.connector.inprocess_http.redirect.＜リダイレクト定義名＞.file.content_type

特定のファイルをレスポンスとしてクライアントに返す場合にレスポンスボディとして使用するファイルのContent-Typeヘッダを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

注意事項

HTTPレスポンスがHTMLファイルの場合，そのHTMLからほかのファイル（画像ファイルなど）を参照していると，正しくブラウザに表示されないことがあります。

リダイレクトURLの指定値がリクエストURLの指定値と一致する場合，クライアントによってはリダイレクトを実行し続けることがあります。

URLの書き換えによるセッション管理をしている場合，リクエストURLと同じWebアプリケーション内へのリダイレクトを実行してもセッションを引き継ぐことはできません。

(3)　設定例

リダイレクトによるリクエストの振り分けの設定例について説明します。

設定例1

リダイレクトによるリクエストの振り分けの設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.redirect.list</param-name>
  <param-value>REDIRECT_1,REDIRECT_2</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_1.request_url</param-name>
  <param-value>/index.html</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_1.redirect_url</param-name>
  <param-value>http://host1/new_dir/index.html</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_1.status</param-name>
  <param-value>302</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.request_url</param-name>
  <param-value>/old_dir/*</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.redirect_url</param-name>
  <param-value>http://host1/new_dir/</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.status</param-name>
  <param-value>301</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.file</param-name>
  <param-value>C:/data/301.html</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_2.file.content_type</param-name>
  <param-value>text/html; charset=ISO-8859-1</param-value>
</param>
：

この設定例では，リダイレクト定義名として，「REDIRECT_1」と「REDIRECT_2」を使用しています。「REDIRECT_1」では，「/index.html」へのリクエストを「http://host1/new_dir/index.html」にステータスコード「302」でリダイレクトします。「REDIRECT_2」では，「/old_dir/」以下へのリクエストを「http://host1/new_dir/」以下にステータス「301」でリダイレクトします。また，レスポンスボディとして「C:/data/301.html」を使用し，Content-Typeヘッダとして「text/html; charset=ISO-8859-1」を使用します。

設定例2

リクエストURLとしてワイルドカードを使用し，リダイレクトURLに「/」で終わる値を指定した場合，レスポンスのLocationヘッダに設定される値は，「リダイレクトURLに指定した値」＋「実際のリクエストURLのワイルドカード以降のパス」になります。

：
<param>
  <param-name>webserver.connector.inprocess_http.redirect.list</param-name>
  <param-value>REDIRECT_3</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_3.request_url</param-name>
  <param-value>/dir1/*</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.redirect.REDIRECT_3.redirect_url</param-name>
  <param-value>http://host/dir2/</param-value>
</param>
：

この設定例の場合，実際のリクエストURLが「/dir1/subdir1/index.html」のときには，Locationヘッダには「http://host/dir2/subdir1/index.html」が設定されます。なお，リクエストURLの指定でワイルドカードを使用した場合でも，リダイレクトURLが「/」で終わらないときは，Locationヘッダの値は，リダイレクトURLと同じ値になります。

リダイレクトが行われる際，実際のリクエストURLにクエリ文字列が付加されていた場合，Locationヘッダに設定される値は，リダイレクトURLの指定値にクエリ文字列を付加した値となります。また，リダイレクトURLにはクエリ文字列の付いた値を指定できます。この場合，実際のリクエストURLにもクエリ文字列が付いているときは，Locationヘッダに設定される値は，リダイレクトURLの指定値の後ろにリクエストのクエリ文字列が付加された値となります。

6.7.4　リダイレクトによるリクエストの振り分けに関する注意事項

リダイレクトによるリクエストの振り分けに関する注意事項を次に示します。

HTTPレスポンスがHTMLファイルの場合，そのHTMLからほかのファイル（画像ファイルなど）を参照していると，正しくブラウザに表示されない場合があります。

リダイレクトURLの指定値とリクエストURLの指定値が一致すると，クライアントによってはリダイレクトを実行し続けることがあるため注意してください。

URLの書き換えによるセッション管理をしている場合，Webアプリケーション内へのリダイレクトを実行してもセッションを引き継ぐことはできません。

6.8　Persistent ConnectionによるWebクライアントとの通信制御

この節では，Persistent ConnectionによるWebクライアントとの通信制御について説明します。

この節の構成を次の表に示します。

表6‒12　この節の構成（Persistent ConnectionによるWebクライアントとの通信制御）

分類

タイトル

参照先

解説

Persistent Connectionによる通信制御

6.8.1

設定

実行環境での設定（J2EEサーバの設定）

6.8.2

注　「実装」および「運用」について，この機能固有の説明はありません。

6.8.1　Persistent Connectionによる通信制御

Persistent Connectionは，WebクライアントとインプロセスHTTPサーバ間で確立したTCPコネクションを持続して，複数のHTTPリクエスト間で使用し続けるための機能です。Persistent Connectionを使用することによって，WebクライアントとWebサーバ間でのコネクション接続に掛かる時間を短縮し，処理時間の短縮と通信トラフィックの軽減を図れます。

インプロセスHTTPサーバでは，次に示す項目を設定することで，Persistent Connectionによる通信制御を実現します。

Persistent Connection数の上限値

Persistent Connection数の上限値を設定することで，一つのTCPコネクションで連続してリクエストを処理できるWebクライアント数を制御します。TCPコネクション数が指定した上限値を超えた場合，リクエスト処理終了後に切断します。これによって，新規リクエストを処理するスレッドが確保でき，リクエスト処理スレッドを特定のクライアントに占有されることを防げます。

Persistent Connectionのリクエスト処理回数の上限値

Persistent Connectionのリクエスト処理回数の最大値を設定することで，同じWebクライアントから連続してリクエスト要求があった場合の処理を制御します。

Persistent Connectionのリクエスト処理回数が指定した上限値を超えた場合，リクエスト処理終了後にコネクションを切断します。これによってリクエスト処理スレッドを特定のクライアントに占有し続けられることを防げます。

Persistent Connectionのタイムアウト

Persistent Connectionのリクエスト待ち時間にタイムアウトを設定することで，Persistent Connectionのリクエスト待ち時間を制御します。指定したタイムアウト時間を超えてリクエスト処理要求がない場合は，TCPコネクションを切断します。これによって，使用されていない状態でTCPコネクションが占有され続けることを防げます。また，Persistent Connectionのリクエスト待ち時間に0を指定してタイムアウトをしない設定にしている場合でも，リクエスト処理回数の上限値を超えたリクエスト要求があるとコネクションが切断されます。

なお，コネクションを切断されたWebクライアントは，接続のリトライを実行して，再度リクエストを送信します。

6.8.2　実行環境での設定（J2EEサーバの設定）

Persistent Connectionによる通信制御を使用する場合，J2EEサーバの設定が必要です。

ここでは，Persistent Connectionによる通信制御の設定および設定例について説明します。

(1)　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Persistent Connectionによる通信制御の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのPersistent Connectionによる通信制御の定義について次の表に示します。

表6‒13　簡易構築定義ファイルでのPersistent Connectionによる通信制御の定義

指定するパラメタ

設定内容

webserver.connector.inprocess_http.persistent_connection.max_connections

一つのTCPコネクションで連続してリクエストを処理できるWebクライアント数を制御するため，Persistent Connection数の上限値を指定します。

webserver.connector.inprocess_http.persistent_connection.max_requests

同じWebクライアントから連続してリクエスト要求があった場合の処理を制御するため，Persistent Connectionのリクエスト処理回数の上限値を指定します。

webserver.connector.inprocess_http.persistent_connection.timeout

Persistent Connectionのリクエスト待ち時間を制御するため，Persistent Connectionのタイムアウトを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

(2)　設定例

Persistent Connectionによる通信制御の設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.persistent_connection.max_connections</param-name>
  <param-value>5</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.persistent_connection.max_requests</param-name>
  <param-value>100</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.persistent_connection.timeout</param-name>
  <param-value>15</param-value>
</param>
：

この設定例では，TCPコネクション数が「5」を超えた場合，またはリクエスト処理回数が「100」を超えた場合には，リクエスト処理終了後にTCPコネクションを切断します。また，タイムアウト時間「15」秒を過ぎてもリクエスト処理要求がない場合は，TCPコネクションを切断します。

6.9　通信タイムアウト（インプロセスHTTPサーバ）

この節では，インプロセスHTTPサーバでの通信タイムアウトによるWebクライアントとの通信制御について説明します。

この節の構成を次の表に示します。

表6‒14　この節の構成（通信タイムアウト（インプロセスHTTPサーバ））

分類

タイトル

参照先

解説

通信タイムアウトの概要

6.9.1

設定

実行環境での設定（J2EEサーバの設定）

6.9.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.9.1　通信タイムアウトの概要

インプロセスHTTPサーバを使用する場合，WebクライアントとインプロセスHTTPサーバ間での，リクエスト受信およびレスポンス送信に，通信タイムアウトを設定できます。ネットワークの障害やアプリケーションの障害などが発生し応答待ち状態になった場合，通信タイムアウトを設定していると，タイムアウトの発生によって障害の発生を検知できます。

インプロセスHTTPサーバを使用する場合，次に示す図中の二つの矢印が示す通信に対してタイムアウトを設定します。

図6‒7　タイムアウトを設定できる通信（インプロセスHTTPサーバを使用する場合）

図に示すように，通信タイムアウトはリクエスト受信とレスポンス送信に対して設定します。通信タイムアウトの設定について，リクエストの受信とレスポンスの送信に分けて説明します。

なお，Webクライアントからのリクエスト受信，およびWebクライアントへのレスポンス送信でタイムアウトが発生した場合，Webクライアントまたはネットワークで障害が発生したと見なされて，Webクライアントとの接続が切断されるため，レスポンスは返されません。

(1)　リクエスト受信時の通信タイムアウト

リクエスト受信時の通信タイムアウトの設定場所を次の図に示します。

図6‒8　リクエスト受信時の通信タイムアウトの設定場所（インプロセスHTTPサーバを使用する場合）

インプロセスHTTPサーバを使用する場合，WebクライアントとインプロセスHTTPサーバ間の通信に，タイムアウトを設定します。

WebクライアントとインプロセスHTTPサーバ間の通信にタイムアウトを設定することによって，クライアント側で次に示す障害が発生したことを検知できます。

Webクライアントが稼働するホストがダウンした

WebクライアントとインプロセスHTTPサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

(2)　レスポンス送信時の通信タイムアウト

レスポンス送信時の通信タイムアウトの設定場所を次の図に示します。

図6‒9　レスポンス送信時の通信タイムアウトの設定場所（インプロセスHTTPサーバを使用する場合）

インプロセスHTTPサーバを使用する場合，インプロセスHTTPサーバとWebクライアント間の通信に，タイムアウトを設定します。

インプロセスHTTPサーバとWebクライアント間の通信にタイムアウトを設定することによって，次に示す障害を検知できます。

Webクライアントが稼働するホストがダウンした

WebクライアントとインプロセスHTTPサーバ間でネットワーク障害が発生した

クライアントアプリケーションで障害が発生した

6.9.2　実行環境での設定（J2EEサーバの設定）

インプロセスHTTPサーバの通信タイムアウトの設定をする場合，J2EEサーバの設定が必要です。

ここでは，インプロセスHTTPサーバの通信タイムアウトの設定および設定例について説明します。

通信タイムアウトは，リクエストの受信時，またはレスポンスの送信時に設定します。リクエスト受信時およびレスポンス送信時の通信タイムアウトの設定についてそれぞれ説明します。

(1)　リクエスト受信時の通信タイムアウトの設定

リクエスト受信時の通信タイムアウトは，クライアント−インプロセスHTTPサーバ間に設定します。

インプロセスHTTPサーバでのリクエスト受信時の通信タイムアウトは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.receive_timeout

クライアントからのリクエスト受信処理の待ち時間を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

(2)　レスポンス送信時の通信タイムアウトの設定

レスポンス送信時の通信タイムアウトは，インプロセスHTTPサーバ−クライアント間に設定します。

インプロセスHTTPサーバでのレスポンス送信時の通信タイムアウトは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.send_timeout

クライアントへのレスポンス送信処理の待ち時間を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細は，「第3編　リファレンス（V9互換モード）」を参照してください。

(3)　設定例

インプロセスHTTPサーバの通信タイムアウトの設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.receive_timeout</param-name>
  <param-value>300</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.send_timeout</param-name>
  <param-value>600</param-value>
</param>
：

この設定例では，リクエスト受信のタイムアウトに「300」秒，リクエスト送信のタイムアウトに「600」秒を設定しています。

6.10　IPアドレス指定（インプロセスHTTPサーバ）

この節では，インプロセスHTTPサーバでのIPアドレス指定によるWebクライアントとの通信制御について説明します。

この節の構成を次の表に示します。

表6‒15　この節の構成（IPアドレス指定（インプロセスHTTPサーバ））

分類

タイトル

参照先

解説

バインド先アドレス設定機能

6.10.1

設定

実行環境での設定（J2EEサーバの設定）

6.10.2

注意事項

インプロセスHTTPサーバでのIPアドレス指定をする場合の注意事項

6.10.3

注　「実装」および「運用」について，この機能固有の説明はありません。

参考

インプロセスHTTPサーバを使用しない場合（Webサーバ連携機能を使用する場合）との機能差異はありません。機能の解説については，「5.7　IPアドレス指定（Webサーバ連携）」を参照してください。

6.10.1　バインド先アドレス設定機能

Webコンテナでは，インプロセスHTTPサーバで利用するIPアドレスを明示的に指定できます。これを，バインド先アドレス設定機能といいます。この機能を使用することで，複数の物理ネットワークインタフェースを持つホスト，または一つの物理ネットワークインタフェースに対して，ホストで実行する場合に，特定の一つのIPアドレスだけを使用するように設定できます。

6.10.2　実行環境での設定（J2EEサーバの設定）

インプロセスHTTPサーバのIPアドレスの設定をする場合，J2EEサーバの設定が必要です。

ここでは，インプロセスHTTPサーバのIPアドレスの設定について説明します。

インプロセスHTTPサーバのIPアドレスは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.bind_host

インプロセスHTTPサーバで利用するホスト名またはIPアドレスを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

6.10.3　インプロセスHTTPサーバでのIPアドレス指定をする場合の注意事項

インプロセスHTTPサーバでのIPアドレス指定をする場合の注意事項を次に示します。

ホスト名またはIPアドレスを設定した場合は，指定されたIPアドレスへの接続要求しか受け付けません。IPアドレスを設定する代わりに，ワイルドカードアドレスを指定することで，そのホスト上の任意のIPアドレスへの接続を受け付けることができます。デフォルトでは，ワイルドカードアドレスを使用する設定になっています。なお，ワイルドカードアドレスを使用する場合は，次のことに注意してください。

指定されたホスト名が，hostsファイルまたはDNSなどで解決できない場合は，ワイルドカードアドレスを使用してサーバを起動します。

指定されたホスト名，またはIPアドレスがリモートホストの場合，ワイルドカードアドレスを使用してサーバを起動します。

6.11　アクセスを許可するホストの制限によるアクセス制御

J2EEサーバへの不正アクセスを防ぐため，アクセスできるホストを制限できます。デフォルトでは，全ホストからのアクセスが可能な状態になっています。アクセスを許可するホストのホスト名やIPアドレスを設定しておくことで，特定のホストからのアクセスだけを許可して，不正アクセスを防止できます。

この節では，アクセスを許可するホストの制限によるアクセス制御について説明します。

表6‒16　この節の構成（アクセスを許可するホストの制限によるアクセス制御）

分類

タイトル

参照先

解説

アクセスを許可するホストの制限

6.11.1

設定

実行環境での設定（J2EEサーバの設定）

6.11.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.11.1　アクセスを許可するホストの制限

ホストを制限するには，アクセスを許可するホストの，ホスト名，またはIPアドレスを設定します。このとき，ホスト名やIPアドレスの代わりにアスタリスク（*）を指定すると，全ホストからのアクセスを許可する設定になります。アクセスを許可するホストをホスト名で指定した場合，J2EEサーバ起動時にホスト名が解決されます。なお，ローカルホストは明記しなくても常にアクセスが許可されます。通常，外部ネットワークからアクセスされるシステムでは，プロキシサーバのIPアドレスを指定します。

アクセスを許可するホストをホスト名で指定した場合の注意事項を次に示します。

注意事項

hostsファイル，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定でサーバが起動されます。

ホスト名の解決をJ2EEサーバの起動時にするため，サーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

6.11.2　実行環境での設定（J2EEサーバの設定）

アクセスを許可するホストの制限の設定をする場合，J2EEサーバの設定が必要です。

ここでは，アクセスを許可するホストの制限の設定方法と設定例について説明します。

(1)　設定方法

アクセスを許可するホストの制限は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.permitted.hosts

アクセスを許可するホストのホスト名やIPアドレスを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

注意事項

アクセスを許可するホストをホスト名で指定した場合の注意事項を次に示します。

hosts，またはDNSなどでホスト名を解決できるようにする必要があります。解決できない場合はデフォルトの設定（全ホストからのアクセスが可能な状態）でJ2EEサーバが起動されます。

J2EEサーバの起動時にホスト名を解決するため，J2EEサーバの起動に時間が掛かることがあります。また，起動後に変更されたIPアドレスは反映されないことがあります。

(2)　設定例

アクセスを許可するホストの制限の設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.permitted.hosts</param-name>
  <param-value>host1,host2</param-value>
</param>
：

この設定例では，「host1」と「host2」からのアクセスだけを許可し，ほかのホストからのアクセスを許可しません。

6.12　リクエストデータのサイズの制限によるアクセス制御

インプロセスHTTPサーバでは，一定のサイズ以下のリクエストデータだけを受け付けることによって，不正なリクエストデータの受け付けを拒否し，サーバへの負荷を抑え，安定した稼働を維持できます。

この節では，リクエストデータのサイズの制限によるアクセス制御について説明します。

この節の構成を次の表に示します。

表6‒17　この節の構成（リクエストデータのサイズの制限によるアクセス制御）

分類

タイトル

参照先

解説

リクエストデータのサイズの制限

6.12.1

設定

実行環境での設定（J2EEサーバの設定）

6.12.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.12.1　リクエストデータのサイズの制限

インプロセスHTTPサーバでは，一定のサイズ以下のリクエストデータだけを受け付けることによって，不正なリクエストデータの受け付けを拒否し，サーバへの負荷を抑え，安定した稼働を維持できます。

次に示す項目を設定することで，リクエストデータのサイズ制限によるアクセス制御を実現します。

リクエストラインの長さの制限

リクエストラインの長さの上限値を設定することで，アクセスを制御します。リクエストラインの長さには，HTTPメソッド，URI（クエリ文字列を含む），HTTPのバージョン，およびリクエストラインの終わりを示す改行文字（2バイト）が含まれます。

受信したリクエストラインの長さが上限値を超えた場合，Webクライアントに対して，ステータスコード414のエラーを返します。

HTTPヘッダ数の制限

HTTPリクエストに含まれるHTTPヘッダ数の上限値を設定することで，アクセスを制御します。

受信したHTTPリクエストに含まれるHTTPヘッダ数が上限値を超えた場合，Webクライアントに対してステータスコード400のエラーを返します。

リクエストヘッダサイズの制限

HTTPリクエストのリクエストヘッダのサイズに上限値を設定することによって，アクセスを制御します。

受信したHTTPリクエストのHTTPヘッダのサイズが上限値を超えた場合，Webクライアントに対してステータスコード400のエラーを返します。

リクエストボディサイズの制限

HTTPリクエストのボディサイズに上限値を設定することによって，アクセスを制御します。インプロセスHTTPサーバでは，リクエストヘッダに含まれるContent-Lengthヘッダの値で判断します。

HTTPリクエストのボディサイズが上限値を超えた場合，Webクライアントに対してステータスコード413のエラーを返します。

なお，チャンク形式でリクエストボディが送信された場合，サーブレット内部では指定された上限値までのデータを読み込みます。上限値を超えるとサーブレットで例外（IOException）が発生しますが，サーブレットの処理は続行されます。リクエストを送信したクライアントには，指定された上限値までのデータを読み込んだ結果に基づいて，アプリケーションが作成したレスポンスを返します。

ポイント

SSLアクセラレータや負荷分散機などのゲートウェイ機器や，プロキシサーバを配置していて，ゲートウェイ機器やプロキシサーバにリクエストデータサイズの制御機能がある場合は，その制御機能の設定値以下の値を設定する必要があります。

6.12.2　実行環境での設定（J2EEサーバの設定）

リクエストデータのサイズ制限の設定をする場合，J2EEサーバの設定が必要です。

ここでは，リクエストデータのサイズ制限の設定方法と設定例について説明します。

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。リクエストデータのサイズ制限の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのリクエストデータのサイズ制限の定義について次の表に示します。

表6‒18　簡易構築定義ファイルでのリクエストデータのサイズ制限の定義

指定するパラメタ

設定内容

webserver.connector.inprocess_http.limit.max_request_line

リクエストラインの上限値を指定します。

webserver.connector.inprocess_http.limit.max_headers

HTTPリクエストに含まれるHTTPヘッダ数の上限値を指定します。

webserver.connector.inprocess_http.limit.max_request_header

HTTPリクエストのリクエストヘッダのサイズの上限値を指定します。

webserver.connector.inprocess_http.limit.max_request_body

HTTPリクエストのボディサイズの上限値を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

ポイント

SSLアクセラレータや負荷分散機などのゲートウェイ機器や，プロキシサーバを配置していて，ゲートウェイ機器やプロキシサーバにリクエストデータサイズの制御機能がある場合は，その制御機能の設定値以下の値を設定する必要があります。

(2)　設定例

リクエストデータのサイズ制限の設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.limit.max_request_line</param-name>
  <param-value>1024</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.limit.max_headers</param-name>
  <param-value>100</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.limit.max_request_header</param-name>
  <param-value>8192</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.limit.max_request_body</param-name>
  <param-value>16384</param-value>
</param>
：

6.13　有効なHTTPメソッドの制限によるアクセス制御

この節では，有効なHTTPメソッドの制限によるアクセス制御について説明します。

この節の構成を次の表に示します。

表6‒19　この節の構成（有効なHTTPメソッドの制限によるアクセス制御）

分類

タイトル

参照先

解説

有効なHTTPメソッドの制限

6.13.1

設定

実行環境での設定（J2EEサーバの設定）

6.13.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.13.1　有効なHTTPメソッドの制限

インプロセスHTTPサーバでは，HTTPリクエストで有効なHTTPメソッドを制限することによって，無効なHTTPメソッドを含むリクエストの受け付けを拒否します。これによって，サーバ上のリソースへの不正アクセスを防止できます。デフォルトでは，DELETEメソッド，HEADメソッド，GETメソッド，OPTIONSメソッド，POSTメソッド，およびPUTメソッドの使用を許可しています。

HTTPメソッドを制限するには，有効なHTTPメソッドのメソッド名を設定します。有効なHTTPメソッドとして設定する値は，RFC2616に規定されている値を使用する必要があります。ただし，メソッド名の文字列にアスタリスク（*）は使用できません。メソッド名の代わりにアスタリスク（*）を指定すると，すべてのメソッドの使用を許可する設定になります。

無効なHTTPメソッドを含むリクエストを受信した場合，Webクライアントに対してステータスコード405のエラーを返します。

なお，静的コンテンツに対してOPTIONSメソッドを含むリクエストを送信した場合，レスポンスに含まれるAllowヘッダには静的コンテンツに対してデフォルトで有効なメソッド（GETメソッド，POSTメソッド，TRACEメソッド，およびOPTIONSメソッド）から，インプロセスHTTPサーバで無効なメソッドを除いたメソッドが返されます。サーブレット/JSPの場合，Webアプリケーションの実装に依存します。

6.13.2　実行環境での設定（J2EEサーバの設定）

有効なHTTPメソッドの制限の設定をする場合，J2EEサーバの設定が必要です。

ここでは，有効なHTTPメソッドの制限の設定方法と設定例について説明します。

(1)　設定方法

有効なHTTPメソッドの制限は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.enabled_methods

有効なHTTPメソッドのメソッド名を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

ポイント

静的コンテンツに対してOPTIONSメソッドを含むリクエストを送信した場合，静的コンテンツに対してデフォルトで有効なメソッド（GETメソッド，POSTメソッド，TRACEメソッド，およびOPTIONSメソッド）から，インプロセスHTTPサーバで無効なメソッドを除いたリクエストが返されます。サーブレット/JSPの場合，Webアプリケーションの実装に依存します。

(2)　設定例

有効なHTTPメソッドの制限の設定例を次に示します。なお，この設定例はデフォルトの設定です。

：
<param>
  <param-name>webserver.connector.inprocess_http.enabled_methods</param-name>
  <param-value>GET,HEAD,POST,PUT,DELETE,OPTIONS</param-value>
</param>
：

この設定例では，GETメソッド，HEADメソッド，POSTメソッド，PUTメソッド，DELETEメソッド，およびOPTIONSメソッドに対してアクセスを許可し，TRACEメソッドに対してアクセスを拒否します。

6.14　HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ

この節では，HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズについて説明します。

この節の構成を次の表に示します。

表6‒20　この節の構成（HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ）

分類

タイトル

参照先

解説

HTTPレスポンスヘッダのカスタマイズ

6.14.1

設定

実行環境での設定（J2EEサーバの設定）

6.14.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.14.1　HTTPレスポンスヘッダのカスタマイズ

ここでは，HTTPレスポンスヘッダのカスタマイズについて説明します。

インプロセスHTTPサーバでは，HTTPレスポンスのServerヘッダに自動設定する情報をカスタマイズできます。デフォルトでは，「CosminexusComponentContainer」が自動設定されます。

Serverヘッダに自動設定する値は，RFC2616に規定されている値を使用する必要があります。サーブレット/JSPでServerヘッダを使用する設定にしている場合はその設定が優先されます。

6.14.2　実行環境での設定（J2EEサーバの設定）

HTTPレスポンスヘッダのカスタマイズの設定をする場合，J2EEサーバの設定が必要です。

ここでは，HTTPレスポンスヘッダのカスタマイズの設定方法と設定例について説明します。

(1)　設定方法

HTTPレスポンスヘッダのカスタマイズは，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に次のパラメタを指定します。

webserver.connector.inprocess_http.response.header.server

HTTPレスポンスのServerヘッダに自動設定する文字列を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　設定例

HTTPレスポンスヘッダのカスタマイズの設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.response.header.server</param-name>
  <param-value>GyoumuServer/1.0</param-value>
</param>
：

この設定例では，Serverヘッダの値として「GyoumuServer/1.0」を指定しています。

6.15　エラーページのカスタマイズ（インプロセスHTTPサーバ）

クライアントから，存在しないリソースへのアクセスなどがあると，インプロセスHTTPサーバはエラーステータスコードとエラーページを返し，クライアントにはインプロセスHTTPサーバが生成したエラーページが表示されます。インプロセスHTTPサーバでは，このエラーページの代わりに，ユーザが作成したページをクライアントに表示させることができます。これを，エラーページのカスタマイズと呼びます。

この節では，エラーページを使用したWebクライアントへのレスポンスのカスタマイズについて説明します。

この節の構成を次の表に示します。

表6‒21　この節の構成（エラーページのカスタマイズ（インプロセスHTTPサーバ））

分類

タイトル

参照先

解説

カスタマイズできるエラーページ

6.15.1

実装

エラーページのカスタマイズを実行する場合に必要な実装

6.15.2

設定

実行環境での設定（J2EEサーバの設定）

6.15.3

注意事項

エラーページのカスタマイズに関する注意事項

6.15.4

注　「運用」について，この機能固有の説明はありません。

6.15.1　カスタマイズできるエラーページ

存在しないリソースへのアクセスなどのエラーが発生したときに，エラーステータスコードが表示されたエラーページの代わりにユーザが作成したエラーページをクライアントに表示させることができます。

インプロセスHTTPサーバによるエラーページのカスタマイズを利用することで，特定のステータスコードに対応するエラーページのカスタマイズや，リクエストURLに対応するエラーページのカスタマイズをWebコンテナ単位にまとめて制御できます。また，次に示すようなWebアプリケーションによるエラーページのカスタマイズが実行できない場合でも，エラーページをカスタマイズできます。

リクエストに対応するコンテキストがない場合（ステータスコード404）

停止処理中のコンテキストでリクエスト処理を実行しようとした場合（ステータスコード503）

インプロセスHTTPサーバがエラーステータスコードを返す場合

インプロセスHTTPサーバが返すエラーステータスコードについては「付録C.3　インプロセスHTTPサーバが返すエラーステータスコード」を参照してください。

インプロセスHTTPサーバでは，次に示すエラーページのカスタマイズができます。

ステータスコードに対応するエラーページのカスタマイズ

ステータスコード400番台，500番台に対応するエラーページをカスタマイズできます。

ステータスコードに対応するエラーページをカスタマイズすることによって，ステータスコードに対応するファイルの送信と，ステータスコードに対応するリダイレクトを実行できます。

ステータスコードに対応するファイルの送信

カスタマイズするステータスコードに対して，レスポンスボディとして特定のファイルをクライアントに返すことができます。この場合，レスポンスのContent-Typeヘッダの値を指定します。

なお，リクエスト処理時にファイルの読み込みに失敗した場合，デフォルトのエラーページが使用されます。

ステータスコードに対応するリダイレクト

カスタマイズするステータスコードに対して，特定のURLにリダイレクトできます。リダイレクトする場合，レスポンスのステータスコードに302を設定して，LocationヘッダにリダイレクトURLを指定します。

ステータスコードに対応するファイルを送信する場合，リダイレクトは実行できません。

リクエストURLに対応するエラーページのカスタマイズ

リクエストURLを指定して，特定のURLのエラーページをカスタマイズできます。リクエストURLを指定した場合，指定したURLと一致するリクエスト処理でエラーが発生した場合だけ，カスタマイズしたエラーページをクライアントに返します。

6.15.2　エラーページのカスタマイズを実行する場合に必要な実装

インプロセスHTTPサーバによるエラーページのカスタマイズを実行する場合，javax.servlet.http.HttpServletResponseインタフェースのsendErrorメソッドを使用してレスポンスのステータスコードを設定する必要があります。なお，setStatusメソッドを使用した場合（JSPでsetStatusメソッドを使用した場合など），インプロセスHTTPサーバによるカスタマイズが実行されないことがあります。ただし，sendErrorメソッドを使用しても，Webアプリケーションが次に示すどちらかの条件に該当する場合，インプロセスHTTPサーバによるエラーページのカスタマイズは実行されません。

sendErrorメソッドの実行時に例外が発生した場合

Webアプリケーションでエラーページのカスタマイズの設定をしていて，エラー発生時にその設定によるエラーページの実行が正常終了した場合※

注※

エラーページの実行が正常終了した場合とは，次の条件を満たす場合のことです。

エラーページでcatchされない例外が発生していない。

ステータスコードが400〜599以外で終了している。

6.15.3　実行環境での設定（J2EEサーバの設定）

エラーページのカスタマイズを実行する場合，J2EEサーバの設定が必要です。

ここでは，エラーページのカスタマイズの設定方法と設定例について説明します。

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。エラーページのカスタマイズの定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのエラーページのカスタマイズの定義について次の表に示します。

表6‒22　簡易構築定義ファイルでのエラーページのカスタマイズの定義

指定するパラメタ

設定内容

webserver.connector.inprocess_http.error_custom.list

エラーページのカスタマイズ定義名を指定します。

webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.status

エラーステータスコードに対応づけるエラーページのカスタマイズをする場合に，エラーページをカスタマイズするエラーステータスコードを指定します。

webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.file

エラーステータスコードに対応するファイルを送信する場合に，レスポンスボディとしてクライアントに返すファイルを指定します。

webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.file.content_type

webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.fileパラメタに指定したファイルをレスポンスボディとしてクライアントに送信する際のContent-Typeヘッダの値を指定します。

webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.redirect_url

エラーステータスコードに対応するリダイレクトをする場合に，リダイレクト先のURLを指定します。

webserver.connector.inprocess_http.error_custom.＜エラーページカスタマイズ定義名＞.request_url

リクエストURLに対応づけるエラーページのカスタマイズをする場合に，エラーページのカスタマイズを適用するリクエストURLを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　設定例

エラーページのカスタマイズの設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.list</param-name>
  <param-value>ERR_CUSTOM_1,ERR_CUSTOM_2</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_1.status</param-name>
  <param-value>404</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_1.file</param-name>
  <param-value>C:/data/404.html</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_1.file.content_type</param-name>
  <param-value>text/html; charset=ISO-8859-1</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_2.status</param-name>
  <param-value>503</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_2.redirect_url</param-name>
  <param-value>http://host1/503.html</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.error_custom.ERR_CUSTOM_2.request_url</param-name>
  <param-value>/dir1/*</param-value>
</param>
：

この設定例では，エラーページのカスタマイズ定義名として，「ERR_CUSTOM_1」と「ERR_CUSTOM_2」を使用しています。「ERR_CUSTOM_1」では，レスポンスのステータスコードが「404」の場合には，「C:/data/404.html」をクライアントに返します。Content-Typeヘッダの値は，「text/html; charset=ISO-8859-1」を使用します。また，「ERR_CUSTOM_2」では，リクエストが「/dir1/」から始まるURLで，レスポンスのステータスコードが「503」の場合に，「http://host1/503.html」にリダイレクトします。

6.15.4　エラーページのカスタマイズに関する注意事項

インプロセスHTTPサーバによるエラーページのカスタマイズに関する注意事項を次に示します。

HTTPレスポンスがHTMLファイルの場合，そのHTMLからほかのファイル（画像ファイルなど）を参照していると，エラーページが正しく表示されない場合があります。

ブラウザの設定によっては，ステータスコードがエラーを示し，レスポンスボディのサイズが小さい場合，レスポンスボディがブラウザ固定のメッセージに置き換えられて表示されることがあるため注意してください。特にエラーページをカスタマイズしなかった場合に表示されるデフォルトのエラーページは，レスポンスボディのサイズが小さいため注意してください。

リダイレクトURLの指定値とリクエストURLの指定値が一致して，リダイレクト後に同じエラーステータスが発生すると，クライアントによってはリダイレクトを実行し続けることがあるため注意してください。

ステータスコードに対応するリダイレクトを実施する場合，エラー発生時にリクエストURLに付加されていたクエリ文字列はリダイレクトURLに付加されません。また，URLの書き換えによるセッション管理をしている場合，エラーの発生したページと同じWebアプリケーション内へのリダイレクトを実施してもセッションを引き継ぐことはできません。

6.16　Webコンテナへのゲートウェイ情報の通知

この節では，Webコンテナへのゲートウェイ情報の通知について説明します。

この節の構成を次の表に示します。

表6‒23　この節の構成（Webコンテナへのゲートウェイ情報の通知）

分類

タイトル

参照先

解説

ゲートウェイ指定機能

6.16.1

設定

実行環境での設定（J2EEサーバの設定）

6.16.2

注意事項

Webコンテナにゲートウェイ情報を通知する場合の注意事項

6.16.3

注　「実装」および「運用」について，この機能固有の説明はありません。

参考

インプロセスHTTPサーバを使用しない場合（Webサーバ連携機能を使用する場合）との機能差異はありません。機能の解説については，「5.10　Webコンテナへのゲートウェイ情報の通知」を参照してください。

6.16.1　ゲートウェイ指定機能

クライアントとインプロセスHTTPサーバとの間に，SSLアクセラレータや負荷分散機などのゲートウェイを配置している場合で，welcomeファイルやForm認証画面への遷移時などにWebコンテナが自動的にリダイレクトするとき，Webコンテナではゲートウェイの情報を得ることができないで，転送先のURLを正しく作成できないことがあります。

これを解決するために，ゲートウェイ指定機能を使用します。ゲートウェイ指定機能によって，Webコンテナにゲートウェイ情報を通知し，welcomeファイルやForm認証画面に正しくリダイレクトできるようになります。

ゲートウェイ指定機能は次のような場合に使用できます。

クライアントとインプロセスHTTPサーバとの間にSSLアクセラレータを配置する場合

クライアントからSSLアクセラレータへのアクセスがHTTPSの場合でも，SSLアクセラレータからWebサーバへのアクセスはHTTPとなるため，WebコンテナはHTTPによるアクセスであると認識します。このため，welcomeファイルやForm認証画面へのリダイレクト先URLのスキームはHTTPとなります。

この場合，ゲートウェイ指定機能を使用して，スキームを常にhttpsと見なすように指定することで，正しくリダイレクトできるようになります。

Hostヘッダのないリクエストに対して，リクエストを受けたインプロセスHTTPサーバ以外へリダイレクトする必要がある場合

Hostヘッダのないリクエストをリダイレクトする場合，リダイレクト先URLのホスト名・ポート番号は，リクエストを受けたWebサーバのホスト名・ポート番号となります。

ゲートウェイ指定機能は，WebサーバまたはインプロセスHTTPサーバの前に負荷分散機を配置している場合などで，クライアントがアクセスするURLのホスト名・ポート番号が，リクエストを受けたWebサーバまたはインプロセスHTTPサーバと異なるときに使用します。これによって，クライアントからアクセスするホスト名・ポート番号が指定されるので，正しくリダイレクトできるようになります。

なお，インプロセスHTTPサーバを使用する場合，一つのWebコンテナに複数の異なる経路でアクセスする場合（複数のゲートウェイからWebコンテナにHTTPリクエストが転送される場合など），ゲートウェイ指定機能を使用できません。インプロセスHTTPサーバを使用する場合，ゲートウェイ指定機能を使用するには，Webコンテナへのアクセス経路は一つになる構成にする必要があります。

6.16.2　実行環境での設定（J2EEサーバの設定）

Webコンテナにゲートウェイ情報を通知するための設定をする場合，J2EEサーバの設定が必要です。

ここでは，Webコンテナにゲートウェイ情報を通知するための設定方法と設定例について説明します。

(1)　設定方法

J2EEサーバの設定は，簡易構築定義ファイルで実施します。Webコンテナにゲートウェイ情報を通知するための設定の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのWebコンテナにゲートウェイ情報を通知するための設定の定義について次の表に示します。

表6‒24　簡易構築定義ファイルでのWebコンテナにゲートウェイ情報を通知するための設定の定義

指定するパラメタ

設定内容

webserver.connector.inprocess_http.gateway.https_scheme

リダイレクト先URLのスキームを指定します。

webserver.connector.inprocess_http.gateway.host

ゲートウェイのホスト名を指定します。

webserver.connector.inprocess_http.gateway.port

ゲートウェイのポート番号を指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

(2)　設定例

ゲートウェイ指定機能の設定例を次に示します。

：
<param>
  <param-name>webserver.connector.inprocess_http.gateway.host</param-name>
  <param-value>host1</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.gateway.port</param-name>
  <param-value>4443</param-value>
</param>
<param>
  <param-name>webserver.connector.inprocess_http.gateway.https_scheme</param-name>
  <param-value>true</param-value>
</param>
：

この設定例では，ゲートウェイ指定機能を使用して，スキームを常にHTTPSと見なすように設定しています。

6.16.3　Webコンテナにゲートウェイ情報を通知する場合の注意事項

ゲートウェイ指定機能を使用する上での注意事項を次に示します。

リダイレクト先URLのホスト名，およびポート番号の指定について

通常，ブラウザはHostヘッダを付けてリクエストを送信するため，リダイレクト先URLのホスト名やポート番号を指定する必要はありません。

なお，リクエストにHostヘッダがあるかどうかは，javax.servlet.http.HttpServletRequestクラスのgetHeaderメソッドに，引数「Host」を指定して呼び出すことで確認できます。

サーブレットAPIの動作について

ゲートウェイ指定機能の利用によって，一部のサーブレットAPIの動作が変わります。WebアプリケーションでAPIを利用するときには注意が必要です。

なお，動作が変わるサーブレットAPIについては，「9.4.2(1)　ゲートウェイ指定機能を使用する場合の注意」を参照してください。

web.xmlの<transport-guarantee>タグについて

ゲートウェイ指定機能でスキームをHTTPSと見なすように設定した場合，WebサーバへのリクエストがHTTPであってもHTTPSであると見なされます。このため，web.xmlの<transport-guarantee>タグでINTEGRALやCONFIDENTIALを指定してもHTTPSのURLへリダイレクトされないので注意してください。

CookieのSecure属性について

ゲートウェイ指定機能でスキームをHTTPSと見なすように設定している場合に，Webコンテナが生成したセッションIDを，Cookieによってクライアントに返すとき，そのCookieにはSecure属性が付与されます。

6.17　ログ・トレースの出力

この節では，インプロセスHTTPサーバが出力するログ・トレースについて説明します。

この節の構成を次の表に示します。

表6‒25　この節の構成（ログ・トレースの出力）

分類

タイトル

参照先

解説

インプロセスHTTPサーバが出力するログ・トレース

6.17.1

設定

インプロセスHTTPサーバのアクセスログのカスタマイズ

6.17.2

注　「実装」，「運用」および「注意事項」について，この機能固有の説明はありません。

6.17.1　インプロセスHTTPサーバが出力するログ・トレース

インプロセスHTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシュートのために，次の表に示すログおよびトレースを出力します。

表6‒26　インプロセスHTTPサーバが出力するログ・トレース

ログ・トレースの種類

説明

アクセスログ

Webクライアントからのリクエスト，およびレスポンスの処理結果を出力します。Webクライアントとの通信の解析に使用します。

アクセスログを解析することによって，Webクライアントからリクエストされたファイルや，インプロセスHTTPサーバの性能情報，およびセッショントラッキング情報などを分析できます。

性能解析トレース

インプロセスHTTPサーバでリクエストを送受信するときの性能解析情報や，障害発生時のトラブルシュートのための情報を出力します。

性能解析トレースは，CSV形式などに変換して，ほかのJ2EEサーバの各機能が出力する性能解析情報とあわせて，システム全体のボトルネックの解析などに使用できます。性能解析トレースの詳細については「14.1　性能解析トレースの概要」を参照してください。

スレッドトレース

保守用のトレースです。

通信トレース

保守用のトレースです。

6.17.2　インプロセスHTTPサーバのアクセスログのカスタマイズ

インプロセスHTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシュートのために，アクセスログ，性能解析トレース，スレッドトレース，および通信トレースを出力します。これらのファイルは，ファイル面数やファイルサイズなどを変更できます。また，アクセスログでは，ログの出力形式をカスタマイズできます。

ここでは，インプロセスHTTPサーバのアクセスログの出力形式のカスタマイズについて説明します。インプロセスHTTPサーバのアクセスログおよびトレースファイルのファイル面数やファイルサイズなどの変更については「15.2　インプロセスHTTPサーバのログ取得の設定」を参照してください。

(1)　カスタマイズの手順

アクセスログの出力形式のカスタマイズの手順を次に示します。

アクセスログのフォーマット名を定義します。

フォーマットを新規作成する場合には，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.logger.access_log.format_listパラメタで，新規に作成するフォーマット名を追加します。

設定例

：
<param>
  <param-name>webserver.logger.access_log.format_list</param-name>
  <param-value>formatA</param-value>
</param>
：

フォーマットを新規作成する場合には，デフォルトで提供されているアクセスログのフォーマットを参考にしてください。フォーマットについては，「6.17.2(2)　アクセスログのフォーマット」を参照してください。

アクセスログの出力形式を定義します。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.logger.access_log.<フォーマット名>パラメタで，<フォーマット名>で指定したフォーマットでのアクセスログの出力形式を定義します。出力形式の定義では，アクセスログのフォーマットの引数を指定します。

設定例

：
<param>
  <param-name>webserver.logger.access_log.formatA</param-name>
  <param-value>%h %u %t &quot;%r&quot; %&gt;s HostHeader=&quot;%{host}i&quot;</param-value>
</param>
：

指定できるフォーマットの引数については，「6.17.2(3)　アクセスログのフォーマットの引数」を参照してください。

アクセスログの出力に使用するフォーマットを指定します。

簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，webserver.logger.access_log.inprocess_http.usage_formatパラメタで，アクセスログの出力に使用するフォーマット名を指定します。ここで指定したフォーマットで，アクセスログが出力されるようになります。

設定例

：
<param>
  <param-name>webserver.logger.access_log.inprocess_http.usage_format</param-name>
  <param-value>formatA</param-value>
</param>
：

(2)　アクセスログのフォーマット

アプリケーションサーバでは，インプロセスHTTPサーバのアクセスログのフォーマットとして，common（デフォルトフォーマット）とcombined（拡張フォーマット）という2種類のフォーマットを提供しています。フォーマットを新規作成する場合には，これらのフォーマットを参考にしてください。

(a)　出力形式

アクセスログの出力形式について説明します。なお，△は，半角スペースを表します。また，ここでは，表記の都合上，複数行にわたっていますが，実際には1行で出力されます。

デフォルトフォーマットの出力形式を次に示します。

Webクライアントのホスト名またはIPアドレス△リモートログ名△認証ユーザ名
△Webクライアントからのリクエストの処理を開始した時刻△リクエストライン
△最終ステータスコード△HTTPヘッダを除く送信バイト数

拡張フォーマットの出力形式を次に示します。

Webクライアントのホスト名またはIPアドレス△リモートログ名△認証ユーザ名
△Webクライアントからのリクエストの処理を開始した時刻△リクエストライン
△最終ステータスコード△HTTPヘッダを除く送信バイト数
△"Refererヘッダの内容"△"User-Agentヘッダの内容"

下線部分が，デフォルトフォーマットと拡張フォーマットの差異です。拡張フォーマットでは，デフォルトフォーマットの出力内容に加えて，「Refererヘッダの内容」と「User-Agentヘッダの内容」が出力されます。

(b)　出力例

デフォルトフォーマットでのアクセスログの出力例を次に示します。

10.20.30.40 - user [20/Dec/2004:15:45:01 +0900] "GET /index.html HTTP/1.1" 200 8358
10.20.30.40 - user [20/Dec/2004:15:45:01 +0900] "GET /left.html HTTP/1.1" 200 2358
10.20.30.40 - user [20/Dec/2004:15:45:01 +0900] "GET /right.html HTTP/1.1" 200 4358

拡張フォーマットでのアクセスログの出力例を次に示します。

10.20.30.40 - - [18/Jan/2005:13:06:10 +0900] "GET / HTTP/1.0" 200 38 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
10.20.30.40 - - [18/Jan/2005:13:06:25 +0900] "GET /demo/ HTTP/1.0" 500 684 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

(3)　アクセスログのフォーマットの引数

フォーマットの出力形式を定義するときに指定する，アクセスログのフォーマットの引数を次の表に示します。

表6‒27　アクセスログのフォーマットの引数の一覧

フォーマットの引数

出力内容

出力例

%%

%記号

%

%a

WebクライアントのIPアドレス

10.20.30.40

%A

J2EEサーバのIPアドレス

10.20.30.100

%b

HTTPヘッダを除く送信バイト数

（0バイトの場合は「-」となる）

2048

%B

HTTPヘッダを除く送信バイト数

（0バイトの場合は「0」となる）

1024

%h

Webクライアントのホスト名またはIPアドレス

（ホスト名を取得できない場合はIPアドレスとなる）

10.20.30.40

%H

リクエストプロトコル

HTTP/1.1

%l

リモートログ名※1

（常に「-」になる）

-

%m

リクエストメソッド

GET

%p

Webクライアントからのリクエストを受け付けたポート番号

80

%q

クエリ文字列

（「?」から始まる。クエリ文字列がない場合は空文字となる）

?id=100&page=15

%r

リクエストライン

GET /index.html HTTP/1.1

%>s

最終ステータスコード

（内部リダイレクトされた値は出力しない）

200

%S※2

ユーザのセッションID

（セッションIDがない場合は「-」となる）

00455AFE4DA4E7B7789F247B8FE5D605

%t

Webクライアントからのリクエストの処理を開始した時刻

（単位：秒，出力形式：dd/MMM/YYYY:HH:mm:ss Z）

[18/Jan/2005:13:06:10 +0900]

%T

Webクライアントのリクエストの処理に掛かった時間

（単位：秒）

2

%d

Webクライアントからのリクエストの処理を開始した時刻

（単位：ミリ秒，出力形式：dd/MMM/YYYY:HH:mm:ss.nnn Z（nnnはミリ秒））

[18/Jan/2005:13:06:10.152 +0900]

%D

Webクライアントのリクエストの処理に掛かった時間

（単位：ミリ秒）

2000

%u

Basic認証ユーザ名，Form認証ユーザ名

（認証ユーザ名がない場合は「-」となる）

user

%U

リクエストファイルパス

/index.html

%v

J2EEサーバのローカルホスト名

server

%{foo}i※3

リクエストヘッダfooの内容

（fooヘッダが存在しない場合は「-」となる）

%{Host}iの場合www.example.com:8888

%{foo}c

Webクライアントが送信したCookie情報でCookieの名前がfooの内容

（Cookieの名前にfooがない場合は「-」となる）

%{JSESSIONID}cの場合00455AFE4DA4E7B7789F247B8FE5D605

%{foo}o※3

レスポンスヘッダfooの内容

（fooヘッダが存在しない場合は「-」となる）

%{Server}oの場合CosminexusComponentContainer

注※1

リモートログ名は，RFC 1413で規定されているIdentificationプロトコルで取得できるWebクライアント側のユーザ名です。

注※2

%Sで表示されるセッションIDは，Cookie名「JSESSIONID」の値です。

注※3

一度のHTTPリクエストまたはHTTPレスポンスで同じヘッダ名を複数回送信する場合があります。この場合，最初に読み込んだヘッダの内容を出力します。

注意事項

フォーマットの引数の指定に誤りがある場合には，デフォルトフォーマットが使用されます。デフォルトフォーマットが使用される例を次に示します。

フォーマットの引数の一覧にない文字列（例：%Gなど）を指定した場合

リクエストヘッダの内容，レスポンスヘッダの内容，Cookie名で0文字（%{}iなど）を指定した場合

参考

デフォルトフォーマットと拡張フォーマットをフォーマットの引数で記述すると，次のような形式になります。

デフォルトフォーマット

%h %l %u %t "%r" %>s %b

拡張フォーマット

%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"

6.18　URIのデコード機能

URIのデコード機能は，Webサーバ連携，およびインプロセスHTTPサーバで利用できます。

この節では，URIのデコード機能について説明します。

この節の構成を次の表に示します。

表6‒28　この節の構成（URIのデコード機能）

分類

タイトル

参照先

解説

URIのデコード機能の概要

6.18.1

設定

実行環境での設定（J2EEサーバの設定）

6.18.2

注意事項

URIのデコード機能を使用する場合の注意事項

6.18.3

注　「実装」および「運用」について，この機能固有の説明はありません。

6.18.1　URIのデコード機能の概要

URIのデコード機能を使用すると，アプリケーションサーバでは，リクエストURIのサーブレットパスおよび追加のパス情報に含まれるURLエンコードされた文字列がデコードされます。ただし，コンテキストパスはデコードされません。

デコードされたURIを使用しないWebアプリケーションを実行するときは，URIのデコード機能を使用しないように設定するか，Webアプリケーション側で対応する必要があります。

URIのデコード機能の使用時に影響があるServlet API，デコードされた文字列を使用する機能，デコード時に使用される文字コード，および文字列のデコードと正規化の実行順序を次に記述します。

(1)　URIのデコード機能の使用時に影響があるServlet API

URIのデコード機能を使用する場合，javax.servlet.http.HttpServletRequestインタフェースの次のメソッドでは，デコードされたURIが戻り値となります。

getPathInfoメソッド

getPathTranslatedメソッド

getServletPathメソッド

ただし，getRequestURIメソッドおよびgetRequestURLメソッドでは，デコードされていないURLが戻り値となります。

(2)　デコードされた文字列を使用する機能

URIのデコード機能を使用する場合，次に示すマッチング処理で，デコードされた文字列が使用されます。

サーブレットおよびJSPのURLパターンとのマッチング

デフォルトマッピングとのマッチング

静的コンテンツとのマッチング

フィルタのURLパターンとのマッチング

web.xmlの<error-page>タグ，またはJSPのpageディレクティブのerrPage属性で指定するエラーページとのマッチング

アクセスを制限するURLパターンとのマッチング

ログイン認証のURL判定

リクエストのフォワードおよびインクルード

HTTPレスポンス圧縮フィルタのURLパターンとのマッチング

URLグループ単位の同時実行スレッド数制御のURLパターンとのマッチング

ただし，コンテキストパスはデコードされないで，元の文字列のまま扱われるため，コンテキストルートと一致しない場合は「404 Not Found」が戻り値となります。

また，アプリケーションサーバの次の機能では，デコード後の文字列でのマッチングは行われません。

インプロセスHTTPサーバのエラーページのカスタマイズ機能

インプロセスHTTPサーバのリダイレクトによるリクエストの振り分け機能

(3)　デコード時に使用される文字コード

URIのデコード機能を使用する場合，デコード時に使用される文字コードはUTF-8です。

(4)　文字列のデコードと正規化の実行順序

クライアントから送信されたリクエストURIで，マッチングに利用されるURLは，デコードされたあとで正規化されます。

6.18.2　実行環境での設定（J2EEサーバの設定）

URIのデコード機能を使用する場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。URIのデコード機能の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.http.request.uri_decode.enabledに指定します。このパラメタでは，URIのデコード機能を使用するかどうかを指定します。

簡易構築定義ファイル，および指定するパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

6.18.3　URIのデコード機能を使用する場合の注意事項

ここでは，URIのデコード機能を使用する場合の注意事項について説明します。

(1)　文字列のデコードと正規化の実行順序

サーブレットパスとURLパターンのマッチングでは，デコードされたあとで正規化されたURIが使用されます。

コンテキストパスとコンテキストルートのマッチングでは，デコードされないで正規化されたURIが使用されます。

(2)　リクエストの属性

フォワード時またはインクルード時にリクエストに追加される属性にも，デコードされた値が格納されるものがあります。フォワード時またはインクルード時にリクエストに設定される各属性について，格納される値がデコードされるかどうかを次の表に示します。

処理

属性

格納される値のデコードの実行

フォワード

javax.servlet.forward.request_uri

×

javax.servlet.forward.context_path

×

javax.servlet.forward.servlet_path

○

javax.servlet.forward.path_info

○

javax.servlet.forward.query_string

×

インクルード

javax.servlet.include.request_uri

×

javax.servlet.include.context_path

×

javax.servlet.include.servlet_path

○

javax.servlet.include.path_info

○

javax.servlet.include.query_string

×

（凡例）

○：デコードされる

×：デコードされない

各属性および各属性に格納される値については，サーブレット仕様書を参照してください。

(3)　HTTPセッションの引き継ぎ

コンテキストパスはデコードされないで，元の文字列のまま扱われるため，HTTPセッションは引き継がれます。

6.19　インプロセスHTTPサーバのログ取得の設定

ここでは，インプロセスHTTPサーバのログ取得で設定できる項目について説明します。

インプロセスHTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシューティングのために，アクセスログ，性能解析トレース，スレッドトレース，および通信トレースを出力します。これらのファイルでは，ファイル面数やファイルサイズを簡易構築定義ファイルで変更できます。

インプロセスHTTPサーバのログ取得で変更できる設定項目と，項目に対応する簡易構築定義ファイルのパラメタを次の表に示します。

表6‒29　インプロセスHTTPサーバのログ取得の設定項目

ログおよびトレース

項目

対応する簡易構築定義ファイルのパラメタ

アクセスログ

アクセスログの出力の有無

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.enabled

（デフォルトではアクセスログが出力されます）

アクセスログのファイル名

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.filename

アクセスログのファイルサイズ

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.filesize

アクセスログのファイル面数

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.filenum

アクセスログのフォーマット名

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.format_list※

アクセスログの出力形式

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.<フォーマット名>※

アクセスログ出力時のフォーマット

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.usage_format※

性能解析トレース

−

ほかの性能解析トレースと同様に，日常的なシステム運用の作業で，cprfedコマンドを実行するときに取得条件などを指定します。性能解析トレースファイルの取得については，「14.　性能解析トレース」を参照してください。

スレッドトレース

スレッドトレースのファイル面数

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.thread_trace.inprocess_http.filenum

スレッドトレースのファイルサイズ

スレッドトレースのファイルサイズ＝（（（A+B）×32,786）＋32,914）バイト

A＝論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.max_connectionsパラメタの値

B＝論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.send_timeoutパラメタの値が0の場合0，0以外の場合1

通信トレース

通信トレースのファイル面数

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.communication_trace.inprocess_http.filenum

通信トレースのファイルサイズ

通信トレースのファイルサイズ＝（（（A+B）×172,050）＋128）バイト

A＝論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.max_connectionsパラメタの値

B＝論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.send_timeoutパラメタの値が0の場合は0，0以外の場合は1

（凡例）−：該当しない

注※　アクセスログでは，これらのキーでフォーマットを定義することで，ログの出力形式をカスタマイズできます。インプロセスHTTPサーバのアクセスログのカスタマイズについては，「6.17.2　インプロセスHTTPサーバのアクセスログのカスタマイズ」を参照してください。

6.20　cjtracesync（インプロセスHTTPサーバ用トレースファイルの同期）

この節では，インプロセスHTTPサーバ用トレースファイルを同期させるcjtracesyncコマンドについて説明します。

形式

cjtracesync [-h] [-thr|-comm] <サーバ名称>

機能

インプロセスHTTPサーバ使用時に，スレッドトレースおよび通信トレースの情報を共有メモリの情報と同期させます。インプロセスHTTPサーバを使用している場合に，Management Serverの機能を利用しないで障害情報を取得するときには，情報を取得する直前に，このコマンドを実行してください。

引数

-h

コマンドの使用方法が表示されます。

-thr

スレッドトレース情報を取得する場合に指定します。-thrオプション，-commオプションのどちらも指定されていない場合，スレッドトレースおよび通信トレースの両方の情報を更新します。

-comm

通信トレース情報を取得する場合に指定します。-thrオプション，-commオプションのどちらも指定されていない場合，スレッドトレースおよび通信トレースの両方の情報を更新します。

<サーバ名称>

トレース情報を取得するJ2EEサーバのサーバ名称を指定します。サーバ名称は必ず指定してください。

戻り値

0：

正常終了しました。

1：

異常終了しました。

9：

管理者特権がないため，コマンドが実行できません（Windowsの場合）。

6.21　SOAPアプリケーション運用時の注意事項

SOAPアプリケーション運用時の注意事項について説明します。

6.21.1　インプロセスHTTPサーバを使用しているJ2EEサーバを停止する場合の注意

インプロセスHTTPサーバを使用している場合，J2EEサーバを停止しようとしても停止しないか，停止までに長時間掛かることがあります。

これは，次の条件がすべて重なる場合に発生します。

J2EEサーバを停止しようとした場合

SOAPサービス側のWebサーバにインプロセスHTTPサーバを使用している場合

webserver.connector.inprocess_http.persistent_connection.timeoutの値を大きく設定しているか，0を設定している場合

運用中のSOAPサービスにコネクションプーリングが有効なSOAPクライアントが接続中であるか，一度でも接続したことがある場合

設定内容および停止方法ごとに，発生する可能性のある現象を次に示します。

インプロセスHTTPサーバのwebserver.connector.inprocess_http.persistent_connection.timeoutの値を大きく設定している場合

cjstopsvコマンドでJ2EEサーバを停止するときにKDJE39514-Wが出力され，最大でこのプロパティに設定した秒数分の時間が掛かることがあります。

インプロセスHTTPサーバのwebserver.connector.inprocess_http.persistent_connection.timeoutの値に0を設定している場合

J2EEサーバが停止しないことがあります。

Management Serverを使用して停止した場合

論理サーバの停止に失敗したことを表すメッセージ（KEOS20011-E）が出力され，強制停止することがあります。

cjstopsvコマンド実行時にKDJE39514-Wが出力されて，J2EEサーバの停止に時間が掛かる場合は，cjstopsvコマンドに-fオプションを付けて再度実行し，J2EEサーバを停止してください。

Management Serverを使用して停止した場合，停止監視時間を設定しているときは，停止監視時間が経過すると強制停止されます。停止監視時間を設定していないときは，次の手順でJ2EEサーバを停止してください。

運用管理ポータルで［論理サーバの起動/停止］アンカーをクリックします。

［サーバビュー］タブの［論理J2EEサーバ］−［J2EEサーバ］−［<J2EEサーバ名>］をクリックします。

［起動/停止］タブをクリックします。

［強制停止］ボタンをクリックします。

7　Cosminexus JAX-RSエンジン（JAX-RS 1.1）

V9互換モードでのCosminexus JAX-RSエンジン（JAX-RS 1.1）について説明します。

7.1　V9互換モードでのCosminexus JAX-RSエンジン（JAX-RS 1.1）

V9互換モードでは，JAX-RS機能はCosminexus JAX-RSエンジン（JAX-RS 1.1）だけ使用できます。Cosminexus JAX-RSエンジン（JAX-RS 1.1）については，マニュアル「アプリケーションサーバ Webサービス開発ガイド」を参照してください。

8　CJPAプロバイダ

この章では，CJPAプロバイダの機能概要，アプリケーションの実装方法，および実行環境の設定について説明します。

8.1　この章の構成

CJPAプロバイダとは，JPA仕様書に定められたAPIや内部処理を実装し，ライブラリ形式でユーザに提供するアプリケーションサーバが提供するJPAプロバイダです。

この章では，CJPAプロバイダの機能について説明します。この章の構成を次の表に示します。

表8‒1　この章の構成（CJPAプロバイダの機能）

分類

タイトル

参照先

解説

CJPAプロバイダとは

8.2

エンティティを使用したデータベースの更新

8.3

EntityManagerによるエンティティの操作

8.4

データベースとJavaオブジェクトとのマッピング情報の定義

8.5

エンティティのリレーションシップ

8.6

エンティティオブジェクトのキャッシュ機能

8.7

プライマリキー値の自動採番

8.8

クエリ言語によるデータベース操作

8.9

楽観的ロック

8.10

JPQLでの悲観的ロック

8.11

実装

エンティティクラスの作成

8.12

エンティティクラスの継承方法

8.13

EntityManagerおよびEntityManagerFactoryの使用方法

8.14

コールバックメソッドの指定方法

8.15

クエリ言語を利用したデータベースの参照および更新方法

8.16

JPQLの記述方法

8.17

persistence.xmlの定義

8.18

設定

実行環境での設定

8.19

注　「運用」について，この機能固有の説明はありません。

8.2　CJPAプロバイダとは

CJPAプロバイダとは，アプリケーションサーバが提供するJPAプロバイダです。CJPAプロバイダの位置づけを次の図に示します。

図8‒1　CJPAプロバイダの位置づけ

CJPAプロバイダはJ2EEサーバの一機能です。JTAおよびJNDIを使用して，データベースを操作します。ここでは，CJPAプロバイダの機能概要について説明します。

8.2.1　CJPAプロバイダでの処理

CJPAプロバイダでは，次の機能を提供しています。

エンティティオブジェクトとデータベースのマッピング

エンティティオブジェクトの管理

JPQLによるデータの操作

JDBCを通じてのデータベースへのアクセス

JPAを使用するには，ユーザが作成したアプリケーションでCJPAプロバイダが提供するインタフェースを操作します。CJPAプロバイダで実行する処理を次の図に示します。

図8‒2　CJPAプロバイダで実行される処理

図について説明します。

persistence.xmlに定義されている永続化ユニットの情報から，CJPAプロバイダはEntityManagerFactoryを生成します。

永続化ユニットとは，マッピング対象となるクラス，O/Rマッピングの情報，データソースなどを集めた論理的なグループです。永続化ユニットの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「5.4.4　永続化ユニットとは」を参照してください。

生成されたEntityManagerFactoryからEntityManagerを生成します。

ユーザアプリケーションから，EntityManager，クエリ，またはトランザクションを操作します。

EntityManager，クエリ，トランザクションから永続化コンテキストを通して，エンティティオブジェクトを操作します。

エンティティオブジェクトの変更をJDBCドライバを介してデータベースに反映します。

なお，EntityManagerには，次の2種類があります。

コンテナ管理EntityManager

J2EEコンテナによって管理されるEntityManagerです。

アプリケーション管理EntityManager

アプリケーションによって管理されるEntityManagerです。

EntityManagerの種類の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「5.5.1　EntityManagerと永続化コンテキスト」を参照してください。

また，トランザクションではトランザクションのコミットやロールバックなどを管理します。CJPAプロバイダでは，トランザクションとしてリソースローカルトランザクションを使用できます。JTAトランザクションと連携する場合，J2EEコンテナが提供する機能を使用します。

8.2.2　CJPAプロバイダが提供する機能

CJPAプロバイダでは次に示す機能を提供しています。

表8‒2　CJPAプロバイダが提供する機能

機能

機能の概要

標準/拡張※

参照先

エンティティを使用したデータベースの更新

ユーザのアプリケーションから生成したエンティティによって，データベースのデータを更新します。

標準

8.3

8.4

データベースとJavaオブジェクトとのマッピング情報の定義

Javaオブジェクトとデータベースとのマッピング情報は，アノテーションまたはO/Rマッピングファイルで定義できます。

標準

8.5

エンティティのリレーションシップの設定

データベースのテーブル間の関連をエンティティで設定します。

標準

8.6

エンティティオブジェクトのキャッシュ

EntityManagerのエンティティオブジェクトの内容をメモリに保持する機能です。同じ内容のエンティティオブジェクトが呼ばれた場合，メモリのエンティティオブジェクトを使用します。

拡張

8.7

プライマリキーの自動採番

エンティティオブジェクトを使用してデータベースにデータを挿入するときに，CJPAプロバイダはプライマリキーを自動的に格納します。ユーザがプライマリキーを指定しなくても，一意の値が格納されます。

標準

8.8

クエリ言語によるデータベース操作

クエリ言語を使用してデータベースを操作できます。CJPAプロバイダでは，クエリ言語としてJPQLまたはSQLを使用できます。

標準

8.9

楽観的ロック

データベースの排他方法の一つです。データベースのデータがほかのトランザクションから更新されていないかを確認してからデータを更新します。楽観的ロックではデータをロックしないため，デッドロックは発生しません。

標準

8.10

JPQLでの悲観的ロック

データベースの排他方法の一つです。ほかのトランザクションから更新されないように，レコードを占有ロックします。悲観的ロックはJPQLを使用した場合だけ実行されます。

拡張

8.11

注※　JPA1.0仕様に基づいた機能かどうかを示します。

標準：JPA1.0仕様に基づいた機能であることを示します。

拡張：CJPAプロバイダ独自の機能であることを示します。

これらの機能の詳細については，表中の「参照先」に示す節を参照してください。

また，CJPAプロバイダでは，PRFトレースを取得できます。PRFトレースの取得ポイントについては「14.　性能解析トレース」を参照してください。

8.2.3　CJPAプロバイダを使用するための前提条件

ここでは，CJPAプロバイダを使用するための前提条件について説明します。

(1)　使用できるコンポーネント

CJPAプロバイダを利用するコンポーネントは，EJBの場合はEJB 3.0以降，Webコンポーネントの場合はServlet 2.5以降となります。

アプリケーションサーバでは，EJB，WebアプリケーションでJPAを使用できます。また，Webアプリケーションからユーザスレッドを使用した場合も，JPAを使用できます。なお，次に示す環境またはライブラリではJPAを使用できません。

EJBクライアントアプリケーション環境

J2EEアプリケーションクライアント環境

コンテナ拡張ライブラリ

JPAを使用できるコンポーネントを次の表に示します。

表8‒3　JPAを使用できるコンポーネント

コンポーネント

JPAの使用

EJB

Stateless Session Bean（EJB3.0以降）※1

○

Stateful Session Bean（EJB3.0以降）※1

○

Stateless Session Bean（EJB3.0より前）

×

Stateful Session Bean（EJB3.0より前）

×

インターセプタ

○

Message-driven Bean

×

Entity Bean

×

Webアプリケーション

サーブレット，フィルタ，イベントリスナ（Servlet2.5以降）

○

JSP，JSPのタグハンドラ，JSPのイベントリスナ，JSPのタグライブラリイベントリスナ※2（Servlet2.5以降）

○

サーブレット，フィルタ，イベントリスナ（Servlet2.5より前）

×

JSP，JSPのタグハンドラ，JSPのイベントリスナ，JSPのタグライブラリイベントリスナ（Servlet2.5より前）

×

（凡例）○：使用できる　×：使用できない

注※1　アプリケーションサーバではEJB3.0のejb-jar.xmlを使用したJPAの定義はできません。このため，@PersistenceUnitや@PersistenceContextなどのアノテーションを使用して，永続化ユニットや永続化コンテキストの参照を定義してください。

注※2　アプリケーションサーバでは，JSPタグライブラリイベントリスナでのアノテーションの使用はできません。JSPタグライブラリイベントリスナでJPAの機能を使用する場合は，web.xmlの<persistence-unit-ref>タグや<persistence-context-ref>タグを使用して永続化ユニットや永続化コンテキストの参照を定義してください。

注意事項

Servlet 2.5以降のweb.xmlのmetadata-complete属性にtrueが設定されている場合，Webコンポーネントのアノテーションが読み込まれません。このため，アノテーションを使用して，永続化コンテキストまたは永続化ユニットの参照を定義することはできません。ただし，web.xmlに参照を定義することはできます。

(2)　接続できるデータベース

CJPAプロバイダを使用する場合，次に示すデータベースに接続できます。

Oracle

HiRDB

(3)　使用できるDB Connector

CJPAプロバイダは，DB Connectorを使用してデータベースを更新します。CJPAプロバイダでは次の表に示すDB Connectorを使用できます。

表8‒4　CJPAプロバイダで使用できるDB Connector

使用するデータベース

トランザクションタイプ

使用できるDB Connector

Oracle

LocalTransaction

NoTransaction

DBConnector_Oracle_CP.rar

XATransaction

DBConnector_Oracle_XA.rar

Oracle RAC

LocalTransaction

NoTransaction

DBConnector_Oracle_CP.rar

DBConnector_CP_ClusterPool_Root.rar

DBConnector_Oracle_CP_ClusterPool_Member.rar

HiRDB

LocalTransaction

NoTransaction

DBConnector_HiRDB_Type4_CP.rar

XATransaction

DBConnector_HiRDB_Type4_XA.rar

(4)　使用できない環境

次の環境ではCJPAプロバイダを使用できません。

バッチアプリケーションの実行環境

EJBクライアントアプリケーションの実行環境

(5)　メソッドキャンセル機能の使用について

CJPAプロバイダでは，OneToOneおよびManyToOneのLAZYフェッチの場合，アクセサメソッドに独自のバイナリコードを埋め込みます。これによって，アクセサメソッドがメソッドキャンセルの対象になります。このため，OneToOneリレーションシップ，またはManyToOneリレーションシップでLAZYフェッチが指定されている場合は，エンティティクラス，埋め込み可能クラス，およびマップドスーパークラスを保護区に登録する必要があります。

なお，保護区に登録しない場合は，埋め込んだバイナリコード上でメソッドキャンセルが起こるおそれがあります。保護区に登録しない場合の動作は保証しません。

保護区に登録されている場合でも，登録されていない場合でも，メソッドタイムアウトで下記のようなスタックトレースが出力されます。ただし，保護区に登録しているとメソッドキャンセルは発生しません。

次に示す例では，ユーザが呼び出したEntityClass1.getMappingClass2メソッドの延長で，埋め込んだEntityClass1._toplink_getmappingClass2が呼ばれています。そこでメソッドタイムアウトが発生していますが，メソッドキャンセルは発生しません。

message-id       message(LANG=ja)
KDJE52703-W      A timeout occurred while the user program was executing. (threadID = 23794987, rootAPInfo = 10.209.11.124/5964/0x4828eb62000128e0, application = JPA_JavaEE_TP, bean = TestBean, method = doTest)
    jpa.test.annotation.onetoone.entity.EntityClass1._toplink_getmappingClass2(EntityClass1.java)
                       locals:
                         (jpa.test.annotation.onetoone.entity.EntityClass1) this = <0x11e35878> (jpa.test.annotation.onetoone.entity.EntityClass1)
                        at jpa.test.annotation.onetoone.entity.EntityClass1.getMappingClass2(EntityClass1.java:34)
                       locals:
                         (jpa.test.annotation.onetoone.entity.EntityClass1) this = <0x11e35878> (jpa.test.annotation.onetoone.entity.EntityClass1)

保護区への登録については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「2.2.5　criticalList.cfg（保護区リストファイル）」を参照してください。

(6)　アノテーションの参照抑止機能の使用について

CJPAプロバイダを使用する場合，アノテーションの参照抑止機能は使用できません。アノテーションの参照抑止機能が有効になっていると，永続化コンテキストおよび永続化ユニットの参照を定義できません。

8.2.4　DB Connectorのコネクション数の見積もり

CJPAプロバイダを使用する場合に必要となるDB Connectorのリソースの見積もりについて説明します。

CJPAプロバイダでは，DB Connectorのコネクションを取得します。CJPAプロバイダが使用するコネクション数の見積もり式を次に示します。

コネクション数の見積もり式

CJPAプロバイダのアプリケーションで利用されるコネクション数

　　＝JPA機能を利用したアプリケーションの同時実行数※

注※　JPA機能を利用したアプリケーションで，複数の永続化ユニットのEntityManagerを利用する場合や，ビジネスメソッドの呼び出しでEntityManagerが利用するトランザクションが異なる場合，EntityManagerごとにそれぞれコネクションが必要となります。

注意事項

ユーザがJPA機能とは別にコネクションを取得する場合，コネクションシェアリング機能を利用することでコネクション数を削減できます。コネクションシェアリングの詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.14.3　コネクションシェアリング・アソシエーション」を参照してください。

8.3　エンティティを使用したデータベースの更新

CJPAプロバイダでは，エンティティを使用したデータベースの更新ができます。

JPAを使用するには，ユーザはデータベースのテーブルをJavaのオブジェクトとして扱うためのエンティティクラスを作成する必要があります。エンティティクラスを使用すると，CJPAプロバイダを通してデータベースのデータを操作します。このとき，CJPAプロバイダが提供するEntityManagerインタフェースを介して，データベースを操作します。

エンティティクラスを使用したデータベースの操作は次のとおりです。

エンティティクラスのインスタンス（エンティティオブジェクト）を生成します。

EntityManagerインタフェースの引数に，エンティティオブジェクトを渡し，データベースを操作します。

この操作をするためには，エンティティクラスを作成する必要があります。

EntityManagerとはエンティティを操作して，状態を制御するためのオブジェクトです。エンティティの操作には，persist操作，remove操作，merge操作，flush操作，およびrefresh操作があります。これらの操作の詳細については，「8.4.1　エンティティの状態遷移」を参照してください。

8.4　EntityManagerによるエンティティの操作

エンティティの状態は，CJPAプロバイダで提供するEntityManagerで制御されます。ここでは，EntityManagerでのエンティティの操作について説明します。

8.4.1　エンティティの状態遷移

エンティティには状態があります。エンティティに対して操作するとエンティティの状態は遷移します。ここでは，エンティティの状態の種類，エンティティに対して実行する操作，およびエンティティの操作と状態遷移について説明します。

(1)　エンティティの状態の種類

エンティティの状態には，new，managed，detached，removedの4種類があります。EntityManagerのメソッドを利用してエンティティを操作することで，エンティティの状態が変更されます。

エンティティのそれぞれの状態について次の表に示します。

表8‒5　エンティティの状態

エンティティインスタンスの状態

説明

new

新しく生成された状態のエンティティです。

新しく生成されたエンティティインスタンスは，永続化アイデンティティを持ちません。このため，永続化コンテキストに関連づいていません。

managed

永続化コンテキストに関連づけられた永続化アイデンティティを持ち，永続化コンテキストで管理されている状態です。

detached

永続化コンテキストに関連づけられていない永続化アイデンティティを持つ状態です。

removed

永続化アイデンティティを持ち，永続化コンテキストに関連づけられている状態です。また，エンティティインスタンスがデータベースから削除されることが予定されている状態でもあります。

(2)　エンティティに対する操作

ユーザがデータベースのレコードを検索すると，CJPAプロバイダは取得したデータをエンティティのフィールドに保持します。また，ユーザがデータベースの内容を更新する場合は，永続化コンテキストに登録されているエンティティの状態を変更して，トランザクションをコミットすることでデータベースにエンティティの状態を反映します。このように，エンティティに対して操作することで，データベースの情報を更新します。

エンティティに対する操作の種類を次の表に示します。

表8‒6　エンティティに対する操作の種類

操作

説明

flush

エンティティオブジェクトの内容をデータベースに反映します。

merge

EntityManagerの管理対象外となっているエンティティオブジェクトをEntityManagerの管理対象とします。

persist

エンティティオブジェクトを管理して，永続化します。

refresh

エンティティオブジェクトにデータベースの内容を反映します。

remove

エンティティオブジェクトを削除予定状態にします。

(3)　エンティティに対する操作と状態遷移

エンティティインスタンスに対する操作と状態遷移について次の図で説明します。

図8‒3　エンティティインスタンスに対する操作と状態遷移

エンティティに対する操作と状態遷移について次の表にまとめます。

表8‒7　エンティティの状態遷移

操作

状態

new

managed

detached

removed

persist

managed※1

managed

managed※1

managed

remove

new

removed

例外※2，※3

Removed

merge

コピー元

new

コピー先

managed

コピー元

managed

コピー先

managed

コピー元

detached

コピー先

managed

例外※3，※4

refresh

例外※2，※4

managed※5

例外※2，※4

例外※2，※4

commit

−

※6

−

detached

rollback

−

detached

−

detached

flush

−

managed

−

detached

clear

−

detached

−

detached

（凡例）−：該当しない

注※1　persist操作で例外が発生した場合，状態は遷移しないで元の状態になります。

注※2　発生する例外はIllegalArgumentExceptionです。

注※3　データベース上に対応する行が存在しない場合，操作は無視されます。

注※4　例外時には状態は遷移しないで，元のままとなります。

注※5　データベース上に対応する行が存在しない場合，EntityNotFoundExceptionが発生します。

注※6　トランザクションスコープの永続化コンテキストの場合はdetachedになります。拡張された永続化コンテキストの場合はmanagedになります。

また，persist，remove，merge，refreshをトランザクション外で実行した場合の動作は，永続化コンテキストの種類によって異なります。

トランザクションスコープの永続化コンテキストの場合

TransactionRequiredExceptionとなります。

拡張された永続化コンテキストの場合

状態が遷移して，次のトランザクション決着のタイミングでデータベースに状態が反映されます。

(4)　エンティティに対する操作の伝播

エンティティがリレーションシップを持つ場合に，リレーションシップを表すアノテーションのcascade属性を指定すると，エンティティに対する操作が関連するエンティティに対して伝播されます。cascade属性には，次の表に示す値を指定できます。

表8‒8　cascade属性の種類

cascade属性の種類

説明

CascadeType.ALL

persist，remove，merge，refreshの操作が関連先に伝播されます。

CascadeType.PERSIST

persist操作が関連先に伝播されます。

CascadeType.REMOVE

remove操作が関連先に伝播されます。

CascadeType.MERGE

merge操作が関連先に伝播されます。

CascadeType.REFRESH

refresh操作が関連先に伝播されます。

8.4.2　エンティティに対するpersist操作

エンティティに対するpersist操作を実行するには，EntityManagerのpersistメソッドを呼び出します。EntityManagerのpersistメソッドを呼び出したり，persist処理がカスケードされたりすると，エンティティはデータベースへの永続化や永続化コンテキストでの管理対象になります。

次の表に，persist操作後のエンティティの状態をエンティティの状態ごとに示します。

表8‒9　Persist操作でのエンティティの状態

エンティティの状態

persist操作後のエンティティの状態

new※

managedに遷移します。managedに遷移したエンティティはトランザクションのコミット時またはコミット前にデータベースに追加されます。または，flush操作の実行の結果としてデータベースに追加されます。

managed

persist操作は無視されます。ただし，エンティティからほかのエンティティへのリレーションシップのcascade属性にPERSISTまたはALLが指定されていると，このエンティティが参照するエンティティにpersist操作が伝播されます。

detached※

データベースにエンティティと対応する行が存在しない場合は，managedに遷移します。対応する行が存在する場合，EntityExistsExceptionが発生します。

removed

managedに遷移します。

注※　CJPAプロバイダの場合，エンティティの状態がnewまたはdetachedの場合，データベース上にエンティティに対応するデータが存在するかどうかでエンティティの状態遷移の結果が異なります。CJPAプロバイダの場合，次のことに注意してください。

データベースに永続化されていないエンティティを引数に指定した場合は，managedに遷移します。

データベースに引数で渡されたエンティティと重複する行が存在し，そのエンティティが永続化コンテキストで管理されている場合，persist処理時にEntityExistsExceptionが発生します。

データベースに引数で渡されたエンティティと重複する行が存在するが，永続化コンテキストでエンティティが管理されていない場合，flushやコミット時にEntityExistsExceptionまたはほかのPersistenceExceptionが発生します。

注意事項

エンティティをデータベースに永続化したり，データベースからエンティティの情報を読み込んだりするタイミングで，エンティティは永続化コンテキストに登録されます。エンティティをmanagedに遷移したあとに，永続化処理をロールバックした場合は，エンティティは永続化コンテキストで管理されていないので注意してください。

8.4.3　エンティティに対するremove操作

エンティティに対するremove操作を実行するには，EntityManagerのremoveメソッドを呼び出します。EntityManagerのremoveメソッドを呼び出したり，remove処理がカスケードされたりすると，エンティティはremoved状態になります。removed状態のエンティティはトランザクションのコミット処理でデータベースから削除されます。

次の表に，remove操作後のエンティティの状態をエンティティの状態ごとに示します。

表8‒10　remove操作でのエンティティの状態

エンティティの状態

状態遷移の結果

new

remove操作は無視されます。ただし，エンティティからほかのエンティティへのリレーションシップのcascade属性にREMOVEまたはALLが指定されていると，このエンティティが参照するエンティティにremove操作が伝播されます。

managed

removedに遷移します。エンティティからほかのエンティティへのリレーションシップのcascade属性にREMOVEまたはALLが指定されていると，このエンティティが参照するエンティティにremove操作が伝播されます。

detached

次のように遷移します。

引数で渡されたdetached状態のエンティティに対応する行がデータベースに存在する場合，remove操作時にIllegalArgumentExceptionがスローされます。

CJPAプロバイダの場合，データベースに対応する行が存在しないときには，remove操作は無視されます。ただし，ほかのエンティティへのリレーションシップのcascade属性にREMOVEまたはALLが指定されていれると，このエンティティが参照するエンティティにremove操作が伝播されます。

removed

remove操作は無視されます。ほかのエンティティへの伝播もしません。

注1　removed状態のエンティティはトランザクションのコミット時，トランザクションのコミット前，またはflush操作時の実行結果としてデータベースから削除されます。

注2　エンティティが削除されたあと，エンティティの内容はremove処理が呼び出された直後の内容になります。ただし，エンティティの生成直後の場合を除きます。

8.4.4　データベースからのエンティティの取得

EntityManagerのfindメソッドまたはgetReferenceメソッドの呼び出しによって，引数で指定した主キーに対応するエンティティをデータベースから取得できます。

EntityManagerのfindメソッドまたはgetReferenceメソッドで返されるエンティティは，トランザクションスコープの永続化コンテキストを利用します。このため，トランザクション内でメソッドを呼び出した場合はmanaged状態になります。また，トランザクション外でfindメソッドまたはgetReferenceメソッドを呼び出した場合はdetached状態になります。

find操作またはgetReference操作で取得したエンティティの状態を次の表に示します。

表8‒11　find操作またはgetReference操作で取得したエンティティの状態

永続化コンテキスト

取得したエンティティの状態

トランザクションスコープの永続化コンテキスト（トランザクション外）

detached

トランザクションスコープの永続化コンテキスト（トランザクション内）

managed

拡張された永続化コンテキスト（トランザクション外）

managed

拡張された永続化コンテキスト（トランザクション内）

managed

なお，CJPAプロバイダの場合，find操作またはgetReference操作では次の点がJPA仕様と異なります。なお，このほかにJPA仕様との機能差はありません。

JPA仕様では，EntityManagerのgetReferenceメソッドでは実際のインスタンスではなく，引数で与えられた主キーに対応するエンティティにProxyを返すことができます。ただし，CJPAプロバイダでは，@Basicに対するLazyローディングをサポートしていません。このため，CJPAプロバイダでは，getReferenceの戻り値として，Proxyではなくエンティティインスタンスを返します。

なお，リレーションシップに対するLazyローディングのサポート範囲については，「8.4.5(2)　データベースからのエンティティ情報の読み込み」を参照してください。

CJPAプロバイダでは，findメソッドとgetReferenceメソッドの間で存在しないエンティティを引数に指定した場合，findメソッドではnull値が返ります。また，getReferenceメソッドではEntityNotFoundExceptionが発生します。

8.4.5　データベースとの同期

トランザクションのコミットまたはflushメソッドの実行時に，エンティティの状態がデータベースに書き込まれます。一方，明示的にrefreshを呼び出さないかぎり，メモリにロードされたエンティティの状態のリフレッシュは実行されません。

ここでは，データベースへのエンティティ情報の書き込みと，データベースからのエンティティ情報の読み込みについて説明します。

(1)　データベースへのエンティティ情報の書き込み

flush操作またはトランザクションのコミットでのエンティティの状態遷移について説明します。次の表ではエンティティAの状態ごとに状態遷移の結果を示しています。

表8‒12　flush操作またはトランザクションのコミットでのエンティティインスタンスの状態遷移

エンティティAの状態

状態遷移の結果

new

flush操作は無視されます。

managed

データベースと同期されます。

removed

エンティティAはデータベースから削除されます。

detached

flush操作は無視されます。

また，managed状態のエンティティAがエンティティBに対してリレーションシップを持っている場合，flush処理の延長で次の表に示す条件に従って，persist操作がカスケードされます。

表8‒13　関連するエンティティBへのflush処理およびコミットでのpersist操作のカスケード

エンティティBへのリレーションシップのcascade属性の指定

エンティティBの状態

結果

PERSISTまたはALLが指定されている

−

persist操作がエンティティBにカスケードされます。

PERSISTまたはALLが指定されていない

new

flush操作の場合

IllegalStateExceptionが発生してトランザクションはロールバックにマークされます。

コミット処理の場合

IllegalStateExceptionが発生してトランザクションのコミットに失敗します。

managed

データベースと同期化されます。

removed

flush操作の場合

IllegalStateExceptionが発生してトランザクションはロールバックにマークされます。

コミット処理の場合

IllegalStateExceptionが発生してトランザクションのコミットに失敗します。

detached

エンティティAがリレーションシップの所有者の場合

リレーションシップの変更はデータベースと同期されます。

エンティティBがリレーションシップの所有者の場合

例外が発生します。CJPAプロバイダでは，この場合の動作はサポート対象外となります。

（凡例）−：該当しない

なお，トランザクションの外でflushメソッドを呼び出すと，TransactionRequiredExceptionが発生します。

ポイント

リレーションシップとデータベースに対する永続化の関連

双方向のリレーションシップを持つmanaged状態のエンティティは，リレーションシップの所有者側で保持される参照を基に永続化されます。アプリケーション開発者は，変更が発生したときに所有者側と被所有者側でそれぞれ，メモリ上の状態に矛盾がないようにエンティティを保持するようアプリケーションを作成してください。

単方向のOneToOne，OneToManyの場合，エンティティで定義しているリレーションシップの関係とデータベースのテーブル間の関係が合っていることは，開発者の責任で保証してください。

(2)　データベースからのエンティティ情報の読み込み

EntityManagerのrefreshメソッドを呼び出すと，それまでに行われたエンティティの変更は破棄され，データベースの内容でエンティティの状態を上書きします。このとき，データベース上に対応する行が存在しない場合はEntityNotFoundExceptionが発生します。

エンティティがmanaged状態以外の場合に，EntityManagerのrefreshメソッドを呼び出すとIllegalArgumentExceptionが発生します。

(a)　データベースからのエンティティ情報を読み込むタイミング

refreshメソッドもしくはfindメソッドの実行時，またはクエリの発行時に，データベースからエンティティが読み込まれます。このときに，関連するエンティティもあわせて読み込むことができます。これをフェッチ戦略といいます。フェッチ戦略は各リレーションシップのfetch属性で指定します。fetch属性には次の2種類のどちらかを指定します。

FetchType.EAGER

データベースからエンティティの情報を読み込むときに，関連するフィールドやエンティティの情報を読み込みます。

FetchType.LAZY

フィールドまたは関連先に初めてアクセスしたときにデータベースからの読み込みが実行されます。これを，Lazyローディングといいます。

FetchType.EAGERを指定するとデータベースからエンティティの情報を読み込むたびに，関連するフィールドやエンティティの情報を読み込みます。このため，不要な関連先のエンティティの取得を回避したい場合は，FetchType.LAZYを指定してください。

CJPAプロバイダでのfetch属性のサポート範囲を次の表に示します。

表8‒14　リレーションシップごとのfetch属性のサポート範囲

リレーションシップのアノテーション

サポート範囲

@ManyToMany

デフォルトはFetchType.LAZYです。

@OneToMany

デフォルトはFetchType.LAZYです。

@OneToOne

デフォルトはFetchType.EAGERです。なお，LAZYを指定したときには，(b)を参照してください。

@ManyToOne

デフォルトではFetchType.EAGERです。なお，LAZYを指定したときには，(b)を参照してください。

@Basic

fetch属性は無視されます。デフォルトのFetchType.EAGERが常に適用されます。

(b)　@OneToOneおよび@ManyToOneでのLAZYフェッチ

@OneToOneおよび@ManyToOneのリレーションシップに対してフェッチ戦略にLAZYを指定した場合，エンティティクラスのローディング時に，LAZYを指定したフィールドのgetterメソッドにバイナリコードを埋め込みます。

getterメソッドが呼び出されると，埋め込んだバイナリコードの処理を通して，データベースから関連先のエンティティを取得します。getterメソッドがバイナリの埋め込み対象になるため，リレーションの対象となるフィールドにアクセスするためのgetterメソッドを設定しておく必要があります。また，そのgetterメソッドに@OneToOneまたは@ManyToOneを設定しておく必要があります。

注意事項

getterメソッドでは，リレーションシップのtargetEntityの型から，関連先のエンティティの型を決定します。targetEntityに指定するクラスの型は，フィールド・プロパティの型にキャストできる必要があります。

8.4.6　永続化コンテキストからのエンティティの切り離しとmerge操作

永続化コンテキストから切り離されたエンティティをdetached状態のエンティティといいます。エンティティは次のタイミングでdetached状態になります。

トランザクションスコープの永続化コンテキストでのトランザクションをコミットしたとき

トランザクションのロールバックを実行したとき

永続化コンテキストをクリアしたとき（EntityManager.clear()を呼び出したとき）

EntityManagerをクローズしたとき

エンティティのシリアライズおよびエンティティの値渡しをしたとき

切り離されたエンティティのインスタンスは，永続化や取得をした永続化コンテキストの外で存在し続けます。エンティティの状態とデータベースの状態は同期されません。

(1)　detached状態のエンティティへのアクセス

アプリケーションは永続化コンテキストの終了後でも，detached状態のエンティティにアクセスできます。この場合，エンティティのフィールドおよび関連先は，フェッチ済みである必要があります。detached状態のエンティティでフェッチされていないフィールドおよび関連先のエンティティにはアクセスできません。なお，フィールドに指定する@Basicには常にFetchType.EAGERが適用されるため，関連先のエンティティやフィールドの情報が取得済みとなります。

リレーションシップではdetached状態のエンティティからアクセスするには，次に示すどれかの条件を満たす必要があります。

find()で取得されたエンティティインスタンスであること

クエリを使って取得されたエンティティまたはFETCH JOIN節で明示的に要求されたエンティティであること

プライマリキーでない永続状態のインスタンスをアプリケーションでアクセス済みであること

fetch=EAGERと指定された関連をたどって別の有効なエンティティから取得済みのエンティティであること

利用できないインスタンスへのアクセス，および利用できるインスタンスの無効なステートへのアクセスを行った場合は，例外が発生します。ただし，CJPAプロバイダでは，FetchType.LAZYを指定した場合，EntityManagerの終了後にdetached状態になっていても，フェッチされていないフィールドおよび関連先エンティティにアクセスすると，データベースから値を取得して，内容を参照することができる場合があります。

(2)　エンティティのmerge処理

EntityManagerのmergeメソッドの呼び出し，またはmerge処理のカスケードによって，detached状態のエンティティをEntityManagerで管理される永続化コンテキストにマージできます。

次の表にmerge処理でのエンティティの状態遷移を，エンティティAの状態ごとに示します。

表8‒15　merge処理でのエンティティの状態遷移の結果

エンティティAの状態

状態遷移の結果

new

managed状態のエンティティA'が新しく作成されて，エンティティAの状態がエンティティA'にコピーされます。mergeの引数のエンティティはnewのままであることに注意してください。

managed

merge操作は無視されます。しかし，エンティティAからほかのエンティティへのリレーションシップのcascade属性に，MERGEまたはALLが指定されている場合，エンティティAが参照するエンティティにmerge操作が伝播されます。

detached

エンティティAの状態が，同じIDを持つすでに存在している管理されたエンティティA'にコピーされます。または，エンティティAのコピーである新しいmanaged状態のエンティティが作成されます。mergeの引数のエンティティはdetached状態のままであることに注意してください。

removed

merge操作によって，IllegalArgumentExceptionが発生します。または，トランザクションのコミットに失敗します。エンティティAの状態はremoved状態のままであることに注意してください。

注1　エンティティAからエンティティBへのリレーションがcascade=MERGEまたはcascade=ALLで指定されていると，すべてのエンティティBは再帰的にエンティティB'としてマージされます。エンティティA'にはエンティティB'がセットされます。なお，エンティティAがmanaged状態の場合，エンティティAとエンティティA'は同じであることに注意してください。

注2　エンティティAのリレーションにcascade=MERGEまたはcascade=ALLが指定されていない状態でエンティティBを参照している場合，エンティティAがエンティティA'にマージされるときには，エンティティA'から関連をたどるとエンティティBと同じ永続化アイデンティティを持つ管理されたエンティティB'の参照にたどり着きます。

JPA仕様では，フェッチされていないことを意味するLAZYにマークされたフィールドはマージのときに無視されます。ただし，CJPAプロバイダでは，@BasicはEAGERとして動作するため，リレーションシップでないすべてのフィールドはマージ処理の対象となります。

また，Version列がエンティティで使われている場合は，マージ操作とそのあとに呼ばれるフラッシュおよびコミット処理時に，エンティティのバージョンチェックを実行します。Version列が存在しない場合，merge操作ではエンティティのバージョンチェックは実行されません。詳細については，「8.10.1　楽観的ロックの処理」を参照してください。

なお，CJPAプロバイダでは，ほかベンダとの間で，エンティティのマージ処理によって永続化コンテキストに戻すという処理はサポートしていません。

(3)　注意事項

CJPAプロバイダの場合，トランザクションスコープの永続化コンテキストでは，managed状態のエンティティはトランザクションのコミットによってdetached状態になります。一方，拡張された永続化コンテキストでは，managed状態のエンティティは管理されたままとなります。

トランザクションスコープでも拡張された永続化コンテキストでも，トランザクションをロールバックすると，すべての存在しているmanaged状態のインスタンスとremoved状態のインスタンスは，detached状態になります。インスタンスの状態は，トランザクションがロールバックされた時点の状態です。

トランザクションをロールバックすると，永続化コンテキストの状態はロールバックした時点の状態になるため，データベースの状態と矛盾します。なお，CJPAプロバイダの場合は，バージョン属性の状態と生成された状態は矛盾した状態になるため，merge操作などを行うと例外になることがあります。

8.4.7　managed状態のエンティティ

EntityManagerのcontains()メソッドはエンティティのインスタンスがカレントの永続化コンテキストで管理されているかを取得するために利用できます。

ここでは，contains()メソッドの戻り値の条件について説明します。

contains()メソッドがtrueを返す条件

エンティティがデータベースから取得されていて，EntityManagerから削除されていない場合，または切り離されていない場合

エンティティのインスタンスが生成され，persistメソッドがそのエンティティに対して実行されている場合，またはpersist操作がそのエンティティに伝播されている場合

contains()メソッドがfalseを返す条件

エンティティのインスタンスが切り離されている場合

removeメソッドがエンティティに対して実行されている場合，またはremove操作がエンティティに伝播されている場合

エンティティのインスタンスが生成され，persistメソッドがそのエンティティに対して実行されていない場合，またはpersist操作がそのエンティティに伝播されていない場合

実際のデータベースでのinsertおよびdelete処理がトランザクションの決着まで遅延されます。これに対して，persistやremoveの伝播はcontainsメソッドではすぐに反映されることに注意してください。

なお，エンティティのインスタンスが単一の永続化コンテキストでだけ管理されていることは，アプリケーション側で保証してください。CJPAプロバイダでは，同じJavaのインスタンスを複数の永続化コンテキストで管理した場合の動作は保証しません。

8.5　データベースとJavaオブジェクトとのマッピング情報の定義

CJPAプロバイダでは，データベースとJavaオブジェクトをマッピングするための情報を定義できます。マッピング情報はアノテーションまたはO/Rマッピングファイルで定義します。

アノテーションを使用した定義

アプリケーションのエンティティクラスに直接マッピング情報を定義します。

O/Rマッピングファイルを使用した定義

O/Rマッピングファイルとは，マッピング情報を記載するためのXML形式のファイルです。タグを使用してマッピング情報を定義します。

アノテーションとO/Rマッピングファイルの両方でマッピング情報を定義している場合，O/Rマッピングファイルの定義が優先されます。このため，アノテーションを使用して定義したマッピング情報を変更する場合にO/Rマッピングファイルを使用すると，アプリケーションを変更することなくマッピング情報を変更できます。

アプリケーションの作成方針に合わせて，アノテーションを使用するか，O/Rマッピングファイルを使用するか，またはアノテーションとO/Rマッピングファイルを併用するかを決定してください。

8.6　エンティティのリレーションシップ

エンティティでは，データベースのテーブル間の関連をリレーションシップで表現できます。CJPAプロバイダでは，エンティティのリレーションシップを設定できます。

8.6.1　リレーションシップの種類

リレーションシップには関連と方向があります。関連には，OneToOne，ManyToOne，OneToMany，およびManyToManyがあります。また，それぞれの関連の方向には，単方向と双方向があります。関連と方向を組み合わせると，リレーションシップの種類には次の7種類があります。

単方向のOneToOneリレーションシップ

単方向のManyToOneリレーションシップ

単方向のOneToManyリレーションシップ

単方向のManyToManyリレーションシップ

双方向のOneToOneリレーションシップ

双方向のManyToOne/OneToManyリレーションシップ

双方向のManyToManyリレーションシップ

ある会社の従業員と部門を例にリレーションシップについて説明します。従業員と部門は次のような関連があります。

エンティティでは，従業員と部門をそれぞれ表現します。

従業員は必ずどこかの部門に所属するものとします。

部門では複数の従業員を保持します。

従業員から部門を参照したり，部門から従業員を参照したりします。

この例の場合，エンティティの双方向のManyToOne/OneToManyリレーションシップで表現します。この場合，Manyが従業員，Oneが部門となります。従業員のエンティティと部門のエンティティの関連を次の図に示します。

図8‒4　従業員のエンティティと部門のエンティティの関連

なお，エンティティには，関連先のエンティティに操作を伝播させる設定ができます。この設定をカスケードといいます。カスケードが設定されていると，エンティティに対して操作した場合，操作したエンティティとリレーションシップがあるエンティティにも自動的に同様の操作が実行されます。カスケードを利用すると，ユーザは関連先のエンティティへの操作の手間を省くことができます。

8.6.2　リレーションシップのアノテーション

エンティティではテーブル間の関連をリレーションシップとして扱います。リレーションシップをエンティティで扱う場合，エンティティでフィールドとしてほかのエンティティへの参照を保持します。その上で，次に示すリレーションシップのアノテーションを，エンティティを参照する永続化プロパティまたはインスタンス変数に設定してください。

OneToOne（1対1）

OneToMany（1対多）

ManyToOne（多対1）

ManyToMany（多対多）

エンティティのリレーションシップとテーブル間の関連を次の図に示します。

図8‒5　エンティティのリレーションシップとテーブル間の関連

エンティティへの参照に対して，リレーションシップのアノテーションが指定されていない場合は動作を保証しません。なお，コレクションを使用した参照で，generic型を利用しない場合，リレーションシップのtargetとして，対象のエンティティを指定する必要があります。

なお，アノテーションを使用する代わりに，O/Rマッピングファイルでリレーションシップを定義することもできます。ただし，O/Rマッピングファイルで定義している場合で，同じ定義をアノテーションに指定しているときには，アノテーションの定義は上書きされるので注意してください。

リレーションシップのアノテーションでのデフォルトマッピング

OneToOne，OneToMany，ManyToOne，ManyToManyのリレーションシップのアノテーションを適用した場合，デフォルトマッピングの規則が適用されます。O/Rマッピングファイルでリレーションシップを指定した場合も同様に，デフォルトマッピングが適用されます。

リレーションシップのアノテーションのデフォルトマッピングを使用する場合，データベースのテーブルおよびリレーションが，「8.6.4　デフォルトマッピング（双方向のリレーションシップ）」または「8.6.5　デフォルトマッピング（単方向のリレーションシップ）」にあるデフォルトと異なると，実行時にデータベース問い合わせでSQL文が正しく作成できません。例外が発生します。

8.6.3　リレーションシップの方向

リレーションシップには，双方向のリレーションシップと単方向のリレーションシップがあります。双方向のリレーションシップを扱う場合，リレーションシップには所有者と被所有者があります。単方向のリレーションシップには所有者だけがあります。リレーションシップの所有者は，データベースのリレーションシップの更新を決定できます。

双方向のリレーションシップでは，次のルールが適用されます。

双方向のリレーションシップの被所有者は，@OneToOne，@OneToMany，@ManyToManyのmappedBy要素によって，所有者を指定します。mappedBy要素では，所有者のエンティティで，被所有者側を参照しているプロパティまたはフィールドの名前を指定します。

ManyToOne/OneToMany双方向のリレーションシップでは，many側を所有者にしてください。そのため，mappedBy要素は@ManyToOneでは指定できません。

OneToOneの双方向のリレーションシップでは，外部キーを含む側のエンティティが所有者になります。

ManyToManyの双方向のリレーションシップは，どちらが所有者でもかまいません。

リレーションシップのアノテーションにはcascade属性があります。cascade属性を指定すると，エンティティに対する操作を参照先のエンティティに対しても伝播させることができます。ただし，リレーションシップのアノテーションのcascade属性にREMOVEを指定できるのは，OneToOneまたはOneToManyのときだけです。ほかのリレーションに対してcascade=REMOVEを適用した場合の動作は保証しません。エンティティがリレーションシップを持つ場合のcascade属性については，「8.4.1(4)　エンティティに対する操作の伝播」を参照してください。

注意事項

CJPAプロバイダでは，実行時のリレーションシップの一貫性を保つためのチェックは実施しません。このため，アプリケーションの実行時にリレーションシップを更新する場合に，リレーションシップに矛盾が発生するような更新を行っても，警告や例外は発生しません。

なお，OneToMany，ManyToManyなどのコレクションのリレーションシップでは，データベースから値をフェッチした場合に，関連するエンティティが存在しないときには，リレーションシップの値として空のコレクションを返します。

8.6.4　デフォルトマッピング（双方向のリレーションシップ）

ここでは，双方向のリレーションシップのデフォルトマッピングについて説明します。

(1)　双方向のOneToOneリレーションシップ

次に示す条件の場合に適用される双方向のOneToOneリレーションシップのデフォルトマッピングについて説明します。

条件

エンティティAはエンティティBの単体のインスタンスを参照して，@OneToOneを設定します。

エンティティBはエンティティAの単体のインスタンスを参照して，@OneToOneを設定します。@OneToOneのmappedBy属性にエンティティAでエンティティBを参照する永続化プロパティ（またはフィールド）名を指定します。

エンティティAは，リレーションシップの所有者です。

適用されるデフォルトマッピング

エンティティAは，テーブルAにマップされます。

エンティティBは，テーブルBにマップされます。

テーブルAは，テーブルBの外部キーを持つ必要があります。なお，外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAのリレーションシッププロパティ（またはフィールド）の名前_テーブルBのプライマリキー列の名前

注　斜体は可変値を表します。

また，外部キー列は，テーブルBのプライマリキーと同じ型を持ち，ユニークキー制約があります。

図8‒6　双方向のOneToOneでのデフォルトマッピング

(2)　双方向のManyToOne/OneToManyリレーションシップ

次に示す条件の場合に適用される双方向のManyToOne/OneToManyリレーションシップのデフォルトマッピングについて説明します。

条件

エンティティAはエンティティBの単体のインスタンスを参照して，@ManyToOne（または，O/Rマッピングファイルの該当するXMLタグ）を設定します。

エンティティBは，エンティティAのコレクションを参照して，@OneToMany（または，O/Rマッピングファイルの該当するXMLタグ）を設定します。@OneToManyにはmappedBy属性を指定します。mappedBy属性は，エンティティAで，エンティティBを参照するために設定した永続プロパティ（またはフィールド）名を指定します。

エンティティAは，リレーションシップの所有者です。

適用されるデフォルトマッピング

エンティティAはテーブルAにマップされます。

エンティティBはテーブルBにマップされます。

テーブルAは，テーブルBに対する外部キーを持つ必要があります。外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAのリレーションシッププロパティ（またはフィールド）の名前_テーブルBのプライマリキー列の名前

注　斜体は可変値を表します。

外部キー列はテーブルBのプライマリキーと同じ型を持ちます。

図8‒7　双方向のManyToOne/OneToManyでのデフォルトマッピング

(3)　双方向のManyToManyリレーションシップ

次に示す条件の場合に適用される双方向のManyToManyリレーションシップのデフォルトマッピングについて説明します。

条件

エンティティAは，エンティティBのコレクションを参照します。コレクションには，@ManyToMany（または，O/Rマッピングファイルで該当するXML要素）を設定します。

エンティティBは，エンティティAのコレクションを参照します。コレクションには，@ManyToMany（または，O/Rマッピングファイルで該当するXMLタグ）を設定して，mappedBy属性を指定します。mappedBy属性には，エンティティAで，エンティティBを参照するために設定した永続化プロパティ（またはフィールド）名を指定します。

エンティティAは，リレーションシップの所有者側です。

適用されるデフォルトマッピング

エンティティAは，テーブルAにマップされます。

エンティティBは，テーブルBにマップされます。

テーブルA，Bのほかに，所有者側のテーブルの名前が最初にくるA_Bという名前の結合表が必要です。この結合表は，二つの外部キー列を持ちます。

一つ目の外部キー列はテーブルAを参照し，テーブルAのプライマリキーと同じ型を持ちます。この外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティBのリレーションシップのプロパティ（またはフィールド）の名前_テーブルAのプライマリキーの名前

また，もう一つの外部キー列は，テーブルBを参照し，テーブルBのプライマリキーと同じ型を持ちます。この外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAのリレーションシップのプロパティ（またはフィールド）の名前_テーブルBのプライマリキーの名前

注　斜体は可変値を表します。

図8‒8　双方向ManyToManyでのデフォルトマッピング

8.6.5　デフォルトマッピング（単方向のリレーションシップ）

単方向のリレーションシップには，Single-ValuedリレーションシップとMulti-Valuedリレーションシップがあります。それぞれのリレーションシップについて説明します。

単方向のSingle-Valuedリレーションシップ

単方向のSingle-Valuedリレーションシップとは，単体のインスタンスを参照し，所有者だけが存在するリレーションシップのことです。

単方向Single-Valuedリレーションシップには，単方向のOneToOneリレーションシップと単方向のManyToOneリレーションシップがあります。

単方向のMulti-Valuedリレーションシップ

単方向のMulti-Valuedリレーションシップとは，コレクションの形でエンティティを参照し，所有者だけが存在するリレーションシップのことです。

単方向Multi-Valuedリレーションシップには，単方向のOneToManyリレーションシップと単方向のManyToManyリレーションシップがあります。

ここでは，単方向のリレーションシップのデフォルトマッピングについて説明します。

(1)　単方向のSingle-Valuedリレーションシップ

単方向のOneToOneリレーションシップと単方向のManyToOneリレーションシップのデフォルトマッピングについて説明します。

(a)　単方向のOneToOneリレーションシップ

次に示す条件の場合に適用される単方向のOneToOneリレーションシップのデフォルトマッピングについて説明します。

条件

エンティティAは，エンティティBの単体のインスタンスを参照して，@OneToOne（または，O/Rマッピングファイルで該当するXMLタグ）を設定します。

エンティティBからは，エンティティAを参照しません。

エンティティAがリレーションシップの所有者となります。

適用されるデフォルトマッピング

エンティティAは，テーブルAにマップされます。

エンティティBは，テーブルBにマップされます。

テーブルAは，テーブルBに対する外部キーを持つ必要があります。外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAのリレーションシップのプロパティ（または，フィールド）の名前_テーブルBのプライマリキー列の名前

注　斜体は可変値を表します。

外部キー列は，テーブルBのプライマリキーと同じ型を持ち，ユニークキー制約です。

図8‒9　単方向のOneToOneでのデフォルトマッピング

(b)　単方向のManyToOneリレーションシップ

次に示す条件の場合に適用される単方向のManyToOneリレーションシップのデフォルトマッピングについて説明します。

条件

エンティティAは，エンティティBの単体のインスタンスを参照し，@ManyToOne（または，O/Rマッピングファイルで該当するXMLタグ）を設定します。

エンティティBからは，エンティティAを参照しません。

適用されるデフォルトマッピング

エンティティAは，テーブルAにマップされます。

エンティティBは，テーブルBにマップされます。

テーブルAは，テーブルBに対する外部キーを持つ必要があります。外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAのリレーションシップのプロパティ（またはフィールド）の名前_テーブルBのプライマリキー列の名前

注　斜体は可変値を表します。

外部キー列は，テーブルBのプライマリキーと同じ型を持つ必要があります。

図8‒10　単方向のManyToOneでのデフォルトマッピング

(2)　単方向のMulti-Valuedリレーションシップ

単方向のOneToManyリレーションシップと単方向のManyToManyリレーションシップのデフォルトマッピングについて説明します。

(a)　単方向のOneToManyリレーションシップ

次に示す条件の場合に適用される単方向のOneToManyリレーションシップのデフォルトマッピングについて説明します。

条件

エンティティAは，エンティティBのコレクションを参照します。コレクションに@OneToMany（または，O/Rマッピングファイルで該当するXMLタグ）を設定します。

エンティティBからは，エンティティAを参照しません。

エンティティAがリレーションシップの所有者です。

適用されるデフォルトマッピング

エンティティAは，テーブルAにマップされます。

エンティティBは，テーブルBにマップされます。

テーブルA，Bのほかに，所有者側のテーブルの名前が最初にくるA_Bという名前の結合表が必要となります。この結合表は，二つの外部キー列を持ちます。

一つ目の外部キー列は，テーブルAを参照し，テーブルAのプライマリキーと同じ型を持ちます。この外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAの名前_テーブルAのプライマリキー列の名前

また，もう一つの外部キー列は，テーブルBを参照し，テーブルBの外部キーと同じ型を持ち，ユニークキー制約があります。この外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAのリレーションシッププロパティ（またはフィールド）の名前_テーブルBのプライマリキー列の名前

注　斜体は可変値を表します。

注意事項

この例のような結合表を使用した単方向のOneToManyリレーションシップは，CJPAプロバイダ以外のJPAプロバイダではサポートされていない可能性があります。単方向のOneToManyリレーションシップで作成したアプリケーションをCJPAプロバイダ以外のJPAプロバイダで動作させる場合は注意してください。

図8‒11　単方向OneToManyでのデフォルトマッピング

(b)　単方向のManyToManyリレーションシップ

次に示す条件の場合に適用される単方向のManyToManyリレーションシップのデフォルトマッピングについて説明します。

条件

エンティティAは，エンティティBのコレクションを参照します。コレクションに@ManyToMany（または，O/Rマッピングファイルで該当するXMLタグ）を設定します。

エンティティBは，エンティティAを参照しません。

所有者はエンティティAです。

適用されるデフォルトマッピング

エンティティAは，テーブルAにマップされます。

エンティティBは，テーブルBにマップされます。

テーブルA，Bのほかに，所有者側のテーブルの名前が最初にくるA_Bという名前の結合表が必要となります。この結合表は，二つ外部キー列を持ちます。

外部キー列の一つは，テーブルAを参照し，テーブルAの外部キーと同じ型を持ちます。この外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAの名前_テーブルAのプライマリキーの名前

また，もう一つの外部キー列は，テーブルBを参照し，テーブルBのプライマリキーと同じ型を持ちます。外部キー列の名前は，次のようになります。

外部キー列の名前

エンティティAのリレーションシップのプロパティ（またはフィールド）の名前_テーブルBのプライマリキーの名前

注　斜体は可変値を表します。

図8‒12　単方向ManyToManyでのデフォルトマッピング

8.7　エンティティオブジェクトのキャッシュ機能

エンティティオブジェクトのキャッシュ機能とは，アプリケーションで使用したエンティティオブジェクトをメモリ内で保持するための機能です。エンティティオブジェクトのキャッシュ機能を使用している場合に，同じエンティティオブジェクトが操作されると，CJPAプロバイダ内にキャッシュされているエンティティオブジェクトが使用されます。データベースから再度データを読み込むことがないので，データベースへのアクセスが最小限になり，処理性能の負荷を軽減できます。なお，この機能は，CJPAプロバイダ独自の機能です。

ここでは，エンティティオブジェクトのキャッシュ機能について説明します。

8.7.1　キャッシュ機能の処理

キャッシュ機能を使用している場合，同じエンティティに対して読み込みをすると，データベースではなく，キャッシュからデータが取得されるようになります。キャッシュ機能の処理の流れ，キャッシュの登録および更新のタイミング，およびキャッシュの更新処理の流れを説明します。

(1)　キャッシュ機能の処理の流れ

キャッシュ機能の処理の流れについて次の図に示します。

図8‒13　キャッシュ機能の処理の流れ

上記の図について説明します。

エンティティの読み込み処理

findなどのメソッドで最初にエンティティを読み込むときは次の流れで処理されます。

エンティティの読み込み処理をします。

データベースからデータを取得します。

取得したデータのエンティティオブジェクトをキャッシュに登録します。

エンティティがリレーションシップを持つ場合でリレーションシップ先のエンティティを取得するとき，目的のエンティティがキャッシュに存在すると，データベースにアクセスしないでキャッシュのエンティティを参照します。

キャッシュは，永続化コンテキスト単位で存在します。

(2)　キャッシュの登録および更新のタイミング

キャッシュへの登録および更新は次に示すタイミングで実施されます。

キャッシュの登録のタイミング

対象となるキャッシュが存在しない状態でのエンティティオブジェクトの読み込み時（find操作）

キャッシュの更新のタイミング

エンティティのリフレッシュ処理時（refresh操作）

トランザクションのコミット時

楽観的ロックの処理で例外が発生した場合

なお，楽観的ロックの処理でOptimisticLockException例外が発生した場合には，キャッシュに登録されているエンティティオブジェクトは削除されます。

(3)　キャッシュの更新処理の流れ

キャッシュの更新処理の流れについて次の図に示します。

図8‒14　キャッシュの更新処理

図について説明します。

エンティティオブジェクトに対して，次の操作を実施します。

refresh操作

トランザクションのコミット

refresh操作の場合は，データベースにアクセスします。

永続化コンテキストにあるデータをキャッシュに登録して，キャッシュのデータを更新します。

なお，JPQLを実行した場合にもキャッシュは登録されます。登録されるタイミングは，対象となるキャッシュが存在しない状態でJPQLを実行した場合です。JPQLでもキャッシュのデータを使用しますが，キャッシュのデータの有無に関係なく，データベースのアクセスが発生します。このため，キャッシュによる処理性能の向上は期待できません。詳細については，(4)を参照してください。

キャッシュは，エンティティのオブジェクト単位で情報を保持しているため，クエリの実行時に返されるオブジェクトがエンティティ自身の場合には，キャッシュへの更新が実行されます。それ以外のフィールドを指定するような場合では，更新はされません。キャッシュの更新が有効になる場合と，ならない場合のJQPLの例を次に示します。

キャッシュの更新が有効に行われるJPQLの例

SELECT emp FROM Employee AS emp

キャッシュの更新がされないJPQLの例

SELECT emp.id, emp.name, emp.address FROM Employee AS emp

(4)　JPQLとキャッシュの関係

JPQLでエンティティオブジェクト全体を取得するような場合，キャッシュに登録されている情報が存在すればキャッシュの情報を取得します。CJPAプロバイダのキャッシュ機能では，対象となるエンティティを特定するためのIDであるプライマリキーが必要になります。プライマリキーを取得するには，JPQLの結果を取得する必要があり，この際にデータベースへのアクセスが発生します。データベースへのアクセスの結果から，プライマリキーを抽出して，キャッシュからエンティティオブジェクトを取得します。また，キャッシュに対象となるデータが存在しない場合は，データベースの情報からエンティティを作成します。

JPQLでは，キャッシュのデータの有無に関係なく必ずデータベースへのアクセスが発生します。そのため，JPQLの場合，キャッシュによる性能向上は望めません。

8.7.2　キャッシュの参照形態とキャッシュタイプ

キャッシュの参照形態には次の3種類があります。

強参照

GCによる回収の対象になりません。

弱参照（java.lang.ref.WeakReference）

弱可到達の場合，GCによる回収の対象になります。なお，弱可到達かどうかは，java.lang.ref.WeakReferenceの仕様に依存します。

CJPAプロバイダで弱参照のキャッシュが回収対象にならない例を次に示します。

永続化コンテキストに登録されているエンティティオブジェクトのキャッシュ

弱可到達でないキャッシュにリレーションシップで参照されているキャッシュ

エンティティの継承戦略を使用している場合，継承関係にある別のエンティティオブジェクトのキャッシュが，弱可到達でないキャッシュ

ソフト参照（java.lang.ref.SoftReference）

メモリ残量の低下時にキャッシュアウトする参照形態です。

リソースの消費率や生存期間に応じて，GCによる回収の対象になります。回収されるタイミングや，回収対象となるオブジェクトの選択方法などの仕様は，JavaVMに依存します。

どの形態でキャッシュを参照するかによってキャッシュタイプの種類が異なります。キャッシュの参照形態とキャッシュタイプの対応を次の表に示します。

表8‒16　キャッシュの参照形態とキャッシュタイプの対応

キャッシュの参照形態

キャッシュタイプ

強参照

Full

強参照＋弱参照※1

HardWeak

弱参照＋ソフト参照※1

SoftWeak

弱参照

Weak

なし※2

None

注※1　参照形態を組み合わせます。

注※2　エンティティオブジェクトをキャッシュしません。

CJPAプロバイダでは，キャッシュのタイプを選択できます。アプリケーションの設計や環境によってタイプを選択してください。キャッシュタイプは，persistence.xmlで指定します。persistence.xmlについては「12.2　persistence.xml」を参照してください。

次にキャッシュタイプについて説明します。

(1)　Full

すべてのエンティティを強参照でキャッシュします。

キャッシュタイプにFullを指定した場合，データベースへのアクセスが少なくなるため，処理に対する負荷が少なくなります。ただし，メモリを占有し続けるため，メモリへの負荷が高くなります。

Fullは，エンティティオブジェクトの存続期間が長く，頻繁なアクセスを必要とする少数のエンティティオブジェクトで作成される場合に指定します。また，多数のエンティティオブジェクトを読み取る場合は，メモリの負荷が高くなるので，複数レコードを一括更新する場合の使用はお勧めしません。

Fullを指定した場合，指定されたキャッシュサイズで強参照領域を確保します。強参照領域が規定のサイズを超えた場合，Hashtableの仕様に基づいて領域を増やします。Fullを指定した場合のキャッシュ内のイメージを次の図に示します。

図8‒15　Fullの場合のキャッシュ内イメージ

(2)　HardWeak

強参照と弱参照でキャッシュします。

エンティティオブジェクトをリストで保持するときには，強参照を使用します。キャッシュサイズに指定した値だけ，強参照領域を固定長で作成します。キャッシュサイズが指定された値に達すると，古いエンティティオブジェクトを弱参照に移動します。このとき，キャッシュへの登録が最も長く使用されていないエンティティオブジェクトから順に弱参照に移動されます。弱参照に移動したエンティティオブジェクトが使用されると，再度，強参照の領域に格納されます。

HardWeakを指定すると，存続期間の長いエンティティオブジェクトを使用して，キャッシュで使用されるメモリを効率良く制御できます。

SoftWeakを使用したシステムでメモリ不足の状態が頻繁に発生する場合には，ソフト参照の利点を生かすことができないため，HardWeakを使用してください。HardWeakの場合のキャッシュ内イメージを次の図に示します。

図8‒16　HardWeakの場合のキャッシュ内イメージ

HardWeakの場合，強参照のキャッシュ領域では強参照でキャッシュを保持します。また，弱参照のキャッシュ領域では弱参照でキャッシュを保持します。

(3)　SoftWeak

ソフト参照と弱参照でキャッシュします。

ソフト参照を使用して，エンティティオブジェクトをリストで保持し，キャッシュサイズに指定した値だけ，ソフト参照領域を固定長で作成します。キャッシュサイズが指定された値に達すると，古いエンティティオブジェクトを弱参照の領域に移動します。このとき，キャッシュへの登録が最も長く使用されていないエンティティオブジェクトから順に弱参照に移動されます。弱参照に移動したエンティティオブジェクトが使用されると，再度，強参照の領域に格納されます。

SoftWeakを指定すると，存続期間の長いエンティティオブジェクトを使用して，キャッシュで使用されるメモリを効率良く制御できます。このため，キャッシュ機能を使用する場合は，SoftWeakを指定することをお勧めします。SoftWeakの場合のキャッシュ内イメージを次の図に示します。

図8‒17　SoftWeakの場合のキャッシュ内イメージ

SoftWeakの場合，ソフト参照のキャッシュ領域ではソフト参照でキャッシュを保持します。また，弱参照のキャッシュ領域では弱参照でキャッシュを保持します。

(4)　Weak

すべてのエンティティを弱参照でキャッシュします。

このため，すべてのエンティティオブジェクトがGCの対象になります。Weakを指定するとメモリへの負荷が少なくなりますが，GCによってキャッシュが削除されるおそれがあります。エンティティオブジェクトのキャッシュ機能を重視しないシステムで使用してください。Weakの場合のキャッシュ内イメージを次の図に示します。

図8‒18　Weakの場合のキャッシュ内イメージ

Weakの場合，弱参照でエンティティをキャッシュします。

(5)　NONE

エンティティオブジェクトはキャッシュされません。エンティティオブジェクトをデータベースから読み取ったあと，すぐに破棄する場合に使用します。

8.7.3　キャッシュ機能の有効範囲

キャッシュのデータは永続化コンテキスト単位で保持されます。このため，別の永続化コンテキストでエンティティオブジェクトが呼び出されていても，キャッシュからデータを取得できません。

なお，キャッシュのデータは，永続化コンテキストが生成されたときから破棄されるまでの間保持されます。

8.7.4　キャッシュ機能を使用するときの注意事項

ここでは，エンティティオブジェクトのキャッシュ機能を使用するときの注意事項を説明します。

(1)　クエリでデータを更新または削除した場合の注意

アプリケーション内でJPQLやネイティブクエリを使用して，データを更新したり，削除したりした場合，キャッシュの内容は更新されません。refresh操作などを行って，データベースの内容を取得し直してください。

次に示す操作の場合，キャッシュのデータを読み込むため，データベースへの更新がされません。

データをエンティティオブジェクトに読み込む。

キャッシュにもエンティティのデータが登録されます。

1.で読み込んだデータを含む削除クエリを実行する。

削除クエリの実行でデータは削除されますが，キャッシュは削除されません。

1.と同じデータをエンティティオブジェクトに読み込む。

1.と同じデータのため，キャッシュにあるデータを読み込みます。

3.のデータをflushする。

データベースには該当する行がないため，追加または更新処理ができません。

(2)　キャッシュを使用する永続化コンテキストが複数ある場合の注意

キャッシュを使用することで，データベースへのアクセス頻度を下げることができます。ただし，一方でキャッシュによるデータのタイムラグが発生して，楽観的ロック例外の発生頻度が高くなるおそれもあります。

キャッシュは永続化コンテキスト単位に存在します。そのため，永続化コンテキストと対で存在するEntityManagerが複数かつ同時期に生成され，同一プライマリキーのエンティティを同時に操作すると，一方でデータを更新しても他方でタイミング良く，更新後のデータを参照できないことがあります。これによって，楽観的ロック例外が発生しやすくなります。

次に，楽観的ロック例外が発生する仕組みと対処方法について説明します。

(a)　楽観的ロック例外が発生する例

ここでは，次の図に示す環境で，永続化コンテキスト単位にキャッシュが存在する場合を例に説明します。

図8‒19　この例で説明する環境

図の状態では，キャッシュとデータベースには不整合はなく，すでにキャッシュにAというデータが格納されているものとします。

永続化コンテキスト1でデータをAからBに変更します。

このとき，キャッシュとデータベースの内容が等しいため例外は発生しません。

図8‒20　永続化コンテキスト1でのデータの変更

1.の処理が終了後，永続化コンテキスト2でAのデータを変更します。

キャッシュのデータは変更されていないため，データベースのデータとキャッシュに不整合があります。このため，楽観的ロックによる例外が発生します。

図8‒21　永続化コンテキスト2でのデータの変更

このような環境の場合，キャッシュを使用すると，更新されないキャッシュが残ってしまい，楽観的ロックによる例外が発生することがあります。

(b)　対処方法

楽観的ロック例外が発生した場合は，キャッシュ内の該当オブジェクトは削除されます。このため，findメソッドを実行するか，またはrefreshメソッドを実行して関連するすべてのデータを再度データベースから取得してください。これによって，キャッシュのデータとデータベースを同期できます。

(3)　キャッシュの登録および更新タイミングに関する注意事項

JPQLを使用して悲観的ロックを取得する場合，クエリの実行時に返されるエンティティオブジェクトはキャッシュに登録されません。

ネイティブクエリを利用して，@SqlResultSetMappingでエンティティを戻り値とするクエリを実行した場合，戻り値のエンティティオブジェクトはキャッシュに格納されます。

エンティティのrefresh操作で，エンティティオブジェクトの読み込み後にほかのスレッドでOptimisticLockExceptionが発生してキャッシュが削除されると，リフレッシュ処理を実行してもキャッシュにエンティティオブジェクトは登録されません。

8.8　プライマリキー値の自動採番

プライマリキー採番機能とは，エンティティオブジェクトを使用してレコードを挿入する際に，プライマリキー値を自動で生成する機能です。この機能によって，ユーザがプライマリキー値を指定しなくても一意の値が格納されるようになります。CJPAプロバイダでは，プライマリキー採番機能を提供しています。

プライマリキー値の生成方法

プライマリキー値の生成方法には次の4種類があります。

TABLE

プライマリキー値を保存しておくためのテーブルを使用して，プライマリキー値を生成する方法です。

SEQUENCE

データベースのシーケンスオブジェクトを使用して，プライマリキー値を生成する方法です。ただし，データベースにHiRDBを使用している場合，CJPAプロバイダではTABLEと同じ処理を実施します。

IDENTITY

データベースのidentity列を利用してプライマリキー値を生成する方法です。ただし，CJPAプロバイダでは，使用しているデータベースの種類によって動作が異なります。

HiRDBの場合，TABLEと同じ処理を実施します。

Oracleの場合，SEQUENCEと同じ処理を実施します。

AUTO

使用しているデータベースに適した生成方法を選択します。CJPAプロバイダでは，HiRDBの場合，Oracleの場合ともにTABLEを選択します。

プライマリキー値が採番されるタイミング

CJPAプロバイダの場合，flush操作またはトランザクションのコミットのタイミングでプライマリキー値が採番されます。

プライマリキー値の生成方法がSEQUENCEの場合の例

プライマリキー値の生成方法がSEQUENCEの場合の例を示します。この例では，事前にEMP_SEQという名称のシーケンスオブジェクトが作成されているものとします。

@Entity
public class Employee {
・・・
    @SequenceGenerator(
        name="EMPLOYEE_GENERATOR",
        sequenceName="EMP_SEQ"

    )
    @Id
    @GeneratedValue(strategy=GenerationType.SEQUENCE,
 generator="EMPLOYEE_GENERATOR")
    @Column(name="EMPLOYEE_ID")
    public Integer getId() {
        return id;
    }
・・・
}

8.9　クエリ言語によるデータベース操作

JPAを使用してデータベースのデータを操作するには，javax.persistence.Queryインタフェースを通して実施します。javax.persistence.Queryインタフェースを使用すると，複数のレコードに対してまとめて，検索，更新，削除などの操作ができます。javax.persistence.Queryインタフェースを使用するには，ユーザはクエリ言語を使用してデータベースを操作します。

CJPAプロバイダでは，クエリ言語としてJPQLおよびSQLを使用できます。JPQLおよびSQLについてそれぞれ説明します。

JPQL

JPA仕様で定義されているクエリ言語です。データベースに依存しない言語で，エンティティクラスを対象に操作します。

SQL

データベースに依存したクエリ言語です。ネイティブクエリともいいます。データベースのデータを対象に操作します。

JPQLやSQLによるデータベース操作については，「8.16　クエリ言語を利用したデータベースの参照および更新方法」を参照してください。また，JPQLの文法については，「8.17　JPQLの記述方法」を参照してください。

8.10　楽観的ロック

CJPAプロバイダでは，EntityManagerと永続化コンテキストを利用して永続化対象のエンティティを管理します。変更されたエンティティの情報は，flushメソッドまたはトランザクションのコミット処理が実行されたときにデータベースに反映されます。複数のトランザクションで同時にデータベースの同じ行を更新するおそれがある場合，データの整合性を保証する必要があります。データの整合性を保証するために，CJPAプロバイダでは楽観的ロックを提供しています。

楽観的ロックとは，データの更新処理を始めてから更新が完了するまでの間に，ほかから更新されていないことを確認するためのロック機能です。楽観的ロックはデータベースをロックしないので，デッドロックなどが発生しないという利点があります。

ここでは，楽観的ロックについて説明します。

8.10.1　楽観的ロックの処理

楽観的ロックを使用すると，CJPAプロバイダはデータベースのデータがほかのアプリケーションから更新されていないかをユーザに代わってチェックします。データベースのデータが更新されていると，CJPAプロバイダは例外を発生させて，ユーザにデータが更新されていることを通知します。また，トランザクションをロールバックにマークします。

(1)　データ更新の有無のチェック方法

データが更新されているかどうかは，データベースのテーブル上に用意したバージョン列の更新の有無によってチェックします。データベース上のデータが更新されると，バージョン列のバージョン番号が更新されます。これによって，ほかのアプリケーションなどからデータベースが更新されたことがわかります。データベースを更新するときのバージョン列の状態と動作について次の表に示します。

表8‒17　データベースを更新するときのバージョン列の状態と動作

テーブルのバージョン列の状態

動作

バージョン列の値が更新されていない場合

CJPAプロバイダは，エンティティの情報をデータベースに反映します。このとき，データベースのバージョン列の値を更新します。

バージョン列の値が更新されている場合

ほかのアプリケーションなどからデータベースのデータが更新されていることを表します。このため，CJPAプロバイダはOptimisticLockExceptionを発生させて，トランザクションをロールバックにマークします。

このように，バージョン列の状態によって，エンティティを読み込んだ状態からデータベースを更新するまでに，ほかのトランザクションがデータを更新していないことを保証できます。

(2)　永続化フィールドおよびリレーションシップのバージョンチェック

楽観的ロックを使用するには，エンティティの永続化フィールドおよびリレーションシップの両方をバージョンチェックの対象にします。バージョンチェックの対象とするには，エンティティにバージョン列に対応するVersionフィールド（プロパティ）を設定してください。Versionフィールドは@VersionまたはO/Rマッピングファイルの<version>タグを使用して設定します。

エンティティのバージョンチェックは次のどちらかのタイミングで実行されます。

エンティティの状態が変更され，その変更をデータベースに書き込むとき

merge処理によって，エンティティがmanaged状態に変更されたとき※

注※

バージョンチェックはmerge実行時だけでなく，flushまたはトランザクションのコミット時にもチェックが実行されます。

バージョンチェックによってエンティティのバージョンが古いことが判明した場合，OptimisticLockExceptionが発生します。また，トランザクションはロールバックにマークされます。

(3)　flush操作またはトランザクションの決着時のバージョンチェック

エンティティをflush操作またはトランザクションの決着時にバージョンチェックの対象にできます。バージョンチェックの対象とするには，EntityManagerのlockメソッドにエンティティを指定します。EntityManagerのlockメソッドを使用することで，トランザクションでのバージョンチェック対象にエンティティを追加したり，バージョン列の更新方針を変更したりできます。

CJPAプロバイダでは，バージョン列の更新タイミング（lockメソッドのLockModeType）としてLockModeType.READおよびLockModeType.WRITEの二つをサポートしています。バージョン列の更新タイミングの指定内容にかかわらず，CJPAプロバイダではトランザクションの決着時に次に示す二つの事象が起きないことを保証します。

ダーティリード（Dirty Read）

トランザクション「T1」が行を変更します。次に，「T1」がコミットやロールバックを行う前に別のトランザクション「T2」が同じ行を読み込み，変更した値を取得します。最終的に「T2」がコミットに成功します。

「T1」がコミットかロールバックをするかどうかが重要ではなく，「T2」のコミットの前またはあとのどちらで「T1」のコミットかロールバックが行われるかが重要になります。

繰り返し不可能な読み込み（un-Repeatable Read）

トランザクション「T1」が行を読み込みます。次に，「T1」がコミットする前に，もう一方のトランザクション「T2」がその行の変更や削除を実施します。最終的に両方のトランザクションはコミットに成功します。

LockModeTypeとしてLockModeType.WRITEを指定すると，エンティティの状態変更がない場合でもバージョン列は強制的に更新されます。バージョン列の更新はflushまたはトランザクションのコミットが呼び出されたタイミングで実行されます。なお，バージョン列の更新前にエンティティが削除された場合，バージョン列の更新は省略されることもあります。

8.10.2　楽観的ロックに失敗した場合の例外処理

明示的に楽観的ロックの実行を確認したい場合は，flush()メソッドを呼び出します。flush()メソッドの呼び出しで楽観的ロック例外が発生した場合，例外処理をキャッチしてリカバリ処理を行うことができます。楽観的ロックに問題がない場合，flush()メソッドによってエンティティのバージョンのチェックおよびVersion列が更新されます。

例外処理の記述例を次に示します。

try{
  em.flush();
} catch (OptimisticLockException e){
  // 例外処理
}

この例に示すように，例外処理の中でOptimisticLockExceptionをラップすることで楽観的ロックの例外をアプリケーション例外として見せることができます。ただし，この場合のトランザクションはロールバックにマークされているので，コミットできないことに注意してください。

なお，CJPAプロバイダでは，例外の原因となったエンティティをOptimisticLockExceptionに格納しません。OptimisticLockExceptionのgetEntity()メソッドは常にnull値を返します。

8.10.3　楽観的ロックを使用する際の注意事項

ここでは，楽観的ロックを使用する際の注意事項について説明します。

(1)　Versionフィールドの設定時の注意事項

Versionフィールドの設定時の注意事項を次に示します。

Versionフィールドが設定されていない場合，そのエンティティに対するバージョンチェックは実施しません。その場合，エンティティとデータベースの間の整合性を保つようなアプリケーションをユーザ責任で作成してください。

トランザクションにVersionフィールドが設定されているエンティティと設定されていないエンティティが含まれている場合，Versionフィールドが設定されているエンティティに対してだけバージョンチェックが実行されます。なお，エンティティにバージョンが含まれていないことはトランザクションの決着処理には影響ありません。

ユーザはVersionフィールドの値を参照できますが，更新はしないでください。ただし，バルク更新処理ではVersionフィールドの値を更新できます。

(2)　lockメソッド使用時の注意

lockメソッド使用時の注意事項を次に示します。

Versionフィールド（プロパティ）を持たないエンティティに対するEntityManagerのlockメソッドはサポートしていません。Versionフィールド（プロパティ）を持たないエンティティを指定して，lock(entity, LockModeType.READ)またはlock(entity, LockModeType.WRITE)が呼ばれた場合は，PersistenceExceptionが発生します。

Versionフィールド（プロパティ）を持つエンティティの状態が更新される場合は，lockメソッドの呼び出し有無にかかわらず，ダーティリード，および繰り返し不可能な読み込みの現象は発生しません。

CJPAプロバイダではLockModeType.READが指定された場合，エンティティに該当するデータベースの値に変更がないかを確認するために，UPDATE文を発行します。このため，データベースに対してUPDATE文による排他が掛かります。UPDATE文は，flush処理の実行時およびトランザクションのコミット時に発行されます。エンティティオブジェクトの状態に変更がない場合でも発行されます。ただし，エンティティが削除された場合は発行されません。

(3)　HiRDBでのクライアント単位の排他制御について

CJPAプロバイダの楽観的ロックは，データベースのIsolationレベルがRead Committedでアクセスされることを想定したロック方式です。データベースがHiRDBの場合，Isolationレベルがデフォルトの設定ではRepeatable Readであるため，Read Committedに変更する必要があります。

クライアント単位のIsolationレベルは，クライアント環境変数のデータ保証レベルのPDISLLVLパラメタで設定します。デフォルトの値はRepeatable Read (2)です。このため，Read Committed (1) に変更してください。変更例を次に示します。

変更例：PDISLLVL=1

クライアント環境変数はConnector属性ファイルの<config-property>タグでenvironmentVariablesプロパティの値に指定するか，またはHiRDBのクライアント環境変数グループの設定ファイルに追加してください。

クライアント環境変数のデータ保証レベルをデフォルト設定のRepeatable Readで動作させた場合は，共有モードで排他が掛かります。このため，findメソッドなどの参照系SQLの発行とflushメソッドなどの更新系SQLの発行を組み合わせることによって，デッドロックが発生しやすくなるので注意してください。

8.11　JPQLでの悲観的ロック

悲観的ロックとは，複数のトランザクションによってデータベース上の同じレコードを更新するときに，対象となるレコードを占有ロックする方法です。あるトランザクションがあるレコードに対して悲観的ロックを掛けると，ほかのトランザクションはそのレコードを参照または更新できません（ただし，Oracleの場合，参照はできます）。悲観的ロックはJPQLを使用しているときだけ使用できます。

悲観的ロックを使用すると，ロックを取得したトランザクションが終了するまでロックの解放待ちが発生します。このため，楽観的ロックよりも同時実行性はありませんが，楽観的ロックで発生するトランザクションのコミット時のエラーを回避できます。

悲観的ロックの指定方法

悲観的ロックは，CJPAプロバイダがサポートするクエリヒントを利用することで実現します。悲観的ロックは，QueryメソッドのsetHint()メソッドまたは@NamedQueryの属性に@QueryHintを指定して実行します。

悲観的ロック機能の実装例

悲観的ロック機能の実装例を次に示します。

実装例1

QueryメソッドのsetHint()メソッドで悲観的ロックを指定する場合の例を次に示します。

Query query = manager.createQuery("SELECT emp FROM  Employee  AS emp");
query.setHint("cosminexus.jpa.pessimistic-lock","Lock");

実装例2

@NamedQueryの属性の@QueryHintで悲観的ロックを指定する場合の例を次に示します。

@NamedQuery(
name="employee_list",
query="SELECT emp FROM  Employee AS emp",
hints={ @QueryHint(name="cosminexus.jpa.pessimistic-lock", value="Lock") }
)
@Entity
public class Employee{
・・・
}

注意事項

悲観的ロックが使用できるのはJPQLの時だけです。createNativeQueryメソッドや@NamedNativeQueryのhints属性に@QueryHintを指定しても有効にはなりません。また，O/Rマッピングファイルの<named-native-query>タグのhint属性に指定した場合も有効にはなりません。なお，CJPAプロバイダでの悲観的ロックの排他仕様は，使用するデータベースの仕様に準じます。

8.12　エンティティクラスの作成

JPAを利用したアプリケーションを作成するには，アプリケーションでエンティティクラスを定義します。エンティティクラスは，データベースのテーブルのレコードをJavaのオブジェクトとして扱うためのクラスです。ユーザがアプリケーションでnewオペレーションを行うと，エンティティクラスのインスタンスが生成されます。

ここでは，JPAアプリケーションの作成について説明します。

8.12.1　エンティティクラスとデータベースの対応の定義

エンティティクラスは，データベースのテーブルの行に対応します。また，エンティティクラスが保持するフィールドは，テーブルのカラムの値に対応します。ユーザがエンティティクラスのインスタンスに対してフィールドの値を更新すると，CJPAプロバイダによって対応するデータベースのテーブルのカラムも更新されます。そのため，ユーザはデータベースに対してSQLを発行することなく，データベースの状態を変更できます。

エンティティクラスとデータベースのテーブルとのマッピングについて次の図に示します。

図8‒22　エンティティクラスとデータベースのテーブルとのマッピング

エンティティのフィールドとデータベースのカラムの対応関係は，アノテーションまたはO/Rマッピングファイルで定義します。アノテーションとO/Rマッピングファイルのどちらでも定義はできます。ただし，両方で定義している場合は，O/Rマッピングファイルの設定がアノテーションよりも優先されます。アノテーションとO/Rマッピングファイルとで同じ設定項目に対して異なる値を設定している場合は，アノテーションの値をO/Rマッピングファイルの値で上書きします。

8.12.2　エンティティクラスの作成要件

JPAを使用したアプリケーションを作成する場合には，JPA仕様で決められたエンティティクラスの作成要件やデータベースのマッピング要件を守る必要があります。作成要件を次に示します。

エンティティクラスは@EntityまたはO/Rマッピングファイルの<entity>タグに指定する必要があります。

エンティティクラスは引数なしのコンストラクタを持ちます。

enumやインタフェースはエンティティクラスとしてはいけません。

エンティティクラスのクラス階層のルートとなるエンティティまたはマップドスーパークラスでは，プライマリキーを持つ必要があります。プライマリキーは，エンティティ階層で必ず一つ定義してください。

エンティティクラスのインスタンスを値渡しでメソッドの引数として渡す場合，Serializableインタフェースを実装する必要があります。

データベースのカラムの状態はエンティティのインスタンス変数で表現し，インスタンス変数はJavaBeanのプロパティに対応します。なお，インスタンス変数は，クライアントから直接アクセスして値を変更してはいけません。アクセサメソッド（getter／setterメソッド）や，ビジネスメソッド経由で値を変更してください。

エンティティの永続インスタンス変数は，private，protected，またはpackageから参照できるアクセスレベルにしてください。

引数なしのコンストラクタは，publicかprotectedで宣言してください。

エンティティクラスはfinalにしないでください。また，エンティティクラスの永続化インスタンス変数とすべてのメソッドもfinalにしてはいけません。

CJPAプロバイダでは，これらの条件に合わない場合，例外が発生するおそれがあります。なお，例外が発生しない場合でもこれらの条件に合わないエンティティクラスを作成している場合の動作は保証しません。

また，CJPAプロバイダの場合，エンティティクラスでは，データベースの一つのカラムを複数のフィールドに対応づけないでください。この条件に合わない場合，アプリケーション実行時に例外が発生することがあります。例外が発生しない場合でも，動作は保証しません。

8.12.3　エンティティクラスのフィールドに対するアクセス方法の指定

CJPAプロバイダは，エンティティの状態をデータベースに書き込んだり，データベースの状態をエンティティとして読み込んだりするときに，エンティティクラスのフィールドにアクセスします。このときのアクセス方法をアクセスタイプと呼びます。アクセスタイプには，プロパティとフィールドの2種類があります。また，アクセスタイプはアノテーションまたはO/Rマッピングファイルで指定します。アクセスタイプと指定方法について次の表に示します。

表8‒18　アクセスタイプと指定方法

アクセスタイプ

説明

指定方法

アノテーション

O/Rマッピングファイル

プロパティ

getterメソッドを経由して取得する方法です。

フィールドのgetterメソッドにアノテーションを指定します。

<access>タグにPROPERTYを指定します。

フィールド

インスタンス変数を直接参照する方法です。

フィールドにアノテーションを指定します。

<access>タグにFIELDを指定します。

アクセスタイプがプロパティの場合，エンティティが保持するプロパティを永続化プロパティといいます。また，アクセスタイプがフィールドの場合，エンティティのフィールドを永続化フィールドといいます。

アクセスタイプに関連する注意事項

アクセスタイプを指定するときには，次の点を考慮してください。

アクセスタイプがフィールドの場合，CJPAプロバイダは永続化フィールドに直接アクセスします。@Transientを設定されていないインスタンス変数は，永続化の対象となります。

アクセスタイプがプロパティの場合，CJPAプロバイダはアクセサメソッドを利用して永続化プロパティの値を取得します。@Transientがアクセサメソッドに設定されていないプロパティは，永続化の対象となります。

アクセスタイプがプロパティの場合，setterメソッドにマッピングアノテーションは設定できません。CJPAプロバイダの場合，setterメソッドに設定したマッピングアノテーションは無視されます。

@TransientまたはO/Rマッピングファイルで<transient>タグが付与されたフィールドとプロパティには，マッピングアノテーションは設定できません。設定した場合には，アプリケーションの開始時に例外が発生します。

プロパティのアクセサメソッドはpublicまたはprotectedにしてください。これは，JPA仕様で禁止されていますが，アプリケーションサーバのJPA機能ではチェックしません。また，privateであっても例外も発生しません。

永続化フィールドと永続化プロパティのアクセサメソッドの両方にマッピングアノテーションが適用された場合，永続化プロパティのアクセサメソッドに設定されたアノテーションはすべて無視されます。

8.12.4　アクセサメソッドの作成

ここでは，アクセサメソッドのシグネチャ規則，およびアクセサメソッドへのビジネスロジックの追加について説明します。

(1)　アクセサメソッドのメソッドシグネチャ規則

CJPAプロバイダが永続化プロパティに対してアクセスする場合，プロパティのアクセサメソッドは，次に示すJavaBeansと同じメソッドシグネチャ規則に従っている必要があります。

T getProperty()

void setProperty(T t)

booleanの戻り値を返すプロパティの場合，getterメソッドはisPropertyという名前にすることもできます。なお，CJPAプロバイダを使用する場合，getterメソッドとsetterメソッドのどちらかしかないときには，アプリケーション開始時に例外が発生します。

また，永続化フィールド，永続化プロパティでコレクション値を扱う場合は，次に示すコレクション値をインタフェースで定義してください。

java.util.Collection

java.util.Set

java.util.List

java.util.Map

永続化プロパティがコレクション値となる場合，アクセサメソッドのメソッドシグネチャはこれらのインタフェースのどれかにしてください。または，これらのコレクションのジェネリックな型を使用することもできます（例：Set<T>）。

(2)　アクセサメソッドへのビジネスロジックの追加

アクセサメソッドは，プロパティのsetter/getter処理に加えて，値を検証するなどのビジネスロジックを含むことができます。アクセスタイプがプロパティの場合，CJPAプロバイダがアクセサメソッドを呼び出すタイミングでビジネスロジックが動作します。

ただし，この場合には，次の点に注意してください。

CJPAプロバイダの実行時に，永続状態をロードして格納するアクセサメソッドが呼び出される順番は定義されていません。このため，getterに含まれるロジックの実行順序は未定となります。

アクセスタイプがプロパティで，永続化プロパティでlazyフェッチが指定されている場合で，移植性を求めるには，エンティティの内容がCJPAプロバイダにフェッチされるまで，エンティティの内容にアクセスしないことをお勧めします。

アクセスタイプがプロパティの場合で，ビジネスロジックとして値を変更するロジックを追加したときには，CJPAプロバイダではデータの一貫性は保証しません。

プロパティアクセサメソッドでRuntime例外が発生すると，現在のトランザクションはロールバックにマークされます。CJPAプロバイダがエンティティの永続状態の内容を読み込んだり，格納する際のアクセサメソッドで例外が発生したりした場合，トランザクションはロールバックされます。また，アプリケーション例外をラップするPersistenceException例外が発生します。

8.12.5　エンティティの永続化フィールドおよび永続プロパティの型

エンティティの永続化フィールド／永続化プロパティは，次に示す型にしてください。

Javaのプリミティブ型

java.lang.String

ほかのシリアライズ型

プリミティブ型のラッパークラス

java.math.BigInteger

java.math.BigDecimal

java.util.Date

java.util.Calendar

java.sql.Date

java.sql.Time

java.sql.Timestamp

ユーザが定義するシリアライズな型

byte[]

Byte[]

char[]

Character[]

enum

エンティティタイプとエンティティタイプで複製できるコレクション

埋め込みできるクラス

CJPAプロバイダを使用する場合は，上記以外の型が指定されたときの動作は保証しません。アプリケーションの実行時に例外が発生するおそれもあります。

ただし，CJPAプロバイダを使用している場合，エンティティのインスタンス変数の型は，データベースのカラムの型と対応づけしている必要があります。Javaの型とデータベースの型の対応づけは，JDBCドライバが行います。CJPAプロバイダでは，Oracle接続時にはOracleが提供するOracle JDBC Thin DriverをJDBCドライバとして利用します。HiRDB接続時にはHiRDB Type4 JDBC DriverをJDBCドライバとして利用します。ユーザはJDBCドライバがサポートする型の変換に合わせてエンティティのインスタンス変数の型を決定してください。

8.12.6　エンティティでのプライマリキーの指定

エンティティでは，プライマリキーをクラス階層の中で必ず指定してください。プライマリキーを指定する場合には，次に示すルールに従ってください。

単体の（複合型でない）プライマリキーは，永続化フィールドまたは永続化プロパティに@Idを指定するか，O/Rマッピングファイルで指定します。これによって，エンティティのフィールドとの対応づけをしてください。

複合型のプライマリキーの場合，@EmbeddedIdとして単一のフィールドでプライマリキークラスを指定するか，または@IdClassと@Idによって，フィールドのセットとして複合プライマリキーを指定します。

複合型のプライマリキーの場合，プライマリキークラスと呼ばれるプライマリキーを含むクラスを作成します。

これらの条件に従っていない場合は，アプリケーション開始時に例外が発生します。

また，アプリケーションでエンティティのプライマリキーの値を変更しないでください。アプリケーションでプライマリキーの値を変更した場合，実行時に例外が発生します。

(1)　プライマリキーの型

単体または複合型のプライマリキーは，次に示す型のどれかにしてください。

Javaのプリミティブ型

プリミティブをラッパした型

java.lang.String

java.util.Date

java.sql.Date

なお，近似値型（例えば浮動小数点数型）をプライマリキーとして指定すると，CJPAプロバイダの場合，丸め誤差が発生したり，equalsメソッドの結果に信頼性がないという問題が発生したりします。このため，CJPAプロバイダではプライマリキーに近似値型を使用した場合の動作は保証しません。java.util.Dateがプライマリキーとしてフィールド／プロパティで使用される場合，temporal type属性はDATE型として指定する必要があります。

(2)　複合型のプライマリキー

エンティティでは複合型のプライマリキーを扱うことができます。エンティティで複合型のプライマリキーを指定するには，埋め込み型クラスを利用する方法と@IdClassを利用する方法の2とおりがあります。それぞれの方法を説明します。

(a)　埋め込み型クラスを利用する方法

埋め込み型クラスを利用するには，@Embeddableを付与したクラスを作成し，そのクラスのフィールドとして複合型のプライマリキーを定義します。エンティティクラスでは，@Embeddableを付与したクラスの型のフィールドを定義して，@EmbeddedIdをアノテートします。エンティティクラスの例と埋め込み型クラスの例を次に示します。

エンティティクラスの例

@Entity
public class Employee {
    private EmployeePK employeePK;

    public Employee(){
    }

    @EmbeddedId
    public EmployeePK getEmployeePK(){
      retrun this.employeePK;
    }

    public void setEmployeePK(EmployeePK employeePK){
      this.employeePK = employeePK;
    }
    ・・・
}

埋め込み型クラスの例

@Embeddable
public class EmployeePK {
    private String name;
    private int employeeId;

    public EmployeePK(){
    }

    public boolean equals(Object obj){
      ・・・
    }

    public int hashCode(){
      ・・・
    }
    ・・・
}

埋め込み型クラスについては「(3)　埋め込み型クラス」を参照してください。なお，アノテーションの代わりにO/Rマッピングファイルを利用することもできます。

(b)　@IdClassを利用する方法

@IdClassを利用するには，エンティティクラスでプライマリキーに対応する複数のインスタンス変数を定義して@Idを付与します。また，@IdClassを使用してプライマリキークラスを指定します。プライマリキークラスでは，エンティティで定義したプライマリキーと同じ名前と型を持つフィールドまたはプロパティを定義します。エンティティクラスの例とプライマリキークラスの例を次に示します。

エンティティクラスの例

@Entity
@IdClass(EmployeePK.class)
public class Employee {
    private String name;
    private int employeeId;

    public Employee(){
    }

    @Id
    public String getName(){
      retrun this.name;
    }

    public void setName(String name){
      this.name = name;
    }

    @Id
    public int getEmployeeId(){
      retrun this.employeeId;
    }

    public void setName(int employeeId){
      this.employeeId = employeeId;
    }
    ・・・
}

プライマリキークラスの例

public class EmployeePK implements Serializable {
    private String name;
    private int employeeId;

    public EmployeePK(){
    }

    public boolean equals(Object obj){
      ・・・
    }

    public int hashCode(){
      ・・・
    }
    ・・・
}

埋め込み型クラスの場合と同様に，アノテーションの代わりにO/Rマッピングファイルを利用することもできます。なお，プライマリキークラスのアクセスタイプは，プライマリキーに対応するエンティティクラスのアクセスタイプで決定します。

複合型のプライマリキーを扱うためには，埋め込み型クラスまたは@IdClassのどちらかを使用します。ただし，次に示すルールに従ってください。

プライマリキークラスは，publicで引数のないコンストラクタを持たなければならなりません。

永続化プロパティを使用する場合，プライマリキークラスのプロパティはpublicまたはprotectedにしてください。

プライマリキークラスは，直列化可能にしてください。

プライマリキークラスではequalsとhashCodeメソッドを定義します。マップされているデータベース上で主キーが等しい場合にはequalsでtrueを返し，hashCodeの値を等しくする必要があります。

複合プライマリキーは，埋め込みクラスとしてマップされているか，エンティティクラスの複数のフィールド／プロパティをマップされている必要があります。

プライマリキークラスがエンティティクラスの複合フィールド／プロパティにマップされる場合，プライマリキークラスのプライマリキーのフィールド／プロパティの名前と，エンティティクラスの名前を一致させてください。また，型も同じにしてください。

CJPAプロバイダでは，これらの条件を満たさない場合動作は保証しません。また，条件を満たさない場合はアプリケーションの開始時に例外が発生することもあります。

(3)　埋め込み型クラス

永続化対象の幾つかのフィールドをまとめたクラスを用意すると，エンティティのフィールドとして保持できます。このようなクラスを埋め込み型クラスといいます。

埋め込み型クラスは，エンティティに埋め込まれてエンティティと同じデータベースのテーブルにマップされます。このため，エンティティとは異なり，プライマリキーを持ちません。

ユーザが埋め込み型クラスを利用する場合，埋め込むクラスには@Embeddableを設定します。また，埋め込まれる側のエンティティクラスでは，埋め込み先のフィールド，プロパティに@Embeddedを指定します。なお，アノテーションの代わりにO/Rマッピングファイルで同様に定義することもできます。

埋め込み型クラスは複合型のプライマリキーを定義するために利用することもできます。この場合，埋め込まれるエンティティクラスでは，@Embeddedの代わりに@EmbeddedIdを設定します。

埋め込み型クラスでは，次に示す作成要件を必ず守ってください。

埋め込み型クラスは，必ず@Embeddableで定義するか，O/Rマッピングファイルの<embeddable>タグで定義してください。

enumやインタフェースを埋め込み型クラスとしないでください。

埋め込み型クラスを含むエンティティクラスをdetachedオブジェクトとして値渡ししている場合，Serializableインタフェースを実装してください。

埋め込み型クラスおよび埋め込み型クラスの永続化インスタンス変数と，すべてのメソッドではfinalにしないでください。

引数なしのコンストラクタを持つ必要があります。

引数なしコンストラクタは，publicかprotectedで宣言してください。

埋め込み型クラスのインスタンス変数は，private，protected，またはpackageから参照できなければなりません。

埋め込み型クラスの永続化インスタンス変数は，クライアントから直接アクセスされないようにしてください。エンティティのアクセサメソッド（getter／setterメソッド）や，ほかのビジネスメソッドでアクセスしないでください。

CJPAプロバイダでは，1.および2.の条件を満たさない場合には例外が発生して，アプリケーションの開始に失敗します。また，3.から8.についても例外が発生するおそれがありますが，例外が発生しない場合でも動作は保証しません。

埋め込み型クラスのアクセスタイプは，埋め込まれた側のエンティティクラスのアクセスタイプで決定します。

埋め込み型クラスを利用する場合，埋め込みの階層は一つにしてください。また，複数のエンティティから埋め込み型クラスのオブジェクトを共有することはできません。これらの条件を満たさない場合，CJPAプロバイダでは動作を保証しません。

8.12.7　永続化フィールドおよび永続化プロパティのデフォルトマッピング規則

リレーションシップ以外の永続化フィールドまたは永続化プロパティに対して，O/Rマッピング情報が指定されていない場合は，次に示すデフォルトのマッピング規則が適用されます。

@Embeddableがアノテートされたクラスの場合，フィールド／プロパティは@Embedded側のエンティティでの指定に従ってデータベースにマップされます。

永続化フィールド／永続化プロパティの型が次のどれかである場合，@Basicが定義されているのと同じ方法でマップされます。

Javaのプリミティブ型

プリミティブ型のラッパ

java.lang.String

java.math.BigInteger

java.math.BigDecimal

java.util.Date

java.util.Calendar

java.sql.Date

java.sql.Time

java.sql.Timestamp

byte[]

Byte[]

char[]

Character[]

enum

Serializableを実装した任意の型

なお，上記以外の型が指定されている場合の動作は保証しません。

8.13　エンティティクラスの継承方法

エンティティクラスの継承には次に示す特長があります。

エンティティクラスは抽象クラス，具象クラスのどちらでも使用できます。抽象クラスおよび具象クラスともに，@Entityが定義できます。また，エンティティとしてマップでき，抽象クラスおよび具象クラスの両方に対してクエリを発行できます。

エンティティクラスはほかのエンティティクラスから継承できます。

エンティティクラスは非エンティティクラスを継承できます。また，非エンティティクラスはエンティティクラスを継承できます。

ここでは，エンティティクラスの継承クラスの種類と継承マッピング戦略について説明します。

8.13.1　継承クラスの種類

エンティティクラスの継承クラスの種類には，抽象エンティティクラス，マップドスーパークラス，および非エンティティクラスがあります。それぞれ説明します。

(1)　抽象エンティティクラス

抽象クラスはエンティティクラスとして定義できます。抽象エンティティクラスは，直接インスタンスを作成できない点が具象エンティティクラスとは異なります。抽象エンティティクラスは，エンティティとしてマップすることも，サブクラスのエンティティを操作・取得するためにクエリの対象に指定することもできます。

サブクラスでは，プロパティのアクセサメソッドをオーバーライドできます。ただし，永続化フィールドおよび永続化プロパティのO/Rマッピング情報をサブクラスでオーバーライドした場合，動作は保証しません。サブクラスでO/Rマッピング情報をオーバーライドする場合は，@AssociationOverrideや@AttributeOverrideなどを使用してください。

抽象エンティティクラスは，@EntityまたはO/Rマッピングファイルで指定します。

(2)　マップドスーパークラス

マップドスーパークラスとは，エンティティクラスのスーパークラスになることができるクラスです。永続化フィールドやマッピング情報を定義でき，さらにこれらを継承するような構成にできます。

マップドスーパークラスは，特定のテーブルを指定できないため，@Tableの指定はできません。そのため，マップドスーパークラスをエンティティにすることはできません。マップドスーパークラスはエンティティクラスとは異なり，問い合わせができないため，EntityManagerやクエリの操作の引数に渡すこともできません。また，リレーションシップの対象にすることもできません。

マップドスーパークラスは，抽象クラスとしても，具象クラスとしても定義できます。クラスをマップドスーパークラスとして定義する場合は，@MappedSuperclass，またはO/Rマッピングファイルに<mapped-superclass>タグを定義します。マッピング情報は，継承されたエンティティクラスに対して提供されます。

マップドスーパークラスとして設計したクラスは，マッピングがサブクラスにだけ提供できるマッピングであることを除いて，エンティティクラスと同様の方法でマップできます。

エンティティがサブクラスとして適用されると，マップドスーパークラスで指定された情報が，サブクラスに継承されます。@AssociationOverrideやO/Rマッピングファイルで対応するXML要素を使用して，マッピング情報をサブクラス上でオーバーライドすることができます。

(3)　エンティティ継承階層構造の非エンティティのクラス

エンティティクラスは非エンティティクラスのスーパークラスを持つことができます。スーパークラスは具象クラスおよび抽象クラスとして定義できます。

非エンティティクラスのスーパークラスには次に示す特長があります。

振る舞いだけを継承します。

状態は永続ではありません。

継承したすべての状態は，継承したエンティティクラスでも永続ではありません。

永続でない状態は，EntityManagerの制御の対象ではありません。

スーパークラスのアノテーションは無視されます。

非エンティティクラスをEntityManagerやQueryインタフェースのメソッドの引数にしたり，マッピング情報にしたりしないでください。CJPAプロバイダの場合，アプリケーションの実行時に例外が発生します。

8.13.2　継承マッピング戦略

エンティティを継承した場合，クラス階層をテーブルにマッピングする方法を継承マッピング戦略として指定できます。継承マッピング戦略は，@InheritanceまたはO/Rマッピングファイルの<entity>タグの<inheritance>タグを使用して指定します。

継承マッピング戦略には次の3種類があります。

SINGLE TABLE戦略

SINGLE TABLE戦略は，エンティティクラスの継承階層にあるすべてのクラスが一つのテーブルにマップする戦略方法です。

JOINED戦略

JOINED戦略は，クラス階層の最上位は単一のテーブルにマップする戦略方法です。

TABLE PER CLASS戦略

エンティティクラスのクラス階層中の各クラスを別々のテーブルにマップする戦略方法です。

ただし，CJPAプロバイダでは，TABLE PER CLASS戦略は使用できません。CJPAプロバイダを使用している場合で，TABLE PER CLASS戦略を指定したときには，アプリケーションの起動時に例外が発生します。

注意事項

CJPAプロバイダを使用する場合，次のことに注意してください。

クラス階層中で継承戦略を複数組み合わせて指定することはできません。また，複数の継承戦略を組み合わせているかどうかのチェックも実施しません。指定した場合の動作は保証しません。

@DiscriminatorColumnで指定したカラムをエンティティのフィールドに定義した場合，persist操作をしてコミットしてもエンティティのフィールドに設定した値はデータベースに反映されません。@DiscriminatorValueで指定した値またはそのデフォルト値が反映されます。また，コミット後には，コミット前にフィールドに設定されていた値が格納されたままとなるため注意が必要です。

これらはjavax.persistence.DiscriminatorType列挙型の値で指定されます。それぞれの戦略について説明します。

(1)　SINGLE TABLE戦略

SINGLE TABLE戦略とは，エンティティクラスの継承階層にあるすべてのクラスが一つのテーブルにマップする戦略方法です。そのため，テーブルではクラスを識別するためのカラムとして，識別カラムを持つ必要があります。

識別カラムは@DiscriminatorColumn，またはO/Rマッピングファイルで指定します。なお，デフォルトの識別カラム名は「DTYPE」です。データベースに識別カラムがない場合，アプリケーションの実行時に例外が発生します。

識別カラムに格納される値を指定したい場合には，@DiscriminatorValueまたはO/Rマッピングファイルの<entity>タグ下の<discriminator-value>タグを使用して指定します。

注意事項

SINGLE TABLE戦略を利用する場合，サブクラスのフィールドに対応するテーブルのカラムでは，null値を指定できるようにする必要があります。

(2)　JOINED戦略

JOINED戦略とは，クラス階層の最上位は単一のテーブルにマップする戦略方法です。各サブクラスは，スーパークラスから継承されていないサブクラス特有のフィールドと，スーパークラス表の主キーの外部キーとして機能する主キー列を持つ別々のテーブルで示されます。

JOINED戦略の場合も，SINGLE TABLEの場合と同様にスーパークラスがマップされるテーブルに識別カラムを持つ必要があります。

注意事項

JOINED戦略を利用する場合，サブクラスのインスタンスの生成で複数回の結合の実行が必要になります。このため，階層構造が深くなると，性能が劣化するおそれがあります。また，クラス階層にわたる範囲でクエリを発行する場合，JOINが必要です。

8.14　EntityManagerおよびEntityManagerFactoryの使用方法

ここでは，アプリケーションから利用するEntityManagerおよびEntityManagerFactoryの使用方法について説明します。

8.14.1　EntityManagerでのエンティティのライフサイクル管理

EntityManagerはデータベースに対して次の操作をするためのインタフェースを持つオブジェクトです。

エンティティを登録したり，削除したりする。

プライマリキーによってエンティティを検索する。

エンティティをわたったクエリを発行する。

EntityManagerに対してエンティティを登録すると，トランザクションのコミットなどの適切なタイミングでエンティティの状態がデータベースで永続化されます。

また，EntityManagerはエンティティの集合を表す永続化コンテキストと関連を持ちます。EntityManagerにエンティティが登録されると，エンティティは特定の永続化コンテキストに属します。また，EntityManagerは，エンティティのライフサイクルを管理します。

EntityManagerで管理するエンティティの集合は永続化ユニットという単位で定義します。永続化ユニットはアプリケーションの設定ファイルであるpersistence.xmlで定義します。

永続化コンテキストと永続化ユニットの注意事項について説明します。

永続化コンテキスト内ではエンティティは一意となるようにします。このため，同一の永続化コンテキスト内では，データベースの同じ行を表すエンティティは一つとしてください。なお，永続化コンテキストが異なる場合は，データベースの同じ行を表すエンティティを複数持つことができます。この場合のデータベース上での排他方法については，「8.10　楽観的ロック」または「8.11　JPQLでの悲観的ロック」を参照してください。

永続化ユニットはそれぞれ単一のデータベースにマッピングされます。定義の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「5.8.2(3)　<jta-data-source>タグ，<non-jta-data-source>タグ」を参照してください。

8.14.2　EntityManagerおよびEntityManagerFactoryの設定方法

アプリケーションで利用するEntityManagerおよびEntityManagerFactoryは，アノテーションまたはDDで設定します。

EntityManagerFactoryの設定

アノテーションの場合：@PersistenceUnitで設定します。

DDの場合：<persistence-unit-ref>タグで設定します。

EntityManagerの設定

アノテーションの場合：@PersistenceContextで設定します。

DDの場合：<persistence-context-ref>タグで設定します。

なお，アノテーションの詳細については「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」，DDに設定するタグの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

8.14.3　EntityManagerのAPIに関する注意事項

EntityManagerが提供するAPIについての注意事項を次に示します。なお，EntityManagerのAPIについては「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

トランザクションスコープ永続化コンテキストのEntityManagerが使用されるとき，persist，merge，remove，refreshメソッドは，トランザクションコンテキスト内で実行する必要があります。トランザクションコンテキストがない場合は，javax.persistence.TransactionRequiredExceptionがスローされます。

findメソッドとgetReferenceメソッドは，トランザクションコンテキストでの実行を要求しません。このため，トランザクションスコープ永続化コンテキストのEntityManagerが使用された場合，結果のエンティティはdetached状態になります。また，拡張された永続化コンテキストのEntityManagerが使用された場合，結果のエンティティはmanaged状態になります。

createQueryメソッドの引数が有効なJPQLの文字列でなければ，IllegalArgument例外を送出し，クエリの実行が失敗します。

実行するネイティブクエリが，接続先のデータベースの仕様に合わない場合，または定義された結果のセットがクエリの結果と互換性がない場合，クエリの実行は失敗し，クエリの実行時にPersistenceException例外がスローされます。

EntityManagerインタフェースのメソッドからランタイム例外が送出されると，カレントのトランザクションはロールバックにマークされます。

EntityManagerから取得したQueryオブジェクト，およびEntityTransactionオブジェクトは，EntityManagerがオープンしている間は有効です。

8.15　コールバックメソッドの指定方法

エンティティのライフサイクルを受け取るために，メソッドをライフサイクルのコールバックメソッドに指定できます。コールバックメソッドとして定義されたメソッドは永続化に関するライフサイクルイベントに対応して呼び出されます。

ここでは，コールバックメソッドの指定個所，実装方法，および呼び出し順序について説明します。

8.15.1　コールバックメソッドの指定個所

コールバックメソッドは，次の場所に指定できます。

エンティティクラスまたはマップドスーパークラス内

エンティティクラスまたはマップドスーパークラスに関連づけられたエンティティリスナクラス

エンティティリスナクラスとは，コールバックメソッドを実装するための専用のクラスです。エンティティリスナクラスを使用すると，コールバックメソッドの実装部分を分離できます。

コールバックメソッドは，アノテーションまたはO/Rマッピングファイルで指定します。ただし，デフォルトのコールバックメソッドは，O/Rマッピングファイルで指定します。アノテーションでは指定できません。なお，デフォルトのコールバックメソッドとは，永続化ユニット内のすべてのエンティティに適用されるエンティティリスナを指します。

コールバックリスナの指定方法について説明します。

(1)　アノテーションでのコールバックメソッドの指定

コールバックメソッドの指定にアノテーションを使用する場合は，次の表にあるアノテーションをメソッドに設定してください。ライフサイクルイベントに応じてメソッドを呼び出すことができます。

表8‒19　アノテーションを使用したコールバックメソッドの指定

アノテーション

実行される内容

@PostLoad

エンティティが永続化コンテキストにロードされたあとか，またはrefresh操作が適用されたあとに，コールバックメソッドが実行されます。キャッシュからエンティティを読み込んだあと，またはデータベースにSELECT文を発行したタイミングで実行されます。

@PrePersist

@PreRemove

EntityManagerがエンティティのpersistまたはremove操作を行う前にコールバックメソッドが呼び出されます。マージ操作が適用され，新しくmanaged状態のインスタンスが作成される場合，managed状態のインスタンスへのPrePersistコールバックメソッドは，エンティティの状態がコピーされたあとに呼び出されます。これらのPrePersistまたはPreRemoveのコールバックは操作がカスケードされるすべてのインスタンスに対しても呼び出されます。PrePersistまたはPreRemoveメソッドは常にpersist，merge，またはremove操作の一部として同期を取って呼び出されます。

@PostPersist

@PostRemove

PostPersistおよびPostRemoveコールバックメソッドは，エンティティがpersistまたはremove操作で，永続化されたあとまたは削除されたあとで呼び出されます。

これらのコールバックは操作がカスケードされたすべてのエンティティに対しても呼び出されます。PostPersistまたはPostRemoveメソッドは，それぞれデータベースのinsertまたはdelete操作が行われたあとに呼び出されます。これらのデータベースへの操作はpersist，merge，もしくはremove操作の直後，またはflushメソッドが呼び出されたあとになります。ただし，トランザクションの終了時になることもあります。生成されたプライマリキーはPostPersistメソッドで利用できます。

@PreUpdate

@PostUpdate

PreUpdateおよびPostUpdateのコールバックはそれぞれエンティティデータのデータベースへのupdate操作の前後に呼び出されます。

これらのデータベースへの操作はエンティティの状態が更新された場合，または状態がデータベースにフラッシュされた場合に実行されます。ただし，データベースへの操作は，トランザクションの終了時になることもあります。一つのトランザクション内で，エンティティを永続化してから更新したり，エンティティを更新してから削除したりした場合には，PreUpdateやPostUpdateのコールバックが発生しないことがあります。

エンティティリスナクラスを利用する場合，エンティティに対して@EntityListenerを指定してエンティティリスナクラスを指定する必要があります。指定方法の例を次に示します。

@Entity
@EntityListeners(CallbackListener.class)
public class Employee implements Serializable{
・・・
}

(2)　O/Rマッピングファイルでのコールバックリスナの指定

O/Rマッピングファイルを使用してコールバックメソッドを指定する場合は次のように指定します。

エンティティリスナのクラスおよびそのクラスのコールバックメソッドを指定する場合，O/Rマッピングファイルの<entity-listener>タグを使用します。ライフサイクルリスナメソッドは，<entity-listener>タグ下の，<pre-persist>タグ，<post-persist,>タグ，<pre-remove>タグ，<post-remove>タグ，<pre-update>タグ，<post-update>タグ，および<post-load>タグを使用して指定します。

エンティティリスナクラスのコールバックメソッドを指定する場合は，コールバックイベントごとに最大一つのメソッドを<entity-listener>タグ以下のタグを使用して指定できます。

<persistence-unit-defaults>タグの<entity-listeners>タグの下位タグに対して，O/Rマッピングファイルの<entity-listener>タグを指定するとデフォルトコールバックメソッドが指定できます。

<entity>タグまたは<mapped-subclass>タグにある<entity-listeners>タグの下位タグに，<entity-listener>タグを指定すると，エンティティまたはマップドスーパークラスとそのサブクラスに対するコールバックリスナの指定になります。

<entity-listeners>タグに指定したリスナの順番でコールバックリスナは呼び出されます。リスナの呼び出し順序については，「8.15.3　コールバックメソッドの呼び出し順序」を参照してください。

8.15.2　コールバックメソッドの実装

ユーザは必要に応じてコールバックメソッドを実装します。エンティティクラスやマップドスーパークラス内に実装するコールバックメソッドとエンティティリスナクラスのコールバックメソッドでコールバックメソッドのシグネチャは異なります。

エンティティクラスやマップドスーパークラスで定義されるコールバックメソッドは次に示すシグネチャになります。

void <METHOD>

また，エンティティリスナクラスで定義されるコールバックメソッドは次に示すシグネチャになります。

void <METHOD>(Object)

引数のObjectには，コールバックメソッドが実行されるエンティティのインスタンスを指定します。

(1)　コールバックメソッド使用時の注意事項

コールバックメソッドについては，次に示す注意事項があります。これらの条件を満たさない場合，アプリケーションの開始時に例外が発生して，アプリケーションの開始に失敗します。

publicで引数がないコンストラクタを持たなければなりません。

コールバックメソッドではpublic，private，protected，およびパッケージレベルのアクセスができます。ただし，staticやfinalは使用できません。

一つのクラスが同じライフサイクルイベントに対して複数のライフサイクルコールバックメソッドを持つことはできません。ただし，同じメソッドが複数のコールバックイベントで使用されることがあります。

(2)　コールバックメソッドに適用されるルール

コールバックメソッドについては次に示すルールが適用されます。

コールバックメソッドでは，未チェックまたは実行時例外の送出が許可されています。トランザクション中に実行したコールバックメソッドでスローされた実行時例外は，トランザクションをロールバックさせます。コールバックメソッドが複数指定されている場合，実行時例外がスローされたあとには残りのコールバックメソッドは実行されません。

コールバックメソッドでは，JNDI，JDBC，JMS，Enterprise Beanを実行できます。

コールバックメソッドで次の操作をしないでください。

EntityManagerを呼び出す。

クエリ操作を実行する。

ほかのエンティティインスタンスにアクセスする。

リレーションシップを更新する。

このような方法で使用した場合，動作を保証しません。

Java EE環境でコールバックメソッドが呼び出された場合，エンティティのコールバックリスナは呼び出すコンポーネントのネーミングコンテキストを共有します。また，エンティティのコールバックメソッドは，コールバックメソッドが呼び出された時点の呼び出し元コンポーネントのトランザクションとセキュリティコンテキストで呼び出されます。

8.15.3　コールバックメソッドの呼び出し順序

エンティティに対して複数のコールバックメソッドを定義した場合，呼び出し順序は次の規則に従います。

O/Rマッピングファイルに定義した順番でデフォルトリスナが呼び出されます。

明示的に@ExcludeDefaultListenersまたはO/Rマッピングファイルの<exclude-default-listeners>タグを指定しないかぎり，デフォルトリスナは永続化ユニット内のすべてのエンティティに適用されます。

@EntityListenersで指定された順番にコールバックメソッドが呼び出されます。

なお，O/Rマッピングファイルを使用すると，次の操作ができます。

エンティティに対するコールバックメソッドの呼び出し順序を指定する。

アノテーションでの指定順序をオーバーライドする。

エンティティ（またはマップドスーパークラス）に指定されたコールバックメソッドが呼び出されます。

(1)　継承階層内での呼び出し順序

エンティティクラスやマップドスーパークラスの継承階層の中で複数回のエンティティリスナを定義した場合，呼び出し順序は次のようになります。

デフォルトコールバックリスナがあれば，最初に呼び出されます。

エンティティリスナクラスのコールバックメソッドがスーパークラスに指定されているリスナから順番に呼び出されます。このとき，@EntityListenerなどの指定があれば，その順序に従います。

すべてのエンティティリスナのコールバックメソッドが呼び出されたあとで，エンティティ（またはマップドスーパークラス）に定義されたコールバックメソッドがスーパークラスに指定されているリスナから順番に呼び出されます。

コールバックメソッドをサブクラスでオーバーライドした場合には，オーバーライドされたメソッドは呼び出されません。オーバーライドしたコールバックメソッドが異なるライフサイクルのイベントを指定している場合，またはライフサイクルコールバックメソッドではない場合，オーバーライドされた側のメソッドは呼び出されます。また，メソッドのコールバックメソッドの設定はオーバーライドされます。

(2)　コールバックメソッドの除外について

@ExcludeDefaultListenersまたはO/Rマッピングファイルの<exclude-default-listeners>タグを指定すると，デフォルトエンティティリスナはエンティティクラス（またはmapped superclass）とそのサブクラスでは呼び出されません。

@ExcludeSuperclassListenersまたはO/Rマッピングファイルの<exclude-superclass-listeners>タグがエンティティクラスやmapped superclassに適用されると，そのクラスとそのサブクラスではリスナのコールバックメソッドは呼び出されません。@ExcludeSuperclassListenersまたはO/Rマッピングファイルの<exclude-superclass-listeners>タグは，デフォルトのエンティティリスナの呼び出しを除外することにはなりません。

O/Rマッピングファイルを使用して，entityやmapped superclassへの除外されたデフォルト/スーパークラスリスナを明示的に指定すると，エンティティやそのサブクラスに適用されることになります。

8.16　クエリ言語を利用したデータベースの参照および更新方法

クエリとは，データベースに対する処理要求（問い合わせ）を文字列として表したものです。データベース上のデータの検索，更新，削除などの命令をシステムに発行するときに使用します。クエリを実行するには，javax.persistence.Queryインタフェースを使用します。クエリには，JPQLとネイティブクエリの2種類があります。ここでは，クエリを利用したデータベースの参照および更新方法について説明します。

8.16.1　JPQLでのデータベースの参照および更新方法

JPQLは，データベースを検索・更新したり，データベースが持っている集合関数などの機能を利用したりするためのクエリ言語です。SQLがテーブルを対象としたクエリ言語であるのに対して，JPQLはエンティティクラスを対象としたJPA仕様で定義されているクエリ言語です。

クエリはアノテーションまたはO/Rマッピングファイルで定義できます。クエリと同じ永続化ユニットでエンティティが定義されている場合，エンティティの集合を表す抽象スキーマ型をクエリで使用できます。また，パス式を使用すると，永続化ユニット内で定義されたリレーションシップをわたってクエリを使用できます。パス式の詳細については，「8.17.4(2)　パス式」を参照してください。

アプリケーションにJPQLを記述して実行すると，次の順序で接続先のデータベースに対してSQLが発行されます。

JPQLが実行されると，CJPAプロバイダによってJPQLの内容が解釈される。

対象となるエンティティクラス内に記述されたアノテーションやO/Rマッピングファイルの情報を基に，接続先のデータベース製品固有のSQL文に組み立てて発行する。

ここでは，JPQLの使用方法について説明します。

(1)　Queryオブジェクトの取得方法

JPQLを使用してQueryオブジェクトを取得するためには，CJPAプロバイダが提供する次のEntityManagerインタフェースのメソッドを使用します。EntityManagerインタフェースのメソッドについて説明します。

(a)　Query createQuery(String JPQL文)

createQueryの記述例を次に示します。引数には実行するJPQL文を指定します。

Query q = em.createQuery(
                   "SELECT c  " +
                   "FROM Customer c " +
                   " WHERE c.name LIKE "Smith");

(b)　Query createNamedQuery(String クエリ名)

あらかじめ名前を付けて定義しておくことのできるクエリを名前付きクエリといいます。名前付きクエリは，@NamedQueryを任意のエンティティクラスに付与して定義します。@NamedQueryのname属性にクエリ名を指定して，query属性にはJPQL文を指定します。

CJPAプロバイダの場合，同じ名称の名前付きクエリを複数指定することはできません。同じ名称の名前付きクエリを複数指定した場合には，警告メッセージKDJE55535-Wを出力します。CJPAプロバイダで指定した場合，どのクエリが動作するかは保証しません。

次に，@NamedQueryの定義例を示します。この例では，@NamedQueryを使用してあらかじめfindAllCustomersWithNameという名前でクエリを登録しています。アプリケーションのcreateNamedQueryメソッドに登録した名前付きクエリ名を渡すことで，事前に登録されているクエリを取得して利用します。

@NamedQueryでのクエリ名の登録

@NamedQuery(
      name="findAllCustomersWithName",
      query="SELECT c FROM Customer c WHERE c.name LIKE :custName"
)
@Entity
public class Customer {
・・・
}

createNamedQueryメソッドでの名前付きクエリの記述例

@Stateless
public class MySessionBean {
・・・
  @PersistenceContext
  public EntityManager em;
  ・・・
  public void doSomething() {
    ・・・
    Query q = em.createNamedQuery("findAllCustomersWithName")
                                     .setParameter("custName", "Smith");
  }
}

なお，同一の永続化ユニット内では，ほかのエンティティで定義した名前付きクエリを使用することもできます。

(2)　パラメタの指定方法

JPQLでは，クエリを生成する際に，WHERE節に記述する条件式にパラメタを使用して，動的に値を設定することができます。パラメタの値はQueryインタフェースのsetParameterメソッドで設定します。パラメタには，位置パラメタと名前付きパラメタがあります。それぞれについて説明します。

位置パラメタ

WHERE節の中のパラメタを組み込みたい位置に，「?」と数値の組み合わせを記述します。パラメタの値は，QueryインタフェースのsetParameterメソッドで設定します。位置パラメタの記述形式と記述例を次に示します。

記述形式

Query setParameter(int 位置, Object 値)

記述例

Query q = em.createQuery(
        "SELECT c FROM Customer c WHERE c.balance < ?1")
.setParameter(1, 20000);

名前付きパラメタ

WHERE節の中のパラメタを組み込みたい位置に，「:」と任意の文字列（ただし，0〜9の文字を除く）の組み合わせを記述します。パラメタの値は，QueryインタフェースのsetParameterメソッドで設定します。名前付きパラメタの記述形式と記述例を次に示します。

記述形式

Query setParameter(String パラメタ名, Object 値)

パラメタ名の先頭には「:」を指定しないでください。また，名前付きパラメタは大文字・小文字を区別します。

記述例

Query q = em.createQuery(
        "SELECT c FROM Customer c WHERE c.name LIKE :custName")
        .setParameter("custName", "John");

なお，パラメタを使用するときには次のことに注意してください。

一つのクエリで位置パラメタと名前付きパラメタを混在して使用しないでください。CJPAプロバイダの場合，混在して使用したときの動作は保証しません。

setParameterメソッドには，java.util.Date型またはjava.util.Calendar型のオブジェクトをパラメタ値として設定するときに，次のように指定できます。なお，パラメタ値の時間タイプはTemporalType列挙型で指定する必要があります。詳細についてはJavaのドキュメントを参照してください。

Query setParameter(int 位置, Date 日付, TemporalType 時間タイプ)

Query setParameter(String パラメタ名, Date 日付, TemporalType 時間タイプ)

Query setParameter(int 位置, Calendar カレンダ, TemporalType 時間タイプ)

Query setParameter(String パラメタ名, Calendar カレンダ, TemporalType 時間タイプ)

(3)　クエリ結果の取得および実行

生成したクエリを実行して，そのクエリ結果を返したり，更新クエリを実行したりするためには，Queryインタフェースの次のメソッドを使用します。それぞれのメソッドについて説明します。

(a)　Object getSingleResult()

このメソッドは，クエリ結果を単一のオブジェクトとして返す場合に使用します。

メソッドを実行するとデータを検索します。検索の結果，ヒットした単一の行をエンティティオブジェクトに格納し，Object型で返します。Object型の戻り値は対象のエンティティクラスにキャストする必要があります。

複数の行がヒットした場合は，NonUniqueResultException例外が発生します。ヒットする行がなかった場合は，NoResultException例外が発生します。

(b)　List getResultList()

このメソッドは，クエリ結果をリストとして返す場合に使用します。

メソッドを実行するとデータを検索します。検索の結果，ヒットした複数の行をエンティティオブジェクトに格納し，リストで返します。実行結果として複数の行が返されること想定しているため，ヒットする行が一つもなかった場合は，空のリストが返ります。

(c)　int executeUpdate()

このメソッドは，更新クエリを実行する場合に使用します。

メソッドを実行するとテーブルから複数の行を一斉に削除または更新するクエリを実行します。実行結果にはヒットした行の件数が返ります。

8.16.2　ネイティブクエリでのデータベースの参照および更新方法

CJPAプロバイダでは，JPQL以外のクエリ言語として，データベース固有のネイティブクエリを直接記述して，データベースの参照・更新などを実行できます。

ここでは，ネイティブクエリでの使用方法について説明します。

(1)　Queryオブジェクトの取得方法

ネイティブクエリを使用してQueryオブジェクトを取得するためには，次に示すCJPAプロバイダが提供するEntityManagerインタフェースのメソッドを使用します。

(a)　Query createNativeQuery(String SQL文)

createNativeQueryの記述例を次に示します。引数には実行するネイティブクエリを指定します。

Query q = em.createNativeQuery(
                   "SELECT o.id, o.quantity, o.item " +
                   "FROM Order o, Item i " +
                   "WHERE (o.item = i.id) AND (i.name = 'widget')");

(b)　Query createNativeQuery(String SQL文，Class 結果格納クラス)

createNativeQueryの記述例を次に示します。第1引数には実行するネイティブクエリ，第2引数には実行結果を格納するクラスオブジェクトを指定します。

Query q = em.createNativeQuery(
                   "SELECT o.id, o.quantity, o.item " +
                   "FROM Order o, Item i " +
                   "WHERE (o.item = i.id) AND (i.name = 'book')",
                   com.hitachi.Order.class);

この例の場合，クエリが実行されると「book」という名前のアイテムに対するすべてのOrderエンティティのコレクションを返します。

なお，SELECT節で指定したクエリの結果と引数に指定したクラスオブジェクトの整合性がない場合は例外が発生します。

(c)　Query createNativeQuery(String SQL文，String 結果セットマッピング名)

第1引数には実行するネイティブクエリ，第2引数には実行結果を格納する結果セットマッピング名を指定します。結果セットマッピングは，@ SqlResultSetMappingで指定します。なお，結果セットマッピングについては，「(2)　結果セットマッピング」を参照してください。

@SqlResultSetMappingの定義例とcreateNativeQueryの記述例を次に示します。

@SqlResultSetMappingの定義例

@SqlResultSetMapping(name="BookOrderResults",
      entities=@EntityResult(entityClass=com.hitachi.Order.class))

createNativeQueryの記述例

Query q = em.createNativeQuery(
                   "SELECT o.id, o.quantity, o.item " +
                   "FROM Order o, Item i " +
                   "WHERE (o.item = i.id) AND (i.name = 'book')",
                   "BookOrderResults");

この例の場合，クエリが実行されると「book」という名前のアイテムに対するすべてのOrderエンティティのコレクションを返します。@SqlResultSetMappingを使用することで，「8.16.1(1)　Queryオブジェクトの取得方法」の@NamedQueryを使用した場合の記述例と同じ結果を得ることができます。

なお，SELECT節で指定したクエリ結果と引数に指定した@SqlResultSetMapping設定の整合性がない場合は例外が発生します。

(d)　Query createNamedQuery(String クエリ名)

ネイティブクエリの場合も，JPQLと同じようにcreateNamedQueryメソッドを使用できます。ネイティブクエリの場合は，引数に名前付きネイティブクエリ名を指定してください。

名前付きネイティブクエリは，@NamedNativeQueryを任意のエンティティクラスに付与して定義します。引数のクエリ名には，@NamedNativeQueryのname属性で指定した名前を使用します。

CJPAプロバイダの場合，同じ名称の名前付きクエリを複数指定することはできません。同じ名称の名前付きクエリを複数指定した場合には，警告メッセージKDJE55522-Wを出力します。CJPAプロバイダで指定した場合，どのクエリが動作するかは保証しません。

次に，createNamedQueryメソッドの使用例を示します。この例では，@NamedNativeQueryを使用してあらかじめfindBookOrderという名前でクエリを登録しています。アプリケーションのcreateNamedQueryメソッドに登録した名前付きクエリ名を渡すことで，事前に登録されているクエリを取得して利用します。

@NamedNativeQueryでのクエリ名の登録

@NamedNativeQuery( name="findBookOrder",
       query="SELECT o.id, o.quantity, o.item " +"
             "FROM Order o, Item i " +
             "WHERE (o.item = i.id) AND (i.name = 'book')")
)
@Entity
public class Order {
・・・
}

createNamedQueryメソッドでの名前付きネイティブクエリの記述例

@Stateless
public class MySessionBean {
  ・・・
  @PersistenceContext
  public EntityManager em;
  ・・・
  public void doSomething() {
    ・・・
    Query q = em.createNamedQuery("findBookOrder ")
  }
}

なお，同一の永続化ユニット内では，ほかのエンティティで定義した名前付きネイティブクエリを使用することもできます。

(2)　結果セットマッピング

結果セットマッピングとは，ネイティブクエリの実行結果を任意のエンティティクラスにマッピングして受け取ったり，スカラ値で受け取ったりするための機能です。

結果セットマッピングでは，ネイティブクエリの実行結果として取得した各カラム値のマッピング情報を@SqlResultSetMappingを指定して任意のエンティティクラスに対して付与します。

(a)　@SqlResultSetMappingの記述形式

@SqlResultSetMappingの記述形式を次に示します。

@SqlResultSetMapping(
  name= 結果セットマッピングの名前,
  entities= 結果をマッピングするためのエンティティクラス指定(@EntityResultの配列),
  columns= 結果をマッピングするためのカラム指定(@ColumnResultの配列) )

name属性

結果セットマッピング名を指定します。

entities属性

@EntityResultの配列を指定します。@EntityResultの記述形式を次に示します。

@EntityResult(
    entityClass= 結果をマッピングするためのクラスを指定,
    fields= 結果をマッピングするためのフィールド指定(@FieldResultの配列) )

@EntityResultのentityClass属性には，カラム値を格納するエンティティクラスを指定します。また，field属性には，@FieldResultの配列を指定します。

@EntityResultの記述形式を次に示します。

@FiledResult(
    name= クラスの永続プロパティ(またはフィールド)の名前,
    column= SELECT節のカラムの名前(または別名) )

@FieldResultのname属性には，@EntityResultのentityClass属性に指定したエンティティクラスの永続化フィールド名を指定します。また，column属性にはカラム名を指定します。

columns属性

columns属性は，エンティティクラスに格納しないでスカラ値として受け取るために，@ColumnResultの配列を指定します。スカラ値を取り出す必要がない場合は指定する必要はありません。@ColumnResultのname属性には，値を取り出すカラム名を指定してください。@ColumnResultの記述形式を次に示します。

@ColumnResult(
    name= SELECT節のカラムの名前(または別名) )

なお，カラム名はASで指定したエリアス名でも指定できます。SELECT節に同じ名前の複数の列を含む場合は，列の別名を使用してください。

(b)　使用例

従業員テーブル（Employee）と部門テーブル（Department）から従業員番号12003のクエリ結果を任意のエンティティクラス（EmployeeSetmap）にマッピングして，スカラ値（EMP_MONTHLY_SALARYカラム）を受け取る例を次に示します。

結果セットマッピング名（NativeQuerySetMap）をcreateNativeQueryの第2引数に指定して，結果セットマッピングを実行します。

結果セットマッピングを使用したネイティブクエリの記述例

query = em.createNativeQuery(
                "SELECT e.EMPLOYEE_ID AS EMP_EMPLOYEE_ID, " +
                "e.EMPLOYEE_NAME AS EMP_EMPLOYEE_NAME, " +
                "d.DEPARTMENT_NAME AS DEP_DEPARTMENT_NAME, " +
                "e.MONTHLY_SALARY AS EMP_MONTHLY_SALARY  " +
                "FROM EMPLOYEE e, DEPARTMENT d " +
                "WHERE e.DEPARTMENT_ID = d.DEPARTMENT_ID " +
                "AND e.EMPLOYEE_ID = 12003",
                "NativeQuerySetMap");

ネイティブクエリの実行結果を格納する任意のエンティティクラス

@Entity
public class EmployeeSetmap implements Serializable {
:
@Id
public int getEmployeeId() { return employeeId; }
public String getEmployeeName() { return employeeName; }
public String getDepartmentName() { return departmentName; }
:
}

@ SqlResultSetMappingの記述例

@SqlResultSetMapping(
       name="NativeQuerySetmap",
       entities={ @EntityResult(
                          entityClass=EmployeeSetmap.class,
                          fields={ @FiledResult(
                                      name="employeeId",
                                      column="EMP_EMPLOYEE_ID"),
                                  @FiledResult(
                                      name="employeeName",
                                      column="EMP_EMPLOYEE_NAME"),
                                  @FiledResult(
                                      name="departmentName",
                                      column="DEP_DEPARTMENT_NAME") } ) },
       columns={ @ColumnResult(
                          name="EMP_MONTHLY_SALARY") }

なお，@ SqlResultSetMappingを実行してネイティブクエリを実行した結果のObject型配列は，次のようになります。

Object[0]

EmployeeSetmapクラスのオブジェクト

（EMP_EMPLOYEE_IDカラム，EMP_EMPLOYEE_NAMEカラム，DEP_DEPARTMENT_NAMEカラムの値が各フィールドに格納される）

Object[1]

EMP_MONTHLY_SALARYカラムの値

(3)　パラメタの指定方法

ネイティブクエリは，JPQLと同様に，パラメタによって動的に値を設定することができます。WHERE節の中のパラメタを組み込みたい位置に，「?」と数値の組み合わせを記述します。パラメタの値は，QueryインタフェースのsetParameterメソッドで設定します。ただし，ネイティブクエリでは，JPQLの名前付きパラメタは使用できません。

パラメタの記述形式を次に示します。

Query setParameter(int 位置, Object 値)

(4)　ネイティブクエリ結果の取得および実行

ネイティブクエリ結果の取得および実行は，JPQLと同様に，Queryインタフェースの次のメソッドを使用します。

Object getSingleResult()

List getResultList()

int executeUpdate()

これらのメソッドの詳細については，「8.16.1　JPQLでのデータベースの参照および更新方法」を参照してください。

8.16.3　クエリ結果件数の範囲指定

複数件あるクエリ結果の中から任意に指定した件数だけを取得したり，開始位置で指定したクエリ結果だけを取得したりすることができます。これらの情報を取得するには，Queryインタフェースのメソッドを使用します。メソッドについて次に説明します。

(1)　setMaxResultsメソッド

複数件あるクエリ結果の中から任意に指定した件数だけを取得するにはQueryインタフェースのsetMaxResultsメソッドを使用します。setMaxResultsメソッドの記述形式を次に示します。

Query setMaxResults(int検索結果の最大数)

メソッドの引数には，検索結果の最大数を指定します。

(2)　setFirstResultメソッド

開始位置で指定したクエリ結果だけを取得するにはsetFirstResultメソッドを使用します。setFirstResultメソッドの記述形式を次に示します。

Query setFirstResult(int検索結果の開始位置)

メソッドの引数に検索結果の開始位置を指定します。なお，開始位置は0から始まる数値を指定してください。

(3)　Queryインタフェースのメソッドの使用例

setMaxResultsメソッドおよびsetFirstResultメソッドの使用例を示します。この例では，従業員データ（Employee）から，月給（e.monthlySalary）の多い順に10番目から5人分のEmployeeオブジェクトを取得します。

Query query = em.createQuery( "SELECT e FROM Employee AS e " +
                              "ORDER BY e.monthlySalary DESC" )
                              .setFirstResult(9)
                              .setMaxResults(5);
List resultList = query.getResultList();

(4)　注意事項

setFirstResultメソッドを使用して開始位置を指定した場合，引数に指定した値によって，getResultListメソッドおよびgetSingleResultメソッドを呼び出してから結果の値を取得するまでの時間が変わります。通常，引数に指定した開始位置の値に比例して，結果の値が戻ってくるまでの時間が掛かります。

8.16.4　フラッシュモードの指定

エンティティオブジェクトに対して実行された未コミット操作をクエリがどのように扱うかを指定できます。この指定をフラッシュモードの指定といいます。

フラッシュモードは，javax.persistence.QueryインタフェースのsetFlushModeメソッドで設定します。CJPAプロバイダでは，設定できる値はAUTOだけです。COMMITは設定できません。

FlushModeType.AUTOの場合

トランザクション内でクエリが実行されたとき，クエリ結果に影響を及ぼす永続化コンテキストにあるすべてのエンティティの変更内容がクエリ結果に反映されます。

この設定は，EntityManagerインタフェースのsetFlushModeメソッドのフラッシュモードに関係なくクエリに適用されます。

8.16.5　クエリヒントの指定

クエリ実行時に，ベンダに依存するヒントとしてクエリヒントを指定できます。CJPAプロバイダでは，悲観的ロックを使用するときに指定します。

クエリヒントは次に示す場所に指定します。

QueryオブジェクトのsetHint()メソッドの引数

@NamedQueryの引数の@Hint

O/Rマッピングファイルの<named-query>タグの下位要素である<hint>タグ

クエリヒントに指定できる範囲以外の値が設定された場合は例外が発生します。なお，指定する値は大文字と小文字を区別しません。

例外が発生するタイミングは，クエリヒントが指定された個所によって異なります。次に例外発生のタイミングを示します。

setHint()メソッドの場合，アプリケーションのクエリ実行時

アノテーションの場合，デプロイ時

O/Rマッピングファイルの場合，アプリケーション開始時

CJPAプロバイダがサポートするクエリヒントについては，アノテーションを使用する場合は「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」，O/Rマッピングファイルを使用する場合は「12.3　O/Rマッピングファイル」を参照してください。

8.16.6　クエリの実行時の注意事項

ここでは，クエリ実行時の注意事項について説明します。

setMaxResultsメソッドまたはsetFirstResultメソッドで，コレクション同士がFETCH JOINを含むクエリを実行した場合，結果は保証されません。

executeUpdateメソッド以外のQueryメソッドは，トランザクション内で実行する必要はありません。特にgetResultListとgetSingleResultメソッドはトランザクション内で実行する必要はありません。

トランザクションスコープ永続化コンテキストのEntityManagerで，クエリが実行された場合の結果のエンティティは，detached状態になります。拡張永続化コンテキストのEntityManagerでクエリが実行された場合，すべてmanaged状態になります。

QueryインタフェースのメソッドからスローされるNoResultExceptionとNonUniqueResultException以外の実行時例外はカレントのトランザクションをロールバックします。

8.17　JPQLの記述方法

ここでは，JPQLの記述方法について説明します。

8.17.1　JPQLの構文

JPQL文には，SELECT文とUPDATE文，DELETE文があります。

JPQL文は，動的に指定したり，アノテーションやO/Rマッピングファイルのタグで静的に定義したりすることができます。また，JPQLのすべての文でパラメタの指定ができます。

JPQLは型付き言語で，すべての式は型を持ちます。式の型は，式の構成や識別変数で定義された抽象スキーマ型，永続化フィールドとリレーションシップを評価する型，およびリテラル型で構成されています。なお，構文の文法については，「付録G　JPQLのBNF」を参照してください。

注意事項

CJPAプロバイダの場合，BNF構文に準拠しないJPQLを使用すると，例外が発生するおそれがあります。例外が発生しない場合でも，動作は保証しません。また，BNF構文に準拠したJPQLを使用した場合でも，使用するデータベースで該当する機能をサポートしていない場合の動作は保証しません。

(1)　抽象スキーマ型

JPQLでは，エンティティを対象にクエリを発行します。そのため，クエリでは対象となるエンティティの抽象スキーマを定義する必要があります。エンティティの抽象スキーマ型は，アノテーションまたはO/Rマッピングファイルによって提供されるエンティティクラスとO/Rマッピングの情報によって定義されます。

抽象スキーマ型とは，エンティティクラスのことを指します。エンティティクラスを構成するものとして，フィールドや，アノテーションなどのO/Rマッピング情報があります。

エンティティの抽象スキーマ型は次に示すフィールドを持ちます。

ステートフィールド

ステートフィールドは，エンティティクラスの永続化フィールド，または永続化プロパティで，リレーションシップによる関連が存在しないフィールド，またはプロパティです。

関連フィールド

関連フィールドは，エンティティクラスでリレーションシップによって関連づいた永続化フィールド，または永続化プロパティです。リレーションシップがOneToManyまたはManyToManyの場合，フィールドはコレクションになります。

(2)　抽象スキーマ名

JPQLでは，エンティティを示すために，その抽象スキーマ型を指定する必要があります。抽象スキーマ型を示すための名前を抽象スキーマ名といいます。抽象スキーマ名は@Entityのname属性（またはO/Rマッピングファイルの<entity>タグのname属性）で定義します。name属性が指定されなかった場合は，エンティティクラスの（パッケージ名抜きの）クラス名となります。

抽象スキーマ名は，永続化ユニット単位で固有となります。

(3)　クエリのドメイン

クエリのドメインは，永続化ユニット内で定義されたすべてのエンティティの抽象スキーマ型を参照できます。抽象スキーマ型の中で定義されている関連フィールドによって，ほかの関連するエンティティの抽象スキーマ型を参照できます。

8.17.2　SELECT文

SELECT文には次の節があります。

SELECT節

検索するオブジェクトの型か集合関数による値を指定します。SELECT節は必ず指定します。

FROM節

検索が適用される範囲を指定します。FROM節は必ず指定します。

WHERE節

検索結果を絞るために使用します。WHERE節は省略できます。

GROUP BY節

検索結果をグループ化するために使用します。GROUP BY節は省略できます。

HAVING節

グループ化されたものをフィルタリングするために使用します。HAVING節は省略できます。

ORDER BY節

検索結果の順序化をするために使用します。ORDER BY節は省略できます。

SELECT文に，SELECT節およびFROM節の指定がない場合は例外が発生します。

8.17.3　SELECT節

SELECT節ではクエリの結果を表します。一つ以上の値がクエリのSELECT節から返ります。SELECT節には，次に示す要素をコンマで区切って指定します。なお，コンマで区切られた一つのまとまりをselect式と呼びます。

抽象スキーマの識別子または識別子を付与した永続化フィールド

パス式

集合関数

コンストラクタ式

なお，DISTINCTキーワードは，重複する値をクエリ結果から除くときに指定してください。

SELECT節の記述例を次に示します。

SELECT e.employeeName, e.monthlySalary
FROM Employee AS e
WHERE e.monthlySalary  < 150000

(1)　コンストラクタ式

コンストラクタ式は，一つ以上のJavaのインスタンスを返すSELECT節のselect式で使用されます。生成名は完全修飾名を指定します。

コンストラクタ式は，エンティティのカラムの一部または全部や，関連する別のエンティティのカラムと組み合わせた形で取得できます。なお，この結果を格納するクラスはエンティティである必要はありません。

コンストラクタ式の構文は，select式にNEW演算子を付けて指定します。格納するクラスがエンティティの場合，エンティティクラスのインスタンスの状態はnewになります。コンストラクタ式の記述例を次に示します。

SELECT NEW com.hitachi.jpa.test.entity.EmployeeTmp
(e.employeeId, e.employeeName, d.departmentName)
FROM Department AS d, d.employees AS e
WHERE e.employeeId = 12003

(2)　集合関数

SELECT節では集合関数を使用できます。使用できる集合関数を次の表に示します。

表8‒20　JPQLのSELECT節で使用できる集合関数

集合関数

引数

結果の型

適用される値がない場合の結果

AVG

数値型のステートフィールド※

Double型

null

MAX

順序を指定できるフィールド型（数値型，文字列型，文字型，または日付型）※

適用するフィールドの型

null

MIN

順序を指定できるフィールド型（数値型，文字列型，文字型，または日付型）※

適用するフィールドの型

null

SUM

数値型のステートフィールド※

整数型の場合：Long型

浮動小数点型の場合：Double型

BigInteger型の場合：BigInteger型

BigDecimal型の場合：BigDecimal型

null

COUNT

識別変数（引数にパス式を指定する場合，ステートフィールドか関連フィールドを指定する）

Long型

0

注　DISTINCTが指定されているかどうかにかかわらず，集合関数が適用される前にnull値は除去されます。

注※　引数にパス式を指定する場合，関連フィールドを指定することはできません。

なお，集合関数式の構文の詳細については，「付録G　JPQLのBNF」を参照してください。

(3)　SELECT節の実行結果

クエリのSELECT節で定義されるクエリ結果の型は，次のどれか一つになります。なお，複数ある場合は順番に並べられます。

エンティティ抽象スキーマ型

フィールド型

集合関数の結果

コンストラクタ式の結果

SELECT節の結果の型は，SELECT節に含まれるselect式の結果の型によって定義されます。複数のselect式がSELECT節で使われている場合，クエリの結果はObject[]型となります。この結果の要素はSELECT節で指定された順番に一致し，各select式の結果の型と一致します。

8.17.4　FROM節

ここではFROM節について説明します。

(1)　範囲変数宣言と識別変数

範囲変数宣言とは，FROM節内でエンティティクラスの論理的な名前を記述し，そのあとにASと識別子を指定する宣言です（ASは省略できます）。この範囲変数宣言の識別子を識別変数といいます。範囲変数宣言と識別変数の例を次に示します。

SELECT ・・・（省略）・・・

FROM  Department AS dep

WHERE ・・・（省略）・・・

「Department AS dep」の部分が範囲変数宣言です。また，「dep」が識別変数となります。次に，範囲変数宣言の構文を示します。

range_variable_declaration ::=
abstract_schema_name [AS] identification_variable

範囲変数宣言での識別変数の構文は，SQLの構文と同じです。構文について説明します。

キーワードASの使用は任意です。

識別変数を省略することはできません。ただし，抽象スキーマと識別変数の間に指定するASは省略できます。識別変数はFROM節で指定します。

予約済みの識別子は使用できません。使用した場合は例外が発生します。

同じ永続化ユニットのほかのエンティティと同じ名前は使用できません。CJPAプロバイダでは，同じ名前のエンティティを使用した場合の動作は保証しません。

識別変数は大文字，小文字の区別をしません。

抽象スキーマ名と同一の名前は指定できません。CJPAプロバイダでは，同じ名前の抽象スキーマを指定した場合の動作は保証しません。

Java識別子文字で始まり，ほかのすべての文字はJava識別子の部分文字となる必要があります。それ以外の文字が指定された場合は，例外が発生します。最初の文字は，Character.isJavaIdentifierStartメソッドの戻り値がtrueになる文字にします（アンダースコア（_）とドルマーク（$）文字を含む）。最初以外の文字は，Character.isJavaIdentifierPartメソッドの戻り値がtrueになる文字にします（ただし，クエスチョンマーク（?）は，JPQLの予約語のため使用できません）。

JPQLの予約語は次のとおりです。

SELECT，FROM，WHERE，UPDATE，DELETE，JOIN，OUTER，INNER，LEFT，GROUP，BY，HAVING，FETCH，DISTINCT，OBJECT，NULL，TRUE，FALSE，NOT，AND，OR，BETWEEN，LIKE，IN，AS，UNKNOWN，EMPTY，MEMBER，OF，IS，AVG，MAX，MIN，SUM，COUNT，ORDER，BY，ASC，DESC，MOD，UPPER，LOWER，TRIM，POSITION，CHARACTER_LENGTH，CHAR_LENGTH，BIT_LENGTH，CURRENT_TIME，CURRENT_DATE，CURRENT_TIMESTAMP，NEW，EXISTS，ALL，ANY，SOME

なお，「UNKNOWN」はJPA1.0では利用していませんが，CJPAプロバイダでは予約語となっているので注意してください。

(2)　パス式

パス式は，識別変数のあとにピリオド（.）を付加し，ステートフィールドまたは関連フィールドを続けるための式です。このため，パス式の型は，ステートフィールドまたは関連フィールドの型になります。

パス式をたどって得た関連フィールドから，さらにパス式を組み立てることができます。ただし，基になるパス式の型がコレクション関連フィールドである場合，パス式を組み立てることはできません。コレクション型からパス式を作ることは，構成的に誤りとなります。

なお，パス式の途中の関連フィールドがnull値の場合，パスは値がないとみなされるので，クエリの結果には影響はありません。

パス式は，inner joinを使用する構文で使用できます。パス式の構文の詳細については，「付録G　JPQLのBNF」を参照してください。

参考

関連フィールドの種類を次に示します。

コレクション関連フィールド（collection_valued_association_field）とは，関連フィールドがコレクションで指定されているものです。OneToManyまたはManyToManyの関係で示されます。

非コレクション関連フィールド（single_valued_association_field）とは，関連フィールドがsingle-valuedで指定されているものです。OneToOneまたはManyToOneの関係で示されます。

エンベッデドクラスフィールドは，embeddedクラスに対応するエンティティのフィールド名です。

(3)　Joins式

Joins式はFROM節で使用できます。使用できるJoins式を次の表に示します。

表8‒21　FROM節で使用できるJoins式

Joins式

内容

BNF構文の構文名※1

Inner Joins

関係するフィールドで，二つのエンティティクラスを結合し，関連を持っているエンティティオブジェクトだけを抽出します。

join, join_spec

Left Outer Joins

関係するフィールドで，二つのエンティティクラスを結合し，関連を持っているエンティティオブジェクトおよび，関連を持っていないエンティティオブジェクトも抽出します。

join, join_spec

Fetch Joins

関係のあるフィールドで，二つエンティティクラスを結合します。なお，エンティティ間にはリレーションシップによる関連があるため，Select節中には一つのエンティティクラスだけを指定します。※2

fetch_join

注※1　BNF構文の構文名の詳細については，「付録G　JPQLのBNF」を参照してください。

注※2　Fetch Joinsでエンティティを取得した場合，右側で指定した関連先のエンティティの情報をクエリ実行と同時に取得します。これによって，フェッチ戦略に依存しないで関連先の情報を取得できます。Fetch Joinsの記述例を次に示します。

SELECT emp FROM Employee AS emp JOIN FETCH emp.company

Join式を使用する場合の注意事項

Join式を使用する場合の注意事項について説明します。

Inner Joinsの注意事項

INNERキーワードは，任意で使われます。

Left Outer Joinsの注意事項

OUTERキーワードは，任意で使われます。

Fetch Joinsの注意事項

Fetch Joinsでは，一つのエンティティで二つのエンティティ情報を指定します。指定するエンティティと，そのエンティティと関連する別のエンティティ情報を結合します。

なお，CJPAプロバイダの場合，一つのエンティティ情報で結合するため，リレーションシップを持つエンティティを指定してください。リレーションシップを持たないエンティティを指定した場合は例外が発生します。

JOIN FETCHの右側で参照される関係は，クエリの結果として返されるエンティティに属する関係となる必要があります。CJPAプロバイダの場合，エンティティに属さないときは例外が発生します。

JOIN FETCHの右側で参照されるエンティティには，識別子を指定できません。このため，クエリ内で参照することはできません。

(4)　コレクションメンバの宣言

コレクションメンバ宣言の識別変数は，予約された識別子INを使って宣言します。コレクションメンバ式で定義された識別変数は，パス式を使ってコレクションの値を取得できます。コレクションメンバ式の記述例を次に示します。

SELECT emp.employeeId, emp.employeeName, dep.departmentName
FROM Department AS dep, IN (dep.employees) AS emp
WHERE dep.departmentId = 3

なお，コレクションメンバ式の構文の詳細については，「付録G　JPQLのBNF」を参照してください。

(5)　注意事項

ここでは，FROM節での注意事項について説明します。

識別変数の影響

FROM節で宣言された識別変数がWHERE節の中で使用されなくても，宣言された識別変数がクエリの結果に反映されます。

多態性の注意事項

JPQLはポリフォリズムです。FROM節で明確に参照している特定のエンティティクラスのインスタンスだけでなく，そのサブクラスも対象になります。このため，クエリによって取得できるインスタンスは，クエリ条件を満たすサブクラスのインスタンスを含みます。

8.17.5　WHERE節

WHERE節は式を満たすオブジェクトまたは変数を検索するために使われる条件式で構成されています。WHERE節では，select文の結果やupdateやdelete操作の範囲を特定します。

(1)　WHERE節で使用できる条件式

WHERE節で使用できる条件式を次の表に示します。

表8‒22　WHERE節で使用できる条件式

式

内容

BNF構文の構文名※

BETWEEN

フィールドで指定した範囲に含まれていることを評価します。

between_expression

IN

フィールドで指定したどれかの値と一致することを評価します。

in_expression

LIKE

フィールドでワイルドカード記号を展開したあとの文字列と一致することを評価します。

like_expression

IS [NOT] NULL

null値かどうかをテストします。

null_comparison_expression

IS [NOT] EMPTY

指定したコレクション値が空かどうかをテストします。

empty_collection_comparison_expression

[NOT] MEMBER [OF]

指定したコレクション値がコレクションのメンバであるかどうかをテストします。空のコレクションを表す場合，MEMBER OF式の値はFALSE，NOT MEMBER OF式の値はTRUEとなります。

collection_member_expression

EXISTS

サブクエリの結果を判定します。一つ以上の値がある場合はtrue，それ以外はfalseを返します。

exists_expression

ALL

サブクエリで返されたすべての値と比較します。

all_or_any_expression

ANY (SOME)

サブクエリで返されたどれかの値と比較します。

all_or_any_expression

サブクエリ

selectによる結果を記述できます。

subquery

関数式

「(2)　関数式」を参照してください。

該当する関数構文を参照

注※　BNF構文の構文名の詳細については，「付録G　JPQLのBNF」を参照してください。

WHERE節を使用する場合の注意事項について説明します。

IN式

評価対象のフィールドがnull値かunknownの場合，式の値はunknownになります。

IN式に対する値の集合を定義したコンマで区切られたリストでは，少なくとも一つ以上の要素が必要です。CJPAプロバイダの場合，一つ以上の要素がないと例外が発生します。

評価対象のフィールドは，文字列，数値，またはenum値を持つ必要があります。

リテラルや入力パラメタ値，およびサブクエリの結果は，評価対象のフィールドと同じ抽象スキーマ型にしてください。CJPAプロバイダの場合，同じ抽象スキーマ型でないと例外が発生します。

LIKE式

BNF構文で示されるstring_expressionまたはpattern_valueの値が，nullまたはunknownの場合，LIKE式の値はunknownになります。

BNF構文で示されるescape_characterが指定されている場合で，値がnullのとき，LIKE式の値はunknownになります。

指定するパターン値は，アンダースコア（_）が1文字に相当し，パーセント（%）文字が連続文字（空の連続文字も含む）に相当します。なお，ほかの文字は検索文字列を示します。

オプションのエスケープ文字は，文字列リテラルかまたはcharacter文字です。パターン文字列のアンダースコアとパーセント文字を標準の文字として解釈させる場合に使用します。

IS [NOT] NULL式

指定したコレクション値がnullまたはunknownの場合，IS [NOT] EMPTY式の値はunknownになります。

[NOT] MEMBER [OF]式

指定した値がnullまたはunknownの場合，戻り値はunknownになります。

ALL式またはANY (SOME)式

条件演算がtrueでもfalseでもない場合は，unknownになります。

一緒に使用できる比較演算子は，=，<，<=，>，>=，<>です。

サブクエリの結果の型は比較演算子の型と同じにする必要があります。CJPAプロバイダの場合，型が異なると例外が発生します。

SOMEは，ANYの同義語です。※

注※　この注意事項はANY (SOME)式の場合だけ該当します。

サブクエリ

WHERE節やHAVING節で使用します。FROM節では使用できません。

(2)　関数式

JPQLでは次の表に示す関数をWHERE節やHAVING節で使用できます。関数式の引数の値がnullかunknownの場合，関数式の値はunknownになります。

表8‒23　JPQLで使用できる関数

分類

関数

返り値

引数についての補足説明

文字列関数

CONCAT

引数の連結した文字列

−

SUBSTRING

引数で指定した開始位置と長さの文字列

2番目と3番目引数は，返されるサブストリングの開始位置および長さを整数で指定します。文字列の先頭の位置は1です。

TRIM

特定の文字を取り除いた文字列

取り除く文字がない場合は，スペース（空白）と見なされます。任意のtrim文字はcharacterの入力文字列です。トリムの方法が指定されない場合はBOTHとなります。

LOWER

小文字化した文字列

−

UPPER

大文字化した文字列

−

LENGTH

文字列長の整数値

−

LOCATE

指定された位置から検索し，与えられた文字列で最初に文字列を見つけた位置の整数値 （文字列が見つからない場合は0）

1番目引数は検索する文字列，2番目引数は検索される文字列を示します。任意となる3番目の引数は，検索を開始する文字の位置を示します（デフォルトは先頭から検索）。文字列の先頭位置は1です。

算術関数

ABS

関数の引数と同じ型（Integer，Float，またはDouble）の絶対値

引数として数値を渡します。

SQRT

引数で渡された数値の平方根（実数）

引数として数値を渡します。

MOD

引数で渡された二つの数値の剰余（整数）

二つの整数を渡します。

SIZE

コレクションの要素数（整数）

コレクションを渡します。

日付時間関数

CURRENT_DATE

データベースの日付

−

CURRENT_TIME

データベースの時刻

−

CURRENT_TIMESTAMP

データベースのタイムスタンプ

−

（凡例）−：該当しない

(3)　注意事項

WHERE節の注意事項について説明します。

(a)　演算子の優先順位

演算子の優先順位を次に示します。

ピリオド（.）

算術演算子

単項演算（+，-），乗算と除算（*，/），加算と減算（+，-）

比較演算子

=，>，>=，<，<=，<>（not equal），[NOT] BETWEEN，[NOT] LIKE，[NOT] IN，IS [NOT] NULL，IS [NOT] EMPTY，[NOT] MEMBER [OF]

論理演算子

NOT，AND，OR

(b)　条件式の注意事項

条件式は，条件式，比較式，論理演算子，評価結果がboolean値になるパス式，booleanリテラル，boolean型の入力パラメタで構成されます。

算術式は，比較式で使用できます。算術式は，ほかの算術式，四則演算，結果が数値になるパス式，数値リテラル，数値型の入力パラメタで構成されます。

算術操作は，数値昇格（numeric promotion）を使用します。

式の評価順序を示すために括弧で囲むことができます。

集合関数は，HAVING節の条件式だけで使用できます。

条件式の中では，シリアライズ形式またはlobsとしてマップされるフィールドを使用しないでください。

(c)　リテラルの注意事項

文字リテラルは，シングルクォテーションで囲みます（例：'literal'）。シングルクォテーションを含む文字列リテラルは，二つシングルクォテーションを使用します。

JavaStringリテラルのように，クエリの文字列リテラルはUnicode文字のエンコードを使用します。

Javaのエスケープ表記の使用は，クエリの文字列リテラルではサポートしません。

enumのリテラルは，Javaのenumリテラル構文のリテラルが使用できます。enumリテラルにはenumクラス名が必要です。

booleanリテラルは，TRUEとFALSEである。このリテラルは大文字小文字を区別しません。

(d)　識別変数の注意事項

識別変数は，クエリのFROM節で宣言された識別子であるため，ほかの節では宣言できません。FROM節以外で宣言した場合は例外が発生します。SELECT文，またはDELETE文のWHEREかHAVING節で使用されるすべての識別変数は，FROM節で定義されたものを使用します。

識別変数の範囲は，WHERE節とHAVING節で決定されます。識別変数は，エンティティの抽象スキーマタイプのコレクションメンバやインスタンスは指定できますが，コレクション自体は指定できません。コレクションを指定した場合は例外が発生します。

(e)　Path式の注意事項

WHEREかHAVING節内でのコレクションのパス式で，条件式の一部としてIS [NOT] EMPTY式や[NOT] MEMBER [OF]式，またはSIZE操作への引数以外を使用しないでください。

(f)　入力パラメタの注意事項

入力パラメタは，クエリのWHERE節かHAVING節で使用できます。

一つのクエリで位置パラメタと名前付きパラメタを混在して使用しないでください。混在した場合の動作は保証されません。

入力パラメタの値がnullの場合，入力パラメタを含む比較操作か算術操作で返される値はunknownになります。

なお，位置パラメタと名前付きパラメタの使い方については，「8.16.1(2)　パラメタの指定方法」を参照してください。

8.17.6　GROUP BY節およびHAVING節

GROUP BY節では，クエリの結果をグループごとにまとめます。また，HAVING節では，クエリ結果をさらに絞り込むための条件指定ができます。グループを指定した上で，HAVING節の条件を指定してください。

クエリにWHERE節とGROUP BY節の両方が含まれる場合，WHERE節が最初に実行され，その後，GROUP BY節で形式を整えてHAVING節に従ってフィルタリングします。

SELECT節に現れる集合関数以外のアイテムは，GROUP BY節にも指定する必要があります。グルーピングでは，null値も含めて条件として扱います。GROUP BY節およびHAVING節の注意事項について説明します。

エンティティによるグルーピングはできますが，シリアライズしたフィールドや，lobフィールドを含むことはできません。CJPAプロバイダでは，指定した場合には例外が発生します。

HAVING節にはグループアイテムに対する検索条件を指定するため，グループアイテムに適用する集合関数を指定する必要があります。CJPAプロバイダでは，検索条件の指定がない場合は例外が発生します。

GROUP BY節がない状態でHAVING節は使用しないでください。使用した場合は例外が発生します。

GROUP BY節およびHAVING節の記述例を次に示します。

SELECT e.department.departmentId
FROM Employee AS e
GROUP BY e.department.departmentId
HAVING COUNT(e.department.departmentId) <= 2

なお，GROUP BY節およびHAVING節の構文については，「付録G　JPQLのBNF」を参照してください。

8.17.7　ORDER BY節

ORDER BY節ではオブジェクトや値が順序付けされてクエリの結果を返します。ORDER BY節の記述例を次に示します。

SELECT e
FROM Employee AS e
ORDER BY e.monthlySalary DESC

ORDER BY節について説明します。

一つ以上のorder項目が指定された場合，orderby項目要素の左から右へ順に優先度を決め，いちばん左のorderby項目がいちばん高い優先度を持ちます。

ASCは昇順のときに，DESCは降順のときに指定します。なお，デフォルト値はASCです。

null値がある場合の順番はSQLのルールを適用します。

ORDER BY節が使用された場合，クエリの結果の順番はクエリメソッドの結果に保存されます。

なお，ORDER BY節の構文については，「付録G　JPQLのBNF」を参照してください。

また，ORDER BY節では次に示す条件を満たす必要があります。

ORDER BY節で指定するorder項目は順序付けができること。

ORDER BY節で指定するorder項目はSELECT節のselect式からたどれること。

これらの条件に合わない場合，CJPAプロバイダでは例外が発生するおそれがあります。ただし，例外が発生しない場合でも動作は保証しません。

8.17.8　バルクUPDATE文およびバルクDELETE文

複数のレコードを一括して更新することをバルク更新といいます。バルク更新をするには，バルクUPDATE文およびバルクDELETE文を使用します。バルクUPDATEとDELETEの操作は，単体のエンティティクラスまたはサブクラスと合わせたエンティティクラスに適用されます。UPDATE文ではUPDATE節に，DELETE文ではFROM節に識別変数を定義して，1種類のエンティティを指定します。

バルクUPDATE文およびバルクDELETE文を使用するときの注意時について説明します。

delete操作は，指定されたクラスとそのサブクラスのエンティティにだけ適用されます。関係するエンティティへのカスケードはされません。

update操作で指定される更新値（new_value）は，割り当てられたフィールドの型との互換性が必要です。互換性がない場合は例外が発生します。

バルクUPDATE文は，楽観的ロックを掛けないでデータベースの更新操作を実行するため，楽観的ロックに関する処理は実行しません。このため，バージョン列の値を手動で参照・更新する必要があります。

注意事項

バルクUPDATE文やバルクDELETE文を実行するときは，データベースと活性化している永続化コンテキストのエンティティとの間で不一致になるため注意が必要です。バルクUPDATE文とバルクDELETE文での操作は，トランザクションと切り離したところで実行するか，トランザクションの開始時に実行する必要があります。

バルクUPDATE文およびバルクDELETE文の記述例を次に示します。

UPDATE EMPLOYEE
SET MONTHLY_SALARY = MONTHLY_SALARY + 1000
WHERE DEPARTMENT_ID = 3

DELETE FROM EMPLOYEE e
WHERE e.EMPLOYEE_NAME IS NULL AND e.monthlySalary  IS EMPTY

なお，バルクUPDATE文，バルクDELETE文の構文については，「付録G　JPQLのBNF」を参照してください。

8.17.9　JPQL使用時の注意事項

ここでは，JPQL使用時の注意事項について説明します。

(1)　null値の注意事項

クエリ結果のnull値

クエリの結果の値が，null値を持つ関連フィールドまたはステートフィールドに対応する場合，そのnull値がクエリメソッドの結果として返されます。

IS NOT NULLの構文は，クエリの結果の集合からnull値を除去するために使用できます。

Javaの数値系プリミティブ型によって定義されるフィールドには，クエリの結果としてnull値を生成できません。

比較，条件式でのnull値

参照の対象がデータベースに存在しない場合，その値はnullとみなされます。null値を検索するには，比較条件IS NULLおよびIS NOT NULLだけが使用できます。

null値をIS NULLやIS NOT NULL以外の条件で使用して，その結果がnull値に依存する場合，結果はunknownになります。

null値の比較または算術操作の結果は，常にunknown値になります。

二つのnull値の比較結果はunknown値になります。

unknown値のある比較または算術操作の結果は，常にunknown値になります。

boolean演算子は3値論理を使用します。ANDの場合，ORの場合，およびNOTの場合の3値論理式をそれぞれ表に示します。

表8‒24　ANDの3値論理式（A AND Bの結果）

A

B

True

False

Unknown

True

True

False

Unknown

False

False

False

False

Unknown

Unknown

False

Unknown

表8‒25　ORの3値論理式（A OR Bの結果）

A

B

True

False

Unknown

True

True

True

True

False

True

False

Unknown

Unknown

True

Unknown

Unknown

表8‒26　NOTの3値論理式（NOT Aの結果）

A

NOT Aの結果

True

False

False

True

Unknown

Unknown

(2)　HiRDBでJPQLを使用する場合の注意事項

次に示すJPQLの関数の引数に，位置パラメタや名前パラメタを指定することはできません。

TRIM，SQRT，ABS，LENGTH，LOWER，MOD，LOCATE，UPPER，CONCAT，SUBSTRING，IS [NOT] NULL

これらの関数の引数に位置パラメタや名前パラメタを指定した場合，動作は保証されません。なお，位置パラメタや名前パラメタを指定した場合はHiRDBのSQL構文エラーとなり，SQLException例外を含んだPersistenceException例外をスローすることがあります。

これらの関数の機能を使用したい場合は，ネイティブクエリを使用してください。

四則演算子（＋，−，＊，／）の両側に？パラメタは指定できません。また，比較演算子（=，>，>=，<，<=，<>）の両側に？パラメタを指定したり，片側に？パラメタを指定したりしてもう一方にリテラルを指定することはできません。指定した場合の動作は保証されません。指定した場合はHiRDBのSQL構文エラーとなり，SQLException例外を含んだPersistenceException例外をスローすることがあります。

JPQLの中で四則演算や比較演算しないで，JPQLを使用する前に四則演算や比較演算の操作をしてからJPQLを使用するようにしてください。

HiRDBでJPQLを使用する場合に使用できないクエリの記述例を次に示します。

使用できない例1：関数の引数に位置パラメタを指定する

Query query1 = em.createQuery(
"SELECT  o FROM TestEntity o "+
                "WHERE o.name=TRIM(LEADING FROM ?1)")
              .setParameter(1, "  SatoTaro");

使用できない例2：四則演算子に位置パラメタを指定する

int no_A=2;
int no_B=4;
Query query2 = em.createQuery(
"SELECT  o FROM TestEntity o WHERE o.id = ?1 + ?2")
               .setParameter(1, no_A)
               .setParameter(2, no_B);

使用できない例3：比較演算子に位置パラメタを指定する

int cmp_no=3;
Query query3 = em.createQuery(
"SELECT  o FROM TestEntity o WHERE o.id = ?1 AND ?1 < 9")
               .setParameter(1, cmp_no);

8.17.10　クエリ使用時に発生する例外

CJPAプロバイダの場合，クエリ関連のアノテーションで文法的に間違いがあると，アプリケーションをデプロイするとき例外が発生します。また，クエリ関連のメソッドの引数が不正であったり，指定された文字列が有効なJPQLの文字列でなかったりすると，IllegalArgumentException例外が発生するか，クエリの実行が失敗します。

ネイティブクエリを使用しているデータベースのクエリに対して有効でない場合，または定義された結果のセットがクエリの結果と互換性がない場合，クエリの実行は失敗します。CJPAプロバイダでは，クエリの実行時にPersistenceException例外がスローされます。

(1)　EntityManager内のクエリ関連インタフェースのAPIで発生する例外

EntityManager内のクエリ関連インタフェースのAPIで発生する例外を次に示します。

createQueryメソッドのクエリ文字列が正しくない場合は，IllegalArgumentException例外がスローされます。

createNamedQueryメソッドに指定された名前でクエリが定義されていない場合は，IllegalArgumentException例外がスローされます。

(2)　QueryインタフェースのAPIで発生する例外

QueryインタフェースのAPIで発生する例外を次に示します。

getResultListメソッドで，JPQLのUPDATE文またはDELETE文が呼び出された場合は，IllegalStateException例外がスローされます。

getSingleResultメソッドで，クエリ結果がない場合は，NoResultException例外がスローされます。なお，クエリ結果が二つ以上ある場合は，NonUniqueResultException例外がスローされます。JPQLのUPDATE文，またはDELETE文が呼び出された場合は，IllegalStateException例外がスローされます。

executeUpdateメソッドで，JPQLのSELECT文が呼び出された場合は，IllegalStateException例外がスローされます。このとき，トランザクションがない場合は，TransactionRequiredException例外がスローされます。

setHintメソッドの第2引数が実装に対して正しくない場合は，IllegalArgumentException例外がスローされます。

setParameterメソッドの引数の位置がクエリの位置パラメタと一致しない場合，または引数のパラメタ名がクエリ文字列のパラメタと一致しない場合は，IllegalArgumentException例外がスローされます。

setMaxResultsまたはsetFirstResultメソッドの引数が負数の場合は，IllegalArgumentException例外がスローされます。

なお，APIの詳細については，Javaのドキュメントを参照してください。

8.18　persistence.xmlの定義

この節では，persistence.xmlの定義について，CJPAプロバイダ独自の機能であるエンティティオブジェクトのキャッシュ機能の定義と，データソースの指定の注意を説明します。

8.18.1　エンティティオブジェクトのキャッシュ機能の定義

CJPAプロバイダで提供するエンティティオブジェクトのキャッシュ機能の定義は，persistence.xmlの<property>タグ内に指定します。persistence.xmlでのエンティティオブジェクトのキャッシュ機能の定義について次の表に示します。

表8‒27　persistence.xmlでのエンティティオブジェクトのキャッシュ機能の定義

指定するプロパティ

設定内容

cosminexus.jpa.cache.size.<ENTITY>

エンティティをキャッシュする場合のキャッシュサイズを指定します。

cosminexus.jpa.cache.size.default

エンティティをキャッシュする場合のキャッシュサイズのデフォルトを指定します。

cosminexus.jpa.cache.type.<ENTITY>

エンティティのキャッシュタイプを指定します。

cosminexus.jpa.cache.type.default

エンティティのキャッシュタイプのデフォルトを指定します。

cosminexus.jpa.target-database

接続するデータベースの名前を指定します。

タグの詳細は「12.2.2　<property>タグに指定できるCJPAプロバイダ独自のプロパティ」を参照してください。

参考

ここで説明しているプロパティは，CJPAプロバイダ独自のプロパティです。persistence.xmlには，このほかにJPA仕様で定義されたプロパティを指定することができます。ただし，CJPAプロバイダの場合，JPA仕様で規定されているjavaxから始まるプロパティは使用できません。

8.18.2　データソースの指定の注意

persistence.xmlでのデータソースの指定では，アプリケーションサーバの機能であるユーザ指定名前空間機能を使用して，リソースアダプタに別名を付けることができます。persistence.xmlの設定でリソースアダプタに別名を設定した場合は，Connector属性ファイルでもリソースアダプタの別名の定義が必要です。詳細については，「8.19　実行環境での設定」を参照してください。

8.19　実行環境での設定

CJPAプロバイダを使用する場合，J2EEサーバの設定およびDB Connectorの設定が必要です。

8.19.1　J2EEサーバの設定

J2EEサーバの設定は，簡易構築定義ファイルで実施します。CJPAプロバイダが出力するログファイルの設定は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

簡易構築定義ファイルでのCJPAプロバイダが出力するログファイルの設定について次の表に示します。

表8‒28　簡易構築定義ファイルでのCJPAプロバイダが出力するログファイルの設定

指定するパラメタ

設定内容

ejbserver.logger.channels.define.JPAOperationLogFile.filenum

稼働ログの面数を指定します。

ejbserver.logger.channels.define.JPAMaintenanceLogFile.filenum

保守ログの面数を指定します。

ejbserver.logger.channels.define.JPAOperationLogFile.filesize

稼働ログのサイズを指定します。

ejbserver.logger.channels.define.JPAMaintenanceLogFile.filesize

保守ログのサイズを指定します。

cosminexus.jpa.logging.level.operation.<category>

稼働ログのログレベルを指定します。

簡易構築定義ファイルおよび指定するパラメタの詳細は，「11.2.1　J2EEサーバ用ユーザプロパティを設定するパラメタ」を参照してください。

8.19.2　DB Connectorの設定

DB Connectorの設定は，サーバ管理コマンドおよびConnector属性ファイルで実施します。

Connector属性ファイルでの設定について次の表に示します。

表8‒29　Connector属性ファイルでの設定

指定するタグ

設定内容

<resource-external-property>−<optional-name>タグ

persistence.xmlのデータソースの指定でリソースアダプタの別名を使用している場合，リソースアダプタの別名を設定します。persistence.xmlでリソースアダプタの別名を使用しない場合は設定不要です。

<resource-external-property>−<res-auth>タグ

persistence.xmlのデータソースの指定でリソースアダプタの別名を使用している場合，リソースの認証方式として必ず「Container」を指定してください。

<resource-external-property>−<res-sharing-scope>タグ

persistence.xmlのデータソースの指定でリソースアダプタの別名を使用している場合，リソース接続を共有するかどうかの指定として必ず「Shareable」を指定してください。

<property>−<property-name>タグ

<property>−<property-value>タグ

データベースへの接続情報を指定します。

ユーザ名の指定

<property-name>タグにUserを，<property-value>タグにデータベース接続で使用するユーザ名を指定します。

パスワードの指定

<property-name>タグにPasswordを，<property-value>タグにデータベース接続で使用するパスワードを指定します。

<connection-definition>−<transaction-support>タグ

トランザクションのサポートレベルを指定します。ここに指定する値は，persistence.xmlの<persistence-unit>タグのtransaction-type属性に指定した値と合わせてください。

Connector属性ファイルおよび指定するタグの詳細は「19.6　Connector属性ファイル」を参照してください。

8.20　アプリケーション開発時の注意事項

8.20.1　Cosminexus 09-60から11-30の環境，またはCosminexus 11-40以降かつJDK 11を使用している環境で，@OneToOneおよび@ManyToOneでのLAZYフェッチを使用する場合の注意事項

Cosminexus 09-60から11-30の環境，またはCosminexus 11-40以降かつJDK 11を使用している環境で，アプリケーションを開発する場合，次の条件が重なるエンティティクラスはJava SE 6のソースファイルとして作成してください。またアプリケーションコンパイル時にJava SE 6のクラスファイルを生成するように設定し，コンパイルしてください。

エンティティクラスに@OneToOneまたは@ManyToOneが含まれる。

@OneToOneまたは@ManyToOneのfetch属性にFetchType.LAZYを指定している。

注　javacコマンドを使用してコンパイルする場合，「-target」および「-source」を使用することで，Java SE 6のクラスファイルを生成できます。

8.21　JPAアプリケーションでトラブルが発生した場合

JPAを使用したアプリケーションでトラブルが発生した場合の解析手順について説明します。

ここでは，代表的な障害の例とその場合の障害原因の解析手順を説明します。

なお，CJPAプロバイダが出力する各ログ間の情報は，時刻，スレッドID／プロセスID，およびPersistenceUnit名を基にして対応づけます。取得したログでの原因の特定ができない場合で，再現性があるときには，ログレベルを上げて資料を取得してください。

8.21.1　ユーザアプリケーションでの例外発生

ユーザアプリケーションで例外が発生した場合のユーザが実施する解析手順を説明します。例外が発生するタイミングは，アプリケーションの起動時（デプロイを含む）またはアプリケーションの実行時が考えられます。それぞれのタイミングで例外が発生したときの解析手順について説明します。

(1)　アプリケーション起動時の例外発生

アプリケーションの起動時に例外が発生した場合の解析手順を次に示します。

メッセージログを確認する。

メッセージログに出力されたメッセージを参照します。メッセージマニュアルを参照して，出力されたメッセージIDの対処方法を確認します。また，対策を検討します。

アプリケーションの定義を確認する。

メッセージログの内容に従って，アプリケーション内のアノテーションの定義情報，persistence.xml，O/Rマッピングファイルの設定内容を見直し，設定内容に問題がないかどうかを確認してください。設定内容の確認で原因が判明しない場合，出力されたメッセージの対処方法が保守員連絡となっている場合は，保守員に連絡してください。

(2)　アプリケーション実行時の例外発生

アプリケーション実行時に例外が発生した場合の解析手順を次に示します。

メッセージログを確認する。

メッセージログに出力されたメッセージから障害の事象を確認します。メッセージについては，マニュアル「アプリケーションサーバ メッセージ(構築／運用／開発用)」を参照してください。

例外ログを確認する。

例外ログに出力されたスタックトレースから，例外が発生した個所を特定します。例外が発生した原因がアプリケーションの処理内容に問題があるかどうかを確認します。アプリケーションの処理に問題がある場合は，アプリケーションを修正してください。

メッセージログの対処方法が保守員連絡になっている場合，アプリケーションの処理に問題がない場合などの原因が判明しないときには，保守員に連絡してください。

8.21.2　性能面での障害発生

特定の処理に時間が掛かっているなど，性能面で障害が発生した場合の解析手順を説明します。性能面で問題が発生するタイミングは，アプリケーション起動時またはアプリケーションの実行時が考えられます。

アプリケーションの起動時に性能面で問題がある場合には，保守員に連絡してください。アプリケーションの実行時に性能面で問題がある場合には，次に示す手順で問題の個所を特定してください。

PRFトレースを確認する。

PRFトレースの内容から処理に時間が掛かっている個所を特定します。ユーザ実装個所とCJPAプロバイダのどちらに障害の原因があるかを特定します。ユーザ実装個所に問題がある場合にはアプリケーションを修正するなどの対処を実施してください。CJPAプロバイダの内部処理で処理に時間が掛かっている場合には保守員に連絡してください。

稼働ログを確認する。

発行したSQLを確認したい場合には，稼働ログを確認します。

例えば，次に示す場合などに該当するかどうかは，発行しているSQLを参照することで確認できます。

継承戦略にJOINEDを利用したため，エンティティの読み込みでJOIN操作が多発している。

コレクションで管理しているエンティティを操作したため，その延長で各要素に対してSELECTが発生している。

なお，CJPAプロバイダで出力される稼働ログについては，「15.1.1　CJPAプロバイダの稼働ログ」を参照してください。

8.21.3　トラブルシューティングで使用する資料

システムで障害が発生した場合，CJPAプロバイダで必要とするトラブルシューティングの資料と資料の取得元を次の表に示します。

表8‒30　CJPAプロバイダで必要とするトラブルシューティングの資料と資料の取得元

トラブルシューティング資料

取得元

資料のファイル名称

メッセージログ

snapshot(1次)

メッセージログ

例外ログ

snapshot(1次)

障害発生時の例外情報

CJPAプロバイダの稼働ログ

snapshot(1次)

CJPAの稼働ログ

J2EEサーバの定義情報

snapshot(1次)

J2EEサーバ用オプション定義ファイル

J2EEサーバ用ユーザプロパティファイル

J2EEサーバ用セキュリティポリシーファイル

J2EEサーバの作業ディレクトリに含まれるアプリケーションの定義情報

persistence.xml

snapshot(2次)

EJBサーバ作業ディレクトリの内容

Webコンテナ作業ディレクトリの内容

O/Rマッピングファイル

EJB，WARの属性ファイル

DB ConnectorのConnector属性ファイル

snapshot(2次)

Webコンテナ作業ディレクトリの内容

DB Connectorのログ

snapshot(1次)

J2EEリソースアダプタとしてデプロイして使用するリソースアダプタの稼働ログ

性能解析トレース

snapshot(1次)

PRFデーモンおよびPRFコマンドのログ

J2EEサーバのスレッドダンプ

スレッドダンプ取得コマンド

接続するデータベースのSQLトレース

（ただし，トレース情報を採取している場合だけ）

HiRDBの場合

SQLトレース

マニュアル「HiRDB SQLリファレンス」を参照してください。

Oracleの場合

SQLトレースinit.oraでsql_trace=trueと設定時に取得されるトレースファイル

Oracleのマニュアルを参照してください。

8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲

javax.persistenceパッケージに含まれるアノテーションの一覧およびアノテーションを指定する際の注意事項について説明します。

なお，マッピング情報はアノテーションの代わりにO/Rマッピングファイルで指定することもできます。アノテーションとO/Rマッピングファイルとの対応については，「8.22.59　アノテーションとO/Rマッピングとの対応」を参照してください。

アノテーションを指定する際の注意事項

アプリケーションサーバのJPA機能では，DDL出力機能に関連する属性に対応していません。

アノテーションで同じカラム名を複数指定する場合は，大文字および小文字をそろえて指定してください。

フィールド名またはメソッド名をカラム名に割り当てた場合，アプリケーションサーバのJPA機能では文字列を大文字として扱います。対応するアノテーションでカラム名を指定する場合は，大文字にしてください。

アクセスタイプは，アノテーションを付与する場所によって決まります。ただし，アクセスタイプがフィールドとプロパティで混在した場合は，フィールドの設定が有効になります。

プロパティ名は，アクセサメソッドのgetまたはset（is）を除いた文字列によって次のように決まります。

・最初の二文字が大文字の場合，そのままの文字列になります。

・最初の二文字が大文字ではない場合，最初の文字を小文字に変換した文字列になります。

・一文字の場合，最初の文字を小文字に変換した文字列になります。

アノテーション一覧

アノテーションの区分

アノテーション名

概要

エンティティのアノテーション

@Entity

クラスがエンティティであることを示します。

テーブル・カラム関連のアノテーション

@Column

永続化フィールドまたは永続化プロパティと，データベース上のカラムとのマッピングを指定します。

@JoinColumn

エンティティクラス間の関連づけで，結合表のための外部キーカラムまたは外部キーカラムから参照された，結合先テーブルのカラムを指定します。

@JoinColumns

@JoinColumnを複数同時に記述する場合に使用します。

@JoinTable

次のクラスに設定する結合表を指定するアノテーションです。

ManyToManyリレーションシップを指定する場合の所有者側のクラス

片方向のOneToManyリレーションシップを持つクラス

@PrimaryKeyJoinColumn

ほかのテーブルと結合する場合に，外部キーとして使われるカラムを指定します。

@PrimaryKeyJoinColumns

@PrimaryKeyJoinColumnを複数同時に記述する場合に使用します。

@SecondaryTable

エンティティクラスにセカンダリテーブルを指定します。

@SecondaryTables

@SecondaryTableを複数同時に記述する場合に使用します。

@Table

エンティティクラスにプライマリテーブルを指定します。

@UniqueConstraint

プライマリテーブルまたはセカンダリテーブルに対して，CREATE文を生成する場合にユニーク制約を含めることを指定します。

なお，このアノテーションは，CJPAプロバイダには対応していません。

ID関連のアノテーション

@EmbeddedId

埋め込み可能クラスの複合プライマリキーであることを指定します。

@GeneratedValue

プライマリキーカラムにユニークな値を自動で生成，付与する方法を指定します。

@Id

エンティティクラスのプライマリキーのプロパティ，またはフィールドであることを指定します。

@IdClass

エンティティクラスの複数のフィールドまたはプロパティへマップされた複合プライマリキークラスを指定します。

@SequenceGenerator

プライマリキーを作成するシーケンスジェネレータの設定を指定します。

@TableGenerator

プライマリキーを作成するジェネレータの設定を指定します。

ロックのアノテーション

@Version

楽観的ロック機能を使用するために用いるversionフィールドまたはversionプロパティを指定します。

マッピング関連のアノテーション

@Basic

最も単純なデータベースのカラムへのマッピングの型を示します。

@Embeddable

埋め込みクラスであることを指定します。

@Embedded

埋め込み先のエンティティクラス内で，埋め込みクラスのインスタンス値を示す永続化プロパティまたは永続化フィールドであることを指定します。

@Enumerated

永続化フィールドまたは永続化プロパティを列挙型として指定します。

@Lob

データベースがサポートしているlargeオブジェクト型の永続化フィールドまたは永続化プロパティであることを指定します。

@MapKey

OneToManyリレーションシップ，またはManyToManyリレーションシップで，被所有者側のエンティティクラスがjava.util.Map型で示される場合にマップ内のオブジェクト識別に用いられるマップキーを指定します。

@OrderBy

エンティティの情報を取得するとき，コレクションが評価した順番を指定します。

@Temporal

時刻を表す型（java.util.Dateおよびjava.util.Calendar）を持つ永続化プロパティまたは永続化フィールドに指定します。

@Transient

永続化しないエンティティクラス，マップドスーパークラス，または埋め込みクラスのフィールドまたはプロパティであることを指定します。

リレーション関連のアノテーション

@ManyToMany

指定したクラスがManyToManyリレーションシップであることを示し，所有者側のエンティティクラスから被所有者側のエンティティクラスへの複数の関連を指定します。

@ManyToOne

指定したクラスがManyToOneリレーションシップであることを示し，被所有者側のエンティティクラスへの関連を指定します。

@OneToMany

指定したクラスがOneToManyリレーションシップであることを示し，所有者側のエンティティクラスから被所有者側のエンティティクラスへの複数の関連を指定します。

@OneToOne

指定したクラスがOneToOneリレーションシップであることを示し，エンティティクラス間の一つの関連を指定します。

継承・オーバーライド関連のアノテーション

@AssociationOverride

マップドスーパークラスや埋め込みクラスで指定された，ManyToOneリレーションシップまたはOneToOneリレーションシップで使用する設定をオーバーライドします。

@AssociationOverrides

@AssociationOverrideを複数同時に記述する場合に使用します。

@AttributeOverride

次に示すマッピング情報をオーバーライドします。

@Basicが指定された（またはデフォルトで適用された）プロパティ，フィールド

@Idで指定されたプロパティ，フィールド

@AttributeOverrides

@AttributeOverrideを複数同時に記述する場合に使用します。

@DiscriminatorColumn

SINGLE_TABLE戦略またはJOINED戦略で使用する識別用カラムを指定します。

エンティティクラスの継承で，スーパークラスとなるエンティティクラスに付与します。

@DiscriminatorValue

SINGLE_TABLE戦略またはJOINED戦略で使用する識別用カラムの値を指定します。

@Inheritance

エンティティクラス階層で使われる継承マッピング戦略を指定します。

@MappedSuperclass

マップドスーパークラスであることを指定します。

クエリ関連のアノテーション

@ColumnResult

SQLのクエリ結果をエンティティクラスとマッピングするためのカラムを指定します。

@EntityResult

SQLのクエリ結果をマッピングするエンティティクラスを指定します。

@FieldResult

SQLのクエリ結果をマッピングするフィールドを指定します。

@NamedNativeQueries

@NamedNativeQueryを複数同時に記述する場合に使用します。

@NamedNativeQuery

SQLで名前付きクエリを指定します。

@NamedQueries

@NamedQueryを複数同時に記述する場合に使用します。

@NamedQuery

JPQLの名前付きクエリを指定します。

@QueryHint

データベース固有のクエリのヒントを指定します。

@SqlResultSetMapping

SQLのクエリの結果セットマッピングを指定します。

@SqlResultSetMappings

@SqlResultSetMappingを複数同時に記述する場合に使用します。

イベント・コールバック関連のアノテーション※

@EntityListeners

エンティティクラスまたはマップドスーパークラスで使用されるコールバックリスナクラスを指定します。

@ExcludeDefaultListeners

次に示すクラスに対して，デフォルトリスナを抑止するアノテーションです。

エンティティクラス

マップドスーパークラス

エンティティクラスまたはマップドスーパークラスのサブクラス

@ExcludeSuperclassListeners

次に示すクラスに対して，スーパークラスリスナを抑止するアノテーションです。

エンティティクラス

マップドスーパークラス

エンティティクラスまたはマップドスーパークラスのサブクラス

@PostLoad

データベースにSELECT文を発行したあとに呼び出されるコールバックメソッドであることを示すアノテーションです。

@PostPersist

データベースにINSERT文を発行したあとに呼び出されるコールバックメソッドであることを示すアノテーションです。

@PostRemove

データベースにDELETE文を発行したあとに呼び出されるコールバックメソッドであることを示すアノテーションです。

@PostUpdate

データベースにUPDATE文を発行したあとに呼び出されるコールバックメソッドであることを示すアノテーションです。

@PrePersist

データベースにINSERT文を発行する前に呼び出されるコールバックメソッドであることを示すアノテーションです。

@PreRemove

データベースにDELETE文を発行する前に呼び出されるコールバックメソッドであることを示すアノテーションです。

@PreUpdate

データベースにUPDATE文を発行する前に呼び出されるコールバックメソッドであることを示すアノテーションです。

EntityManagerとEntityManagerFactoryのリファレンス関連のアノテーション

@PersistenceContext

コンテナ管理のEntityManagerを定義します。詳細はマニュアル「アプリケーションサーバ リファレンス API編」の「2.7　javax.persistenceパッケージ」を参照してください。

@PersistenceContexts

@PersistenceContextを複数同時に記述する場合に使用します。詳細はマニュアル「アプリケーションサーバ リファレンス API編」の「2.7　javax.persistenceパッケージ」を参照してください。

@PersistenceProperty

コンテナ管理のEntityManagerにプロパティを設定します。詳細はマニュアル「アプリケーションサーバ リファレンス API編」の「2.7　javax.persistenceパッケージ」を参照してください。

@PersistenceUnit

EntityManagerFactoryへの永続化ユニットを定義します。詳細はマニュアル「アプリケーションサーバ リファレンス API編」の「2.7　javax.persistenceパッケージ」を参照してください。

@PersistenceUnits

@PersistenceUnitを複数同時に記述する場合に使用します。詳細はマニュアル「アプリケーションサーバ リファレンス API編」の「2.7　javax.persistenceパッケージ」を参照してください。

注※　コールバックメソッドの詳細については，「8.15　コールバックメソッドの指定方法」を参照してください。

8.22.1　@AssociationOverride

(1)　説明

マップドスーパークラスや埋め込みクラスで指定されたManyToOneリレーションシップまたはOneToOneリレーションシップで使用する設定をオーバーライドするアノテーションです。

@AssociationOverrideが指定されていない場合，外部キーカラムはオリジナルマッピングと同様にマッピングされます。

適用可能要素は，クラス，メソッド，およびフィールドです。

(2)　属性

@AssociationOverrideの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

オーバーライドする関連マッピングを持つフィールドまたはプロパティの名前を指定する属性です。

joinColumns

必須

＠JoinColumnの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

オーバーライドする関連マッピングを持つフィールドまたはプロパティの名前を指定する属性です。

デフォルト値

なし

(b)　joinColumns属性

型

JoinColumn[]

説明

＠JoinColumnの配列を指定する属性です。

マッピングの型はマップドスーパークラスまたは埋め込みクラスの定義が適用されます。

指定できる値は，@JoinColumnの配列で指定できる範囲です。詳細は，「8.22.24　@JoinColumn」を参照してください。

デフォルト値

なし

8.22.2　@AssociationOverrides

(1)　説明

@AssociationOverrideを複数同時に記述する場合に指定するアノテーションです。

適用可能要素は，クラス，メソッド，およびフィールドです。

(2)　属性

@AssociationOverridesの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

@AssociationOverrideの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

AssociationOverride[]

説明

@AssociationOverrideの配列を指定する属性です。

指定できる値は，@AssociationOverrideの配列で指定できる範囲です。詳細は，「8.22.1　@AssociationOverride」を参照してください。

デフォルト値

なし

8.22.3　@AttributeOverride

(1)　説明

次に示すマッピング情報をオーバーライドするアノテーションです。

@Basicで指定した（デフォルトが適用された）プロパティまたはフィールド

デフォルトが適用されたプロパティまたはフィールド

@Idで指定されたプロパティまたはフィールド

マップドスーパークラスや埋め込みクラスに定義された@Columnの設定をオーバーライドするために，マップドスーパークラスを継承したエンティティクラスや埋め込みクラスのフィールドまたはプロパティに適用します。

@AttributeOverrideが指定されていない場合，カラムはオーバーライド前のオリジナルマッピングでマップされます。

継承関係を持たない単体のエンティティクラスに@AttributeOverrideを定義した場合，動作はしますが動作の保証はできません。

適用可能要素は，クラス，メソッド，およびフィールドです。

(2)　属性

@AttributeOverrideの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

マッピングがオーバーライドされるフィールドまたはプロパティの名前を指定する属性です。

column

必須

オーバーライドする＠Columnを指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

マッピングがオーバーライドされるフィールドまたはプロパティの名前を指定する属性です。

デフォルト値

なし

(b)　column属性

型

Column

説明

オーバーライドする＠Columnを指定する属性です。

マッピングの型は埋め込み可能クラス，またはマップドスーパークラスの定義が適用されます。

指定できる値は，@Columnで指定できる範囲です。詳細は，「8.22.6　@Column」を参照してください。

デフォルト値

なし

8.22.4　@AttributeOverrides

(1)　説明

@AttributeOverrideを複数同時に記述する場合に指定するアノテーションです。

適用可能要素は，クラス，メソッド，およびフィールドです。

(2)　属性

@AttributeOverridesの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

@AttributeOverrideの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

AttributeOverride[]

説明

@AttributeOverrideの配列を指定する属性です。

指定できる値は，@AttributeOverrideの配列で指定できる範囲です。詳細は，「8.22.3　@AttributeOverride」を参照してください。

デフォルト値

なし

8.22.5　@Basic

(1)　説明

最も単純なデータベースのカラムへのマッピングの型を示すアノテーションです。

次に示す永続化する型のプロパティまたはインスタンス変数に適用できます。

Javaのプリミティブ型

プリミティブ型のラッパークラス

java.lang.String

java.math.BigInteger

java.math.BigDecimal

java.util.Date

java.util.Calendar

java.sql.Date

java.sql.Time

java.sql.Timestamp

byte[]

Byte[]

char[]

Character[]

enums

ユーザが定義するシリアライズ型

適用可能要素は，メソッドとフィールドです。

(2)　属性

@Basicの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

fetch

任意

フェッチ戦略の指定値を指定する属性です。

optional

任意

フィールドまたはプロパティにnull値を使用できるかどうかを指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　fetch属性

型

FetchType

説明

フェッチ戦略の指定値を指定する属性です。

指定できる値は，FetchType.EAGERまたはFetchType.LAZYです。

なお，CJPAプロバイダでは，fetch属性は無視され，デフォルトのFetchType.EAGERが常に適用されます。fetch属性の詳細は，「8.4.5　データベースとの同期」を参照してください。

デフォルト値

FetchType.EAGER

8.22.6　@Column

(1)　説明

永続化フィールドまたは永続化プロパティと，データベース上のカラムとのマッピングを指定するアノテーションです。

永続化プロパティまたは永続化フィールドに明示的に@Columnを指定しない場合でも，@Columnが指定されたように永続化フィールドまたは永続化プロパティは扱われます。この場合@Columnの各属性値にはデフォルト値が適用されます。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@Columnの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

任意

カラム名を指定する属性です。

unique

任意

プロパティがユニークキーであるかどうかを指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

nullable

任意

データベースのカラムにnull値を指定できるかどうかを指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

insertable

任意

@Columnで指定したカラムをSQLのINSERT文に含むかどうかを指定する属性です。

updatable

任意

@Columnで指定したカラムをSQLのUPDATE文に含むかどうかを指定する属性です。

columnDefinition

任意

CREATE文を出力するとき，カラムに付加する制約をDDLで記載する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

table

任意

カラムを含むテーブル名を指定する属性です。

length

任意

カラムの長さを指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

precision

任意

カラムの精度を指定する属性です。カラムが数値型の場合に指定します。

なお，この属性は，CJPAプロバイダには対応していません。

scale

任意

カラムのスケールを指定する属性です。カラムが数値型の場合に指定します。

なお，この属性は，CJPAプロバイダには対応していません。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

カラム名を指定する属性です。

指定できるカラム名は，データベースの仕様に依存します。

デフォルト値

このアノテーションを指定したプロパティ名またはフィールド名

(b)　insertable属性

型

boolean

説明

@Columnで指定したカラムをSQLのINSERT文に含むかどうかを指定する属性です。指定できる値は，trueまたはfalseです。

それぞれの値の意味は次のとおりです。

true：@Columnで指定したカラムをSQLのINSERT文に含みます。

false：@Columnで指定したカラムをSQLのINSERT文に含みません。

デフォルト値

true

(c)　updatable属性

型

boolean

説明

@Columnで指定したカラムをSQLのUPDATE文に含むかどうかを指定する属性です。指定できる値は，trueまたはfalseです。

それぞれの値の意味は次のとおりです。

true：@Columnで指定したカラムをSQLのUPDATE文に含みます。

false：@Columnで指定したカラムをSQLのUPDATE文に含みません。

デフォルト値

true

(d)　table属性

型

String

説明

カラムを含むテーブル名を指定します。

指定できるテーブル名は，データベースの仕様に依存します。

デフォルト値

プライマリテーブル名

8.22.7　@ColumnResult

(1)　説明

SQLのクエリ結果をエンティティクラスとマッピングするためのカラムを指定するアノテーションです。

適用可能要素は，@SqlResultSetMappingのcolumnsです。

(2)　属性

@ColumnResultの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

SELECT節のカラムの名またはカラムの別名を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

SELECT節のカラム名またはカラムの別名を指定する属性です。

指定できるカラム名は，データベースの仕様に依存します。

デフォルト値

なし

8.22.8　@DiscriminatorColumn

(1)　説明

SINGLE_TABLE戦略またはJOINED戦略で使用する識別用カラムを指定するアノテーションです。エンティティクラスの継承で，スーパークラスとなるエンティティクラスに付与します。

適用可能要素は，クラスです。

(2)　属性

@DiscriminatorColumnの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

任意

識別用カラム名を指定する属性です。

discriminatorType

任意

識別用カラムの型を指定する属性です。

columnDefinition

任意

CREATE文を出力するとき，識別用カラムに付加する制約をDDLで記載する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

length

任意

識別用カラムが文字列の場合，その長さを指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

識別用カラム名を指定する属性です。

指定できるカラム名は，データベースの仕様に依存します。

name属性の値は，@Columnのname属性と同じ値（大文字および小文字を合わせた値）を指定してください。

デフォルト値

"DTYPE"

(b)　discriminatorType属性

型

DiscriminatorType

説明

識別用カラムの型を指定する属性です。

指定できる値は，次のとおりです。

DiscriminatorType.STRING

DiscriminatorType.CHAR

DiscriminatorType.INTEGER

デフォルト値

DiscriminatorType.STRING

8.22.9　@DiscriminatorValue

(1)　説明

SINGLE_TABLE戦略またはJOINED戦略で使用する識別用カラムの値を指定するアノテーションです。スーパークラスまたはサブクラスに指定できます。

適用可能要素は，クラスです。

なお，次の点に注意して指定してください。

@DiscriminatorValueの設定は継承されません。@DiscriminatorValueをエンティティクラスごとに設定する必要があります。

@DiscriminatorValueの設定は，@DiscriminatorColumnのdiscriminatorTypeの型とlengthの長さに一致させる必要があります。

@DiscriminatorColumnのdiscriminatorTypeがINTEGERの場合は，次の点に注意してください。

@DiscriminatorValueには，先頭に0や空白を含まない整数だけを指定してください。

@DiscriminatorValueは省略できません。省略した場合の動作は保証しません。

@DiscriminatorColumnのdiscriminatorTypeがINTEGER以外の場合は，@DiscriminatorValueを省略できます。このとき，valueの値がエンティティのクラス名であるものとして動作します。

(2)　属性

@DiscriminatorValueの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

識別用のカラムに設定する値を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

String

説明

識別用カラムに設定する値を指定する属性です。

指定できる値は，識別用カラムの型に依存します。

デフォルト値

エンティティ名

8.22.10　@Embeddable

(1)　説明

埋め込みクラスであることを示すアノテーションです。

埋め込みクラスとは，エンティティクラス内にフィールドとして埋め込むことができるクラスのことです。

適用可能要素は，クラスです。

(2)　属性

@Embeddableの属性はありません。

8.22.11　@Embedded

(1)　説明

エンティティクラス内で，埋め込みクラスのインスタンス値を示す永続化プロパティまたは永続化フィールドであることを示すアノテーションです。

埋め込みクラス内で宣言されたカラムマッピングをオーバーライドしたい場合は，@AttributeOverrideまたは@AttributeOverridesを使用します。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@Embeddedの属性はありません。

8.22.12　@EmbeddedId

(1)　説明

埋め込みクラスの複合プライマリキーであることを示すアノテーションです。

エンティティが所有する埋め込み可能クラスの永続化プロパティまたは永続化フィールドに付与します。

@EmbeddedIdを利用する場合，@EmbeddedIdを複数指定したり，@EmbeddedId以外に@Idを指定したりしてはいけません。

@Transientを埋め込みクラスのフィールドに付与した場合，そのフィールドは複合プライマリキーの対象になりません。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@EmbeddedIdの属性はありません。

8.22.13　@Entity

(1)　説明

クラスがエンティティであることを示すアノテーションです。

エンティティクラスのクラス名は，パッケージ名を含まないクラス名になります。指定するときは，次の内容に注意してください。

エンティティ名は永続化ユニット内でユニークな名称にしてください。

JPQLの予約文字を設定してはいけません。設定した場合の動作は保証しません。

適用可能要素は，クラスです。

(2)　属性

@Entityの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

任意

エンティティクラスに対する論理的な名前を指定する属性です。なお，JPQLでは，抽象スキーマ名となります。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

エンティティクラスに対する論理的な名前を指定する属性です。なお，JPQLでは，抽象スキーマ名となります。

指定できる値は，JPQLの仕様に依存します。

デフォルト値

@Entityを指定したクラスのクラス名

8.22.14　@EntityListeners

(1)　説明

エンティティクラスまたはマップドスーパークラスで使用されるコールバックリスナクラスを指定するアノテーションです。

適用可能要素は，クラスです。

(2)　属性

@EntityListenersの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

コールバックリスナクラスを指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

Class[]

説明

コールバックリスナクラスを指定する属性です。

指定できる値は，クラスです。

デフォルト値

なし

8.22.15　@EntityResult

(1)　説明

SQLのクエリ結果をマッピングするエンティティクラスを指定するアノテーションです。

適用可能要素は，@SqlResultSetMappingのentities属性です。

(2)　属性

@EntityResultの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

entityClass

必須

結果のクラスを指定する属性です。

fields

任意

@FieldResultの配列を指定する属性です。

discriminatorColumn

任意

エンティティインスタンスの型を決定するSELECT節の中で，識別用カラムの名前または別名を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　entityClass属性

型

Class

説明

結果のクラスを指定する属性です。

指定できる値は，クラス名です。

デフォルト値

なし

(b)　fields属性

型

FieldResult[]

説明

@FieldResultの配列を指定する属性です。

指定できる値は，@FieldResultの配列で指定できる範囲です。詳細は，「8.22.19　@FieldResult」を参照してください。

デフォルト値

空の配列

(c)　discriminatorColumn属性

型

String

説明

エンティティインスタンスの型を決定するためのSELECT節の中で，識別用カラムの名前または別名を指定する属性です。

指定できる値は，テーブルに指定されたカラムの名前または別名です。

デフォルト値

空の文字列

8.22.16　@Enumerated

(1)　説明

永続化フィールドまたは永続化プロパティを列挙型として指定するアノテーションです。

@Basicとともに使用できます。列挙型にはORDINAL（数値型）とSTRING（文字列型）が指定できます。

次の場合，列挙型はORDINAL（数値型）が指定されます。

value属性に列挙される型が指定されていない場合

@Enumeratedが指定されていない場合

適用可能要素は，メソッドとフィールドです。

(2)　属性

@Enumeratedの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

任意

列挙型をマッピングするのに使われる型を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

EnumType

説明

列挙型をマッピングするのに使われる型を指定する属性です。

指定できる値は，次のどちらかの値です。

EnumType.ORDINAL：数値型

EnumType.STRING：文字列型

デフォルト値

EnumType.ORDINAL

8.22.17　@ExcludeDefaultListeners

(1)　説明

次に示すクラスに対して，デフォルトリスナを抑止するアノテーションです。

エンティティクラス

マップドスーパークラス

エンティティクラスまたはマップドスーパークラスのサブクラス

なお，デフォルトリスナを指定できるのは，XMLディスクリプタだけです。

適用可能要素は，クラスです。

(2)　属性

@ExcludeDefaultListenersの属性はありません。

8.22.18　@ExcludeSuperclassListeners

(1)　説明

次に示すクラスに対して，スーパークラスリスナを抑止するアノテーションです。

エンティティクラス

マップドスーパークラス

エンティティクラスまたはマップドスーパークラスのサブクラス

適用可能要素は，クラスです。

(2)　属性

@ExcludeSuperclassListenersの属性はありません。

8.22.19　@FieldResult

(1)　説明

SQLのクエリ結果をマッピングするフィールドを指定するアノテーションです。

適用可能要素は，@EntityResultのfield属性です。

(2)　属性

@FieldResultの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

クラスの永続化フィールドまたは永続化プロパティの名前を指定する属性です。

column

必須

SELECT節のカラム名またはカラムの別名を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

クラスの永続化フィールドまたは永続化プロパティの名前を指定する属性です。

デフォルト値

なし

(b)　column属性

型

String

説明

SELECT節のカラム名またはカラムの別名を指定する属性です。

指定できるカラム名または別名は，データベースの仕様に依存します。

デフォルト値

なし

8.22.20　@GeneratedValue

(1)　説明

プライマリキーカラムにユニークな値を自動で生成，付与する方法を指定するアノテーションです。@Idを持つエンティティクラスまたはマップドスーパークラスのプライマリキーのフィールドまたはプロパティに適用します。

プライマリキー値の生成方法には，次の4種類の方法があります。なお，選択する生成方法に基づいて，あらかじめ基礎テーブルやデータベースシーケンスオブジェクトを用意しておく必要があります。それぞれの生成方法の詳細は，strategy属性の説明を参照してください。

GenerationType.AUTO

GenerationType.IDENTITY

GenerationType.SEQUENCE

GenerationType.TABLE

適用可能要素は，メソッドとフィールドです。

(2)　属性

@GeneratedValueの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

strategy

任意

エンティティクラスのプライマリキー値を生成する方法を指定する属性です。

generator

任意

使用する@SequenceGeneratorまたは@TableGeneratorで設定されるname属性を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　strategy属性

型

GenerationType

説明

エンティティクラスのプライマリキー値を生成する方法を指定する属性です。

指定できる値は，次の4種類です。

GenerationType.AUTO

データベースごとに最も適切な手順を選択して，プライマリキー値を生成します。

データベースがOracleまたはHiRDBの場合は，GenerationType.TABLEと同じ処理をします。

GenerationType.IDENTITY

データベースのidentity列を利用して，プライマリキー値を生成します。

データベースがOracleの場合は，GenerationType.SEQUENCEと同じ処理をします。

データベースがHiRDBの場合は，GenerationType.TABLEと同じ処理をします。

GenerationType.SEQUENCE

データベースのシーケンスオブジェクトを使用して，プライマリキー値を生成します。

データベースがHiRDBの場合は，GenerationType.TABLEと同じ処理をします。

GenerationType.TABLE

プライマリキー値を保持しておくためのテーブルを使用して，プライマリキー値を生成します。

デフォルト値

GenerationType.AUTO

(b)　generator属性

型

String

説明

使用する@SequenceGeneratorまたは@TableGeneratorで設定されるname属性を指定する属性です。

デフォルト値

strategy属性の値によって，次の名前が仮定されます。

GenerationType.AUTOの場合

"SEQ_GEN"

GenerationType.SEQUENCEの場合

"SEQ_GEN_SEQUENCE"

GenerationType.TABLEの場合

"SEQ_GEN_TABLE"

8.22.21　@Id

(1)　説明

エンティティクラスのプライマリキーのプロパティまたはフィールドであることを示すアノテーションです。

@Idは，エンティティクラスまたはマップドスーパークラスで適用されます。

@Idを指定したフィールドまたはプロパティに対してマップされたデータベース上のカラムは，プライマリテーブルのプライマリキーカラムであると仮定されます。プライマリキーカラムのカラム名を@Columnを用いて指定していない場合，プライマリキーカラムのカラム名は@Idを指定したフィールドまたはプロパティの名前になります。

なお，@Idを指定したフィールドに@Versionを指定した場合は，@Idが無効になります。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@Idの属性はありません。

8.22.22　@IdClass

(1)　説明

エンティティクラスの複数のフィールドまたはプロパティへマップされた複合プライマリキークラスを指定するアノテーションです。

このアノテーションは，マップドスーパークラスまたはエンティティクラスに適用されます。

エンティティクラスのプライマリキーのフィールドまたはプロパティと，複合プライマリキークラスのフィールドまたはプロパティの名前と型は一致させる必要があります。このアノテーションで指定した名前および型は，@Idが付いたエンティティのプライマリキーのプロパティまたはフィールドの型および名前に対応させてください。

適用可能要素は，クラスです。

(2)　属性

@IdClassの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

複合プライマリキークラスを指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

Class

説明

複合プライマリキークラスを指定する属性です。

指定できる値は，クラス名です。

デフォルト値

なし

8.22.23　@Inheritance

(1)　説明

エンティティの継承階層で使われる継承マッピング戦略を指定するアノテーションです。

@Inheritanceは継承階層の親であるエンティティクラスに指定されます。

CJPAプロバイダで使用できる継承マッピング戦略には，次の2種類があります。

SINGLE_TABLE（クラス階層ごとの単体テーブル）

JOINED（結合サブクラス戦略）

継承マッピング戦略については，「8.13.2　継承マッピング戦略」を参照してください。

適用可能要素は，クラスです。

(2)　属性

@Inheritanceの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

strategy

任意

継承マッピング戦略の種類を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　strategy属性

型

InheritanceType

説明

エンティティで使用する継承マッピング戦略の種類を指定する属性です。

指定できる値は，次の2種類です。

InheritanceType.SINGLE_TABLE：継承階層にあるすべてのクラスを一つのテーブルにマッピングする戦略です。

InheritanceType.JOINED：継承階層の最上位（親クラス）は単一の表にマッピングされ，各サブクラスはサブクラス特有のマッピングをする戦略です。

デフォルト値

InheritanceType.SINGLE_TABLE

8.22.24　@JoinColumn

(1)　説明

エンティティクラス間の関連づけをする場合に，結合表のための外部キーカラムまたは外部キーカラムによって参照された，結合先テーブルのカラム名を指定するアノテーションです。必ず結合先テーブルのプライマリキーとなっているカラムを指定してください。

複数の外部キーカラムがある場合は@JoinColumnsを使用し，それぞれの関連に対して@JoinColumnを指定してください。なお，複数の@JoinColumnを指定した場合は，name属性およびreferencedColumnName属性をそれぞれのアノテーションで指定してください。

@JoinColumnを明示的に指定しない場合，関連を示す永続化プロパティまたは永続化フィールドに単体の外部キーカラムを指定しているように扱われます。また，@JoinColumnの各属性値にデフォルト値が適用されます。

また，一つのカラムがフィールドに対して行った変更と，カスケード操作の関連づけによる変更が同時に実施されたことによって，整合性が取れなくなる場合があります。このため，name属性およびreferencedColumnName属性に指定したカラムをエンティティのフィールドに定義する場合は，insertable属性およびupdatable属性をfalseに指定する必要があります。この指定によって，フィールドに対して行った変更だけがデータベースに反映されますが，カスケード操作の関連づけによる変更はデータベースに反映されません。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@JoinColumnの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

任意

対象テーブルを結合するために使用する外部キーカラム名を指定する属性です。

referencedColumnName

任意

name属性で指定した外部キーカラムによって参照された結合先テーブルのカラム名を指定する属性です。

unique

任意

プロパティがユニークキーであるかどうかを指定する属性です。

なお，この属性は，CJPAプロバイダでは対応していません。

nullable

任意

データベースのカラムにnull値を指定できるかどうかを指定する属性です。

なお，この属性は，CJPAプロバイダでは対応していません。

insertable

任意

@JoinColumnで指定したカラムをSQLのINSERT文に含むかどうか指定する属性です。

updatable

任意

@JoinColumnで指定したカラムをSQLのUPDATE文に含むかどうか指定する属性です。

columnDefinition

任意

CREATE文を出力する場合，外部カラムに追加する規約をDDLで記載する属性です。

なお，この属性は，CJPAプロバイダでは対応していません。

table

任意

外部キーカラムを含むテーブル名を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

対象テーブルを結合するために使用する外部キーカラム名を指定する属性です。

外部キーカラムは，エンティティのリレーションシップの種別ごとに存在する個所が異なります。エンティティのリレーションシップの種別ごとに外部キーカラムの存在個所を示します。

OneToOneリレーションシップまたはManyToOneリレーションシップの場合

自エンティティのテーブル内

ManyToManyリレーションシップの場合

@JoinTableの結合表内

なお，指定できる値は，データベースのカラム名の仕様に依存します。

デフォルト値

自エンティティ内に単体の外部キーカラムが指定され，name要素の値に何も指定しない場合

<自エンティティ内の関連プロパティまたはフィールドの名前>_<参照されるプライマリキー列の名前>

参照している関連プロパティやフィールドがない場合（例：@JoinTableを使用している場合）

<参照しているエンティティの名前>_<参照されるプライマリキー列の名前>

(b)　referencedColumnName属性

型

String

説明

name属性で指定した外部キーカラムによって参照された結合先テーブルのカラム名を指定する属性です。

結合先テーブルのカラム名は次の個所に存在します。

リレーションシップのアノテーションを使った場合

参照されるテーブル内

@JoinTableで使った場合

所有者側エンティティのエンティティテーブル内

注

結合が逆結合の一部で定義される場合は，被所有者側のエンティティクラスのテーブル内になります。

なお，指定できるカラム名は，データベースの仕様に依存します。

デフォルト値

外部キーによって参照されるテーブルのプライマリキーのカラム名

注

単体の外部キーカラムが指定される場合は，デフォルトを適用します。

(c)　insertable属性

型

boolean

説明

@JoinColumnで指定したカラムをSQLのINSERT文に含むかどうかを指定する属性です。指定できる値は，trueまたはfalseです。

それぞれの値の意味は次のとおりです。

true：@JoinColumnで指定したカラムをSQLのINSERT文に含みます。

false：@JoinColumnで指定したカラムをSQLのINSERT文に含みません。

デフォルト値

true

(d)　updatable属性

型

boolean

説明

@JoinColumnで指定したカラムをSQLのUPDATE文に含むかどうかを指定する属性です。指定できる値は，trueまたはfalseです。

それぞれの値の意味は次のとおりです。

true：@JoinColumnで指定したカラムをSQLのUPDATE文に含みます。

false：@JoinColumnで指定したカラムをSQLのUPDATE文に含みません。

デフォルト値

true

(e)　table属性

型

String

説明

外部キーカラムを含むテーブル名を指定する属性です。

指定できるテーブル名は，データベースの仕様に依存します。

デフォルト値

プライマリテーブル名

8.22.25　@JoinColumns

(1)　説明

同じ関連を示す@JoinColumnを複数同時に記述する場合に指定するアノテーションです。また，@JoinColumnsは複合外部キーのマッピングを定義します。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@JoinColumnsの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

@JoinColumnの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

JoinColumn[]

説明

@JoinColumnの配列を指定する属性です。

指定できる値は，@JoinColumnの配列で指定できる範囲です。

デフォルト値

なし

8.22.26　@JoinTable

(1)　説明

次のクラスに設定する結合表を指定するアノテーションです。

ManyToManyリレーションシップを指定する場合の所有者側のクラス

片方向のOneToManyリレーションシップを持つクラス

name属性が指定されない場合，結合表の名前は次の名称になります。

<所有者側テーブル名>_<被所有者側テーブル名>

適用可能要素は，メソッドとフィールドです。

(2)　属性

@JoinTableの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

任意

結合表のテーブル名を指定する属性です。

catalog

任意

結合表のテーブルのカタログ名を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

schema

任意

結合表のテーブルのスキーマ名を指定する属性です。

joinColumns

任意

所有者側エンティティのプライマリテーブルを参照する，結合表の外部キーカラムを指定する属性です。

inverseJoinColumns

任意

被所有者側エンティティのプライマリテーブルを参照する，結合表の外部キーカラムを指定する属性です。

uniqueConstraints

任意

テーブルのユニーク規制を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

結合表のテーブル名を指定する属性です。

指定できるテーブル名は，データベースの仕様に依存します。

デフォルト値

<所有者側テーブル名>_<被所有者側テーブル名>

(b)　schema属性

型

String

説明

テーブルのスキーマ名を指定する属性です。

指定できる値は，データベースのスキーマ名の仕様に依存します。

デフォルト値

使用するデータベースのデフォルトのスキーマ

(c)　joinColumns属性

型

JoinColumn[]

説明

所有者側エンティティのプライマリテーブルを参照する，結合表の外部キーカラムを指定する属性です。@JoinColumnの配列を指定します。@JoinColumnのname属性には結合表の外部キーカラム名，referencedColumnName属性には所有者側の参照カラム名をそれぞれ指定します。

指定できるカラム名は，データベースの仕様に依存します。

デフォルト値

@JoinColumnの外部キー

(d)　inverseJoinColumns属性

型

JoinColumn[]

説明

被所有者側エンティティのプライマリテーブルを参照する，結合表の外部キーカラムを指定する属性です。@JoinColumnの配列を指定します。@JoinColumnのname属性には結合表の外部キーカラム名，referencedColumnName属性には外部キーカラムで参照された結合先テーブルのカラムをそれぞれ指定します。

指定できる値は，データベースのカラム名の仕様に依存します。

デフォルト値

@JoinColumnの外部キーカラム

8.22.27　@Lob

(1)　説明

データベースがサポートしているlargeオブジェクト型の永続化フィールドまたは永続化プロパティであることを指定するアノテーションです。@Basicとともに使用できます。

@Lobにはバイナリ型（Blob）とキャラクタ型（Clob）があります。@Lobの型は，永続化フィールドまたは永続化プロパティの型によって決まります。文字列およびキャラクタ型の場合はClobになり，そのほかの場合はBlobになります。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@Lobの属性はありません。

8.22.28　@ManyToMany

(1)　説明

ManyToManyリレーションシップの関係を持つ所有者側のエンティティクラスから被所有者側のエンティティクラスへの複数の関連を指定するアノテーションです。

ManyToManyリレーションシップは，双方向，単方向に関係なく，所有者側と被所有者側を持ちます。関係が双方向の場合，結合表の指定はどちらの側でも指定できます。

なお，Genericsを使用してCollection要素型が指定されている場合，被所有者側のエンティティクラスを指定する必要はありません。そのほかの場合は，必ず指定してください。

また，@ManyToManyを指定した場合は，次に示すアノテーションの設定に注意してください。

@OneToManyのための同じアノテーションの属性は，@ManyToManyと同じ属性を持ちます。

所有者側と被所有者側のクラスで@ManyToManyを定義したプロパティまたはフィールドが同じ名前の場合は，@JoinTableのデフォルト設定（joinColumns属性，inverseJoinColumns属性の指定がない状態）を使用しないでください。

双方向関係の場合には，所有者側の情報を基に結合表の値が更新されます。mappedBy属性を指定したエンティティクラスでマッピング情報を変更しても，その情報は結合表には反映されません。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@ManyToManyの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

targetEntity

任意

被所有者側のエンティティクラスを指定する属性です。

cascade

任意

カスケード対象となるオペレーションを指定する属性です。

fetch

任意

フェッチ戦略の指定値を指定する属性です。

mappedBy

任意

被所有者側のエンティティクラスの要素に付与して，所有者側のエンティティクラスで関係を保持しているフィールドまたはプロパティの名前を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　targetEntity属性

型

Class

説明

被所有者側のエンティティクラスを指定する属性です。

Genericsを使って定義されているコレクションプロパティの場合は，任意で指定します。それ以外の場合は必ず指定してください。

デフォルト値

コレクションのパラメタ化された型

注　Genericsを使って定義されているときにだけ設定されます。

(b)　cascade属性

型

CascadeType[]

説明

カスケード対象となるオペレーションを指定する属性です。

指定できる値を次に示します。

CascadeType.ALL：所有者側のエンティティクラスのpersist，remove，merge，refreshの操作が関連先にカスケードされます。

CascadeType.MERGE：所有者側のエンティティクラスのmerge操作が関連先にカスケードされます。

CascadeType.PERSIST：所有者側のエンティティクラスのpersist操作が関連先にカスケードされます。

CascadeType.REFRESH：所有者側のエンティティクラスのrefresh操作が関連先にカスケードされます。

CascadeType.REMOVE：所有者側のエンティティクラスのremove操作が関連先にカスケードされます。

デフォルト値

カスケード対象なし

(c)　fetch属性

型

FetchType

説明

データベースからのデータのフェッチ戦略を定義する属性です。フェッチ戦略については，「8.4.5　データベースとの同期」を参照してください。

指定できる値は，次の2種類です。

EAGER戦略：データがEAGERにフェッチされなければならない要求

LAZY戦略：データが最初にアクセスされるときに，LAZYにフェッチされる要求

デフォルト値

FetchType.LAZY

(d)　mappedBy属性

型

String

説明

被所有者側のエンティティクラスの要素に付与し，所有者側のエンティティクラスで関係を保持しているフィールドまたはプロパティの名前を指定する属性です。

この属性を指定した場合，関係は双方向になります。双方向関係の場合には所有者側の情報を基に結合表の値は更新されます。被所有者側のエンティティクラス（mappedBy属性を指定したエンティティクラス）でマッピング情報を変更しても，その情報は結合表には反映されません。

デフォルト値

なし

8.22.29　@ManyToOne

(1)　説明

@ManayToOneが指定されたクラスがManyToOneリレーションシップであることを示し，所有者側のエンティティクラスから被所有者側のエンティティクラスへの関連を指定するアノテーションです。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@ManyToOneの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

targetEntity

任意

被所有者側のエンティティクラスを指定する属性です。

cascade

任意

カスケード対象となるオペレーションを指定する属性です。

fetch

任意

フェッチ戦略の指定値を指定する属性です。

optional

任意

すべての非プリミティブ型のフィールドおよびプロパティの値にnull値を設定できるかどうかを指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　targetEntity属性

型

Class

説明

被所有者側のエンティティクラスを指定する属性です。

デフォルト値

アノテーションが付与されているフィールドやプロパティの型

(b)　cascade属性

型

CascadeType[]

説明

カスケード対象となるオペレーションを指定する属性です。

指定できる値を次に示します。

CascadeType.ALL：所有者側のエンティティクラスのpersist，remove，merge，およびrefreshの操作が関連先にカスケードされます。

CascadeType.MERGE：所有者側のエンティティクラスのmerge操作が関連先にカスケードされます。

CascadeType.PERSIST：所有者側のエンティティクラスのpersist操作が関連先にカスケードされます。

CascadeType.REFRESH：所有者側のエンティティクラスのrefresh操作が関連先にカスケードされます。

CascadeType.REMOVE：所有者側のエンティティクラスのremove操作が関連先にカスケードされます。

デフォルト値

カスケード対象なし

(c)　fetch属性

型

FetchType

説明

データベースからのデータのフェッチ戦略を定義する属性です。フェッチ戦略については，「8.4.5　データベースとの同期」を参照してください。

指定できる値は，次の2種類です。

EAGER戦略：データがEAGERにフェッチされなければならない要求

LAZY戦略：データが最初にアクセスされるときに，LAZYにフェッチされる要求

デフォルト値

FetchType.EAGER

(d)　optional属性

型

boolean

説明

すべての非プリミティブ型のフィールドおよびプロパティの値にnull値を指定できるかどうかを指定する属性です。指定できる値は，次のとおりです。

true：すべての非プリミティブ型のフィールドおよびプロパティの値にnull値を設定できます。

false：すべての非プリミティブ型のフィールドおよびプロパティの値にnull値を指定できません。

デフォルト値

true

8.22.30　@MapKey

(1)　説明

OneToManyリレーションシップまたはManyToManyリレーションシップで被所有者側のエンティティクラスがjava.util.Map型で示される場合に，マップ内のオブジェクト識別に用いられるマップキーを指定するアノテーションです。

name属性が指定されない場合，関連づけられたエンティティのプライマリキーはマップキーとして使われます。

プライマリキーが複合プライマリキーである場合に@IdClassとしてマップされるときは，マップキーに複合プライマリキーを使います。

プライマリキー以外の永続化フィールドまたは永続化プロパティがマップキーとして使われる場合は，そのマップキーと関連したユニークキー制約を持つことができます。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@MapKeyの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

任意

マップキーとして使われる被所有者側のエンティティクラスの永続化フィールドまたは永続化プロパティの名前を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

マップキーとして使われる被所有者側のエンティティクラスの永続化フィールドまたは永続化プロパティの名前を指定する属性です。

デフォルト値

被所有者側のエンティティクラスのプライマリキーフィールドまたはプロパティの名前

8.22.31　@MappedSuperclass

(1)　説明

マップドスーパークラスであることを指定するアノテーションです。

マップドスーパークラスは，継承するためのクラスであるため，このクラスに対応するテーブルを持ちません。マップドスーパークラスは，サブクラスへのマッピングと関連マッピング情報が継承されることを除いて，エンティティと同じ方法でテーブルにマップされます。

@AttributeOverrideを使うことでマッピング情報をサブクラスでオーバーライドできます。

適用可能要素は，クラスです。

(2)　属性

@MappedSuperclassの属性はありません。

8.22.32　@NamedNativeQueries

(1)　説明

@NamedNativeQueryを複数同時に記述する場合に指定するアノテーションです。

適用可能要素は，クラスです。

(2)　属性

@NamedNativeQueriesの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

@NamedNativeQueryの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

NamedNativeQuery[]

説明

@NamedNativeQueryの配列を指定する属性です。

指定できる値は，@NamedNativeQuery配列で指定できる範囲です。詳細は，「8.22.33　@NamedNativeQuery」を参照してください。

デフォルト値

なし

8.22.33　@NamedNativeQuery

(1)　説明

SQLで名前付きクエリを指定するアノテーションです。エンティティクラスとマップドスーパークラスに適用できます。

適用可能要素は，クラスです。

(2)　属性

@NamedNativeQueryの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

名前付きクエリの名前を指定する属性です。

query

必須

SQLの文字列を指定する属性です。

hints

任意

@QueryHintの配列を指定する属性です。

resultClass

任意

SQLの結果を反映するクラスを指定する属性です。

resultSetMapping

任意

@SqlResultSetMappingのname属性で指定した名前を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

名前付きクエリの名前を指定する属性です。

指定できる値は，文字列です。

デフォルト値

なし

(b)　query属性

型

String

説明

SQLの文字列を指定する属性です。

指定できるSQLは，使用するデータベースの仕様に依存します。

デフォルト値

なし

(c)　hints属性

型

QueryHint[]

説明

@QueryHintの配列を指定する属性です。

指定できる値は，@QueryHintの配列で指定できる範囲です。詳細は，「8.22.48　@QueryHint」を参照してください。

デフォルト値

空の配列

(d)　resultClass属性

型

Class

説明

SQLの結果を反映するクラスを指定する属性です。

resultClass属性は，クエリの実行結果をマッピングしたいクラスがあるときに指定します。resultClass属性とresultSetMapping属性は同時に指定しないでください。

指定できる値は，クラス名です。

デフォルト値

void.class

(e)　resultSetMapping属性

型

String

説明

結果セットを定義した@SqlResultSetMappingのname属性で指定した名前を指定する属性です。

任意の結果セットにSQLの結果をマッピングしたいときに指定します。

resultClass属性とresultSetMapping属性は同時に指定しないでください。

指定できる範囲は，@SqlResultSetMappingのname属性で指定できる範囲です。詳細は，「8.22.52(2)(a)　name属性」を参照してください。

デフォルト値

空の文字列

8.22.34　@NamedQueries

(1)　説明

@NamedQueryを複数同時に記述する場合に指定するアノテーションです。

適用可能要素は，クラスです。

(2)　属性

@NamedQueriesの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

@NamedQueryの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

NamedQuery[]

説明

@NamedQueryの配列を指定する属性です。

指定できる値は，@NamedQueryの配列で指定できる範囲です。詳細は，「8.22.35　@NamedQuery」を参照してください。

デフォルト値

なし

8.22.35　@NamedQuery

(1)　説明

JPQLの名前付きクエリを指定するアノテーションです。エンティティクラスとマップドスーパークラスに適用できます。

適用可能要素は，クラスです。

(2)　属性

@NamedQueryの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

名前付きクエリ名を指定する属性です。

query

必須

JPQLのクエリ文字列を指定する属性です。

hints

任意

@QueryHintの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

名前付きクエリ名を指定する属性です。

指定できる値は，文字列です。

デフォルト値

なし

(b)　query属性

型

String

説明

JPQLのクエリ文字列を指定する属性です。

指定できる値は，JPQLの仕様に依存します。

デフォルト値

なし

(c)　hints属性

型

QueryHint[]

説明

@QueryHintの配列を指定する属性です。

指定できる値は，@QueryHintの配列で指定できる範囲です。詳細は，「8.22.48　@QueryHint」を参照してください。

デフォルト値

空の配列

8.22.36　@OneToMany

(1)　説明

OneToManyリレーションシップの関係を持つ所有者側のエンティティクラスから被所有者側のエンティティクラスへの複数の関連を指定するアノテーションです。

@OneToManyのための同じアノテーションの属性は，@ManyToManyと同じ属性を持ちます。

なお，Genericsを使用してCollection要素型が指定されている場合，被所有者側のエンティティクラスを指定する必要はありません。そのほかの場合は，必ず指定してください。

また，双方向の関係にする場合は，非所有者側に必ずmappedBy属性を指定してください。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@OneToManyの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

targetEntity

任意

被所有者側のエンティティクラスを指定する属性です。

cascade

任意

カスケード対象となるオペレーションを指定する属性です。

fetch

任意

フェッチ戦略の指定値を指定する属性です。

mappedBy

任意

被所有者側のエンティティクラスの要素に付与し，所有者側のエンティティクラスで関係を保持しているフィールドまたはプロパティの名前を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　targetEntity属性

型

Class

説明

被所有者側のエンティティクラスを指定する属性です。

Genericsを使って定義されているコレクションプロパティの場合は，任意で指定します。それ以外の場合は必ず指定してください。

デフォルト値

コレクションのパラメタ化された型

注　Genericsを使って定義されているときにだけ設定されます。

(b)　cascade属性

型

CascadeType[]

説明

カスケード対象となるオペレーションを指定する属性です。

指定できる値を次に示します。

CascadeType.ALL：所有者側のエンティティクラスのpersist，remove，merge，およびrefreshの操作が関連先にカスケードされます。

CascadeType.MERGE：所有者側のエンティティクラスのmerge操作が関連先にカスケードされます。

CascadeType.PERSIST：所有者側のエンティティクラスのpersist操作が関連先にカスケードされます。

CascadeType.REFRESH：所有者側のエンティティクラスのrefresh操作が関連先にカスケードされます。

CascadeType.REMOVE：所有者側のエンティティクラスのremove操作が関連先にカスケードされます。

デフォルト値

カスケード対象なし

(c)　fetch属性

型

FetchType

説明

データベースからのデータのフェッチ戦略を定義する属性です。フェッチ戦略については，「8.4.5　データベースとの同期」を参照してください。

指定できる値は，次の2種類です。

EAGER戦略：データがEAGERにフェッチされなければならない要求

LAZY戦略：データが最初にアクセスされるときに，LAZYにフェッチされる要求

デフォルト値

FetchType.LAZY

(d)　mappedBy属性

型

String

説明

被所有者側のエンティティクラスの要素に付与し，所有者側のエンティティクラスで関係を保持しているフィールドまたはプロパティの名前を指定する属性です。

この属性を指定した場合，関係は双方向になります。

デフォルト値

なし

8.22.37　@OneToOne

(1)　説明

指定されたクラスがOneToOneリレーションシップであることを示し，エンティティクラス間の一つの関連を指定するアノテーションです。

双方向の関係にする場合は，非所有者側に必ずmappedBy属性を指定してください。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@OneToOneの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

targetEntity

任意

被所有者側のエンティティクラスを指定する属性です。

cascade

任意

カスケード対象となるオペレーションを指定する属性です。

fetch

任意

フェッチ戦略の指定値を指定する属性です。

optional

任意

すべての非プリミティブ型のフィールドおよびプロパティの値にnull値を設定できるかどうかを指定する属性です。

mappedBy

任意

被所有者側のエンティティクラスの要素に付与し，所有者側のエンティティクラスで関係を保持しているフィールド名を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　targetEntity属性

型

Class

説明

被所有者側のエンティティクラスを指定する属性です。

デフォルト値

アノテーションが付与されているフィールドやプロパティの型

(b)　cascade属性

型

CascadeType[]

説明

カスケード対象となるオペレーションを指定する属性です。

指定できる値を次に示します。

CascadeType.ALL：所有者側のエンティティクラスのpersist，remove，merge，refreshの操作が関連先にカスケードされます。

CascadeType.MERGE：所有者側のエンティティクラスのmerge操作が関連先にカスケードされます。

CascadeType.PERSIST：所有者側のエンティティクラスのpersist操作が関連先にカスケードされます。

CascadeType.REFRESH：所有者側のエンティティクラスのrefresh操作が関連先にカスケードされます。

CascadeType.REMOVE：所有者側のエンティティクラスのremove操作が関連先にカスケードされます。

デフォルト値

カスケード対象なし

(c)　fetch属性

型

FetchType

説明

データベースからのデータのフェッチ戦略を定義する属性です。フェッチ戦略については，「8.4.5　データベースとの同期」を参照してください。

指定できる値は，次の2種類です。

EAGER戦略：データがEAGERにフェッチされなければならない要求

LAZY戦略：データが最初にアクセスされるときに，LAZYにフェッチされる要求

デフォルト値

FetchType.EAGER

(d)　optional属性

型

boolean

説明

すべての非プリミティブ型のフィールドおよびプロパティの値にnull値を指定できるかどうかを指定する属性です。指定できる値は，次のとおりです。

true：すべての非プリミティブ型のフィールドおよびプロパティの値にnull値を設定できます。

false：すべての非プリミティブ型のフィールドおよびプロパティの値にnull値を指定できません。

デフォルト値

true

(e)　mappedBy属性

型

String

説明

被所有者側のエンティティクラスの要素に付与し，所有者側のエンティティクラスで関係を保持しているフィールド名を指定します。指定した場合，関係は双方向になります。

デフォルト値

なし

8.22.38　@OrderBy

(1)　説明

エンティティの情報を取得するとき，コレクションに保持される順番を指定するアノテーションです。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@OrderByの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

任意

プライマリキー以外のフィールドまたはプロパティを基にした順番でエンティティを取得したい場合に指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

String

説明

プライマリキー以外のフィールドまたはプロパティを基にした順番でエンティティクラスを取得するときに指定する属性です。コンマ区切りで，順番を指定したいフィールドまたはプロパティを指定します。

取得する順番は，フィールドまたはプロパティのあとに指定します。指定できる値は次のとおりです。指定しなかった場合は，昇順になります。

ASC：昇順

DESC：降順

value属性内で指定されるフィールドまたはプロパティには，比較演算できる値が格納されているカラムを指定します。

デフォルト値

エンティティクラスのプライマリキーによる昇順

8.22.39　@PostLoad

(1)　説明

キャッシュからエンティティを読み込んだあと，またはデータベースにSELECT文を発行したあとに呼び出されるコールバックメソッドであることを示すアノテーションです。エンティティクラス，マップドスーパークラス，またはエンティティリスナクラスのメソッドに適用されます。

適用可能要素は，メソッドです。

(2)　属性

@PostLoadの属性はありません。

8.22.40　@PostPersist

(1)　説明

データベースにINSERT文を発行したあとに呼び出されるコールバックメソッドであることを示すアノテーションです。エンティティクラス，マップドスーパークラス，またはエンティティリスナクラスのメソッドに適用されます。

適用可能要素は，メソッドです。

(2)　属性

@PostPersistの属性はありません。

8.22.41　@PostRemove

(1)　説明

データベースにDELETE文を発行したあとに呼び出されるコールバックメソッドであることを示すアノテーションです。エンティティクラス，マップドスーパークラス，またはエンティティリスナクラスのメソッドに適用されます。

適用可能要素は，メソッドです。

(2)　属性

@PostRemoveの属性はありません。

8.22.42　@PostUpdate

(1)　説明

データベースにUPDATE文を発行したあとに呼び出されるコールバックメソッドであることを示すアノテーションです。エンティティクラス，マップドスーパークラス，またはエンティティリスナクラスのメソッドに適用されます。

適用可能要素は，メソッドです。

(2)　属性

@PostUpdateの属性はありません。

8.22.43　@PrePersist

(1)　説明

データベースにINSERT文を発行する前に呼び出されるコールバックメソッドであることを示すアノテーションです。エンティティクラス，マップドスーパークラス，またはエンティティリスナクラスのメソッドに適用されます。

適用可能要素は，メソッドです。

(2)　属性

@PrePersistの属性はありません。

8.22.44　@PreRemove

(1)　説明

データベースにDELETE文を発行する前に呼び出されるコールバックメソッドであることを示すアノテーションです。エンティティクラス，マップドスーパークラス，またはエンティティリスナクラスのメソッドに適用されます。

適用可能要素は，メソッドです。

(2)　属性

@PreRemoveの属性はありません。

8.22.45　@PreUpdate

(1)　説明

データベースにUPDATE文を発行する前に呼び出されるコールバックメソッドであることを示すアノテーションです。エンティティクラス，マップドスーパークラス，またはエンティティリスナクラスのメソッドに適用されます。

適用可能要素は，メソッドです。

(2)　属性

@PreUpdateの属性はありません。

8.22.46　@PrimaryKeyJoinColumn

(1)　説明

ほかのテーブルと結合する場合に外部キーとして使われるカラムを指定するアノテーションです。次の場合に使用します。

継承マッピング戦略のJOINED戦略で，エンティティのスーパークラスのプライマリキーとサブクラスのプライマリキーが異なる名前の場合

@SecondaryTableで，プライマリテーブルとセカンダリテーブルを結合する場合※

OneToOneリレーションシップで，被所有者側のエンティティクラスのプライマリキーが外部キーとして使用されている場合

注※

この場合は，@SecondaryTable内で使用します。

適用可能要素は，クラス，メソッド，およびフィールドです。

(2)　属性

@PrimaryKeyJoinColumnの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

任意

対象テーブルを結合するためのカラム名を指定する属性です。

referencedColumnName

任意

name属性で指定したカラムによって参照される結合先テーブルのプライマリキーのカラム名を指定する属性です。

columnDefinition

任意

CREATE文を出力するときにカラムに付加する制約をDDLで記載する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

対象テーブルを結合するためのカラム名を指定する属性です。

指定できるカラム名は，データベースの仕様に依存します。

デフォルト値

JOINED戦略を使用した場合

スーパークラスのプライマリテーブルのプライマリキーのカラム名

@SecondaryTableを使用した場合

プライマリテーブルのプライマリキーのカラム名

OneToOneリレーションシップを使用した場合

対象となるエンティティのテーブルのプライマリキーのカラム名

(b)　referencedColumnName属性

型

String

説明

name属性で指定したカラムによって参照される結合先テーブルのプライマリキーのカラム名を指定する属性です。@Columnのname属性の文字列と同じ値を指定してください。なお，指定する文字列は大文字，小文字もそろえてください。

指定できるカラム名は，データベースの仕様に依存します。

OneToOneリレーションシップでカラムの指定をプライマリキーにしなくてもユニークキー制約があれば動作してしまいますが，動作の保証はしません。

デフォルト値

JOINED戦略を使用した場合

スーパークラスのプライマリテーブルのプライマリキーのカラム名

@SecondaryTableを使用した場合

プライマリテーブルのプライマリキーのカラム名

OneToOneリレーションシップを使用した場合

対象となるエンティティのテーブルのプライマリキーのカラム名

8.22.47　@PrimaryKeyJoinColumns

(1)　説明

@PrimaryKeyJoinColumnを複数同時に記述する場合に指定するアノテーションです。

適用可能要素は，クラス，メソッド，およびフィールドです。

(2)　属性

@PrimaryKeyJoinColumnsの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

@PrimaryKeyJoinColumnの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

PrimaryKeyJoinColumn[]

説明

@PrimaryKeyJoinColumnの配列を指定する属性です。

指定できる値は，@PrimaryKeyJoinColumnで指定できる範囲です。詳細は，「8.22.46　@PrimaryKeyJoinColumn」を参照してください。

デフォルト値

なし

8.22.48　@QueryHint

(1)　説明

データベース固有のクエリのヒントを指定するアノテーションです。

悲観的ロックやエンティティのキャッシュ機能の設定ができます。

適用可能要素は，@NamedQuery，または@NamedNativeQueryのhints要素です。

(2)　属性

@QueryHintの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

ヒントの名前を指定する属性です。

value

必須

ヒントの値を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

使用するヒントの名前を指定する属性です。指定できる値は次のとおりです。

cosminexus.jpa.pessimistic-lock

悲観的ロックを使用するかどうかを指定するヒントの名前です。

デフォルト値

なし

(b)　value属性

型

String

説明

ヒントの値を指定する属性です。name属性で指定したヒントの名前に合わせて，次の値を指定します。

name属性でcosminexus.jpa.pessimistic-lockを指定した場合の指定値

NoLock：悲観的ロックを使用しない場合に指定します。

Lock：悲観的ロックを使用する場合に指定します。対象となるテーブルがすでにロックされている場合は，解放されるまで待ちます。このとき発行されるSQLを使用するデータベースごとに示します。

Oracleの場合：SELECT.... FOR UPDATE

HiRDBの場合：SELECT....WITH EXCLUSIVE LOCK

LockNoWait：悲観的ロックを使用する場合に指定します。対象となるテーブルがすでにロックされている場合は，例外が発生します。このとき発行されるSQLを使用するデータベースごとに示します。

Oracleの場合：SELECT.... FOR UPDATE NO WAIT

HiRDBの場合：SELECT....WITH EXCLUSIVE LOCK NO WAIT

デフォルト値

name属性でcosminexus.jpa.pessimistic-lockを指定した場合

NoLock

8.22.49　@SecondaryTable

(1)　説明

エンティティクラスにセカンダリテーブルを指定するアノテーションです。

エンティティクラスがデータベース上の複数のテーブルにわたってマッピングされる場合に指定します。

@SecondaryTableをエンティティクラス内で指定しない場合，エンティティクラスのすべての永続化プロパティまたは永続化フィールドは，プライマリテーブルで指定されたテーブルとマッピングします。

適用可能要素は，クラスです。

(2)　属性

@SecondaryTableの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

セカンダリテーブル名を指定する属性です。

catalog

任意

セカンダリテーブルのカタログ名を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

schema

任意

セカンダリテーブルのスキーマ名を指定する属性です。

pkJoinColumns

任意

セカンダリテーブルがプライマリテーブルと結合するために使用する外部キーカラムを指定する属性です。

uniqueConstraints

任意

テーブルでのユニークキー制約を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

セカンダリテーブル名を指定する属性です。

指定できるテーブル名は，データベースの仕様に依存します。

デフォルト値

なし

(b)　schema属性

型

String

説明

セカンダリテーブルのスキーマ名を指定する属性です。

指定できるスキーマ名は，データベースの仕様に依存します。

デフォルト値

使用するデータベースのデフォルトのスキーマ名

(c)　pkJoinColumns属性

型

PrimaryKeyJoinColumn[]

説明

セカンダリテーブルの外部キーカラムを指定する属性です。@PrimaryKeyJoinColumnの配列で指定します。

この要素が指定されない場合，セカンダリテーブルの外部キーカラムはプライマリテーブルのプライマリキーカラムと同じ名前と型を持ちます。このため，セカンダリテーブルはプライマリテーブルのプライマリキーカラムを参照します。

デフォルト値

指定できる値は，@PrimaryKeyJoinColumnの配列で指定できる範囲です。詳細は，「8.22.46　@PrimaryKeyJoinColumn」を参照してください。

8.22.50　@SecondaryTables

(1)　説明

@SecondaryTableを複数同時に記述する場合に指定するアノテーションです。

適用可能要素は，クラスです。

(2)　属性

@SecondaryTablesの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

@SecondaryTableの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

SecondaryTable[]

説明

@SecondaryTableの配列を指定する属性です。

指定できる値は，@SecondaryTableの配列で指定できる範囲です。詳細は，「8.22.49　@SecondaryTable」を参照してください。

デフォルト値

なし

8.22.51　@SequenceGenerator

(1)　説明

プライマリキーを作成するシーケンスジェネレータの設定を指定するアノテーションです。@SequenceGeneratorを使用する場合，次の設定が必要です。

@GeneratedValueのstrategy属性にGenerationType.SEQUENCEを指定します。

@GeneratedValueのgenerator属性で指定された名前を@SequenceGeneratorのname属性に設定します。

シーケンスジェネレータは，エンティティクラス，またはプライマリキーのフィールドもしくはプロパティで指定されます。シーケンスジェネレータ名のスコープは永続化ユニットで有効です。

シーケンスオブジェクトを作成する場合，順序の番号間の増分間隔（INCREMENT BY）と生成する順序番号の初期値（START WITH）には，正の整数を指定します。初期値（START WITH）に1を指定した場合，プライマリキーは1から生成されます。負の値を指定した場合の動作は保証しません。

適用可能要素は，クラス，メソッド，およびフィールドです。

(2)　属性

@SequenceGeneratorの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

@GeneratedValueアノテーションのgenerator属性で指定された名前を指定する属性です。

sequenceName

任意

既存のプライマリキー値または事前に定義したプライマリキー値を取得するためのデータベースシーケンスオブジェクトの名前を指定する属性です。

initialValue

任意

シーケンスオブジェクトが，プライマリキー値生成を開始する初期値を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。値を指定した場合は無視されます。

allocationSize

任意

シーケンスからプライマリキー値を割り当てるサイズを指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

@GeneratedValueアノテーションのgenerator属性で指定された名前を指定する属性です。

指定できる値は，文字列です。

デフォルト値

なし

(b)　sequenceName属性

型

String

説明

既存のプライマリキー値または事前に定義したプライマリキー値を取得するためのデータベースシーケンスオブジェクトの名前を指定する属性です。

指定できるシーケンスオブジェクト名は，データベースの仕様に依存します。

デフォルト値

@GeneratedValueのgenerator属性の指定値

(c)　allocationSize属性

型

int

説明

シーケンスからプライマリキー値を割り当てるサイズを指定する属性です。指定できるシーケンスオブジェクト名は，データベースの仕様に依存します。

指定できるサイズは，int型の1以上の数値です。シーケンスオブジェクトの増分間隔と同じ値を指定します。異なる値を指定した場合の動作は保証しません。

なお，この属性は，実行時に利用する最大値を指定できます。シーケンス番号の管理領域として取得するため，大きな値を指定した場合は，実行時にjava.lang.OutOfMemoryError例外が発生します。

デフォルト値

50

8.22.52　@SqlResultSetMapping

(1)　説明

SQLのクエリの結果セットマッピングを指定するアノテーションです。

適用可能要素は，クラスです。

(2)　属性

@SqlResultSetMappingの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

結果セットマッピングの名前を指定する属性です。

entities

任意

@EntityResultの配列を指定する属性です。

columns

任意

@ColumnResultの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

結果セットマッピングの名前を指定する属性です。

指定できる値は，文字列です。

デフォルト値

なし

(b)　entities属性

型

EntityResult[]

説明

@EntityResultの配列を指定する属性です。

指定できる値は，@EntityResultの配列で指定できる範囲です。詳細は，「8.22.15　@EntityResult」を参照してください。

デフォルト値

空の配列

(c)　columns属性

型

ColumnResult[]

説明

@ColumnResultの配列を指定する属性です。

指定できる値は，@ColumnResultの配列で指定できる範囲です。詳細は，「8.22.7　@ColumnResult」を参照してください。

デフォルト値

空の配列

8.22.53　@SqlResultSetMappings

(1)　説明

@SqlResultSetMappingを複数同時に記述する場合に指定するアノテーションです。

適用可能要素は，クラスです。

(2)　属性

@SqlResultSetMappingsの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

@SqlResultSetMappingの配列を指定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

SqlResultSetMapping[]

説明

@SqlResultSetMappingの配列を指定する属性です。

指定できる値は，@SqlResultSetMappingの配列で指定できる範囲です。詳細は，「8.22.52　@SqlResultSetMapping」を参照してください。

デフォルト値

なし

8.22.54　@Table

(1)　説明

エンティティクラスに，プライマリテーブルを指定するアノテーションです。

明示的にエンティティクラスに@Tableを指定しない場合でも，@Tableが指定されたようにエンティティクラスは扱われます。その場合，@Tableの各属性値にはデフォルト値が適用されます。

エンティティがマッピングするテーブルを複数指定する場合は，@SecondaryTableまたは@SecondaryTablesを使用してください。

適用可能要素は，クラスです。

(2)　属性

@Tableの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

任意

テーブル名を指定する属性です。

catalog

任意

テーブルのカタログ名を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

schema

任意

テーブルのスキーマ名を指定する属性です。

uniqueConstraints

任意

テーブルでのユニークキー制約を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

テーブル名を指定する属性です。

指定できるテーブル名は，データベースの仕様に依存します。

デフォルト値

エンティティ名

(b)　schema属性

型

String

説明

テーブルのスキーマ名を指定する属性です。

指定できるスキーマ名は，データベースの仕様に依存します。

デフォルト値

使用するデータベースのデフォルトのスキーマ名

8.22.55　@TableGenerator

(1)　説明

プライマリキーを作成するジェネレータの設定を指定するアノテーションです。

@TableGeneratorを使用する場合，次の設定が必要です。

@GeneratedValueのstrategy属性にGenerationType.TABLEを指定します。

@GeneratedValueのgenerator属性で指定された名前を@TableGeneratorのname属性に設定します。

テーブルジェネレータは，エンティティクラス，またはプライマリキーのフィールドまたはプロパティに指定されます。ジェネレータ名のスコープは永続化ユニットで有効です。

エンティティはプライマリキー値を生成するために，ジェネレータテーブルの行を使用します。

シーケンスを管理するテーブルを作成する場合，初期値には正の整数を指定します。初期値に0を指定した場合，プライマリキーは1から生成されます。

適用可能要素は，クラス，メソッド，およびフィールドです。

(2)　属性

@TableGeneratorの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

name

必須

プライマリキー値のためのジェネレータ名を指定する属性です。

table

任意

生成されるプライマリキー値を確保するテーブルの名前を指定する属性です。

catalog

任意

生成されるプライマリキー値を確保するテーブルのカタログ名を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。

schema

任意

生成されるプライマリキー値を確保するテーブルのスキーマ名を指定する属性です。

pkColumnName

任意

生成されるプライマリキー値を確保するテーブルのプライマリキーカラム名を指定する属性です。

valueColumnName

任意

生成された最終値を確保するカラム名を指定する属性です。

pkColumnValue

任意

生成されるプライマリキー値を確保するテーブルのプライマリキー値を指定する属性です。

initialValue

任意

生成された最新の値を確保するカラムを初期化するために使う値を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。値を指定した場合は無視されます。

allocationSize

任意

ジェネレータからプライマリキー値を割り当てるサイズを指定する属性です。

uniqueConstraints

任意

生成されるプライマリキー値を確保するテーブル上でのユニークキー制約を指定する属性です。

なお，この属性は，CJPAプロバイダには対応していません。値を指定した場合は無視されます。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　name属性

型

String

説明

プライマリキー値のためのジェネレータ名を指定する属性です。

指定できる値は，文字列です。

デフォルト値

なし

(b)　table属性

型

String

説明

生成されるプライマリキー値を確保するテーブルの名前を指定する属性です。

指定できるテーブル名は，データベースの仕様に依存します。

デフォルト値

"SEQUENCE"

(c)　schema属性

型

String

説明

生成されるプライマリキー値を確保するテーブルのスキーマ名を指定する属性です。

指定できるスキーマ名は，データベースの仕様に依存します。

デフォルト値

使用するデータベースのデフォルトのスキーマ名

(d)　pkColumnName属性

型

String

説明

生成されるプライマリキー値を確保するテーブルのプライマリキーカラム名を指定する属性です。

指定できるカラム名は，データベースの仕様に依存します。

デフォルト値

"SEQ_NAME"

(e)　valueColumnName属性

型

String

説明

生成された最終値を確保するカラム名を指定する属性です。

指定できるカラム名は，データベースの仕様に依存します。

デフォルト値

"SEQ_COUNT"

(f)　pkColumnValue属性

型

String

説明

生成されるプライマリキー値を確保するテーブルのプライマリキー値を指定する属性です。

指定できる値は，生成されたプライマリキーのカラムの型に依存します。

デフォルト値

name属性で指定された文字列

(g)　allocationSize属性

型

int

説明

ジェネレータからプライマリキー値を割り当てるサイズを指定する属性です。

指定できる値は，int型の1以上の数値です。

なお，この属性は，実行時に利用する最大値を指定できます。シーケンス番号の管理領域として取得するため，大きな値を指定した場合は，実行時にjava.lang.OutOfMemoryError例外が発生します。

デフォルト値

50

8.22.56　@Temporal

(1)　説明

時刻を表す型（java.util.Dateおよびjava.util.Calendar）を持つ永続化プロパティまたは永続化フィールドに指定するアノテーションです。@Basicとともに使用できます。

ただし，@Versionと@Temporalは同時に指定できません。どちらかのアノテーションだけを指定してください。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@Temporalの属性の一覧を次の表に示します。

属性名

任意/必須

属性の説明

value

必須

データベース型に対応するTemporalType列挙型に設定する属性です。

CJPAプロバイダで対応する属性の詳細を次に示します。

(a)　value属性

型

TemporalType

説明

データベース型に対応するTemporalType列挙型に設定する属性です。

指定できる値は，次の3種類です。

TemporalType.DATE：java.sql.Dataと同じです。

TemporalType.TIME：java.sql.Timeと同じです。

TemporalType.TIMESTAMP：java.sql.Timestampと同じです。

デフォルト値

なし

8.22.57　@Transient

(1)　説明

次に示す永続化しないクラスのフィールドまたはプロパティであることを示すアノテーションです。

エンティティクラス

マップドスーパークラス

埋め込みクラス

適用可能要素は，メソッドとフィールドです。

@Transientを定義したフィールドの値は永続化されませんが，永続化コンテキストに保持されるため，設定した値を取得できます。ただし，別のEntityManagerからは値を取得できません。

(2)　属性

@Transientの属性はありません。

8.22.58　@Version

(1)　説明

楽観的ロック機能を使用するために用いるversionフィールドまたはversionプロパティを指定するアノテーションです。

versionフィールドまたはversionプロパティでサポートする型を次に示します。

int

java.lang.Integer

short

java.lang Short

long

java.lang Long

java.sql.Timestamp

このアノテーションを使用する場合は，次のことに注意してください。

@Versionと@Temporalは同時に指定できません。どちらかのアノテーションだけを指定してください。

versionプロパティをプライマリテーブル以外のテーブルには指定しないでください。

@Versionで指定されたフィールドまたはプロパティは，アプリケーションによって更新してはいけません。

SQLを使用して複数のレコードを一度に更新するバルク更新の場合は，versionフィールドまたはversionプロパティを自動更新しません。このため，バルク更新をする場合に楽観的ロックを使用するときは，手動で参照および更新をする必要があります。

エンティティクラスに対しては，versionフィールドまたはversionプロパティは一つだけ設定できます。複数のversionフィールドまたはversionプロパティを設定した場合，一つだけ有効となります。設定が有効になる順番は不定です。

適用可能要素は，メソッドとフィールドです。

(2)　属性

@Versionの属性はありません。

8.22.59　アノテーションとO/Rマッピングとの対応

アノテーションとO/Rマッピングファイルとの対応を次の表に示します。

表8‒31　アノテーションとO/Rマッピングファイルの対応

アノテーション

O/Rマッピングの要素

@AssociationOverride

<association-override>

@AssociationOverrides

−

@AttributeOverride

<attribute-override>

@AttributeOverrides

−

@Basic

<basic>

@Column

<column>

@ColumnResult

<column-result>

@DiscriminatorColumn

<discriminator-column>

@DiscriminatorValue

<discriminator-value>

@Embeddable

<embeddable>

@Embedded

<embedded>

@EmbeddedId

<embedded-id>

@Entity

<entity>

@EntityListeners

<entity-listeners>

@EntityResult

<entity-result>

@Enumerated

<enumerated>

@ExcludeDefaultListeners

<exclude-default-listeners>

@ExcludeSuperclassListeners

<exclude-superclass-listeners>

@FieldResult

<field-result>

@GeneratedValue

<generated-value>

@Id

<id>

@IdClass

<id-class>

@Inheritance

<inheritance>

@JoinColumn

<join-column>

@JoinColumns

−

@JoinTable

<join-table>

@Lob

<lob>

@ManyToMany

<many-to-many>

@ManyToOne

<many-to-one>

@MapKey

<map-key>

@MappedSuperclass

<mapped-superclass>

@NamedNativeQueries

−

@NamedNativeQuery

<named-native-query>

@NamedQueries

−

@NamedQuery

<named-query>

@OneToMany

<one-to-many>

@OneToOne

<one-to-one>

@OrderBy

<order-by>

@PostLoad

<post-load>

@PostPersist

<post-persist>

@PostRemove

<post-remove>

@PostUpdate

<post-update>

@PrePersist

<pre-persist>

@PreRemove

<pre-remove>

@PreUpdate

<pre-update>

@PrimaryKeyJoinColumn

<primary-key-join-column>

@PrimaryKeyJoinColumns

−

@QueryHint

<hint>

@SecondaryTable

<secondary-table>

@SecondaryTables

−

@SequenceGenerator

<sequence-generator>

@SqlResultSetMapping

<sql-result-set-mapping>

@SqlResultSetMappings

−

@Table

<table>

@TableGenerator

<table-generator>

@Temporal

<temporal>

@Transient

<transient>

@UniqueConstraint

<unique-constraint>

@Version

<version>

（凡例）

−：該当しません。

9　Webコンテナ

この章では，Webコンテナ（サーブレットとJSPを実行するためのサーバ基盤）について，V9互換モードだけで使用できる機能や注意事項を説明します。Webコンテナの機能は，サーブレットまたはJSPを使用したJ2EEアプリケーションを実行する場合に使用します。

9.1　リクエストおよびレスポンスのフィルタリング機能

この節では，リクエストおよびレスポンスのフィルタリング機能について説明します。

この節の構成を次の表に示します。

表9‒1　この節の構成（リクエストおよびレスポンスのフィルタリング機能）

分類

タイトル

参照先

解説

アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）

9.1.1

フィルタ連鎖の推奨例

9.1.2

実装

DDでの定義

9.1.3

設定

実行環境での設定（Webアプリケーションの設定）

9.1.4

注　「運用」および「注意事項」について，この機能固有の説明はありません。

アプリケーションサーバで使用できるフィルタリングの機能には，Servlet仕様で規定されている機能と，アプリケーションサーバで提供する機能があります。どちらの機能も，サーブレット/JSPのリクエストやレスポンスに対してフィルタリングをする機能です。

Servlet仕様で規定されているフィルタリング機能では，サーブレット/JSPを実行する前のリクエスト，またはサーブレット/JSPを実行したあとのレスポンスをラップします。これによって，データの変更，リソースに対するトレースの取得などができます。

また，アプリケーションサーバが提供するフィルタリング機能では，セッション情報を引き継いだり，HTTPレスポンスを圧縮したりできます。アプリケーションサーバでは，これらのフィルタリング機能を使用するためにサーブレットフィルタを提供しています。アプリケーションサーバが提供するサーブレットフィルタをbuilt-inフィルタといいます。次項でアプリケーションサーバが提供するbuilt-inフィルタについて説明します。

9.1.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）

アプリケーションサーバでは，次に示す機能を使用するためのサーブレットフィルタ（built-inフィルタ）を提供しています。

HTTPレスポンスの圧縮

HTTPリクエストに対するHTTPレスポンスを圧縮するために，アプリケーションサーバはbuilt-inフィルタとしてHTTPレスポンス圧縮フィルタを提供しています。

built-inフィルタの種類を次の表に示します。また，Webアプリケーションにbuilt-inフィルタを組み込むことによって使用できる機能の参照先をあわせて示します。

表9‒2　built-inフィルタの種類

built-inフィルタの種類

機能の説明

参照先マニュアル

参照個所

HTTPレスポンス圧縮フィルタ

サーブレット，JSP，および静的コンテンツへのHTTPリクエストに対するHTTPレスポンスをgzip形式に圧縮します。

このマニュアル

9.2

なお，Servlet 3.0以降では，web.xmlではなくAPIでのフィルタ定義ができますが，built-inフィルタはAPIでのフィルタ定義はできません。

以降で，built-inフィルタのHTTPリクエスト・HTTPレスポンスへの作用，built-inフィルタの動作条件に関する制約について説明します。

(1)　HTTPリクエストおよびHTTPレスポンスへの作用

built-inフィルタは，クライアント側から送信されるHTTPリクエストのリクエストヘッダ，およびリクエストボディに対して作用して，情報の削除，追加，変更などを実施する場合があります。また，サーバから送信されるHTTPレスポンスのレスポンスヘッダ，およびレスポンスボディに対して同様に作用する場合もあります。built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用を次の表に示します。

表9‒3　built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用

built-inフィルタの種類

HTTPリクエストへの作用

HTTPレスポンスへの作用

HTTPレスポンス圧縮フィルタ

−

レスポンスボディが圧縮される場合，Content-Encodingヘッダに「gzip」を指定します。また，レスポンスボディをgzip形式で圧縮します。

（凡例）　−：該当なし

(2)　動作条件に関する制約

ユーザのフィルタと，built-inフィルタを同時に使用する場合，フィルタ連鎖の中でbuilt-inフィルタが呼び出される順序に制約があります。

built-inフィルタごとに次に示す制約について説明します。

位置に関する制約

フィルタ連鎖中のbuilt-inフィルタの位置（呼び出される順序）に関する制約です。

動作条件に関する制約

built-inフィルタが動作する上での前提条件などの動作条件に関する制約です。

前後に配置するほかのサーブレットフィルタに対する制約

built-inフィルタの前後に配置するサーブレットフィルタに対する制約です。

(a)　HTTPレスポンス圧縮フィルタに対する制約

HTTPレスポンス圧縮フィルタに対する制約を次の表に示します。

表9‒4　HTTPレスポンス圧縮フィルタに対する制約

制約の種類

説明

位置に関する制約

−

動作条件に関する制約

−

前後に配置するほかのサーブレットフィルタに対する制約

javax.servlet.http.HttpServletResponseクラスのsetHeaderメソッド，addHeaderメソッド，setIntHeaderメソッド，またはaddIntHeaderメソッドを使用して，Content-Lengthヘッダ，またはContent-Encodingヘッダの設定を変更するサーブレットフィルタと同時に使用する場合，そのサーブレットフィルタはHTTPレスポンス圧縮フィルタよりあとに配置する必要があります。

（凡例）　−：該当なし

9.1.2　フィルタ連鎖の推奨例

フィルタ連鎖の推奨例を次に示します。次に示す順序で連鎖するように配置してください。

なお，例で説明するユーザのフィルタは，リクエストボディおよびレスポンスボディに作用する一般的なフィルタを想定しています。

HTTPレスポンス圧縮フィルタ，およびユーザのフィルタ（FilterA）を使用する場合

HTTPレスポンス圧縮フィルタ

ユーザのフィルタ（FilterA）

HTTPレスポンス圧縮フィルタ，およびユーザのフィルタ（FilterD）を使用する場合

HTTPレスポンス圧縮フィルタ

ユーザのフィルタ（FilterD）

9.1.3　DDでの定義

リクエストおよびレスポンスのフィルタリング機能の定義は，web.xmlに指定します。

DDでのリクエストおよびレスポンスのフィルタリング機能の定義については，次の場所を参照してください。

HTTPレスポンス圧縮フィルタについては，「9.2　HTTPレスポンス圧縮機能」を参照してください。

9.1.4　実行環境での設定（Webアプリケーションの設定）

リクエストおよびレスポンスのフィルタリング機能を定義する場合，Webアプリケーションの設定が必要です。cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。リクエストおよびレスポンスのフィルタリングの定義には，フィルタ属性ファイルおよびWAR属性ファイルを使用します。

フィルタ属性ファイルおよびWAR属性ファイルで指定するタグは，DDと対応しています。DD（web.xml）での定義については，「9.1.3　DDでの定義」を参照してください。

9.2　HTTPレスポンス圧縮機能

この節では，HTTPレスポンス圧縮機能について説明します。

HTTPレスポンス圧縮機能とは，サーブレット，JSP，および静的コンテンツへのHTTPリクエストに対するHTTPレスポンスを，gzip形式に圧縮する機能です。この機能を使用してHTTPレスポンスを圧縮することで，WebコンテナとWebクライアント（ブラウザなど）との間のHTTPレスポンス通信に掛かる時間を削減できます。

この機能は，Webアプリケーションに組み込んで動作させるサーブレットフィルタとして提供されています。これを，HTTPレスポンス圧縮フィルタといいます。

この節の構成を次の表に示します。

表9‒5　この節の構成（HTTPレスポンス圧縮機能）

分類

タイトル

参照先

解説

HTTPレスポンス圧縮フィルタの概要

9.2.1

HTTPレスポンス圧縮フィルタを使用するための条件

9.2.2

実装

HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

9.2.3

DDでの定義

9.2.4

DDの定義例

9.2.5

設定

実行環境での設定（Webアプリケーションの設定）

9.2.6

注　「運用」および「注意事項」について，この機能固有の説明はありません。

9.2.1　HTTPレスポンス圧縮フィルタの概要

HTTPレスポンス圧縮機能を有効にすると，HTTPレスポンスのレスポンスボディをgzip形式に圧縮します。HTTPレスポンス圧縮機能の概要を次の図に示します。

図9‒1　HTTPレスポンス圧縮機能の概要

HTTPレスポンス圧縮機能を有効にするためには，アプリケーションサーバが提供するHTTPレスポンス圧縮フィルタをWebアプリケーションに組み込む必要があります。HTTPレスポンス圧縮機能を適用する場合，WebアプリケーションのDD（web.xml）にHTTPレスポンス圧縮フィルタのフィルタ定義，およびフィルタマッピングの定義を追加します。J2EEサーバにデプロイ済みのWebアプリケーションに適用する場合は，サーバ管理コマンドを使用して，HTTPレスポンス圧縮フィルタのフィルタ定義，およびフィルタマッピングの定義を追加します。

9.2.2　HTTPレスポンス圧縮フィルタを使用するための条件

ここでは，HTTPレスポンス圧縮フィルタを使用する場合の条件や注意事項について説明します。

(1)　前提条件

HTTPレスポンス圧縮機能を使用にするには，次の前提条件を満たしている必要があります。

Webクライアントのgzip形式の対応

HTTPレスポンス圧縮機能を有効にした場合，gzip形式で圧縮されたHTTPレスポンスをWebクライアントで解凍する必要があります。そのため，Webクライアントがgzip形式に対応していることが前提となります。Webクライアントがgzip形式に対応していない場合は，HTTPレスポンス圧縮機能を有効にしていても，HTTPレスポンスは圧縮されません。

WebクライアントのHTTP/1.1の対応

HTTPレスポンス圧縮機能では，Webクライアントがgzip形式に対応しているかどうかをHTTPリクエストのAccept-Encodingヘッダに指定された値によって判定しています。そのため，WebクライアントはAccept-Encodingヘッダの仕様が規定されているHTTP/1.1に対応している必要があります。

(2)　必要なメモリ量

HTTPレスポンス圧縮機能に必要なメモリ量は次の計算式で求められます。

HTTPレスポンス圧縮機能に必要なメモリ量（バイト）=HTTPレスポンス圧縮機能が有効となるHTTPリクエストの同時実行数×レスポンスの圧縮しきい値（バイト）

圧縮しきい値とは，HTTPレスポンスボディのサイズによって，HTTPレスポンスを圧縮するかどうかを判定するためのしきい値です。HTTPレスポンスボディのサイズが圧縮しきい値に定義したサイズを超える場合にだけ，HTTPレスポンスを圧縮します。なお，圧縮しきい値は，HTTPリクエストに対して設定します。

圧縮しきい値は，DD（web.xml）に定義します。圧縮しきい値を定義することで，HTTPレスポンスのサイズが小さい場合に，HTTPレスポンスの圧縮に掛かる時間が，通信に掛かる時間よりも大きくならないようにします。

圧縮しきい値は，圧縮するリソースの種別と通信回線の速度によって適切なサイズが決まります。圧縮しきい値に定義するサイズは実測で求め，適切なサイズを定義することを推奨します。

(3)　HTTPレスポンス圧縮機能を有効にする場合の条件

HTTPレスポンス圧縮機能が有効になる条件を指定できます。指定できる条件を次に示します。

HTTPリクエストのURLパターン

HTTPレスポンス圧縮フィルタを実装しているWebアプリケーションに対するリクエストのURLが，指定したURLパターンと一致する場合，そのリクエストに対するレスポンスを圧縮します。

HTTPレスポンスの圧縮を実行するHTTPリクエストのURLパターンとして「*.html」を指定した場合の例を次の図に示します。

図9‒2　HTTPレスポンスの圧縮を実行するHTTPリクエストのURLパターンとして「*.html」を指定した場合の例

HTTPレスポンスのMedia-Type

HTTPレスポンスのContent-Typeヘッダに含まれるMedia-Typeの値が，指定した値と一致する場合，HTTPレスポンスを圧縮します。

HTTPレスポンスのMedia-Typeは，サーブレット/JSPの場合はJ2EEアプリケーションがsetContentTypeメソッドによって設定した値です。静的コンテンツの場合は拡張子に対応づけられたMIMEタイプとなります。

HTTPレスポンスの圧縮を実行するHTTPレスポンスのMedia-Typeとして「text/html」を指定した場合の例を次の図に示します。

図9‒3　HTTPレスポンスの圧縮を実行するHTTPレスポンスのMedia-Typeとして「text/html」を指定した場合の例

HTTPレスポンスのボディサイズ

HTTPレスポンスの圧縮を実行するためしきい値を設定して，ボディサイズがこのしきい値を超える場合，HTTPレスポンスを圧縮します。

HTTPレスポンスの圧縮を実行するHTTPレスポンスのボディサイズとして「200バイト」を指定してHTTPレスポンス圧縮機能を有効にした場合の例を次の図に示します。

図9‒4　HTTPレスポンスの圧縮を実行するHTTPレスポンスのボディサイズとして「200バイト」を指定した場合の例

(4)　注意事項

HTTPレスポンス圧縮フィルタの定義に関する注意事項

HTTPレスポンス圧縮フィルタを使用する場合，built-inフィルタのHTTPリクエストおよびHTTPレスポンスへの作用やフィルタ連鎖の順序制約を考慮して，WebアプリケーションにHTTPレスポンス圧縮フィルタを組み込む必要があります。built-inフィルタの詳細については，「9.1.1　アプリケーションサーバが提供するサーブレットフィルタ（built-inフィルタ）」を参照してください。

なお，Servlet 3.0以降では，web.xmlではなくAPIでのフィルタ定義ができますが，built-inフィルタはAPIでのフィルタ定義はできません。

エラーページに関する注意事項

HTTPレスポンス圧縮機能を使用するWebアプリケーションでは，次の機能を使用してエラーページをカスタマイズできます。

Webサーバの機能を使用したエラーページのカスタマイズ

インプロセスHTTPサーバによるエラーページのカスタマイズ

web.xmlの<error-page>タグを使用したエラーページのカスタマイズ

web.xmlの<error-page>タグを使用したエラーページを使用する場合は，エラーページに静的コンテンツ，またはレスポンスからjavax.servlet.ServletOutputStreamを取得して使用するサーブレットを指定してください。

HTTPレスポンス圧縮機能では圧縮後のデータの出力にレスポンスオブジェクトから取得したjavax.servlet.ServletOutputStreamを使用します。そのため，エラーページを生成するサーブレット，またはJSPでレスポンスオブジェクトからは，java.io.PrintWriterを取得できません。

9.2.3　HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装

ここでは，HTTPレスポンス圧縮フィルタを使用するアプリケーションを開発するときの注意事項について説明します。

(1)　ほかのフィルタと併用する場合の呼び出し順序

HTTPレスポンス圧縮フィルタは，HTTPレスポンスのヘッダに設定するほかのフィルタよりも前に呼び出される必要があります。javax.servlet.http.HttpServletResponseのsetHeaderメソッド，addHeaderメソッド，setIntHeaderメソッド，およびaddIntHeaderメソッドを使用して，Content-Lengthヘッダ，Content-Encodingヘッダを設定するほかのフィルタを使用する場合は，HTTPレスポンス圧縮フィルタよりも後ろに配置してください。

(2)　HTTPレスポンスのバッファに関する注意事項

HTTPレスポンス圧縮機能を有効にした場合，HTTPレスポンスのバッファよりも前に圧縮しきい値に指定したサイズのバッファが設けられます。HTTPレスポンスのバッファには，出力したデータが圧縮しきい値を超えたときに書き込まれます。

圧縮後のデータサイズがHTTPレスポンスのバッファサイズを超えなければ，WebクライアントにHTTPレスポンスが書き出されることはありません。出力したデータのサイズが圧縮しきい値を超える前に，HTTPレスポンスをWebクライアントに書き出す必要がある場合は，明示的にレスポンス出力用ストリーム※のflushメソッドを呼び出す必要があります。ただし，出力したデータのサイズが圧縮しきい値を超える前にflushメソッド，またはjavax.servlet.ServletResponseクラスのflushBufferメソッドを呼び出した場合は，出力したデータは圧縮されないでWebクライアントに書き出されます。

注※

レスポンス出力用ストリームとは，次に示すオブジェクトを指します。

javax.servlet. ServletResponseクラスのgetOutputStreamメソッドによって取得したjavax.servlet.ServletOutputStream

javax.servlet. ServletResponseクラスのgetWriterメソッドによって取得したjava.io.PrintWriter

JSPで暗黙的に利用できるjavax.servlet.jsp.JspWriter

(3)　HTTPレスポンスのレスポンスヘッダに関する注意事項

HTTPレスポンス圧縮機能によってHTTPレスポンスのレスポンスボディが圧縮される場合，このHTTPレスポンスのContent-Encodingヘッダにはgzip，VaryヘッダにはAccept-Encodingが指定されます。Content-Lengthヘッダには何も指定されません。

したがって，javax.servlet.ServletResponseクラスのsetContentLengthメソッドを使用する場合とjavax.servlet.http.HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用する場合は，次の点に注意してください。

次のどちらかのAPIを使用してContent-Lengthヘッダ，Content-Encodingヘッダを設定するフィルタを追加している場合は，レスポンス圧縮用フィルタよりもあとに実行されるようにDD（web.xml）で定義してください。

ServletResponseクラスのsetContentLengthメソッド

HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※

HTTPレスポンスのレスポンスボディが圧縮される場合，ServletResponseクラスのsetContentLengthメソッド，およびHttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用しても，HTTPレスポンスのContent-Lengthヘッダは付加されません。Content-Lengthヘッダが付加されていないHTTPレスポンスはWebコンテナによってchunk形式でクライアントに送信されます。

HTTPレスポンスのレスポンスボディが圧縮される場合，HttpServletResponseクラスのレスポンスヘッダを追加・変更するAPI※を使用してもContent-Encodingヘッダには値が設定されません。レスポンスボディが圧縮される場合は，WebコンテナによってContent-Encodingヘッダにgzipが指定されます。

注※

レスポンスヘッダを追加・変更するAPIとは，javax.servlet.http.HttpServletResponseクラスの次のメソッドを指します。

setHeaderメソッド

addHeaderメソッド

setIntHeaderメソッド

addIntHeaderメソッド

(4)　HTTPレスポンスのデータ出力に関する注意事項

javax.servlet.ServletResponseクラスのgetOutputStreamメソッド，またはgetWriterメソッドによってServletOutputStreamまたはPrintWriterを取得し，HTTPレスポンスを出力する場合は，次の点に注意してください。

ServletOutputStreamまたはPrintWriterを使用して，HTTPレスポンスのバッファにデータを書き出している状態で，ServletResponseのsetContentTypeメソッドを呼び出した場合，圧縮するように指定されたMedia-Typeを持つHTTPレスポンスであっても圧縮されません。

ただし，圧縮するMedia-Typeにアスタリスク（*）が指定されているときは圧縮されます。

Media-Typeを指定してJSPの出力を圧縮するためには，pageディレクティブのcontentType属性を指定するか，またはJSPのバッファを超える前にServletResponseクラスのsetContentTypeメソッドを呼び出す必要があります。

(5)　アプリケーションでHTTPレスポンスを圧縮する場合の注意事項

アプリケーションで圧縮したHTTPレスポンスには，HTTPレスポンス圧縮機能が有効にならないように設定してください。アプリケーションで圧縮したHTTPレスポンスに対して，HTTPレスポンス圧縮機能を有効にした場合の動作は保証できません。

9.2.4　DDでの定義

ここでは，HTTPレスポンス圧縮機能を使用する場合に必要なDDの定義について説明します。

HTTPレスポンス圧縮機能を有効にするためには，WebアプリケーションのDDに，フィルタ定義およびフィルタマッピング定義を追加する必要があります。HTTPレスポンス圧縮機能は，フィルタマッピング定義によってマッピングされたURLパターンを持つリソースに対してリクエストがあった場合にだけ有効となります。

HTTPレスポンス圧縮機能の定義は，web.xmlに指定します。

DDでのHTTPレスポンス圧縮機能の定義について次の表に示します。

表9‒6　DDでのHTTPレスポンス圧縮機能の定義

設定項目

指定するタグ

設定内容

フィルタ定義

<filter>タグ内の<filter-name>タグ

追加するフィルタ名称を指定します。設定値は，固定値です。

設定値（固定値）

com.hitachi.software.was.web.ResponseCompressionFilter

<filter>タグ内の<filter-class>タグ

追加するフィルタのクラス名を指定します。設定値は，固定値です。

設定値（固定値）

com.hitachi.software.was.web.ResponseCompressionFilter

URLパターンとHTTPレスポンス圧縮規則のマッピング

<filter-class><init-param>タグ内の<param-name>タグ，<param-value>タグ

URLパターンとHTTPレスポンス圧縮機能のマッピングを指定します。

詳細については，「9.2.4(1)　URLパターンとHTTPレスポンス圧縮規則のマッピング（url-mapping）」を参照してください。

HTTPレスポンス圧縮規則

HTTPレスポンスの圧縮規則として，圧縮規則名，Media-Typeと圧縮しきい値を指定します。

詳細については，「9.2.4(2)　HTTPレスポンス圧縮規則」を参照してください。

フィルタマッピング定義

<filter-mapping>タグ内の<filter-name>タグ

フィルタ名称を指定します。設定値は，固定値です。

設定値（固定値）

com.hitachi.software.was.web.ResponseCompressionFilter

<filter-mapping>タグ内の<url-pattern>タグ

URLパターンやサーブレットクラスと，HTTPレスポンス圧縮フィルタのマッピングを指定します。HTTPレスポンス圧縮機能は，フィルタマッピング定義によって，マッピングされたURLパターンを持つリソースに対してリクエストがあった場合だけ有効となります。

設定値は，任意です。

次に示すDDの定義例を基に，DDの定義内容を説明します。

     ：
<filter>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
   <init-param>
     <param-name>url-mapping</param-name>
     <param-value>
       /*=rule1;
     </param-value>
   </init-param>
   <init-param>
     <param-name>rule1</param-name>
     <param-value>
       *:1000;
     </param-value>
   </init-param>
</filter>
     ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>

<filter>タグで囲まれた部分がフィルタ定義，<filter-mapping>タグで囲まれた部分がフィルタマッピング定義となります。フィルタ定義の<filter-name>タグおよび<filter-class>タグに指定する値は，次のパッケージ名で固定です。

com.hitachi.software.was.web.ResponseCompressionFilter

次に，DDの<init-param>タグ内に定義する内容を示します。

(1)　URLパターンとHTTPレスポンス圧縮規則のマッピング（url-mapping）

HTTPレスポンス圧縮機能が有効となるURLパターンと，指定したURLパターンに適用するHTTPレスポンス圧縮規則名のマッピングを指定します。

パラメタ指定時の規則およびURLパターンのマッピング規則を示します。

(a)　パラメタ指定時の規則

URLパターンは，大文字と小文字が区別されます。

HTTPレスポンス圧縮規則名は，大文字と小文字が区別されます。

URLパターンとHTTPレスポンス圧縮規則名は，半角のイコール（=）で区切ります。

複数指定する場合は，半角のセミコロン（;）で区切ります。

複数のURLパターンに該当する場合は，先に指定したものが使用されます。

パラメタ値の改行，タブ，スペースは無視されます。

パラメタ値の末尾にある半角のセミコロン（;）は無視されます。

(b)　URLパターンのマッピング規則

url-mappingパラメタに定義するURLパターンには，パス一致，拡張子一致，および完全一致のマッピング規則が適用されます。それぞれのマッピング規則を次に示します。

パス一致

URLパターンとして「/」で始まり「/*」で終わる文字列を指定した場合は，リクエストURLのコンテキストルートからの相対パスがURLパターンの「*」を除く文字列で始まっているときに，一致したとみなされます。また，URLパターンとして「/*」を指定した場合は，すべてのリクエストURLが一致したとみなされます。

（例）

URLパターンが「/jsp/*」では，リクエストURLのコンテキストルートからの相対パスが「/jsp/index.jsp」の場合に一致したとみなされます。

拡張子一致

URLパターンとして「*.」で始まる文字列を指定した場合は，リクエストURLの拡張子とURLパターンの「*.」に続く文字列と同じであるときに，一致したとみなされます。

（例）

URLパターンが「*.jsp」では，リクエストURLのコンテキストルートからの相対パスが「/jsp/index.jsp」の場合に一致したとみなされます。

完全一致

URLパターンとして「/」で始まる上記以外の文字列を指定した場合は，リクエストURLのコンテキストルートからの相対パスがこのURLパターンと完全に同じであるときに，一致したとみなされます。

（例）

URLパターンが「/jsp/index.jsp」では，リクエストURLのコンテキストルートからの相対パスが「/ jsp/index.jsp」の場合に一致したとみなされます。

(2)　HTTPレスポンス圧縮規則

圧縮するHTTPレスポンスのMedia-Typeと圧縮しきい値を指定します。

Media-Type

HTTPレスポンス圧縮機能では，条件として指定したMedia-TypeがHTTPレスポンスに含まれる場合に，HTTPレスポンスを圧縮します。

圧縮しきい値

圧縮しきい値は，100から2,147,483,647までの整数値で指定します。デフォルトの設定では，すべてのMedia-Typeに対して圧縮しきい値「100」が適用されます。

圧縮しきい値とは，HTTPレスポンスボディのサイズによって，HTTPレスポンスを圧縮するかどうかを判定するためのしきい値です。HTTPレスポンス圧縮機能では，HTTPレスポンスボディのサイズが圧縮しきい値に定義したサイズを超える場合に，HTTPレスポンスを圧縮します。

圧縮しきい値を定義することで，HTTPレスポンスのサイズが小さい場合に，HTTPレスポンスの圧縮に掛かる時間が，通信に掛かる時間よりも大きくならないようにします。

圧縮しきい値は，圧縮するリソースの種別と通信回線の速度によって適切なサイズが決まるので，圧縮しきい値に定義するサイズは実測で求め，適切なサイズを定義することをお勧めします。

パラメタ指定時の規則を示します。

Media-Typeにアスタリスク（*）を指定した場合は，すべてのMedia-Typeを表します。ただし，Media-Typeごとの指定がある場合は，Media-Typeごとの指定が優先されます。

Media-Typeは，大文字と小文字が区別されません。

Media-Typeと圧縮しきい値は，半角のコロン（:）で区切ります。

複数指定する場合は半角のセミコロン（;）で区切ります。

同じMedia-Typeを複数指定した場合はあとに指定したものが使用されます。

パラメタ値の改行，タブ，スペースは無視されます。

パラメタ値の末尾にある半角のセミコロン（;）は無視されます。

(3)　注意事項

HTTPレスポンス圧縮フィルタの設定時の注意事項を次に示します。

レスポンス圧縮用フィルタの初期化時に，フィルタの初期化パラメタの妥当性をチェックします。ここで初期化パラメタに定義された値に問題がある場合は，フィルタの初期化処理でエラーとなり，Webアプリケーションは開始しません。

リクエストURLがurl-mappingパラメタに指定したURLパターンに一致しても，レスポンス圧縮用フィルタがマッピングされているURLパターンに一致しない場合は，url-mappingパラメタに指定したレスポンス圧縮規則が適用されることはありません。

レスポンス圧縮フィルタに複数のURLパターンをマッピングする場合は，リクエストURLが同時に複数のURLパターンに一致しないようにフィルタマッピングの定義を記述する必要があります。複数のURLパターンに対して異なるレスポンス圧縮機能を設定する場合は，url-mappingパラメタに複数のURLパターンを指定してください。

WebアプリケーションのバージョンがServlet 2.4以降の場合，<filter-mapping>の<dispatcher>タグは指定しないでください。また，<dispatcher>タグで「FORWARD」，「INCLUDE」，「ERROR」を指定した場合，Webアプリケーションの開始時にエラーが発生し，アプリケーションが開始できないので，注意してください。

9.2.5　DDの定義例

ここでは，次に示すそれぞれの場合を例に，HTTPレスポンス圧縮機能を使用するDDの定義例を示します。

HTTPレスポンスのボディサイズで圧縮条件を指定する場合

URLパターンで圧縮条件を指定する場合

HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合

圧縮条件を組み合わせて指定する場合

(1)　HTTPレスポンスのボディサイズで圧縮条件を指定する場合

HTTPレスポンスのボディサイズで圧縮条件を指定する場合の定義例を示します。

<web-app>
     ：
<!-- The filter for Response Compression Filter -->
<filter>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
   <init-param>
     <param-name>url-mapping</param-name>
     <param-value>
       /*=rule1;
     </param-value>
   </init-param>
   <init-param>
     <param-name>rule1</param-name>
     <param-value>
       *:1000;
     </param-value>
   </init-param>
</filter>
     ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
     ：
</web-app>

定義例では，URLパターンが/*のアクセスに対するHTTPレスポンスで，ボディサイズが1,000バイトを超えるものを圧縮します。

(2)　URLパターンで圧縮条件を指定する場合

URLパターンで圧縮条件を指定する場合の定義例を示します。

<web-app>
     ：
<!-- The filter for Response Compression Filter -->
<filter>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
   <init-param>
     <param-name>url-mapping</param-name>
     <param-value>
       /app/dir/*=rule1;
       *.html=rule1;
     </param-value>
   </init-param>
   <init-param>
     <param-name>rule1</param-name>
     <param-value>
       *:100;
     </param-value>
   </init-param>
</filter>
     ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <url-pattern>/app/*</url-pattern>
</filter-mapping>
     ：
</web-app>

定義例では，URLパターンが/app/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

HTTPリクエストのURLパターンが/app/dir/*で，ボディサイズが100バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが*.htmlで，ボディサイズが100バイトを超えるHTTPレスポンス

(3)　HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合

HTTPレスポンスのMedia-Typeで圧縮条件を指定する場合の定義例を示します。

<web-app>
     ：
<!-- The filter for Response Compression Filter -->
<filter>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
   <init-param>
     <param-name>url-mapping</param-name>
     <param-value>
       /*=rule1;
     </param-value>
   </init-param>
   <init-param>
     <param-name>rule1</param-name>
     <param-value>
       text/html:500;
       application/pdf:1000;
     </param-value>
   </init-param>
</filter>
     ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
     ：
</web-app>

定義例はURLパターンが/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

Media-Typeがtext/htmlでボディサイズが500バイトを超えるHTTPレスポンス

Media-Typeがapplication/pdfでボディサイズが1,000バイトを超えるHTTPレスポンス

(4)　圧縮条件を組み合わせて指定する場合

次に示す例のように，圧縮条件を組み合わせて定義することもできます。

<web-app>
     ：
<!-- The filter for Response Compression Filter -->
<filter>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <filter-class>com.hitachi.software.was.web.ResponseCompressionFilter</filter-class>
   <init-param>
     <param-name>url-mapping</param-name>
     <param-value>
       /app/dir1/*=rule1;
       /app/dir2/*=rule2;
       *.html=rule3;
     </param-value>
   </init-param>
   <init-param>
     <param-name>rule1</param-name>
     <param-value>
       *:500;
       application/pdf:1000;
     </param-value>
   </init-param>
   <init-param>
     <param-name>rule2</param-name>
     <param-value>
       application/pdf:2000;
     </param-value>
   </init-param>
   <init-param>
     <param-name>rule3</param-name>
     <param-value>
       *:100;
     </param-value>
   </init-param>
</filter>
     ：
<!-- The filter mappings for Response Compression Filter -->
<filter-mapping>
   <filter-name>com.hitachi.software.was.web.ResponseCompressionFilter</filter-name>
   <url-pattern>/app/*</url-pattern>
</filter-mapping>
     ：
</web-app>

定義例では，URLパターンが/app/*のアクセスに対するHTTPレスポンスで次の条件を満たすものを圧縮します。

HTTPリクエストのURLパターンが/app/dir1/*でMedia-Typeがapplication/pdf以外，ボディサイズが500バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが/app/dir1/*でMedia-Typeがapplication/pdf，ボディサイズが1,000バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが/app/dir2/*でMedia-Typeがapplication/pdf，ボディサイズが2,000バイトを超えるHTTPレスポンス

HTTPリクエストのURLパターンが*.htmlでボディサイズが100バイトを超えるHTTPレスポンス

9.2.6　実行環境での設定（Webアプリケーションの設定）

フィルタリングによるHTTPレスポンスの圧縮を使用する場合，Webアプリケーションの設定が必要です。

なお，Webアプリケーションの設定は，cosminexus.xmlを含まないWebアプリケーションのプロパティを設定または変更する場合にだけ参照してください。

実行環境でのWebアプリケーションの設定は，サーバ管理コマンドおよび属性ファイルで実施します。フィルタリングによるHTTPレスポンスの圧縮の定義には，フィルタ属性ファイルおよびWAR属性ファイルを使用します。

フィルタ属性ファイルおよびWAR属性ファイルで指定するタグは，DDと対応しています。DD（web.xml）での定義については，「9.2.4　DDでの定義」および「9.2.5　DDの定義例」を参照してください。

9.3　Webコンテナに関する注意事項

V9互換モードのWebコンテナで取り扱えるPOSTデータの最大サイズは2GBです。また，Webコンテナの設定や，WebコンテナのフロントにあるWebサーバやリダイレクタの設定によって，取り扱えるPOSTデータの最大サイズは制限されます。

9.4　サーブレットおよびJSPの実装時の注意事項

この節では，サーブレットおよびJSPの実装時の注意事項について説明します。

この節の構成を次の表に示します。

表9‒7　この節の構成（サーブレットおよびJSPの実装時の注意事項）

タイトル

参照先

サーブレットおよびJSP実装時共通の注意事項

9.4.1

サーブレット実装時の注意事項

9.4.2

EL2.2仕様で追加，変更された仕様についての注意事項

9.4.3

9.4.1　サーブレットおよびJSP実装時共通の注意事項

アプリケーションサーバ上で動作するアプリケーションのプログラムとして，サーブレットおよびJSPを実装するときの共通の注意事項を示します。

(1)　Webアプリケーションの動作の前提となるJ2EEアプリケーションのバージョン

Webアプリケーションの動作の前提となるJ2EEアプリケーションが準拠するJ2EE仕様のバージョンについて，Webアプリケーションのバージョンごとに次の表に示します。

表9‒8　J2EEアプリケーションが準拠するJ2EE仕様のバージョン

J2EEアプリケーションが準拠するJ2EE仕様のバージョン

Webアプリケーションに対応するServlet仕様

3.0

2.5

2.4

2.3

2.2

Java EE 6

○

○

○

○

○

Java EE 5

×

○

○

○

○

J2EE1.4

×

×

○

○

○

J2EE1.3

×

×

△

○

○

J2EE1.2

×

×

△

△

○

（凡例）

○：使用できる

△：使用できる（J2EEアプリケーションのインポート時にJ2EE仕様のバージョンが1.4に更新されるため）

×：使用できない

(2)　Webアプリケーションのサポート範囲

Webアプリケーションのバージョンは，web.xmlに記述するServlet仕様のバージョン情報で識別されます。上位のバージョンのWebアプリケーションは下位のバージョンの機能を使用できます。下位のバージョンのWebアプリケーションは上位のバージョンの機能を使用できません。

Webアプリケーションのバージョンごとに，使用できる機能範囲を次の表に示します。

表9‒9　Webアプリケーションのサポート範囲

Webアプリケーションのバージョン

Servlet

JSP

タグライブラリ※1

3.0

2.5

2.4

2.3

2.2

2.2

2.1

2.0

1.2

1.1

2.1

2.0

1.2

1.1

3.0

○

○

○

○

○

×※2

○

○

○

○

○

○

○

○

2.5

×

○

○

○

○

×

○

○

○

○

○

○

○

○

2.4

×

×

○

○

○

×

×

○

○

○

×

○

○

○

2.3

×

×

×

○

○

×

×

×

○

○

×

×

○

○

2.2

×

×

×

×

○

×

×

×

×

○

×

×

×

○

（凡例）○：使用できる　×：使用できない

注※1

タグライブラリのバージョンとは，タブライブラリ・ディスクリプタ（TLDファイル）のバージョンを表します。

注※2

JSP 2.2に対応したweb.xmlは読み込めますが，JSP 2.2で追加されたタグについては無視されます。

なお，下位のバージョンのWebアプリケーションから上位のバージョンの機能を使用した場合，エラーが発生することがあります。発生するエラーについてバージョンごとに次に示します。

表9‒10　Servlet 2.2，2.3，2.4または2.5仕様に対応するWebアプリケーションからServlet 3.0の機能を使用した場合のエラー

仕様

使用する機能

エラー時の処理

Servlet 3.0

新規APIの呼び出し

Servlet 3.0仕様で追加されたAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。

新規アノテーションの使用

アノテーションを使用してエラーとなった場合の処理については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「17.　アノテーションの使用」を参照してください。

JSP 2.2

ELの新規API

EL2.2のAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。

Servlet 2.2仕様，Servlet 2.3仕様，Servlet 2.4仕様およびServlet 2.5仕様から，Servlet 3.0仕様にWebアプリケーションのバージョンアップする場合の作業，および注意事項については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(Webコンテナ)」の「8.2.12　既存のWebアプリケーションをServlet 3.0仕様にバージョンアップする場合の留意点」を参照してください。

表9‒11　Servlet 2.2，2.3，または2.4仕様に対応するWebアプリケーションからServlet 2.5の機能を使用した場合のエラー

仕様

使用する機能

エラー時の処理

Servlet 2.5

新規APIの呼び出し

Servlet 2.5仕様で追加されたAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。

新規アノテーションの使用

アノテーションを使用してエラーとなった場合の処理については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「17.　アノテーションの使用」を参照してください。

JSP 2.1

新規ディレクティブの属性※1

サーブレットログにKDJE39145-Eのメッセージ，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2，トランスレーションエラーとなります。

TLD 2.1

Webアプリケーション開始時に次に示すTLDファイルが存在した場合，メッセージログにKDJE39293-Wのメッセージが出力され，処理されません。

web.xmlの<taglib>要素内の<tablib-location>要素に指定されたTLDファイル

/WEB-INF/libディレクトリ以下のJarファイル内の/META-INFディレクトリ以下に配置されたTLDファイル

Webアプリケーション開始時にこれら以外のTLDファイルが存在した場合は，JSPコンパイル時にメッセージログにKDJE39293-Wのメッセージが出力され，処理されません。

アプリケーションへの初回アクセス時などにJSPコンパイルが発生した場合は，サーブレットログにKDJE39145-Eのメッセージ，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2，トランスレーションエラーとなります。

ELの追加機能

JSP 2.1で追加されたEnum型については，専用の処理は実施されないで，一般のクラスと同様に処理されます。

ただし，JSP 2.1仕様で非推奨となったJSP 2.0仕様のELのAPIを使用した場合，Webアプリケーションのバージョンに関係なく，JSP 2.0仕様のELの機能範囲で処理されます。

#{}の書式のELは文字列として表示されます。

"¥#"はエスケープシーケンスとして扱われません。「"¥#"」という文字列として表示されます。

注※1

JSPページで<jsp:directive.XXX />形式でXXXにJSP仕様で未定義のディレクティブを指定した場合，または<jsp:XXX>形式でXXXにJSP仕様で未定義のスタンダードアクションを指定した場合，定義内容はそのまま出力されます。

注※2

KDJE39145-EにはJSPのコンパイルエラーの詳細，KDJE39186-Eにはトランスレーションエラーの発生通知が出力されます。

Servlet 2.2仕様，Servlet 2.3仕様およびServlet 2.4仕様から，Servlet 2.5仕様にWebアプリケーションのバージョンアップする場合の作業，および注意事項については，マニュアル「アプリケーションサーバ 機能解説基本・開発編(Webコンテナ)」の「8.2.13　既存のWebアプリケーションをServlet 2.5仕様にバージョンアップする場合の留意点」を参照してください。

表9‒12　Servlet 2.2または2.3仕様に対応するWebアプリケーションからServlet 2.4仕様の機能を使用した場合のエラー

仕様

使用する機能

エラー時の処理

Servlet 2.4

新規APIの呼び出し

Servlet 2.4仕様で追加されたAPIを使用したかどうかはチェックされません。呼び出した場合の動作は保証されないため呼び出さないよう注意してください。

新規リスナ登録

Webアプリケーションの開始時にKDJE39297-Wのメッセージがメッセージログに出力され，そのリスナ定義は無視されます。

JSP 2.0

新規ディレクティブ新規スタンダードアクション※1

サーブレットログにKDJE39145-Eのメッセージ，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2，トランスレーションエラーとなります。

タグファイル

TLDを使用しない場合

taglibディレクティブで新規属性となるtagdir属性が不正として，サーブレットログにKDJE39145-Eのメッセージ，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2，トランスレーションエラーとなります。

TLDを使用する場合

TLD 2.0を使用したエラーになります。

TLD 2.0

次に示すTLDファイルは，Webアプリケーション開始時にチェックされます。該当する場合，メッセージログにKDJE39293-Wのメッセージが出力され，無視されます。

web.xmlの<taglib><tablib-location>に指定されたTLDファイル

/WEB-INF/lib下のJarファイル内の/META-INF以下に配置されたTLDファイル

これら以外のTLDファイルは，JSPコンパイル時にチェックされます。初回アクセス時など，JSPファイルのコンパイル時は，サーブレットログにKDJE 39145-Eのメッセージ，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2，トランスレーションエラーとなります。

シンプル・タグ・ハンドラ

サーブレットログにKDJE39145-Eのメッセージを，メッセージログにKDJE39186-Eのメッセージがそれぞれ出力され※2，トランスレーションエラーとなります。

注※1

JSPページで<jsp:directive.XXX />形式でXXXにJSP仕様で未定義のディレクティブを指定した場合，または<jsp:XXX>形式でXXXにJSP仕様で未定義のスタンダードアクションを指定した場合，定義内容はそのまま出力されます。

注※2

KDJE39145-EにはJSPのコンパイルエラーの詳細，KDJE39186-Eにはトランスレーションエラーの発生通知が出力されます。

Servlet 2.2仕様およびServlet 2.3仕様から，Servlet 2.4仕様にWebアプリケーションのバージョンアップする場合の作業，および注意事項については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「8.2.15　既存のWebアプリケーションをServlet 2.4仕様にバージョンアップする場合の留意点」を参照してください。

なお，Servlet 2.2仕様に対応するWebアプリケーションからServlet 2.3の機能を使用しても，アプリケーションのインポート時にServlet 2.3仕様に準拠したWebアプリケーションに書き換えられるため，正常に処理され，エラーは通知されません。

(3)　トランザクションとJDBCコネクション利用時の注意

サーブレット，JSPでトランザクションを利用する場合，該当するサービスメソッドでJDBCコネクションを取得し，該当するサービスメソッドが終了する前に解放してください。トランザクションが開始しているサーブレットおよびJSPでは，次に示すJDBCコネクションの使用はサポートされません。

サーブレット，JSPのサービスメソッドが生成したスレッド上のJDBCコネクションを使用する。

サーブレット，JSPのサービスメソッドから呼び出した別のサーブレット，JSPのサービスメソッドでJDBCコネクションを使用する。

サーブレット，JSPのサービスメソッドのinitメソッドで取得したJDBCコネクションを使用する。

インスタンス変数に格納されたJDBCコネクションを使用する。※

注※

SingleThreadModelのサーブレットおよびJSPを使用した場合は，インスタンス変数にJDBCコネクションを格納できます。

(4)　パッケージ名の指定に関する注意

不正なパッケージ名が指定されたクラスをサーブレットおよびJSPで使用した場合，ブラウザからアクセスしたときにステータスコード500のエラーになります。例えば，作成したクラスファイルを正しく配置して，ブラウザからアクセスしても，パッケージ名の宣言に不正があった場合は，該当クラスが見つかりません。この場合，ステータスコード500のエラーが返されます。

(5)　Cookie利用時の注意

日本語などの2バイトコードを含むCookieは使用しないでください。使用した場合，サーブレットおよびJSPで利用しているHTTPセッションが失われる場合があります。

Cookieでセッション管理をする場合，ホスト名によるURLでアクセスしたサーブレットまたはJSPで生成されたセッションは，ホスト名の代わりにIPアドレスを指定したURLでアクセスしたサーブレットまたはJSPに引き継がれません（逆も同様です）。

(6)　特別な意味を持つ入力値の表示に関する注意

フォームなどで「<」や「>」などの特別な意味を持つ文字の入力値をそのまま表示した場合，悪意のあるユーザが<SCRIPT>，<OBJECT>，<APPLET>，<EMBED>のスクリプトなどを実行できるタグを使用して，重大なセキュリティ上の問題を引き起こすおそれがあります。アプリケーション開発者は，ユーザから入力されたデータに対して必ず検査をする処理を追加して，特別な意味を持つ文字を排除する必要があります。

(7)　コミット後のエラーページの表示に関する注意

サーブレットまたはJSPでレスポンスがコミットされたあとは，例外などのエラーが発生したとしても，次に示すエラーページはブラウザに表示されません。

web.xmlで指定したエラーページ

JSPのpageディレクティブのerrorPage属性で指定したエラーページ

レスポンスのコミットは，ユーザがServletResponseクラスのflushBufferメソッドなどを明示的に呼び出してコミットする場合以外にも，レスポンスのバッファが満杯になって自動的にWebコンテナがコミットすることがあります。

サーブレットまたはJSPでコミットされているかどうかを調べるには，ServletResponseクラスのisCommittedメソッドを使用します。また，バッファサイズの変更は，サーブレットの場合はServletResponseクラスのsetBufferSizeメソッドで，JSPの場合はpageディレクティブのbuffer属性の指定で実施できます。

(8)　PrintWriter，JSPWriterクラス利用時の性能向上について

PrintWriterクラスおよびJSPWriterクラスのprintメソッドとprintlnメソッドの呼び出し回数を少なくすることで，アクセス回数を減らし，性能を向上できます。例えば，StringBufferクラスを使用し，最後にprintlnメソッドを呼び出すようにして，printおよびprintlnメソッドの呼び出し回数を削減します。

(9)　javax.servlet.error.XXXXXによるエラー情報参照時の注意

Servlet 2.3仕様で定義されているjavax.servlet.error.XXXXX属性は，web.xmlの<error-page>タグに指定されたサーブレットまたはJSP内でそのエラーページを実行する要因となったエラー情報を参照するためのものです。web.xmlの<error-page>タグに指定されたサーブレットまたはJSP以外からは，これらの属性を参照しないでください。

(10)　ファイルアクセス時の注意

ファイルにアクセスする場合は，必ず絶対パスを指定してください。相対パスを指定すると，J2EEサーバは実行ディレクトリからの相対パスによって目的のパスを検索しようとします。ServletContextクラスのgetRealPathメソッドで相対パスを指定すると，WARファイルを展開したディレクトリでの相対パスが取得されます。

また，ファイルにアクセスする場合は，必ずファイルをクローズしてください。WARファイル展開ディレクトリでファイルにアクセスしてクローズしないと，J2EEサーバで正常にアンデプロイできなくなります。WARファイルの展開ディレクトリ下のパスを指定していない場合でもファイルをクローズしていないと，J2EEサーバの起動中にファイルを削除できないなどの現象が発生します。

(11)　例外発生時のエラーページの設定について

JSP，サーブレットへのアクセスで例外が発生した場合，Webコンテナのデフォルトの処理では例外のステータスコードをブラウザに返します。このデフォルトの処理を変える場合はJSPのerrorPageの指定やweb.xmlでエラーページを設定してください。

(12)　クラスローダの取得に関する注意

J2EEアプリケーション内のコードからComponent Containerのクラスローダを取得して，次に示すメソッドを使用する場合に，java.net.JarURLConnectionクラスが使用されます。

getResource(String).openConnection().getInputStream()

getResource(String).openStream()

これらのメソッドが呼び出される過程でjava.net.JarURLConnectionクラスのopenConnectionメソッドが呼び出され，該当するURLに指定されたJARファイルがオープンされます。このJARファイルはcloseメソッドを明示的に呼ばないかぎり，オープンされたままになり削除できません。これらのメソッドはJ2EEアプリケーション内で使用しないでください。また，JARファイルに対する操作が必要でjava.net.JarURLConnectionクラスのopenConnectionメソッドを使用する場合には，java.net.JarURLConnectionのgetJarFileメソッドが返すJarFileインスタンスのcloseメソッドを必ず呼び出すようにしてください。

(13)　URLConnectionクラス使用時の注意

java.net.URLConnectionクラスはsetUseCaches(boolean)メソッドを使用して，指定されたURLに対してコネクションを取得するときにキャッシュの情報を利用するかどうかを指定できます。URLConnectionクラスに対してsetUseCaches(false)メソッドを指定した場合に，コネクションごとに対象のオブジェクトが生成されます。J2EEアプリケーション内のコードから使用する場合には，J2EEサーバのJavaVMがメモリ不足となるおそれがあります。

(14)　ネイティブライブラリのロードに関する注意

System.loadLibraryメソッドを使用して，サーブレットおよびJSPからネイティブライブラリをロードしないでください。サーブレットおよびJSPでネイティブライブラリをロードすると，JNI仕様の制約によって，java.lang.UnsatisfiedLinkErrorが発生することがあります。ネイティブライブラリのロードが必要な場合は，System.loadLibraryメソッドを呼び出すコンテナ拡張ライブラリを作成し，サーブレットおよびJSPからコンテナ拡張ライブラリを参照するように実装してください。コンテナ拡張ライブラリの作成については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「19.　コンテナ拡張ライブラリ」を参照してください。

(15)　ユーザスレッドの使用方法

アプリケーションを構成するサーブレットおよびJSPからスレッドを生成して，使用できます。ユーザがプログラムの中で明示して生成するスレッドのことを，ユーザスレッドといいます。

ユーザスレッドは，生成後の動作のしかた（ライフサイクル）によって，次の二つに分けられます。

サービスメソッドやinitメソッドの範囲内で動作させる。

サービスメソッドやinitメソッドのバックグラウンドで動作させる。

ユーザスレッドの使用条件

ユーザスレッドは，Enterprise Beanでは使用できません（EJB仕様で，Enterprise Beanからのスレッドの生成が禁止されているため）。

ユーザスレッドを使用する場合のライフサイクルについて説明します。

(a)　サービスメソッドやinitメソッドの範囲内で動作させる場合

サービスメソッドやinitメソッドでユーザスレッドの処理を完了させるモデルです。このモデルの処理の流れを次の図に示します。

図9‒5　サービスメソッドやinitメソッドの範囲内で動作させる場合の処理

サービスメソッドやinitメソッドの呼び出しの範囲内で，ユーザスレッドを生成します。サービスメソッドやinitメソッドでは，joinメソッドによってユーザスレッドの処理が完了するのを待ってから，リターンします。

(b)　サービスメソッドやinitメソッドのバックグラウンドで動作させる場合

サービスメソッドやinitメソッドでユーザスレッドを生成し，その後ユーザスレッドをバックグラウンドで動作させるモデルです。このモデルの処理の流れを次の図に示します。

図9‒6　サービスメソッドやinitメソッドのバックグラウンドで動作させる場合の処理

ユーザスレッドを生成したサービスメソッドやinitメソッドは，ユーザスレッドを生成したあと，処理の完了を待たないでリターンします。ただし，アプリケーションを停止したあとは，ユーザスレッドからJ2EEサービスを利用できなくなります。したがって，アプリケーションの停止によってjavax.servlet.ServletContextListenerのcontextDestroyedメソッドか，JSPまたはServletのdestroyメソッドでユーザスレッドを停止すれば問題ありません。

(16)　セッション情報の永続化について

Webコンテナではセッション情報の永続化はサポートされません。Webコンテナではセッション情報は，正常，異常に関係なくWebコンテナが終了すると失われます。セッション情報を保持したい場合は，セッションフェイルオーバ機能を使用してください。

また，web.xmlで<distributable>タグを指定した場合，およびSerializableでないオブジェクトをセッション情報として登録した場合もIllegalArgumentExceptionは発生しません。

(17)　initメソッドおよびdestroyメソッドをオーバーライドしていない場合に出力されるメッセージ

initメソッドおよびdestroyメソッドをオーバーライドしていないサーブレットを初期化または終了すると，次の形式のログがサーブレットログに出力されます。

メッセージID：KDJE39037-I

メッセージ本文：path="aa....aa" :bb....bb: init※

aa....aa

「/」から始まるコンテキストパスを表します。

bb....bb

web.xmlの<servlet-name>タグで指定したサーブレット名を表します。デフォルトマッピングのサーブレットの場合は，「org.apache.catalina.INVOKER.<クラス名>」となります。

注※

initメソッドの場合は「init」，destroyメソッドの場合は「destroy」となります。出力されるメッセージは，それぞれjavax.servlet.GenericServletクラスのinitメソッドおよびdestroyメソッドで出力されるログです。したがって，initメソッドまたはdestroyメソッドをオーバーライドしたサーブレットではこれらのメッセージは出力されません。

また，JSPの場合は，pageディレクティブのextends属性で指定するJSPの基底クラスでinitメソッドおよびdestroyメソッドをオーバーライドしなかった場合，同様のメッセージが出力されます。その場合，サーブレット名は"com.hitachi.software.web.servlet-name.jsp"となります。JSPでpageディレクティブのextends属性を指定しなかった場合は，initメソッドのログだけが出力され，destroyメソッドのログは出力されません。

ただし，サーブレットの場合もJSPの場合も，initメソッドおよびdestroyメソッドをオーバーライドしてスーパークラスのinitメソッドおよびdestroyメソッドを呼ぶときは，このメッセージを出力します。

(18)　javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性について

javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性について，Servletで例外をスローした場合とJSPファイルで例外をスローした場合の二つに分けて説明します。

(a)　Servletで例外をスローした場合

Servletでスローした例外クラスがjava.lang.Error，またはその派生クラスの場合

javax.servlet.ServletExceptionクラスの例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。Servletでスローした例外は，javax.servlet.ServletExceptionクラスのgetRootCauseメソッドで取得できます。

Servletでスローした例外クラスがjava.lang.Error，またはその派生クラス以外のクラスの場合

Servletでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。

(b)　JSPファイルで例外をスローした場合

エラーページがJSPファイルの場合

web.xmlの<error-page>タグでエラーページを指定した場合

web.xmlの<error-page>タグでエラーページを指定した場合について，JSP 2.0以降とJSP 1.2に分けて示します。

JSP 2.0以降

JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。

JSP 1.2

JSPファイルでスローした例外クラスが次のクラスのどれかであれば，JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。

・java.io.IOException，またはその派生クラス

・java.lang.RuntimeException，またはその派生クラス

・javax.servlet.ServletException，またはその派生クラス

JSPファイルでスローした例外クラスがこれら以外の場合，javax.servlet.ServletExceptionクラスの例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。JSPファイルでスローした例外は，javax.servlet.ServletExceptionクラスのgetRootCauseメソッドで取得できます。

pageディレクティブのerrorPage属性でエラーページを指定した場合

pageディレクティブのerrorPage属性でエラーページを指定した場合について，エラーページでpageディレクティブのisErrorPage属性にtrueを指定した場合とfalseを指定した場合に分けて示します。

エラーページでpageディレクティブのisErrorPage属性にtrueを指定した場合

JSPファイルでスローした例外がjavax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に設定されます。

エラーページでpageディレクティブのisErrorPage属性にfalseを指定した場合

javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に値は設定されません。

エラーページがServletの場合

web.xmlの<error-page>タグでエラーページを指定した場合

エラーページがJSPファイルの場合の，web.xmlの<error-page>タグでエラーページを指定した場合と同様です。

pageディレクティブのerrorPage属性でエラーページを指定した場合

javax.servlet.ServletRequestオブジェクトのjavax.servlet.error.exception属性に値は設定されません。

(19)　バイナリデータを含むWebアプリケーションの操作について

バイナリデータを含むWebアプリケーションでは，次のことに注意してください。

クライアントから送信されたバイナリデータへのリクエストを実行する場合

バイナリデータへのリクエストで適用されるフィルタ内で，レスポンスオブジェクトからのPrintWriterを取得しないでください。

クライアントから送信されたリクエストを処理するサーブレットまたはJSPがディスパッチする場合

次の場所では，レスポンスオブジェクトからのPrintWriterを取得しないでください。

バイナリデータへのリクエストで適用されるフィルタ内

バイナリデータにディスパッチするサーブレットまたはJSP内

参考

バイナリデータとは，拡張子にマッピングされたMIMEタイプが"text/"から始まっていない静的コンテンツ，またはマッピングが存在しない静的コンテンツです。

(20)　レスポンスの文字エンコーディングに関する注意

JSPまたはサーブレットのレスポンスボディの文字エンコーディングが，UTF-16（16ビットUCS変換形式）の場合，ブラウザによって正しく表示できない場合があります。その場合は，JSPまたはサーブレットの文字エンコーディングに，UTF-16BE（16ビットUCS変換形式のビッグエンディアンバイト順），またはUTF-16LE（16ビットUCS変換形式のリトルエンディアンバイト順）を使用してください。

(21)　javax.servlet.ServletRequestインタフェースのgetServerNameメソッドおよびgetServerPortメソッドの戻り値について

getServerNameメソッド，およびgetServerPortメソッドの戻り値について説明します。

Servlet 2.4仕様以降では，Hostヘッダの有無によって，getServerNameメソッド，およびgetServerPortメソッドの戻り値が異なります。Servlet 2.4仕様以降でのgetServerNameメソッド，およびgetServerPortメソッドの戻り値を次の表に示します。

表9‒13　getServerNameメソッド，およびgetServerPortメソッドの戻り値（Servlet 2.4仕様以降の場合）

Hostヘッダの有無

getServerNameメソッドの戻り値

getServerPortメソッドの戻り値

あり

Hostヘッダの「:」より前の部分

Hostヘッダの「:」よりあとの部分

なし

解決されたサーバ名またはIPアドレス

クライアントとの接続を受け付けたサーバのポート番号

アプリケーションサーバでは，getServerNameメソッド，およびgetServerPortメソッドの戻り値は，HTTPリクエストと，使用する機能の組み合わせによって得られます。なお，HTTP 1.1のリクエストにHostヘッダが含まれない場合，HTTP 1.1仕様に従って，400エラーとなります。また，HTTP 1.1仕様では，リクエストラインのリクエストURIが絶対URIの場合，ホストにはリクエストURIのホストを使用して，Hostヘッダの内容は無視するように定義されています。なお，Servlet仕様では明記されていませんが，HTTP仕様に従って，リクエストラインのURIに含まれるホスト名を優先するようになっています。

HTTPリクエストと，使用する機能の組み合わせによって得られる，getServerNameメソッド，およびgetServerPortメソッドの戻り値を次の表に示します。なお，ゲートウェイ指定機能を使用している場合の，getServerNameメソッド，およびgetServerPortメソッドの戻り値については，表9-13を参照してください。

表9‒14　getServerNameメソッド，およびgetServerPortメソッドの戻り値（アプリケーションサーバの場合）

HTTPリクエスト

使用する機能

getServerNameメソッドの戻り値

getServerPortメソッドの戻り値

Hostヘッダの有無

リクエストラインのURIの種類

あり

絶対URI

Webサーバ連携

リクエストラインのホスト名

リクエストラインのポート番号

インプロセスHTTPサーバ

リクエストラインのホスト名

リクエストラインのポート番号

相対URI

Webサーバ連携

Hostヘッダのホスト名

Hostヘッダのポート番号

インプロセスHTTPサーバ

Hostヘッダのホスト名

Hostヘッダのポート番号

なし

絶対URI

Webサーバ連携

リクエストラインのホスト名

リクエストラインのポート番号

インプロセスHTTPサーバ

リクエストラインのホスト名

リクエストラインのポート番号

相対URI

Webサーバ連携

Webサーバのホスト名またはIPアドレス※2

Webサーバのポート番号

インプロセスHTTPサーバ

J2EEサーバのホスト名またはIPアドレス※1

インプロセスHTTPサーバのポート番号

注※1　java.net.InetAddress.getLocalHostメソッド，またはgetHostNameメソッドの戻り値となります。

注※2　HTTP Serverを使用する場合，ServerNameディレクティブに指定した値となります。ServerNameディレクティブについては，マニュアル「HTTP Server」を参照してください。

ゲートウェイ指定機能使用時のgetServerNameメソッド，およびgetServerPortメソッドの戻り値を次の表に示します。

表9‒15　ゲートウェイ指定機能使用時のgetServerNameメソッド，およびgetServerPortメソッドの戻り値（アプリケーションサーバの場合）

HTTPリクエスト

使用する機能

getServerNameメソッドの戻り値

getServerPortメソッドの戻り値

Hostヘッダの有無

リクエストラインのURIの種類

あり

絶対URI

Webサーバ連携

リクエストラインのホスト名

リクエストラインのポート番号

インプロセスHTTPサーバ

リクエストラインのホスト名

リクエストラインのポート番号

相対URI

Webサーバ連携

Hostヘッダのホスト名

Hostヘッダのポート番号

インプロセスHTTPサーバ

Hostヘッダのホスト名

Hostヘッダのポート番号

なし

絶対URI

Webサーバ連携

ゲートウェイ指定機能で指定したホスト名

ゲートウェイ指定機能で指定したポート番号

インプロセスHTTPサーバ

リクエストラインのホスト名

リクエストラインのポート番号

相対URI

Webサーバ連携

ゲートウェイ指定機能で指定したホスト名

ゲートウェイ指定機能で指定したポート番号

インプロセスHTTPサーバ

ゲートウェイ指定機能で指定したホスト名

ゲートウェイ指定機能で指定したポート番号

(22)　javax.servlet.ServletExceptionクラスのコンストラクタで指定した根本原因の例外の取得について

アプリケーションサーバでは，コンストラクタServletException(String, Throwable)またはServletException(Throwable)で指定した根本原因の例外をgetCauseメソッドで取得できます。なお，getRootCauseメソッドでも取得できます。ただし，07-60以前のバージョンではgetCauseメソッドにはnullを返します。

javax.servlet.ServletExceptionクラスのコンストラクタで指定した根本原因の例外の取得について，互換用のパラメタおよび注意事項について説明します。

互換用のパラメタ

07-60以前と同じ動作にする場合，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内で互換用のパラメタwebserver.servlet_api.exception.getCause.backcompatにtrueを指定します。パラメタの詳細は，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」を参照してください。

互換用のパラメタwebserver.servlet_api.exception.getCause.backcompatの指定値によるgetCauseメソッドおよびgetRootCauseメソッドの戻り値の違いを次の表に示します。

表9‒16　webserver.servlet_api.exception.getCause.backcompatの指定値によるgetCauseメソッドおよびgetRootCauseメソッドの戻り値の違い

メソッド

webserver.servlet_api.exception.getCause.backcompatの指定値

true

false

getCause()

×

○

getRootCause()

○

○

（凡例）○：根本原因の例外を返す　×： nullを返す

なお，この互換用のパラメタの指定内容は，javax.servlet.jsp.JspExceptionクラスのgetCauseメソッドおよびgetRootCauseメソッドの動作にも適用されます。

注意事項

根本原因の例外をgetCauseメソッドの実装によって取得できる場合，コンストラクタServletException(String, Throwable)またはServletException(Throwable)で生成したServletExceptionオブジェクトに対してinitCause(Throwable)を呼び出すことはできません。initCause(Throwable)を呼び出した場合，java.lang.IllegalStateException例外がスローされます。

(23)　javax.servlet.ServletOutputStreamオブジェクトに対するflushメソッドの実行についての注意

アプリケーションサーバでは，javax.servlet.ServletResponseオブジェクトから取得するjavax.servlet.ServletOutputStreamオブジェクトに対して，closeメソッドを実行したあとでflushメソッドを実行しても，java.io.IOException例外をスローしません。

(24)　リクエストURIの正規化

アプリケーションサーバでは，リクエストURIに含まれる文字列は，正規化されたあと，次に示すマッチング処理で使用されます。

コンテキストパスとコンテキストルートのマッチング

サーブレットおよびJSPのURLパターンとのマッチング

デフォルトマッピングとのマッチング

静的コンテンツとのマッチング

フィルタのURLパターンとのマッチング

web.xmlの<error-page>タグ，またはJSPのpageディレクティブのerrPage属性で指定するエラーページとのマッチング

アクセスを制限するURLパターンとのマッチング

ログイン認証のURL判定

リクエストのフォワードおよびインクルード

HTTPレスポンス圧縮フィルタのURLパターンとのマッチング

URLグループ単位の同時実行スレッド数制御のURLパターンとのマッチング

インプロセスHTTPサーバのエラーページのカスタマイズ

インプロセスHTTPサーバのリダイレクトによるリクエストの振り分け

(25)　javax.servlet.http.HttpServletRequestインタフェースのgetRequestURIメソッドおよびgetRequestURLメソッドの戻り値について

javax.servlet.http.HttpServletRequestインタフェースのgetRequestURIメソッドおよびgetRequestURLメソッドでは，正規化されたURLが戻り値となります。

(26)　welcomeファイルにURLマッピングされたServletまたはJSPの指定

リクエストURLがURLマッピングされたServletまたはJSPと一致しないで，welcomeファイルに転送される必要がある場合，Webコンテナでは次のように転送先のwelcomeファイルが選択されます。

まず，指定されたwelcomeファイル名から静的コンテンツやJSPファイルの候補が優先して選択されます。該当するものがない場合，URLマッピングされたServletまたはJSPの候補が選択されます。

welcomeファイルに関する注意事項について説明します。

welcomeファイル転送方式による制約

welcomeファイルの転送は，HTTPリダイレクト（HTTPステータスコード302でブラウザがリダイレクトする）によって実現しています。この転送方式には制約があるため，URL設計の際に次のことに注意してください。

POSTリクエストを受け付けた際，ブラウザから送信されたリクエストボディの情報を転送先のwelcomeファイルに引き継げません。POSTされた情報がフォーム入力形式（Content-Typeがapplication/x-www-form-urlencoded）の場合だけ，Webコンテナが生成するwelcomeファイル転送先URLのクエリ文字列に情報を付与する形で引き継げます。ただし，この場合も，リクエストボディの情報が多い場合に転送先URLが長くなり過ぎる，ブラウザのアドレスバーにクエリ文字列として情報がそのまま見える，などについて考慮が必要です。

転送先のwelcomeファイルのサーブレットがdoGetメソッドを実装していない場合，ブラウザに「400 Bad Request」（HTTP/1.1以外の場合）または「405 Method Not Allowed」（HTTP/1.1の場合）が表示されます。

Webアプリケーションからjavax.servlet.RequestDispatcherインタフェースのincludeメソッドを呼び出した際，インクルードする対象のURLとしてwelcomeファイルが存在するディレクトリを指定していても，転送先のwelcomeファイルのコンテンツは挿入されません。

JSP事前コンパイル済み環境でのwelcomeファイルの追加

JSP事前コンパイル済みのWebアプリケーションに，welcomeファイルに指定したJSPファイルを追加する場合，JSPファイルの追加後にJSP事前コンパイルを再度実行する必要があります。JSP事前コンパイルを再度実行しなかった場合，正しくwelcomeファイル転送処理が実行されません。

サーブレットクラスが参照できないサーブレットのwelcomeファイルの指定

サーブレットクラスが参照できないサーブレットをwelcomeファイルに指定しないでください。サーブレットクラスが参照できないサーブレットを指定した場合，正しくwelcomeファイル転送処理が実行されません。

ディレクトリが存在しないパスへのwelcomeファイル要求

Webアプリケーション内のリソースとして存在しないディレクトリのパスに対するリクエストの場合，リクエストURLの末尾が「/」であってもwelcomeファイル転送処理は実行されません。

(27)　サーブレット，フィルタ，リスナの開始・終了順序

Webアプリケーションを開始すると，リクエストの受付を開始する前に次の順序で初期化処理をすることがServlet 2.4仕様で明確化されました。アプリケーションサーバでは，Servlet2.3以前のWebアプリケーションでも同じ順序で初期化処理をします。Webアプリケーション開始時のサーブレット，フィルタ，およびリスナは次の順序で開始されます。

リスナの開始（インスタンスの生成※1，@PostConstructアノテーションのメソッドおよびServletContextListenerのcontextInitializedメソッドの呼び出し※2）

フィルタの開始（インスタンスの生成※1，@PostConstructアノテーションのメソッドおよびinitメソッドの呼び出し）

load-on-startupタグで指定されたServlet/JSPの開始（インスタンスの生成※1，@PostConstructアノテーションのメソッドおよびinitメソッドの呼び出し）

注※1　Servlet 3.0以降では，API呼び出しによって動的にサーブレット，フィルタ，リスナを追加できますが，インスタンスを指定するAPI呼び出しによって定義を追加したサーブレット，フィルタ，リスナについては，インスタンス生成済みのため，Webコンテナではインスタンスを生成しません。

注※2　リスナのcontextInitialized()メソッドの呼び出しで例外が発生しても，KDJE39103-Eのメッセージを出力してWebアプリケーションの開始処理を継続します。

なお，web.xmlの<load-on-startup>要素によってWebアプリケーション開始時の初期化処理実行を指定しなかったサーブレットについては，初回リクエスト実行時にサーブレットのインスタンスの生成およびinit()メソッドを呼び出します。

このとき，サーブレットのインスタンスの生成およびinit()メソッドはフィルタより前に呼び出します。

Webアプリケーション終了時のサーブレット，フィルタ，およびリスナは次の順序で終了します。

開始済みのServlet/JSPの終了(destroyメソッド，@PreDestroyアノテーションのメソッド呼び出し)

フィルタの終了(destroyメソッド，@PreDestroyアノテーションのメソッド呼び出し)

リスナの終了(@PreDestroyアノテーションのメソッド呼び出し)

(28)　Webアプリケーション内の静的コンテンツへのアクセス

Webアプリケーション内の静的コンテンツへのアクセス時に使用できるメソッドは，GET，HEAD，POST，TRACE，OPTIONSのどれかです。

POSTメソッドを使用した場合，GETメソッド使用時と同様，静的コンテンツの内容を応答します。

(29)　文字エンコーディングに関する注意

同じWebアプリケーション内では，web.xmlで指定したエラーページと，HTTPレスポンスに文字エンコーディングを使用するサーブレットおよびJSPに，同じ文字エンコーディングを使用してください。

(30)　クエリ文字列にイコール（"="）以降だけ指定した場合の戻り値について

リクエストのクエリ文字列にイコール（"="）以降しか指定していない場合（例えば，http://localhost/application/getparam.jsp?=paramのような場合），使用しているWebサーバ種別によって，javax.servlet.ServletRequestインタフェースのリクエストパラメタを取得するServlet APIの戻り値が異なります。

Webサーバ種別ごとのServlet APIの戻り値を次に示します。

Webサーバ連携機能または簡易Webサーバを使用している場合

getParameterメソッド

空文字（""）を指定するとイコール（"="）以降に指定されたパラメタを返します。

getParameterMapメソッド

空文字（""）をキーとするパラメタを含むjava.util.Mapオブジェクトを返します。

getParameterNamesメソッド

空文字（""）を含むjava.util.Enumerationオブジェクトを返します。

getParameterValuesメソッド

空文字（""）を指定するとイコール（"="）以降に指定されたパラメタを返します。

インプロセスHTTPサーバを使用している場合

getParameterメソッド

空文字（""）を指定してもnullを返します。

getParameterMapメソッド

空のjava.util.Mapオブジェクトを返します。

getParameterNamesメソッド

空のjava.util.Enumerationオブジェクトを返します。

getParameterValuesメソッド

空文字（""）を指定してもnullを返します。

(31)　javax.servlet.http.HttpServletResponseインタフェースのcontainsHeaderメソッドについて

以下のレスポンスヘッダはWebコンテナにより自動的にレスポンスにセットされる場合があります。このようなレスポンスヘッダは，javax.servlet.http.HttpServletResponseインタフェースのcontainsHeaderメソッドで，レスポンスにセットされているかどうかを確認できません。

Webサーバ連携の場合

Content-Length

Content-Type

Set-Cookie

インプロセスHTTPサーバの場合

Connection

Content-Language

Content-Length

Content-Type

Date

Server

Set-Cookie

Transfer-Encoding

(32)　アプリケーションサーバのライブラリに関する注意

アプリケーションサーバのライブラリをJ2EEアプリケーションに含めると，ライブラリのバージョン不整合などが原因で，アプリケーションのインポートや開始，実行で不正な動作になることがあります。そのため，製品が使用方法として明示している場合を除いて，アプリケーションサーバのライブラリはJ2EEアプリケーションに含めないようにしてください。

9.4.2　サーブレット実装時の注意事項

サーブレットを実装するときの注意事項を示します。

(1)　ゲートウェイ指定機能を使用する場合の注意

Webコンテナにゲートウェイ情報を通知し，welcomeファイルやFORM認証画面に正しくリダイレクトするゲートウェイ指定機能を使用できます。ゲートウェイ指定機能については，「5.10　Webコンテナへのゲートウェイ情報の通知」を参照してください。

ゲートウェイ指定機能を使用する場合，一部のサーブレットAPIの動作が変わります。ゲートウェイ指定機能使用時のサーブレットAPIの注意事項を，使用するメソッドごとに示します。

javax.servlet.http.HttpServletResponseクラスのsendRedirectメソッド

引数に相対URLを指定し，Hostヘッダのないリクエストの場合，リダイレクト先URLのホスト名とポート番号は，ゲートウェイ指定機能で指定した値となります。引数に相対URLを指定し，ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合，リダイレクト先URLのスキームは常に「https」となります。

javax.servlet.ServletRequestインタフェースのgetRequestURLメソッド

ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合，戻り値は常に「https://」で始まるURLとなります。

javax.servlet.ServletRequestインタフェースのgetServerNameメソッド

ゲートウェイ指定機能でリダイレクト先URLのホスト名を指定し，リクエストにHostヘッダがない場合，戻り値は指定した値となります。

javax.servlet.ServletRequestインタフェースのgetServerPortメソッド

ゲートウェイ指定機能でリダイレクト先URLのポート番号を指定し，リクエストにHostヘッダがない場合，戻り値は指定した値となります。ゲートウェイ指定機能でリダイレクト先URLのホスト名を指定し，ポート番号を省略した場合，戻り値はリクエストのスキームがhttpであれば「80」，httpsであれば「443」となります。

javax.servlet.ServletRequestインタフェースのgetSchemeメソッド

ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合，戻り値は常に「https」となります。

javax.servlet.ServletRequestインタフェースのisSecureメソッド

ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合，戻り値は常に「true」となります。

javax.servlet.ServletRequestインタフェースのgetAttributeメソッド

ゲートウェイ指定機能でスキームをhttpsと見なすように設定した場合でも，次の属性は取得できません。

javax.servlet.request.cipher_suite（WebサーバにMicrosoft IISを使用している場合は，ゲートウェイ指定機能の使用に関係なく取得できません）

javax.servlet.request.key_size

javax.servlet.request.X509Certificate

9.4.3　EL2.2仕様で追加，変更された仕様についての注意事項

EL2.2仕様で追加，変更された仕様を，アプリケーションサーバ上で使用するときの注意事項を示します。EL2.2仕様については，EL2.2仕様書を参照してください。

アプリケーションサーバではEL2.2をサポートしますが，EL2.1の処理系とEL2.2の処理系の両方を保持します。使用する処理系は簡易構築定義ファイルの次のパラメタで切り替えられます。このパラメタは簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。

webserver.jsp.el2_2.enabled

webserver.jsp.el2_2.enabledパラメタの詳細については，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.11.2　J2EEサーバ用ユーザプロパティを設定するパラメタ」を参照してください。

一つのBean内に同じ数のパラメタを持つメソッドが複数定義された場合，最初に定義されたメソッドに型変換されます。そのため，メソッドを呼び出すときの引数の型が，最初に定義されたメソッドに合う場合は正しく呼び出されますが，引数の型が合わない場合はELExceptionが発生します。

9.5　V9互換モードで事前コンパイルをする場合の注意事項

V9互換モードでJSPの事前コンパイルをする場合の注意事項を次に示します。

JSPの事前コンパイルコマンド（cjjspc）は推奨モード用とV9互換モード用でインストール先が異なります。V9互換モード用の事前コンパイルコマンドのインストール先については，「17.　Webアプリケーションで使用するコマンド」を参照してください。

推奨モードで事前コンパイルした結果をV9互換モードで実行できません。使用した場合の動作は未サポートです。

第3編　リファレンス（V9互換モード）

10　J2EEサーバで使用するファイル

この章では，J2EEサーバで使用するファイルの形式，格納先，機能，指定できるキーなどについて説明します。ここでは，推奨モードと異なる内容だけ説明します。

10.1　J2EEサーバで使用するファイルの詳細

10.1.1　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）

(1)　cosminexus.jpaから始まるキー

指定できるキーについて次に示します。なお「省略値」とは，キーの指定がない場合に仮定される値です。

「VR」とは，キーが導入・変更されたアプリケーションサーバのバージョンです。

キー名称

内容

省略値

VR

cosminexus.jpa.logging.level.operation.<category>

J2EEサーバのJPA機能を利用する場合に，JPAプロバイダ稼働ログのカテゴリごとのログレベルを指定します。カテゴリ名，およびログレベルは大文字と小文字を区別します。

未設定の場合，稼働ログには出力されません。セキュリティや性能面に対する影響があるため，出力レベルの設定には注意してください。

Offを指定した場合：

JPAプロバイダ稼働ログに対するログを出力しません。

Informationを指定した場合：

JPAプロバイダ稼働ログにJPAの稼働情報を出力します。

Detailを指定した場合：

JPAプロバイダ稼働ログにJPAの詳細な稼働情報および，Informationで出力される情報を出力します。

Off

08-00

cosminexus.jpa.exception.logging.sql※

JPAプロバイダがSQL文を実行してデータベースから例外を受け取った場合に，例外メッセージに例外が発生した原因となったSQL文を含むどうかを指定します。

Offを指定した場合：

JPAプロバイダが実行したSQL文と?パラメタ（プレースホルダ）への指定値を例外メッセージに含みません。

Informationを指定した場合：

JPAプロバイダが実行したSQL文を例外メッセージに含みます。

Detailを指定した場合：

JPAプロバイダが実行したSQL文と?パラメタ（プレースホルダ）への指定値を例外メッセージに含みます。

Off

08-00

注※

このプロパティで指定した値は，例外ログの出力内容にも反映されます。

Information，およびDetailの場合は，SQL文や?パラメータ（プレースホルダ）の内容が例外ログにも出力されるため，セキュリティに注意してください。開発時や保守のために必要に応じて値を指定してください。

バイナリデータを扱う場合，?パラメータ（プレースホルダ）にはバイナリオブジェクトのハッシュ値が出力されます。

SQL発行の準備が完了する以前に通信異常によるコネクション取得エラーなどが発生した場合, ?パラメータ（プレースホルダ）値を取得できない場合があります。

(2)　ejbserver.jpaから始まるキー

指定できるキーについて次に示します。なお「省略値」とは，キーの指定がない場合に仮定される値です。

「VR」とは，キーが導入・変更されたアプリケーションサーバのバージョンです。

キー名称

内容

省略値

VR

ejbserver.jpa.defaultJtaDsName

デフォルトのJTAデータソースの参照を指定します。このプロパティはpersistence.xmlのjta-data-sourceを指定しなかった場合，または空白文字を指定した場合に使用されます。

なし

08-00

ejbserver.jpa.defaultNonJtaDsName

デフォルトの非JTAデータソースの参照を指定します。このプロパティはpersistence.xmlのnon-jta-data-sourceを指定しなかった場合または空白文字を指定した場合に使用されます。

なし

08-00

ejbserver.jpa.defaultProviderClassName

デフォルトのJPAプロバイダクラス名を指定するプロパティです。このプロパティは，persistence.xmlのproviderを指定しなかった場合または空白文字が指定した場合に使用されます。

com.hitachi.software.jpa.PersistenceProvider

08-00

ejbserver.jpa.disable※

アプリケーションサーバのJPA機能を使用する場合に指定します。

trueを指定した場合：

アプリケーションサーバのJPA機能は無効になります。

falseを指定した場合：

アプリケーションサーバのJPA機能は有効になります。

false

08-20

ejbserver.jpa.overrideJtaDsName

persistence.xmlのjta-data-sourceに指定した値，およびejbserver.jpa.defaultJtaDsNameに指定した値より優先して使用するJTAデータソースの参照を指定します。

なし

08-00

ejbserver.jpa.overrideNonJtaDsName

persistence.xmlのnon-jta-data-sourceに指定した値，およびejbserver.jpa.defaultNonJtaDsNameに指定した値より優先して使用する非JTAデータソースの参照を指定します。

なし

08-00

ejbserver.jpa.overrideProvider

persistence.xmlのproviderに指定した値，およびejbserver.jpa.defaultProviderClassNameに指定した値より優先して使用するJPAプロバイダクラス名を指定します。

なし

08-00

ejbserver.jpa.emfprop.<property key>

JPAプロバイダ独自のプロパティのキーを指定します。すべての永続化ユニットのデプロイ時に，「ejbserver.jpa.emfprop.」プリフィックスを除去したプロパティがJPAプロバイダに渡されます。

なし

08-00

注※　ejbserver.jpa.disable=trueを指定した場合の注意事項

アプリケーションにpersistence.xmlが含まれる場合，アプリケーションサーバはアプリケーション開始時にpersistence.xmlを読み込まなくなります。また，アプリケーションのリロード機能を利用している場合，persistence.xmlが更新検知の対象ではなくなります。

アプリケーションがアプリケーションサーバの管理する永続化コンテキストまたは永続化ユニットを利用している場合，アプリケーションの開始ができなくなります。

(3)　ejbserver.loggerから始まるキー

指定できるキーについて次に示します。なお「省略値」とは，キーの指定がない場合に仮定される値です。

「VR」とは，キーが導入・変更されたアプリケーションサーバのバージョンです。

「関連情報」とは，指定したキーに関する情報の参照先です。マニュアル名称の「アプリケーションサーバ」を省略しています。

キー名称

内容

省略値

VR

関連情報

ejbserver.logger.channels.define.<チャネル名>※.filenum

J2EEサーバのログファイルの面数を，1〜16の整数で指定します。

チャネル名がWebAccessLogFileの場合

16

チャネル名がMaintenanceLogFileまたはWebServletLogFileの場合

4

チャネル名が上記以外の場合

2

−

ejbserver.logger.channels.define.<チャネル名>※.filesize

J2EEサーバのログファイルのサイズ（単位：バイト）を，4096〜2147483647の整数で指定します。

チャネル名がWebAccessLogFileの場合

2097152

チャネル名がMaintenanceLogFileの場合

16777216

チャネル名がWebServletLogFileの場合

4194304

チャネル名が上記以外の場合

1048576

−

（凡例）

−：08-00より前のバージョンを示します。

空欄：関連情報はありません。

注※

チャネル名称として次に示す名称を設定できます。

アプリケーションサーバシステムのログ出力用のチャネル

MessageLogFile，MaintenanceLogFile，ExceptionLogFile，ConsoleLogFile，EJBContainerLogFile，WebContainerLogFile，WebServletLogFile，UserOutLogFile，UserErrLogFile，WebAccessLogFile，JPAOperationLogFile，JPAMaintenanceLogFile

リソース枯渇監視ログ出力用のチャネル

MemoryWatchLogFile，FileDescriptorWatchLogFile，ThreadWatchLogFile，ThreaddumpWatchLogFile，RequestQueueWatchLogFile，HttpSessionWatchLogFile，ConnectionPoolWatchLogFile

資料の取得については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「2.3　資料の取得」を参照してください。

(4)　ejbserver.serverから始まるキー

指定できるキーについて次に示します。なお「省略値」とは，キーの指定がない場合に仮定される値です。

「VR」とは，キーが導入・変更されたアプリケーションサーバのバージョンです。

「関連情報」とは，指定したキーに関する情報の参照先です。マニュアル名称の「アプリケーションサーバ」を省略しています。

キー名称

内容

省略値

VR

関連情報

ejbserver.server.eheap.ajp13.enabled

リダイレクタとの通信用オブジェクトをExplicitヒープに配置するかどうかを指定します。

trueを指定した場合：

リダイレクタとの通信用オブジェクトをExplicitヒープに配置します。

falseを指定した場合：

リダイレクタとの通信用オブジェクトをJavaヒープ領域に配置します。

ただし，JavaVMオプションHitachiUseExplicitMemoryを無効にした場合，このプロパティは無効（false指定時と同じ挙動）となります。

true

08-00

（凡例）

空欄：関連情報はありません。

(5)　webserver.connectorから始まるキー

指定できるキーについて次に示します。なお「省略値」とは，キーの指定がない場合に仮定される値です。

「VR」とは，キーが導入・変更されたアプリケーションサーバのバージョンです。

「関連情報」とは，指定したキーに関する情報の参照先です。マニュアル名称の「アプリケーションサーバ」を省略しています。

キー名称

内容

省略値

VR

関連情報

webserver.connector.ajp13.backlog

リダイレクタからの接続要求の最大の待ち行列数を指定します。1〜2147483647の整数で指定します。

有効な最大値は実行するプラットフォームで指定できるSocketのListenキューの最大値となります。実際のListenキューの最大値はOSによって異なるため，詳細は各OSのlisten関数についてのマニュアルを参照してください。

このキーに指定した値は，java.net.ServerSocketクラスのコンストラクタのbacklog引数に設定されます。ただし，この指定値がOSの制限値を超えた場合は，OSの制限値が設定されたものと解釈され，エラーにはなりません。制限値はOSによって異なります。制限値を拡張する方法については，OSのマニュアルを参照してください。

100

−

webserver.connector.ajp13.bind_host

Webサーバ連携で使用するIPアドレスまたはホスト名称を指定します。

IPアドレス，またはホスト名称の前後の半角スペースは無視されます。値を指定しない場合は，ワイルドカードアドレスが使用されます。

このプロパティを指定するときは，ワーカホスト名称にもローカルホスト名称またはIPアドレスを指定する必要があります。

同一ホストで実行しているWebサーバとWebサーバ連携をしている構成で，次のどちらかの設定をしている場合，WebコンテナはWebサーバからのリクエストを受信できません。

webserver.connector.ajp13.bind_hostプロパティにローカルホスト名称，またはIPアドレスを指定し，リダイレクタのワーカホスト名称にlocalhostなどのループバックアドレスを指定している。

webserver.connector.ajp13.bind_hostプロパティにlocalhostなどのループバックアドレスを指定し，リダイレクタのワーカホスト名称にローカルホスト名称，またはIPアドレスを指定している。

なし

−

「5.7　IPアドレス指定（Webサーバ連携）」

webserver.connector.ajp13.max_threads

Webコンテナがリクエストを処理する同時実行数を指定します。※1

1〜1024の整数で指定します。

指定されたリクエストの同時実行数分のスレッドがサーバ起動時に生成されます。

10

−

「機能解説 基本・開発編(Webコンテナ)」の「2.14　Webコンテナ単位での同時実行スレッド数の制御」

webserver.connector.ajp13.port

Webサーバとの通信に使用するポート番号を指定します。

1〜65535の整数で指定します。

すでにほかのアプリケーションで使用または確保されているポート番号は指定できません。また，複数のJ2EEサーバでWebサーバとの通信に使用するポートのポート番号に同じ値を設定しないでください。同一のポート番号を指定したJ2EEサーバはcjstartsvコマンドで複数起動できません。

8007

−

webserver.connector.ajp13.receive_timeout

リクエスト受信処理のリダイレクタへのデータ要求処理で，リダイレクタからの応答を待つ時間（通信タイムアウト値）を0〜3600の整数（単位：秒）で指定します。

0を指定した場合は，リダイレクタからの応答を受け取るまで待ち続け，タイムアウトは発生しません。

600（秒）

−

webserver.connector.ajp13.send_timeout

レスポンス送信処理のタイムアウト値を0〜3600の整数（単位：秒）で指定します。

数値以外の文字列や範囲外の数値を指定した場合は，メッセージを出力し，デフォルト値を使用します。

タイムアウト値に0，またはTCPの持つデータ送信の再送タイマより長い時間を設定した場合，タイムアウト値はTCPの持つタイムアウト値になります。その場合，不正なタイムアウト値が指定されたことを示すメッセージは出力されません。

600

−

webserver.connector.inprocess_http.backlog

Webクライアントからの接続要求を格納するTCPリスンキューの長さを1〜2147483647の整数で指定します。

有効な指定値の最大値や実際に設定されるTCPリスンキューの長さはOSによって異なります。

数値以外の文字列，範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

511

−

webserver.connector.inprocess_http.bind_host

インプロセスHTTPサーバで使用するIPアドレスまたはホスト名を指定します。

IPアドレスまたはホスト名の前後の半角スペースは無視されます。値を指定しない場合は，ワイルドカードアドレスが使用されます。

指定されたホスト名またはIPアドレスが解決できない場合，ローカルではないホストのホスト名またはIPアドレスを指定した場合はメッセージが出力され，ワイルドカードアドレスが使用されます。

なし

−

webserver.connector.inprocess_http.enabled

インプロセスHTTPサーバ機能を有効にするかどうかを指定します。

trueを指定した場合：

インプロセスHTTPサーバ機能を有効にします。

falseを指定した場合：

インプロセスHTTPサーバ機能を無効にします。

trueまたはfalse以外の文字列を指定した場合，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

なお，インプロセスHTTPサーバ機能が有効の場合は，Webサーバ連携は使用できません。

false

−

webserver.connector.inprocess_http.enabled_methods

アクセスを許可するHTTPメソッドを指定します。

複数のメソッドを指定する場合は，コンマ（,）で区切ります。メソッド名にはHTTP/1.1で定義されたメソッドを指定します。

また，アスタリスク（*）を指定した場合は，すべてのメソッドが許可されます。

HTTPメソッドでは大文字，小文字が区別されるため，このプロパティに指定する値も区別されます。

メソッド名にはRFC2616で規定されている値を使用する必要があります。ただし，文字列"*"をメソッド名として指定できません。

各メソッド名の前後の空白文字※2は無視されます。不正な値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

GET,HEAD,POST,PUT,DELETE,OPTIONS

−

webserver.connector.inprocess_http.error_custom.list

エラーページカスタマイズ機能で使用するエラーページカスタマイズ定義名を指定します。

指定できる値の最大長は1024文字で，英数字（A〜Z，a〜z，0〜9）またはアンダースコア（_）で構成される文字列で指定します。定義名一つの文字列長は1〜32文字です。

定義名を複数指定する場合は，コンマ（,）で区切ります。コンマの前後の空白文字※2は無視されます。また，同じエラーページカスタマイズ定義名を複数回指定できません。

不正な値を指定した場合，メッセージが出力され，すべてのエラーページカスタマイズ定義は無効となります。

なし

−

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.file

エラーページカスタマイズ機能で，エラーページカスタマイズ時のレスポンスボディとして使用するファイルを絶対パスで指定します。

パスの区切り記号には”/”を使用します。

webserver.connector.inprocess_http.error_custom.listで設定されていないエラーページカスタマイズ定義名を使用してこのプロパティを設定した場合，プロパティは無効になります。

webserver.connector.inprocess_http.error_custom.listで指定したエラーページカスタマイズ定義名について，このプロパティ，またはwebserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.redirect_urlのどちらか一方だけを必ず指定してください。両方のプロパティを指定した場合，どちらも指定しなかった場合，絶対パスで指定しなかった場合，または存在しないファイルや読み取り権限のないファイルを指定した場合は，メッセージが出力され，このエラーページカスタマイズ定義は無効となります。

空文字列または空白文字※2を指定した場合，プロパティは無効になります。

なし

−

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.file.content_type

エラーページカスタマイズ機能で，エラーページカスタマイズ時のレスポンスのContent-Typeヘッダの値を指定します。

webserver.connector.inprocess_http.error_custom.listで設定されていないエラーページカスタマイズ定義名を使用してこのプロパティを設定した場合，プロパティは無効となります。

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.fileが設定されていない場合，プロパティは無効になります。

text/html

−

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.redirect_url

エラーページカスタマイズ機能で，リダイレクトURLを絶対パスで指定します。

webserver.connector.inprocess_http.error_custom.listで設定されていないエラーページカスタマイズ定義名を使用してこのプロパティを設定した場合，プロパティは無効となります。

webserver.connector.inprocess_http.error_custom.listで指定したエラーページカスタマイズ定義名について，このプロパティ，またはwebserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.fileのどちらか一方だけを必ず指定してください。

値が正しいかどうかのチェックは行われないため，実際に動作させて確認する必要があります。

なし

−

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.request_url

エラーページカスタマイズ機能で，エラーページカスタマイズを適用するリクエストURLをスラッシュ（/）で始まる絶対パスで指定します。ワイルドカード（*）はスラッシュの直後に1回だけ指定できます。"*"は必ずワイルドカードと解釈されるため，通常の文字としては使用できません。

また，このプロパティで指定した値とwebserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.statusで指定した値は，ほかのエラーページカスタマイズ定義と完全に一致してはいけません。

webserver.connector.inprocess_http.error_custom.listで設定されていないエラーページカスタマイズ定義名を使用してこのプロパティを設定した場合，プロパティは無効となります。

不正な値を指定した場合，メッセージが出力され，このエラーページカスタマイズ定義は無効となります。

/*

−

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.status

エラーページカスタマイズ機能で，エラーページのカスタマイズを行うレスポンスのステータスコードを400〜599の整数で指定します。

このプロパティで指定した値，およびwebserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.request_urlで指定した値は，ほかのエラーページカスタマイズ定義と完全に一致してはいけません。

webserver.connector.inprocess_http.error_custom.listで設定されていないエラーページカスタマイズ定義名を使用してこのプロパティを設定した場合，プロパティは無効となります。

webserver.connector.inprocess_http.error_custom.listで指定したエラーページカスタマイズ定義名について，このプロパティは必ず指定してください。指定しなかった場合，または不正な値を指定した場合，メッセージが出力され，このエラーページカスタマイズ定義は無効となります。

なし

−

webserver.connector.inprocess_http.gateway.host

ゲートウェイのホスト名またはIPアドレスを指定します。Hostヘッダのないリクエストに対してwelcomeファイルなどにリダイレクトするとき，Locationヘッダに指定するURLのホスト名部分が指定値となります。

なし

−

webserver.connector.inprocess_http.gateway.port

ゲートウェイのポート番号を1〜65535の整数で指定します。

Hostヘッダのないリクエストに対してwelcomeファイルなどにリダイレクトするとき，Locationヘッダに指定するURLのポート番号部分が指定値となります。

webserver.connector.inprocess_http.gateway.hostが指定されていない場合は，このプロパティの指定は無視されます。

また，webserver.connector.inprocess_http.gateway.hostを指定し，このプロパティを省略した場合は下記の値が設定されます。

webserver.connector.inprocess_http.gateway.https_schemeにtrueを指定している場合：443

webserver.connector.inprocess_http.gateway.https_schemeにfalseを指定している場合，または未指定の場合：80

数値以外の文字列，または範囲外の数値を指定した場合は，メッセージが出力され，指定されなかったものとみなされます。

なし

−

webserver.connector.inprocess_http.gateway.https_scheme

クライアントからのリクエストのスキームはhttpsで，SSLアクセラレータなどによってWebサーバへのスキームがhttpとなる場合にtrueを指定します。

trueを指定した場合：

Webサーバへのリクエストのスキームがhttpsとみなされます。

falseを指定した場合：

何もしません。

trueまたはfalse以外の文字列を指定した場合，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

false

−

webserver.connector.inprocess_http.hostname_lookups

インプロセスHTTPサーバで受信したリクエストに対して，Webコンテナがホスト名のルックアップの逆引きをしてクライアントのIPアドレスをホスト名に変換するかどうかを指定します。

ただし，ホスト名の逆引きをすると，スループットが低下します。

ホスト名を解決しなかった場合，javax.servlet.ServletRequestインタフェースのgetRemoteHost()メソッドの結果や，ログファイルに出力するクライアントのIPアドレスは，ドット（.）で区切られた書式のIPアドレスとなります。

trueを指定した場合：

IPアドレスをホスト名に変換します。

falseを指定した場合：

IPアドレスをホスト名に変換しません。

trueまたはfalse以外の文字列を指定した場合，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

false

−

webserver.connector.inprocess_http.init_threads

サーバ起動時に生成するインプロセスHTTPサーバのリクエスト処理スレッド数を1〜1024の整数で指定します。

指定する値は，Webクライアントとの最大接続数（webserver.connector.inprocess_http.max_connectionsに指定した値）以下である必要があります。これを超える値を指定した場合，メッセージが出力され，Webクライアントとの最大接続数が値として設定されます。

また，有効な最大値は実行するOSによって異なります。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

10

−

webserver.connector.inprocess_http.keep_start_threads

サーバ起動時に作成したスレッド数を維持するかどうかを指定します。

trueを指定した場合：

サーバ起動時に作成したスレッド数を維持します。プールに保持された予備スレッド数が，予備スレッド数の最大数（webserver.connector.inprocess_http.max_spare_threadsに指定した値）を超えた状態でも，サーバ起動時に作成したスレッド数を下回りません。

falseを指定した場合：

サーバ起動時に作成したスレッド数を維持しません。予備スレッドとして保持する最大数，最小数に従って調節します。

また，サーバ起動時に作成したスレッド数が予備スレッド数の最小数（webserver.connector.inprocess_http.min_spare_threadsに指定した値）よりも小さい場合，このプロパティの設定に関係なく予備スレッドの最小数に指定した値でスレッド数が維持されます。

このプロパティにfalseを指定した場合，サーバ起動時に作成したスレッドは予備スレッド数の最大数以下になるように調整されます。サーバ起動時に予備スレッドの最大数より大きい数のリクエスト処理スレッドを作成した場合，予備スレッドの最大数を超えたスレッドは，サーバ起動後に1秒間隔で一つずつ破棄されます。

trueまたはfalse以外の文字列を指定した場合，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

false

−

webserver.connector.inprocess_http.limit.max_headers

HTTPリクエストに含まれるHTTPヘッダの個数の上限を0〜32767の整数で指定します。上限値を設定しない場合は，0を指定してください。

このプロパティで指定したHTTPヘッダの個数に満たない場合でも，webserver.connector.inprocess_http.limit.max_request_headerで指定したサイズを超えた場合はエラーとなります。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

100

−

webserver.connector.inprocess_http.limit.max_request_body

HTTPリクエストのリクエストボディの最大サイズ（単位：バイト）を-1〜2147483647の整数で指定します。上限値を設定しない場合は，-1を指定してください。また，リクエストボディがチャンク形式で送信された場合，チャンクヘッダのサイズも指定するサイズに含める必要があります。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

-1

−

webserver.connector.inprocess_http.limit.max_request_header

HTTPリクエストのリクエストヘッダの最大サイズ（単位：バイト）を7〜65536の整数で指定します。

このプロパティで設定したリクエストヘッダの最大サイズに満たない場合でも，webserver.connector.inprocess_http.limit.max_headersで指定したHTTPヘッダを超えた場合はエラーとなります。

また，HTTPヘッダの終わりを示す改行文字（CR(0x0d)+LF(0x0a)の2バイト）も指定するサイズに含める必要があります。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

16384

−

webserver.connector.inprocess_http.limit.max_request_line

リクエストラインの最大長（単位：バイト）を-1または7〜8190の整数で指定します。上限値を指定しない場合は，-1を指定してください。リクエストラインは，HTTPメソッドやクエリ文字列を含む，URIおよびHTTPバージョンを含みます。

指定する値は，リクエストヘッダの最大サイズ（webserver.connector.inprocess_http.limit.max_request_headerに指定した値）以下である必要があります。これを超える値を指定した場合は，メッセージが出力され，リクエストヘッダの最大サイズがリクエストラインの最大長として設定されます。

また，リクエストラインの終わりを示す改行文字（CR(0x0d)+LF(0x0a)の2バイト）も指定するサイズに含める必要があります。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

8190

−

webserver.connector.inprocess_http.max_connections

Webクライアントとの最大接続数を1〜1024の整数で指定します。有効な最大値は実行するOSによって異なります。

このパラメタに指定した値がリクエスト処理スレッドの最大値になります。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

100

−

webserver.connector.inprocess_http.max_execute_threads

Webコンテナがリクエストを処理する同時実行数を1〜1024の整数で指定します。

指定する値は，Webクライアントとの最大接続数（webserver.connector.inprocess_http.max_connectionsに指定した値）以下である必要があります。これを超える値を指定した場合は，メッセージが出力され，Webクライアントとの最大接続数が値に設定されます。

数値以外の文字列や範囲外の数値，空文字列または，空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

10

−

webserver.connector.inprocess_http.max_spare_threads

プールに保存する予備スレッドの最大数を1〜1024の整数で指定します。

指定する値は，Webクライアントとの最大接続数（webserver.connector.inprocess_http.max_connectionsに指定した値）以下である必要があります。これを超える値を指定した場合は，メッセージが出力され，Webクライアントとの最大接続数が値に設定されます。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

20

−

webserver.connector.inprocess_http.min_spare_threads

プールに保持する予備スレッドの最小数を1〜1024の整数で指定します。

設定する値はプールに保持する予備スレッドの最大数（webserver.connector.inprocess_http.max_spare_threadsに指定した値）以下である必要があります。プールに保持する予備スレッドの最大数を超える値を設定した場合は，メッセージが出力され，プールに保持する予備スレッドの最大数がプールに保持する予備スレッドの最小数として設定されます。

数値以外の文字列や範囲外の数値，空文字列，または空白文字※2を指定した場合は，メッセージが出力されデフォルト値が設定されます。

5

−

webserver.connector.inprocess_http.permitted.hosts

インプロセスHTTPサーバへのアクセスを許可するホストのIPアドレス（10進表記），またはホスト名を指定します。複数指定する場合は，IPアドレスまたはホスト名の間をコンマ（,）で区切ります。アクセス制限をしない場合はアスタリスク（*）だけを指定します。

なお，ローカルホスト（"localhost"に関連づけられたアドレス※3）は明記しなくても常にアクセスが許可されます。

空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

指定されたホスト名が解決できない場合は，メッセージが出力され，ローカルホスト（"localhost"に関連づけられたアドレス※3）からのアクセスだけが許可されます。

なお，IPアドレスまたはホスト名の前後の半角スペースは無視されます。

*

−

webserver.connector.inprocess_http.persistent_connection.max_connections

Persistent Connectionで保持するTCPコネクションの最大数を0〜1024の整数で指定します。

設定する値はWebクライアントとの最大接続数（webserver.connector.inprocess_http.max_connectionsに指定した値）以下である必要があります。Webクライアントとの最大接続数を超える値を設定した場合は，メッセージが出力され，Webクライアントとの最大接続数がPersistent Connectionで保持するTCPコネクションの最大数として設定されます。

数値以外の文字列や範囲外の数値を指定した場合は，メッセージが出力され，webserver.connector.inprocess_http.max_connectionsに指定した値がデフォルト値として設定されます。また，空文字列または空白文字※2を指定した場合は，webserver.connector.inprocess_http.max_connectionsに指定した値がデフォルト値として設定されます。

webserver.connector.inprocess_http.max_connectionsに指定した値

−

webserver.connector.inprocess_http.persistent_connection.max_requests

Persistent ConnectionによるTCPコネクションを持続したままの連続接続回数の上限を0〜2147483647の整数で指定します。上限値を設定しない場合は，0を指定してください。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

100

−

webserver.connector.inprocess_http.persistent_connection.timeout

Persistent ConnectionでTCPコネクションを持続した状態での，リクエスト待ち時間（単位：秒）を0〜3600の整数で指定します。0を指定した場合，タイムアウトしません。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

3

−

webserver.connector.inprocess_http.port

インプロセスHTTPサーバが使用するポート番号を1〜65535の整数で指定します。すでにほかのアプリケーションで使用されているポート番号は指定できません。ほかのアプリケーションで使用されているポート番号や確保されているポート番号を指定した場合，メッセージが出力され，J2EEサーバが起動されません。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

80

−

webserver.connector.inprocess_http.receive_timeout

Webクライアントからのリクエスト受信で，タイムアウトするまでの時間（単位：秒）を0〜3600の整数で指定します。0を指定した場合，タイムアウトしません。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

300

−

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.file

リダイレクト機能で，リダイレクト時のレスポンスボディとして使用するファイルを絶対パスで指定します。パスの区切り記号には”/”を使用します。

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.statusに200を指定した場合，必ずこのプロパティを指定します。webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.statusに200を指定し，このプロパティが指定されていない場合，メッセージが出力され，このリダイレクト定義は無効となります。

webserver.connector.inprocess_http.redirect.listで設定されていないリダイレクト定義名を使用してこのプロパティを設定した場合，空文字列または空白文字※2を指定した場合，プロパティは無効となります。

絶対パスでない値を指定した場合は，メッセージが出力され，このリダイレクト定義は無効となります。存在しないファイルや読み取り権限のないファイルを指定した場合は，J2EEサーバ起動時にメッセージが出力され，このリダイレクト定義は無効となります。

なし

−

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.file.content_type

リダイレクト機能で，リダイレクト時のレスポンスのContent-Typeヘッダの値を指定します。

webserver.connector.inprocess_http.redirect.listで設定されていないリダイレクト定義名を使用してこのプロパティを設定した場合，プロパティは無効となります。

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.fileを設定していない場合，プロパティは無効となります。

text/html

−

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.redirect_url

リダイレクト機能で，リダイレクトURLを絶対URLで指定します。

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.status に 200を指定した場合，このプロパティは設定できません。webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.statusに200を指定し，このプロパティを指定した場合，メッセージが出力され，リダイレクト定義は無効となります。

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.statusに200以外を指定した場合，必ずこのプロパティを指定します。webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.status に 200以外を指定し，このプロパティを指定しなかった場合，メッセージが出力され，そのリダイレクト定義は無効となります。

webserver.connector.inprocess_http.redirect.listで設定されていないリダイレクト定義名を使用してこのプロパティを設定した場合，プロパティは無効となります。

値が正しいかどうかのチェックは行われないため，実際に動作させて確認する必要があります。

なし

−

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.request_url

リダイレクト機能で，リダイレクトを行うリクエストURLをスラッシュ（/）で始まる絶対パスで指定します。ワイルドカード（*）はスラッシュの直後に1回だけ指定できます。ワイルドカードは0文字以上の任意の文字列を表します。"*"は必ずワイルドカードと解釈されるため，通常の文字としては使用できません。また，ほかのリダイレクト定義で指定した値と同じ値は指定できません。

webserver.connector.inprocess_http.redirect.listで指定したリダイレクト定義名について，必ずこのプロパティを指定する必要があります。指定しなかった場合，メッセージが出力され，そのリダイレクト定義は無効となります。

webserver.connector.inprocess_http.redirect.listで設定されていないリダイレクト定義名を使用してこのプロパティを設定した場合，プロパティは無効となります。

不正な値を指定した場合は，メッセージが出力され，そのリダイレクト定義は無効となります。

なし

−

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.status

リダイレクト機能で，リダイレクト時のレスポンスのステータスコード（200，300，301，302，303，305，307）を指定します。

webserver.connector.inprocess_http.redirect.listで設定されていないリダイレクト定義名を使用してこのプロパティを設定した場合，プロパティは無効となります。

不正な値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

302

−

webserver.connector.inprocess_http.redirect.list

リダイレクト機能で使用するリダイレクト定義名を指定します。

このプロパティに指定できる値の最大長は1024文字です。リダイレクト定義名は，英数字（A〜Z，a〜z，0〜9）またはアンダースコア（_）で構成される文字列で指定します。また，リダイレクト定義名一つの文字列長は1文字〜32文字です。

リダイレクト定義名を複数指定する場合は，コンマ（,）で区切ります。コンマの前後の空白文字※2は無視されます。同じリダイレクト定義名は複数回指定できません。

不正な値を指定した場合は，メッセージが出力され，すべてのリダイレクト定義は無効となります。

なし

−

webserver.connector.inprocess_http.rejection_threads

アクセスを拒否するリクエスト処理スレッドの数を0〜1023の整数で指定します。指定する値は，リクエスト処理スレッドの最大数（webserver.connector.inprocess_http. max_connectionsに指定した値）よりも小さくする必要があります。Webクライアントとの最大接続数以上の値を設定した場合は，メッセージが出力され，Webクライアントとの最大接続数よりも1小さい値がアクセスを拒否するリクエスト処理スレッド数として設定されます。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

1

−

webserver.connector.inprocess_http.response.header.server

レスポンスに自動的に付加するServerヘッダの値を指定します。

空文字列または空白文字※2を指定した場合，メッセージが出力され，デフォルト値が設定されます。

CosminexusComponentContainer

−

webserver.connector.inprocess_http.send_timeout

Webクライアントへのレスポンス送信で，タイムアウトするまでの時間（単位：秒）を0〜3600の整数で指定します。0を指定した場合，タイムアウトは有効になりません。

数値以外の文字列や範囲外の数値，空文字列または空白文字※2を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

300

−

webserver.connector.limit.max_fileupload_count

ファイルアップロードを実施するリクエストに含まれるアップロードファイル数の上限値を-1〜2147483647の整数で指定します。

上限値を設定しない場合は，-1を指定します。

数値以外の文字列や範囲外の数値，空文字列または空白文字を指定した場合は，メッセージが出力され，デフォルト値が設定されます。

ファイル数が上限値を超えたことを検知すると，ファイルシステムへのファイル作成を実施する前にエラーとしKDJE39606-Eを出力します。

アップロードファイル数が指定した上限値を超える場合，次のAPI呼び出し時にIllegalStateExceptionをスローします。

javax.servlet.http.HttpServletRequest.getPart(String)

javax.servlet.http.HttpServletRequest.getParts()

また，リクエストのアップロードファイル数が指定した上限値を超える場合，次のAPIを実行してもマルチパートで送信されたリクエストパラメタは取得できません。

javax.servlet.ServletRequest.getParameter(String)

javax.servlet.ServletRequest.getParameterMap()

javax.servlet.ServletRequest.getParameterNames()

javax.servlet.ServletRequest.getParameterValues(String)

10000

11-00-10

（凡例）

−：08-00より前のバージョンを示します。

注※1

有効な最大値は実行するプラットフォームに依存します。

Webサーバに到着するリクエストの一部がWebコンテナに転送されるため，Webサーバの最大同時接続数は，URLグループ単位，Webアプリケーション単位およびデフォルトの実行待ちキューサイズの総和＋Webコンテナ単位の最大同時実行スレッド数より大きく設定する必要があります。

また，データベース操作をするサーブレットやJSPについては，データベースコネクションの数よりも多くの多重度は得られないため，Webコンテナの同時実行数を増やす場合は，利用できるデータベースコネクションの数も増やす必要があります。

性能のチューニング時には，次に示す関係を常に考慮して，各パラメタの値を調整してください。

<Webサーバの最大同時接続数> ＞ <URLグループ単位，Webアプリケーション単位およびデフォルトの実行待ちキューサイズの総和>＋<Webコンテナ単位の最大同時実行スレッド数>

<Webコンテナ単位の最大同時実行スレッド数> ≧ <データベースコネクションの数>

Webコンテナ単位での同時実行スレッド数の制御については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.14　Webコンテナ単位での同時実行スレッド数の制御」を参照してください。

Webサーバでの処理の同時接続数についてはWebサーバのマニュアルを参照してください。

注※2

空白文字とは，半角スペース，タブ，LF（0x0a），CR（0x0d）またはFF（0x0c）のことを指します。

注※3

J2EEサーバ起動時に"localhost"に関連づけられたアドレスになります。

(6)　webserver.containerから始まるキー

指定できるキーについて次に示します。なお「省略値」とは，キーの指定がない場合に仮定される値です。

「VR」とは，キーが導入・変更されたアプリケーションサーバのバージョンです。

「関連情報」とは，指定したキーに関する情報の参照先です。マニュアル名称の「アプリケーションサーバ」を省略しています。

キー名称

内容

省略値

VR

関連情報

webserver.container.ac.logEnabled

Webコンテナの保守用のトレースログを出力するかどうかを指定します。

trueを指定した場合：

トレースログを出力します。

falseを指定した場合：

トレースログを出力しません。

false

−

（凡例）

−：08-00より前のバージョンを示します。

10.1.2　server.policy（J2EEサーバ用セキュリティポリシーファイル）

(1)　形式

J2SEのセキュリティポリシーファイル形式に従います。

(2)　ファイルの格納先

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥server¥usrconf¥ejb¥<サーバ名称>¥

UNIXの場合

/opt/Cosminexus/CC/server/usrconf/ejb/<サーバ名称>/

(3)　機能

J2EEサーバを実行するJavaVMのセキュリティポリシーを指定します。

J2EEサーバの稼働中に，このファイルの内容を変更した場合，変更した内容は次にJ2EEサーバを起動したときに反映されます。

(4)　記述例

使用されるポリシーファイルの内容を次に示します。

// (1)
// Grant all permissions to anything loaded from the
// EJB server itself

grant codeBase "file:${ejbserver.install.root}/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${tpbroker.java.home}/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/DABJ/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/manager/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/c4web/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/c4web/exlib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/jaxws/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/jaxrs/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/jaxp/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/CTM/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/PRF/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/wss/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/XMLSEC/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${ejbserver.install.root}/sfo/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${hntrlib.home}/classes/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${cosminexus.home}/common/lib/*" {
permission java.security.AllPermission;
};
grant codeBase "file:${ejbserver.install.root}/weld/lib/*" {
permission java.security.AllPermission;
};

// (2)
// Grant all permissions to the container generated stubs and
// implementation classes
grant codeBase "file:${ejbserver.http.root}/ejb/${ejbserver.serverName}/containers/-" {
permission java.security.AllPermission;
};

// (3)
// Grant all permissions to imported resource (datasource) implementations
// implementation classes
grant codeBase "http://*/ejb/${ejbserver.serverName}/import/resjars/-" {
permission java.security.AllPermission;
};

// (4)
// Grant permissions to resource adapters
//
grant codeBase "file:${ejbserver.http.root}/ejb/${ejbserver.serverName}/rarjars/-" {

// For uCosminexus TP1 Connector & TP1/Client/J
permission java.util.PropertyPermission "*", "read, write";

// For uCosminexus TP1 Connector & TP1/Client/J & Cosminexus Reliable Messaging
permission java.io.FilePermission "<<ALL FILES>>", "read, write, delete";
permission java.net.SocketPermission "*", "connect,listen,accept";

// For TP1/Message Queue - Access
permission java.lang.RuntimePermission "loadLibrary.*";

// For TP1/Message Queue - Access & Cosminexus Reliable Messaging
permission java.lang.RuntimePermission "modifyThreadGroup";
permission java.lang.RuntimePermission "modifyThread";

// For DB Connector
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";

// For authentication (from J2EE RI server.policy file)
permission javax.security.auth.PrivateCredentialPermission "* * ¥"*¥"", "read";

// For Cosminexus Reliable Messaging
permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
permission java.lang.RuntimePermission "getenv.HRMDIR";

// For Cosminexus SOA FTP Inbound Adapter
permission java.lang.RuntimePermission "getClassLoader";
permission java.lang.RuntimePermission "setContextClassLoader";
permission java.lang.RuntimePermission "accessDeclaredMembers";
};

// (5)
// Grant permissions to JSP/Servlet
//
grant codeBase "file:${ejbserver.http.root}/web/${ejbserver.serverName}/-" {
permission java.lang.RuntimePermission "loadLibrary.*";
permission java.lang.RuntimePermission "queuePrintJob";
permission java.lang.RuntimePermission "modifyThread";
permission java.lang.RuntimePermission "modifyThreadGroup";
permission java.net.SocketPermission "*", "connect";
permission java.io.FilePermission "<<ALL FILES>>", "read, write";
permission java.util.PropertyPermission "*", "read";
permission javax.security.auth.AuthPermission "getSubject";
permission javax.security.auth.AuthPermission "createLoginContext.*";
};

// (6)
// Grant permissions to Cosminexus Service Coordinator
//
grant codeBase "file:${cosminexus.home}/CSC/lib/*" {
permission java.security.AllPermission;
};

// (7)
// Grant permissions to custom login modules
//
grant codeBase "file:${cosminexus.home}/manager/modules/-" {
permission java.io.FilePermission "<<ALL FILES>>", "read";
permission javax.security.auth.AuthPermission "modifyPrincipals";
permission javax.security.auth.AuthPermission "modifyPublicCredentials";
};

// (8)
// Grant minimal permissions to everything else:
//  EJBs
//  client implementation classes
grant  {
permission java.util.PropertyPermission "*", "read";
permission java.lang.RuntimePermission "queuePrintJob";
permission java.net.SocketPermission "*", "connect";
};

記述例の（1）〜（8）について説明します。

（1）

J2EEサーバが使用するクラスファイルに対して次の権限を許可します。

すべてのアクセス権を許可

（2）

J2EEサーバが生成するスタブとスケルトンなどのクラスファイルに対して次の権限を許可します。

すべてのアクセス権を許可

（3）

J2EEサーバが使用するリソースのクラスファイルに対して次の権限を許可します。

すべてのアクセス権を許可

（4）

J2EEサーバが使用するリソースアダプタのクラスファイルに対して次の権限を許可します。

すべてのプロパティ情報に対して読み取り，および書き込みを許可

すべてのファイルに対して読み取り，書き込み，および削除を許可

すべてのソケット通信に対してネットワークへの接続，接続での待機，および接続の受け付けを許可

すべてのライブラリのロードを許可

スレッドグループの変更を許可

スレッドの変更を許可

すべてのリフレクション操作を許可

任意のSubjectが所有する，すべての非公開Credentialへのアクセスを許可

Subjectに関連づけられた非公開CredentialのSetの変更を許可

環境変数HRMDIRの値の取得を許可

クラスローダの取得を許可

コンテキストクラスローダの設定を許可

クラスの宣言されたメンバへのアクセスを許可

注意事項

リソースアダプタ内のJARファイルの展開先であるJ2EEサーバ管理下のディレクトリが記載されています。

J2EEサーバで動作するすべてのリソースアダプタが有効範囲です。

（5）

JSP／サーブレットのクラスファイルに対して次の権限を許可します。

すべてのライブラリのロードを許可

印刷ジョブ要求を許可

スレッドの変更を許可

スレッドグループの変更を許可

すべてのソケット通信に対してネットワーク接続を許可

すべてのファイルに対して読み取り，および書き込みを許可

すべてのプロパティ情報の読み取りを許可

Subjectの参照を許可

あらゆる名称でLoginContextクラスのインスタンス化を許可

注意事項

次の定義は，07-00より前の環境で構築したサーバには記載されていません。Webアプリケーションでユーザスレッドを作成する必要がある場合，追加してください。

permission java.lang.RuntimePermission "modifyThread";

permission java.lang.RuntimePermission "modifyThreadGroup";

（6）

Service Coordinatorのクラスファイルに対し次の権限を許可します。

すべてのアクセス権を許可

（7）

統合ユーザ管理のカスタムログインモジュールに対し次の権限を許可します。

すべてのファイルに対する読み込みを許可

SubjectにPrincipalおよびCredentialの追加を許可

（8）

すべてのクラスファイルに対して次の権限を許可します。

すべてのプロパティ情報の読み取りを許可

印刷ジョブ要求を許可

すべてのソケット通信に対してネットワーク接続を許可

(5)　注意事項

構文が不正または適切なアクセス権限が設定されていないserver.policyファイルを使用した場合，java.lang.StackOverflowErrorまたはjava.lang.OutOfMemoryErrorが発生してJ2EEサーバが異常終了することがあります。

サーバをセットアップするときに生成されたserver.policyファイルには，J2EEサーバを動作させるために最低限必要な権限が記述されています。生成されたserver.policyファイルの記述行の削除および変更はしないでください。

11　Smart Composer機能で使用するファイル

この章では，Smart Composer機能で使用するファイルの形式，格納先，機能，指定できるキーなどについて説明します。ここでは，推奨モードと異なる内容だけ説明します。

11.1　論理Webサーバで指定できるパラメタ

ここでは，論理Webサーバで指定できるパラメタについて説明します。

11.1.1　HTTP Server用リダイレクタ動作定義を設定するパラメタ

HTTP Server用リダイレクタ動作定義を設定するパラメタについて，次の表に示します。

「省略値」とは，パラメタの指定がない場合に仮定される値です。「VR」とは，パラメタが導入・変更されたアプリケーションサーバのバージョンです。なお，「param-name指定値」に対応するparam-valueの指定内容については，「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。

注

AllTextパラメタを指定する場合，HTTP Server用リダイレクタ動作定義を設定するパラメタの指定を有効にするには，設定ファイルの内容に次の記述を含めてください。

Include "<Application Serverのインストールディレクトリ>/CC/web/redirector/servers/<論理Webサーバ>/mod_jk.conf"

表11‒1　HTTP Server用リダイレクタ動作定義を設定するパラメタ

param-name指定値

指定可能値

省略値

VR

JkConnectTimeout

0〜3600の整数で指定します。

30

07-00

JkGatewayHost

次のどれかを指定します。

IPv4アドレス

ホスト名

なお，ホスト名には，英数字，アンダースコア「_」，ピリオド「.」，およびハイフン「-」で指定した255文字以内の文字列を指定してください。

なし

07-50

JkGatewayHttpsScheme

次のどちらかを指定します。

On

Off

このパラメタについては，「5.10　Webコンテナへのゲートウェイ情報の通知」を参照してください。

Off

06-50

JkGatewayPort

1〜65535の整数で指定します。

なし

07-50

JkLogFileDir

任意の文字列を指定します。

logs

06-50

JkLogFileNum

1〜64の整数で指定します。

8

06-50

07-50

JkLogFileSize

4096〜2147483647の整数で指定します。

4194304

06-50

07-50

JkLogLevel

次のどれかを指定します。

emerg

error

info

debug

error

06-50

JkModulePriority

次のどれかを指定します。

REALLY_FIRST（整数値の-10に対応）

FIRST（整数値の0に対応）

MIDDLE（整数値の10に対応）

LAST（整数値の20に対応）

REALLY_LAST（整数値の30に対応）

-10〜30の整数

FIRST

07-00

JkMount

次の形式で指定します。

<URLパターン> <ワーカ名>

<ワーカ名>にはワーカの定義でworker.listに指定した名称を使用してください。ワーカの定義とworker.listについては「11.1.2　ワーカ定義を設定するパラメタ」を参照してください。

注

同一のJ2EEサーバを複数のワーカ名で定義しないでください。そのようなワーカをJkMountに指定した場合の動作は保証されません。

combined-tierとhttp-tierの場合※

/* ［J2EEサーバ名］

注

同時に［J2EEサーバ名］がworker（タイプ：ajp13）として設定されます。

07-50

JkPrfId

英数字を31文字以内で指定します。

「TSC」,「tsc」または「CTM」や「ctm」で始まる文字列を指定した場合，エラーになります。

なし

free-tier以外の場合，値は自動で設定されます。

07-50

JkRequestRetryCount

1〜16の整数で指定します。

3

07-00

JkSendTimeout

0〜3600の整数で指定します。

100

07-00

JkTraceLog

次のどちらかを指定します。

On

Off

On

06-50

JkTraceLogFileDir

任意の文字列を指定します。

logs

06-50

JkTraceLogFileNum

1〜64の整数で指定します。

4

06-50

07-50

JkTraceLogFileSize

4096〜2147483647の整数で指定します。

16777216

06-50

07-50

JkTranslateBackcompat

次のどちらかを指定します。

On

Off

Off

06-50

注

キーを複数指定した場合，最後に指定した値が有効になります。

注※

なお，combined-tierとhttp-tierでこのパラメタを省略した場合，次のように関連するパラメタに値が設定されます。

<param>

<param-name>JkMount</param-name>

<param-value>/* [J2EEサーバ名]</param-value>

</param>

<param>

<param-name>worker.list</param-name>

<param-value>[J2EEサーバ名]</param-value>

</param>

<param>

<param-name>worker.[J2EEサーバ名].host</param-name>

<param-value>[ホスト名]</param-value>

</param>

<param>

<param-name>worker.[J2EEサーバ名].port</param-name>

<param-value>[ポート番号]</param-value>

</param>

<param>

<param-name>worker.[J2EEサーバ名].type</param-name>

<param-value>ajp13</param-value>

</param>

11.1.2　ワーカ定義を設定するパラメタ

ワーカ定義を設定するパラメタについて，次の表に示します。

「省略値」とは，パラメタの指定がない場合に仮定される値です。「VR」とは，パラメタが導入・変更されたアプリケーションサーバのバージョンです。なお，「param-name指定値」に対応するparam-valueの指定内容については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。

注

AllTextパラメタを指定する場合，ワーカ定義を設定するパラメタの指定を有効にするには，設定ファイルの内容に次の記述を含めてください。

Include "<Application Serverのインストールディレクトリ>/CC/web/redirector/servers/<論理Webサーバ>/mod_jk.conf"

(1)　ワーカ定義ファイルに指定できるキー

ワーカ，およびワーカごとの各パラメタを定義します。このキーに不正な値を設定した場合，動作は保証されません。

param-name指定値

指定可能値

省略値

VR

worker.list

任意の文字列を指定します。

なし

07-50

worker.<ワーカ名>.<パラメタ>

定義パラメタについては，「(2)　ワーカごとの定義パラメタ」を参照してください。

なし

07-50

(2)　ワーカごとの定義パラメタ

param-name指定値

指定可能値

省略値

VR

worker.<ワーカ名>.balanced_workers

任意の文字列を指定します。

なし

07-50

worker.<ワーカ名>.cachesize※1

1〜2147483647の整数で指定します。

64

07-50

worker.<ワーカ名>.default_worker

ワーカ名をコンマ「,」で区切って指定します。

先頭と末尾のスペースは無視されます。

なし

07-50

worker.<ワーカ名>.delegate_error_code

400〜417，422〜424，500〜505，507，510をコンマ「,」で区切って指定します。

なし

07-50

worker.<ワーカ名>.host

指定できる値を次に示します。

IPv4アドレス※2

ホスト名※2

@myhost

なし

07-50

worker.<ワーカ名>.lbfactor※1

0〜9999999999の整数で指定します。

1

07-50

worker.<ワーカ名>.port

1〜65535の整数で指定します。

なし

07-50

worker.<ワーカ名>.post_data

数字（0〜9）の10文字以内の文字列とm，M，k，Kが0〜1回連続する文字列を指定します。

なし

07-50

worker.<ワーカ名>.post_size_workers

任意の文字列を指定します。

なし

07-50

worker.<ワーカ名>.receive_timeout※1

0〜3600の整数で指定します。

3600

07-50

worker.<ワーカ名>.type

次のどれかを指定します。

ajp13

lb

post_size_lb

なし

07-50

注

ワーカを新規に定義する場合は，次のパラメタを必ず定義してください。

JkMountについては「11.1.1　HTTP Server用リダイレクタ動作定義を設定するパラメタ」を参照してください。

・worker.list

・worker.＜ワーカ名＞.host

・worker.＜ワーカ名＞.port

・worker.＜ワーカ名＞.type

・JkMount

注※1

combined-tierまたはhttp-tierで構築した場合，省略値はJ2EEサーバ名で定義されたワーカ名のワーカに適用されます。省略値を変更したい場合は，上記の「注」に示すワーカを定義してください。

注※2

IPv4アドレスまたはホスト名を指定する場合は，ホストの定義の<host-name>タグの値を指定してください。異なる値を指定した場合，警告メッセージ（KEOS24195-W）が出力され，意図しない設定となることがあります。

11.2　論理J2EEサーバで指定できるパラメタ

ここでは，論理J2EEサーバで指定できるパラメタについて説明します。

指定できるパラメタと詳細についての参照先を次の表に示します。

表11‒2　使用するサーバと指定するパラメタの参照先の対応

使用するサーバ

指定するパラメタ

J2EEサーバ

J2EEサーバ用ユーザプロパティを設定するパラメタ（11.2.1参照）

11.2.1　J2EEサーバ用ユーザプロパティを設定するパラメタ

J2EEサーバ用ユーザプロパティを設定するパラメタについて説明します。

「param-name指定値」に対応するparam-valueの指定内容については，「10.1.1　usrconf.properties（J2EEサーバ用ユーザプロパティファイル）」についての説明を参照してください。また，参照する場合はキーをパラメタに読み替えてください。「省略値」とは，パラメタの指定がない場合に仮定される値です。「VR」とは，パラメタが導入・変更されたアプリケーションサーバのバージョンです。

なお，「param-valueの指定内容」が記載されているパラメタは，usrconf.properties（J2EEサーバ用ユーザプロパティファイル）と指定方法が異なるパラメタです。

J2EE サーバ用ユーザプロパティを設定するパラメタを指定する場合の指定形式を次に示します。

指定形式

<param-name>パラメタ</param-name>
<param-value>値</param-value>

usrconf.properties（J2EEサーバ用ユーザプロパティファイル）に指定できるパラメタのうち，この項の表に記載していないパラメタは，次の形式で指定してください。

指定形式

<param-name>ex.properties</param-name>
<param-value>パラメタ=値</param-value>

値を複数指定する場合は，複数の<param-value>を指定します。

値を複数指定する場合の指定形式

<param-name>ex.properties</param-name>
<param-value>パラメタ=値</param-value>
<param-value>パラメタ=値</param-value>

なお，この項に記載があるパラメタのうち，次のパラメタは，この形式で指定することもできます。それ以外のパラメタをこの形式で指定した場合，動作が保証されません。また，<param-name>パラメタ</param-name>の形式とこの形式の両方で同じパラメタを指定した場合，動作が保証されません。

運用管理ポータルの画面に対応しないパラメタ

運用管理ポータルの画面に対応し，画面名が「システムプロパティの設定」，設定個所が「システムプロパティ」であるパラメタ

パラメタと運用管理ポータルの画面の対応については，マニュアル「アプリケーションサーバ 運用管理ポータル操作ガイド」を参照してください。

(1)　cosminexus.jpaから始まるパラメタ

cosminexus.jpaから始まるパラメタについて次の表に示します。「param-name指定値」に対応するparam-valueの指定内容については，「10.1.1(1)　cosminexus.jpaから始まるキー」についての説明を参照してください。また，参照する場合はキーをパラメタに読み替えてください。

表11‒3　cosminexus.jpaから始まるパラメタ

param-name指定値

指定可能値

省略値

VR

cosminexus.jpa.logging.level.operation.<category>

指定できる文字列を次に示します。

Off

Information

Detail

Off

08-00

cosminexus.jpa.exception.logging.sql

指定できる文字列を次に示します。

Off

Information

Detail

Off

08-00

(2)　ejbserver.jpaから始まるパラメタ

ejbserver.jpaから始まるパラメタについて次の表に示します。「param-name指定値」に対応するparam-valueの指定内容については，「10.1.1(2)　ejbserver.jpaから始まるキー」についての説明を参照してください。また，参照する場合はキーをパラメタに読み替えてください。

表11‒4　ejbserver.jpaから始まるパラメタ

param-name指定値

指定可能値

省略値

VR

ejbserver.jpa.defaultJtaDsName

任意の文字列を指定します。

なし

08-00

ejbserver.jpa.defaultNonJtaDsName

任意の文字列を指定します。

なし

08-00

ejbserver.jpa.defaultProviderClassName

任意の文字列を指定します。

com.hitachi.software.jpa.PersistenceProvider

08-00

ejbserver.jpa.disable

指定できる文字列を次に示します。

true

false

false

08-50

ejbserver.jpa.overrideJtaDsName

任意の文字列を指定します。

なし

08-00

ejbserver.jpa.overrideNonJtaDsName

任意の文字列を指定します。

なし

08-00

ejbserver.jpa.overrideProvider

任意の文字列を指定します。

なし

08-00

ejbserver.jpa.emfprop.<property key>

任意の文字列を指定します。

なし

08-00

(3)　ejbserver.loggerから始まるパラメタ

ejbserver.loggerから始まるパラメタについて次の表に示します。「param-name指定値」に対応するparam-valueの指定内容については，「10.1.1(3)　ejbserver.loggerから始まるキー」についての説明を参照してください。また，参照する場合はキーをパラメタに読み替えてください。

表11‒5　ejbserver.loggerから始まるパラメタ

param-name指定値

指定可能値

省略値

VR

ejbserver.logger.channels.define.JPAOperationLogFile.filenum

1〜16の整数で指定します。

2

08-00

ejbserver.logger.channels.define.JPAOperationLogFile.filesize

4096〜2147483647（単位：バイト）の整数で指定します。

1048576

08-00

ejbserver.logger.channels.define.JPAMaintenanceLogFile.filenum

1〜16の整数で指定します。

2

08-00

ejbserver.logger.channels.define.JPAMaintenanceLogFile.filesize

4096〜2147483647（単位：バイト）の整数で指定します。

1048576

08-00

ejbserver.logger.channels.define.WebAccessLogFile.filenum

1〜16の整数で指定します。

16

07-50

ejbserver.logger.channels.define.WebAccessLogFile.filesize

4096〜2147483647（単位：バイト）の整数で指定します。

4194304

07-50

(4)　ejbserver.serverから始まるパラメタ

ejbserver.serverから始まるパラメタについて次の表に示します。「param-name指定値」に対応するparam-valueの指定内容については，「10.1.1(4)　ejbserver.serverから始まるキー」についての説明を参照してください。また，参照する場合はキーをパラメタに読み替えてください。

表11‒6　ejbserver.serverから始まるパラメタ

param-name指定値

指定可能値

省略値

VR

ejbserver.server.eheap.ajp13.enabled

指定できる文字列を次に示します。

true

false

true

08-00

(5)　webserver.connectorから始まるパラメタ

webserver.connectorから始まるパラメタについて次の表に示します。「param-name指定値」に対応するparam-valueの指定内容については，「10.1.1(5)　webserver.connectorから始まるキー」についての説明を参照してください。また，参照する場合はキーをパラメタに読み替えてください。

表11‒7　webserver.connectorから始まるパラメタ

param-name指定値

指定可能値

省略値

VR

webserver.connector.ajp13.backlog

1〜2147483647の整数で指定します。

100

06-50

webserver.connector.ajp13.bind_host

指定できる文字列を次に示します。

ホスト名※

IPv4アドレス※

@myhost

なし

07-50

webserver.connector.ajp13.max_threads

1〜1024の整数で指定します。

10

06-50

webserver.connector.ajp13.port

1〜65535の整数で指定します。

8007

06-50

07-00

webserver.connector.ajp13.receive_timeout

0〜3600（単位：秒）の整数で指定します。

600

06-50

07-00

webserver.connector.ajp13.send_timeout

0〜3600（単位：秒）の整数で指定します。

600

07-00

webserver.connector.inprocess_http.backlog

1〜2147483647の整数で指定します。

511

07-50

webserver.connector.inprocess_http.bind_host

指定できる文字列を次に示します。

ホスト名※

IPv4アドレス※

@myhost

なし

07-50

webserver.connector.inprocess_http.enabled

指定できる文字列を次に示します。

true

false

false

07-50

webserver.connector.inprocess_http.enabled_methods

指定できる値を次に示します。

GET

HEAD

POST

PUT

DELETE

OPTIONS

TRACE

CONNECT

PATCH

LINK

UNLINK

アスタリスク「*」

GET,HEAD,POST,PUT,DELETE,OPTIONS

07-50

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.file

ファイル名

なし

07-50

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.file.content_type

任意の文字列を指定します。

text/html

07-50

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.redirect_url

任意の文字列を指定します。

なし

07-50

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.request_url

任意の文字列を指定します。

/*

07-50

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.status

400〜599の整数で指定します。

なし

07-50

webserver.connector.inprocess_http.error_custom.list

英数字，およびアンダースコア「_」を使って32文字以内で指定します。また，複数指定する場合はコンマ「,」で区切って指定します。

なし

07-50

webserver.connector.inprocess_http.gateway.host

次のどれかを指定します。

ホスト名

IPv4アドレス

@myhost

なし

07-50

webserver.connector.inprocess_http.gateway.https_scheme

指定できる文字列を次に示します。

true

false

false

07-50

webserver.connector.inprocess_http.gateway.port

1〜65535の整数で指定します。

なし

07-50

webserver.connector.inprocess_http.init_threads

1〜1024の整数で指定します。

10

07-50

webserver.connector.inprocess_http.keep_start_threads

指定できる文字列を次に示します。

true

false

false

07-50

webserver.connector.inprocess_http.limit.max_headers

0〜32767の整数で指定します。

100

07-50

webserver.connector.inprocess_http.limit.max_request_body

-1〜2147483647（単位：バイト）の整数で指定します。

-1

07-50

webserver.connector.inprocess_http.limit.max_request_header

7〜65536（単位：バイト）の整数で指定します。

16384

07-50

webserver.connector.inprocess_http.limit.max_request_line

指定できる値（単位：バイト）を示します。

-1

7〜8190

8190

07-50

webserver.connector.inprocess_http.max_connections

1〜1024の整数で指定します。

100

07-50

webserver.connector.inprocess_http.max_execute_threads

1〜1024の整数で指定します。

10

07-50

webserver.connector.inprocess_http.max_spare_threads

1〜1024の整数で指定します。

20

07-50

webserver.connector.inprocess_http.min_spare_threads

1〜1024の整数で指定します。

5

07-50

webserver.connector.inprocess_http.permitted.hosts

次のどれかを指定します。

ホスト名

IPv4アドレス

@myhost

アスタリスク「*」

*

07-50

webserver.connector.inprocess_http.persistent_connection.max_connections

0〜1024の整数で指定します。

100

07-50

webserver.connector.inprocess_http.persistent_connection.max_requests

0〜2147483647の整数で指定します。

100

07-50

webserver.connector.inprocess_http.persistent_connection.timeout

0〜3600（単位：秒）の整数で指定します。

3

07-50

webserver.connector.inprocess_http.port

1〜65535の整数で指定します。

80

07-50

webserver.connector.inprocess_http.receive_timeout

0〜3600（単位：秒）の整数で指定します。

300

07-50

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.file

ファイル名を指定します。

なし

07-50

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.file.content_type

任意の文字列を指定します。

text/html

07-50

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.redirect_url

任意の文字列を指定します。

なし

07-50

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.request_url

任意の文字列を指定します。

なし

07-50

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.status

指定できる値を次に示します。

200

300

301

302

303

305

307

302

07-50

webserver.connector.inprocess_http.redirect.list

英数字，およびアンダースコア「_」を使って32文字以内で指定します。また，複数指定する場合はコンマ「,」で区切って指定します。

なし

07-50

webserver.connector.inprocess_http.rejection_threads

0〜1023の整数で指定します。

1

07-50

webserver.connector.inprocess_http.response.header.server

任意の文字列を指定します。

CosminexusComponentContainer

07-50

webserver.connector.inprocess_http.send_timeout

0〜3600（単位：秒）の整数で指定します。

300

07-50

注※

ホスト名またはIPv4アドレスを指定する場合は，ホストの定義の<host-name>タグの値を指定してください。異なる値を指定した場合，警告メッセージ（KEOS24186-W）が出力され，意図しない設定となることがあります。

(6)　webserver.containerから始まるパラメタ

webserver.containerから始まるパラメタについて次の表に示します。「param-name指定値」に対応するparam-valueの指定内容については，「10.1.1(6)　webserver.containerから始まるキー」についての説明を参照してください。また，参照する場合はキーをパラメタに読み替えてください。

表11‒8　webserver.containerから始まるパラメタ

param-name指定値

指定可能値

省略値

VR

webserver.container.ac.logEnabled

指定できる文字列を次に示します。

true

false

false

06-50

12　JPAで使用するファイル

この章では，CJPAプロバイダで使用するファイルの形式，格納先，機能，指定できるキーなどについて説明します。

12.1　CJPAプロバイダで使用するファイルの一覧

CJPAプロバイダで使用するファイルの一覧を，次の表に示します。

表12‒1　CJPAプロバイダで使用するファイルの一覧

ファイル名

概要

参照先

persistence.xml

アプリケーションサーバのJPA機能の永続化ユニット情報を設定するためのファイルです。

12.2

O/Rマッピングファイル

O/Rマッピング情報を設定するためのファイルです。

12.3

12.2　persistence.xml

persistence.xmlの構成を次に示します。

タグ名

出現パターン

説明

<persistence>

1回

ルートタグを表します。

┗

<persistence-unit>

0回以上

永続化ユニットの定義をします。

┣

┃

<description>

0または1回

永続化ユニットに関する説明を記述します。

┣

┃

<provider>

0または1回

javax.persistence.spi.PersistenceProviderの実装クラス名を指定します。

┣

┃

<jta-data-source>

0または1回

JTAトランザクションに対応したデータソースの参照を指定します。

┣

┃

<non-jta-data-source>

0または1回

JTAトランザクションには対応していないデータソースの参照を指定します。

┣

┃

<mapping-file>

0回以上

O/Rマッピングファイルを指定します。

┣

┃

┃

<jar-file>

0回以上

entityクラス，embeddableクラス，およびmappedsuperクラスを含むJARファイル名を記述します。

┣

┃

<class>

0回以上

entityクラス，embeddableクラス，およびmappedsuperクラスを記述します。

┣

┃

<exclude-unlisted-classes>

0または1回

Persistenceクラスを指定します。

┗

<properties>

0または1回

CJPAプロバイダ独自のプロパティを定義します。

┗

<property>

0回以上

各種のプロパティを定義します。

それぞれのタグの詳細については，「12.2.1　persistence.xmlの詳細」を参照してください。

12.2.1　persistence.xmlの詳細

(1)　<persistence>

永続化ユニットの定義を開始することを示すルートタグです。

<persistence>タグには，XML名前空間を指定するxmlns要素を設定する必要があります。

指定できる属性を次の表に示します。

表12‒2　<persistence>の属性

属性名

型

任意／必須

説明

version

persistence:versionType

必須

XMLスキーマのバージョン"1.0"を指定します。

(2)　<persistence-unit>

永続化ユニットを定義します。指定できる属性を次の表に示します。

表12‒3　<persistence-unit>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

永続化ユニットの名前を指定します。

name属性で指定する名前は，永続化ユニットがパッケージングされる範囲内で一意な名前である必要があります。

重複した名前の永続化ユニットが定義された場合は，CJPAプロバイダでは動作は保証しません。

Java EE環境で同名の永続化ユニットを定義した場合，コンテナ側で警告メッセージを出力します。

Java EE環境では，name属性に指定する値は，空文字であってはなりません。空文字を指定した場合には，コンテナ側で例外が発生します。

transaction-type

persistence:persistence-unit-transaction-type

任意

EntityManagerが使用するトランザクションを指定します。

JTA

JTAトランザクションを使用します。

RESOURCE_LOCAL

JTAトランザクションを使用しないで，独自にトランザクションを管理します。

transaction-type属性の値を指定しなかった場合は，デフォルトである「JTA」が適用されます。

Java EE環境で指定できる属性の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「5.8.1　<persistence-unit>タグに指定する属性」を参照してください。

(3)　<description>

永続化ユニットに関する説明を記述します。

(4)　<provider>

javax.persistence.spi.PersistenceProviderの実装クラス名を指定します。

CJPAプロバイダを使用する場合，com.hitachi.software.jpa.PersistenceProviderを指定します。ほかのJPAプロバイダが存在する場合など，明示的に指定する場合に記述します。なお，値を指定しない場合は，コンテナの挙動に依存します。

注意事項

<provider>タグの途中に空白が入ると，要素を指定していない場合と同じ処理をします。

(5)　<jta-data-source>

JTAトランザクションに対応したデータソースの参照を指定します。

<persistence-unit>タグのtransaction-typeに指定した値がJTAの場合に指定します。なお，値を指定しない場合は，コンテナの挙動に依存します。

(6)　<non-jta-data-source>

JTAトランザクションには対応していないデータソースの参照を指定します。<persistence-unit>タグのtransaction-typeに指定した値がRESOURCE_LOCALの場合に指定します。

transaction-typeに指定した値がJTAの場合，CJPAプロバイダでは<non-jta-data-source>タグに値が指定されても無視します。値を指定しない場合は，コンテナの挙動に依存します。

(7)　<mapping-file>

O/Rマッピングファイルを指定します。

指定したファイルはクラスパスで指定している場所に格納されている必要があります。O/Rマッピングファイルを使用しない場合，または，orm.xmlを所定の位置に配置して使用する場合は，記述する必要はありません。

指定したファイルが見つからない場合，アプリケーション開始に失敗します。

(8)　<jar-file>

entityクラス，embeddableクラス，mappedsuperクラスを含むJARファイル名を記述します。JARファイルのパスは，永続化ユニットのルートから相対パスで指定します。

指定したファイルが見つからない場合，コンテナの挙動に依存します。

(9)　<class>

entityクラス，embeddableクラス，およびmappedsuperクラスを記述します。

指定したクラスが見つからない場合，コンテナの挙動に依存します。

なお，<class>タグに指定された値がentityクラス，embeddableクラス，およびmappedsuperクラスであるかどうかのチェックはCJPAプロバイダでは実施しません。そのため，entityクラス，embeddableクラス，およびmappedsuperクラス以外のクラスを指定した場合に例外は発生しないで，動作します。

(10)　<exclude-unlisted-classes>

Persistenceクラスを定義します。

指定できる値と，値を指定した場合の挙動を次に示します。

true

class要素，jar-file要素，およびmapping-file要素によって明示的に指定されたクラスだけPersistenceクラスとして扱います。

false

exclude-unlisted-class要素を指定していない場合，永続化ユニットのルート以下のclassファイルに対してJPA対象のクラスであるかどうかを検索します。

(11)　<properties>

CJPAプロバイダ独自のプロパティを定義します。この要素以下にproperty要素を指定してプロパティを定義します。

(12)　<property>

各種のプロパティを定義します。

プロパティの詳細については，「12.2.2　<property>タグに指定できるCJPAプロバイダ独自のプロパティ」を参照してください。

指定できる属性を次の表に示します。

表12‒4　<property>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

プロパティの名前。

value

xsd:string

必須

プロパティの値。

12.2.2　<property>タグに指定できるCJPAプロバイダ独自のプロパティ

persistence.xmlの<property>タグに指定するCJPAプロバイダ独自のプロパティについて説明します。

CJPAプロバイダでは，EntityManagerFactoryのcreateEntityManager()の引数として，指定できるプロパティはありません。なお，persistence.xmlファイルのプロパティの属性値は，数値であっても引用符（ダブルクォーテーションまたはシングルクォーテーション）で囲って指定してください。

注意事項

CJPAプロバイダでは，JPA仕様で規定されているjavaxから始まるプロパティを<property>タグに指定できません。JPA仕様で規定されているjavaxから始まるプロパティを，persistence.xmlの<property>タグに指定した場合の動作は保証しません。

また，JPA仕様で規定されているjavaxから始まるプロパティはシステムプロパティとして指定しないでください。JPA仕様で規定されているjavaxから始まるプロパティを次に示します。

javax.persistence.transactionType

javax.persistence.jtaDataSource

javax.persistence.nonJtaDataSource

javax.persistence.provider

CJPAプロバイダ独自のプロパティについて説明します。

これらのプロパティは，persistence.xmlファイルの<property>タグに指定します。

プロパティの値に指定可能範囲外の値が設定された場合，デプロイ時に例外が発生します。また，大文字と小文字は区別されます。

CJPAプロバイダ独自のプロパティについて表で示します。

表12‒5　CJPAプロバイダ独自のプロパティ

プロパティ名

内容

指定可能値

デフォルト

cosminexus.jpa.cache.size.<ENTITY>

<ENTITY>で指定されたエンティティのキャッシュに設定する初期化サイズを指定します。

キャッシュのタイプがFullの場合，エンティティのキャッシュに対する初期化サイズを設定します。

キャッシュタイプがHardWeakまたはSoftWeakの場合，エンティティのキャッシュの最大サイズを設定します。

キャッシュサイズの指定は，全体で呼び出されるエンティティの最大ID数（レコード数）を目安にして設定します。

0〜2147483647

1000

cosminexus.jpa.cache.size.default

エンティティをキャッシュする場合のデフォルトのキャッシュサイズを設定します。

キャッシュのタイプがFullの場合，エンティティのキャッシュに対する初期化サイズを設定します。

キャッシュタイプがHardWeakまたはSoftWeakの場合，エンティティのキャッシュの最大サイズを設定します。

キャッシュサイズの指定は，全体で呼び出されるエンティティの最大ID数（レコード数）を目安にして設定します。

0〜2147483647

1000

cosminexus.jpa.cache.type.<ENTITY>

<ENTITY>で指定されたエンティティのキャッシュのタイプを指定します。

指定できる文字列は次のとおりです。

Full

Weak

HardWeak

SoftWeak

NONE

SoftWeak

cosminexus.jpa.cache.type.default

キャッシュのデフォルトタイプを指定します。

指定できる文字列は次のとおりです。

Full

Weak

HardWeak

SoftWeak

NONE

SoftWeak

cosminexus.jpa.target-database

接続するデータベースの名前を指定します。各データベース固有の処理を切り分けるために，指定値によりデータベース固有部分を実装したクラスを読み込みます。

Autoを指定した場合は，CJPAプロバイダへの初回リクエスト時に，persistence.xmlの<jta-data-source>または<non-jta-data-source>に指定したリソースの情報から，自動でデータベースを識別します。このため，データベースの名前を指定した場合に比べて若干処理時間が長くなります。

通常はAutoを使用しないでデータベースの名前を指定することを推奨します。

指定できる文字列を次に示します。

Auto

HiRDB

Oracle

Auto

12.3　O/Rマッピングファイル

O/Rマッピングファイルの構成を次に示します。

タグ名

出現パターン

説明

<entity-mappings>

1回

ルートタグ。

┣

┃

<description>

0または1回

説明を付加します。

┣

┃

<persistence-unit-metadata>

0または1回

PersistenceUnit全体に関する定義を指定します。

┃

┃

┃

┣

┃

┃

<xml-mapping-metadata-complete>

0または1回

永続化ユニットのマッピングメタデータを抑止するかどうかを指定します。

┃

┃

┗

<persistence-unit-defaults>

0または1回

永続化ユニットのデフォルト値を指定します。

┃

┃

┣

┃

<schema>

0または1回

スキーマを定義します。

┃

┃

┣

┃

<catalog>

0または1回

カタログを定義します。

┃

┃

┣

┃

<access>

0または1回

アクセスタイプを指定します。

┃

┃

┣

┃

<cascade-persist>

0または1回

カスケード永続化オプションを追加します。

┃

┃

┃

┗

<entity-listeners>

0または1回

永続化ユニットのデフォルトエンティティリスナを定義します。

┃

┃

┗

<entity-listener>

0回以上

エンティティリスナを指定します。

┃

┃

┣

┃

<pre-persist>

0または1回

ライフサイクルコールバックメソッドを指定します。

┃

┃

┣

┃

<post-persist>

0または1回

ライフサイクルコールバックメソッドを指定します。

┃

┃

┣

┃

<pre-remove>

0または1回

ライフサイクルコールバックメソッドを指定します。

┃

┃

┣

┃

<post-remove>

0または1回

ライフサイクルコールバックメソッドを指定します。

┃

┃

┣

┃

<pre-update>

0または1回

ライフサイクルコールバックメソッドを指定します。

┃

┃

┣

┃

<post-update>

0または1回

ライフサイクルコールバックメソッドを指定します。

┃

┃

┗

<post-load>

0または1回

ライフサイクルコールバックメソッドを指定します。

┣

┃

┃

<package>

0または1回

同一マッピングファイル内の要素や属性に記載されたクラスのパッケージを指定します。

┣

┃

<schema>

0または1回

スキーマを定義します。

┣

┃

<catalog>

0または1回

カタログを定義します。

┣

┃

<access>

0または1回

アクセス方法を定義します。

┣

┃

<sequence-generator>

0回以上

シーケンスジェネレータを追加します。

┣

┃

<table-generator>

0回以上

テーブルジェネレーターを定義します。

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┣

┃

<named-query>

0回以上

名前付きクエリを定義します。

┃

┃

┣

┃

<query>

1回

クエリ文字列を指定します。

┃

┃

┗

<hint>

0回以上

クエリにヒントを付加します。

┣

┃

<named-native-query>

0回以上

名前付きネイティブクエリを定義します。

┃

┃

┣

┃

<query>

1回

クエリ文字列を指定します。

┃

┃

┗

<hint>

0回以上

クエリにヒントを付加します。

┣

┃

<sql-result-set-mapping>

0回以上

SQL結果セットマッピングを定義します。

┃

┃

┃

┣

┃

┃

<entity-result>

0回以上

ネイティブSQLのクエリ結果をマッピングするためのEntityクラスを指定します。

┃

┃

┃

┃

┃

┃

┗

<field-result>

0回以上

ネイティブSQLのクエリ結果をマッピングするためのフィールドを指定します。

┃

┃

┃

┗

<column-result>

0回以上

ネイティブSQLのクエリ結果をマッピングするためのカラムを指定します。

┣

┃

<mapped-superclass>

0回以上

永続化ユニットのマップドスーパークラスを定義します。

┃

┃

┃

┣

┃

┃

<description>

0または1回

永続化ユニットのマップドスーパークラスの説明を付加します。

┃

┃

┣

┃

<id-class>

0または1回

マップドスーパークラスで指定した@IdClassを上書きします。

┃

┃

┃

┃

┣

┃

┃

┃

<exclude-default-listeners>

0または1回

マップドスーパークラスとそのサブクラスのデフォルトエンティティリスナを抑止するかどうかを定義します。

┃

┃

┃

┃

┣

┃

┃

┃

<exclude-superclass-listeners>

0または1回

マップドスーパークラスとそのサブクラスのスーパークラスリスナを抑止するかどうかを定義します。

┃

┃

┣

┃

<entity-listeners>

0または1回

コールバックリスナクラスを指定します。

┃

┃

┃

┃

┗

<entity-listener>

0回以上

エンティティリスナを指定します。

┃

┃

┃

┃

┣

┃

<pre-persist>

0または1回

ライフサイクルコールバックメソッドを指定します。

┃

┃

┃

┃

┣

┃

<post-persist>

0または1回

┃

┃

┃

┃

┣

┃

<pre-remove>

0または1回

┃

┃

┃

┃

┣

┃

<post-remove>

0または1回

┃

┃

┃

┃

┣

┃

<pre-update>

0または1回

┃

┃

┃

┃

┣

┃

<post-update>

0または1回

┃

┃

┃

┃

┗

<post-load>

0または1回

┃

┃

┃

┃

┣

┃

┃

┃

<pre-persist>

0または1回

マップドスーパークラスで，対応するアノテーションによるライフサイクルコールバックメソッドを定義します。

┃

┃

┣

┃

<post-persist>

0または1回

┃

┃

┣

┃

<pre-remove>

0または1回

┃

┃

┣

┃

<post-remove>

0または1回

┃

┃

┣

┃

<pre-update>

0または1回

┃

┃

┣

┃

<post-update>

0または1回

┃

┃

┣

┃

<post-load>

0または1回

┃

┃

┗

<attributes>

0または1回

要素自体の定義はありません。

┃

┃

┃

┣

┃

┃

<id>

0回以上※1

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<column>

0または1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┃

┣

┃

<generated-value>

0または1回

プライマリキー値生成戦術を指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<temporal>

0または1回

DATE，TIME，TIMESTAMP型へマッピングをするときに指定します。

┃

┃

┃

┃

┣

┃

<table-generator>

0または1回

テーブルジェネレータを追加します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┗

<sequence-generator>

0または1回

シーケンスジェネレータを追加します。

┃

┃

┃

┣

┃

┃

<embedded-id>

0または1回※1

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┗

<attribute-override>

0回以上

プロパティやフィールドのマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┗

<column>

1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┣

┃

┃

<basic>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<column>

0または1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┃

┣

┃

<lob>

0または1回※2

Lob型へマッピングをするときに指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<temporal>

0または1回※2

DATE，TIME，TIMESTAMP型へマッピングをするときに指定します。

┃

┃

┃

┃

┗

<enumerated>

0または1回※2

列挙型へマッピングをするときに指定します。

┃

┃

┃

┣

┃

┃

<version>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<column>

0または1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┃

┃

┃

┗

<temporal>

0または1回

DATE，TIME，TIMESTAMP型へマッピングをするときに指定します。

┃

┃

┃

┣

┃

┃

<many-to-one>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上※3

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-table>

0または1回※3

多対多や片方向の一対多で使用する結合表を指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<inverse-join-column>

0回以上

被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┗

<cascade>

0または1回

カスケード可能な操作を指定します。

┃

┃

┃

┃

┣

┃

<cascade-all>

0または1回

すべての操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-persist>

0または1回

persist操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-merge>

0または1回

merge操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-remove>

0または1回

remove操作をカスケードします。

┃

┃

┃

┃

┗

<cascade-refresh>

0または1回

refresh操作をカスケードします。

┃

┃

┃

┣

┃

┃

<one-to-many>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┣

┃

<order-by>

0または1回

関連をコレクションに保持する際に付ける順序を指定します。

┃

┃

┃

┃

┣

┃

<map-key>

0または1回

Map型の関連としてマップキーを指定します。

┃

┃

┃

┃

┣

┃

<join-table>

0または1回※4

多対多や片方向の一対多で使用する結合表を指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<inverse-join-column>

0回以上

被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上※4

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┗

<cascade>

0または1回

カスケード可能な操作を指定します。

┃

┃

┃

┃

┣

┃

<cascade-all>

0または1回

すべての操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-persist>

0または1回

persist操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-merge>

0または1回

merge操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-remove>

0または1回

remove操作をカスケードします。

┃

┃

┃

┃

┗

<cascade-refresh>

0または1回

refresh操作をカスケードします。

┃

┃

┃

┣

┃

┃

<one-to-one>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

┃

<primary-key-join-column>

0回以上※5

ほかのテーブルにJOINする外部キーとして使用される，プライマリキーカラムを指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上※5

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-table>

0または1回※5

多対多や片方向の一対多で使用する結合表を指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<inverse-join-column>

0回以上

被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┗

<cascade>

0または1回

カスケード可能な操作を指定します。

┃

┃

┃

┃

┣

┃

<cascade-all>

0または1回

すべての操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-persist>

0または1回

persist操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-merge>

0または1回

merge操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-remove>

0または1回

remove操作をカスケードします。

┃

┃

┃

┃

┗

<cascade-refresh>

0または1回

refresh操作をカスケードします。

┃

┃

┃

┣

┃

┃

<many-to-many>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┣

┃

<order-by>

0または1回

関連をコレクションに保持する際に付ける順序を指定します。

┃

┃

┃

┃

┣

┃

<map-key>

0または1回

Map型の関連としてマップキーを指定します。

┃

┃

┃

┃

┣

┃

<join-table>

0または1回

多対多や片方向の一対多で使用する結合表を指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<inverse-join-column>

0回以上

被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┗

<cascade>

0または1回

カスケード可能な操作を指定します。

┃

┃

┃

┃

┣

┃

<cascade-all>

0または1回

すべての操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-persist>

0または1回

persist操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-merge>

0または1回

merge操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-remove>

0または1回

remove操作をカスケードします。

┃

┃

┃

┃

┗

<cascade-refresh>

0または1回

refresh操作をカスケードします。

┃

┃

┃

┣

┃

┃

<embedded>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┗

<attribute-override>

0回以上

プロパティやフィールドのマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┗

<column>

1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┗

<transient>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┣

┃

<entity>

0回以上

永続化ユニットのエンティティを定義します。

┃

┃

┣

┃

<description>

0または1回

永続化ユニットのエンティティの説明を付加します。

┃

┃

┃

┣

┃

┃

<table>

0または1回

Entityクラスの@Table（デフォルト値も含む）を上書きします。

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┣

┃

┃

┃

<secondary-table>

0回以上

Entityクラスのすべての@SecondaryTableと@SecondaryTables（デフォルト値も含む）を上書きします。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

┃

┃

<primary-key-join-column>

0回以上

Entityクラスのすべての@PrimaryKeyJoinColumnと@PrimaryKeyJoinColumns（デフォルト値も含む）を上書きします。

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┃

┣

┃

┃

┃

┃

<primary-key-join-column>

0回以上

Entityクラスのすべての@PrimaryKeyJoinColumnと@PrimaryKeyJoinColumns（デフォルト値も含む）を上書きします。

┃

┃

┣

┃

<id-class>

0または1回

Entityクラスに指定された@IdClassを上書きします。

┃

┃

┃

┣

┃

┃

<inheritance>

0または1回

Entityクラスの@Inheritance（デフォルト値も含む）を上書きします。

┃

┃

┃

┃

┣

┃

┃

┃

<discriminator-value>

0または1回

Entityクラスの@DiscriminatorValue（デフォルト値も含む）を上書きします。

┃

┃

┃

┃

┣

┃

┃

┃

<discriminator-column>

0または1回

Entityクラスの@DiscriminatorColumn（デフォルト値も含む）を上書きします。

┃

┃

┃

┣

┃

┃

<sequence-generator>

0または1回

プライマリキーを作成するシーケンスジェネレータの設定を指定します。

┃

┃

┣

┃

<table-generator>

0または1回

プライマリキーを作成するジェネレータの設定を指定します。

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┣

┃

<named-query>

0回以上

名前付きクエリを定義します。

┃

┃

┃

┃

┣

┃

<query>

1回

クエリ文字列を指定します。

┃

┃

┃

┃

┗

<hint>

0回以上

クエリにヒントを付加します。

┃

┃

┣

┃

<named-native-query>

0回以上

名前付きネイティブクエリを定義します。

┃

┃

┃

┃

┣

┃

<query>

1回

クエリ文字列を指定します。

┃

┃

┃

┃

┗

<hint>

0回以上

クエリにヒントを付加します。

┃

┃

┣

┃

<sql-result-set-mapping>

0回以上

SQL結果のマッピングを定義します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<entity-result>

0回以上

ネイティブSQLのクエリ結果をマッピングするためのEntityクラスを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┗

<field-result>

0回以上

ネイティブSQLのクエリ結果をマッピングするためのフィールドを指定します。

┃

┃

┃

┃

┃

┃

┗

<column-result>

0回以上

ネイティブSQLのクエリ結果をマッピングするためのカラムを指定します。

┃

┃

┃

┣

┃

┃

<exclude-default-listeners>

0または1回

Entityクラスとそのサブクラスのデフォルトエンティティリスナを抑止します。

┃

┃

┃

┣

┃

┃

<exclude-superclass-listeners>

0または1回

Entityクラスとそのサブクラスのスーパークラスリスナを抑止します。

┃

┃

┃

┣

┃

┃

<entity-listeners>

0または1回

Entityクラスの@EntityListenersを上書きします。

┃

┃

┃

┃

┗

<entity-listener>

0回以上

エンティティリスナを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

┃

<pre-persist>

0または1回

マップドスーパークラスで，対応するアノテーションによるライフサイクルコールバックメソッドの定義を上書きします。

┃

┃

┃

┃

┣

┃

<post-persist>

0または1回

┃

┃

┃

┃

┣

┃

<pre-remove>

0または1回

┃

┃

┃

┃

┣

┃

<post-remove>

0または1回

┃

┃

┃

┃

┣

┃

<pre-update>

0または1回

┃

┃

┃

┃

┣

┃

<post-update>

0または1回

┃

┃

┃

┃

┗

<post-load>

0または1回

┃

┃

┃

┃

┣

┃

┃

┃

<pre-persist>

0または1回

Entityクラスで，対応するアノテーションによるライフサイクルコールバックメソッドの定義を上書きします。

┃

┃

┣

┃

<post-persist>

0または1回

┃

┃

┣

┃

<pre-remove>

0または1回

┃

┃

┣

┃

<post-remove>

0または1回

┃

┃

┣

┃

<pre-update>

0または1回

┃

┃

┣

┃

<post-update>

0または1回

┃

┃

┣

┃

<post-load>

0または1回

┃

┃

┃

┃

┣

┃

┃

┃

<attribute-override>

0回以上

Entityクラスの@AttributeOverrideもしくは@AttributeOverridesで定義された値に追加されます。

┃

┃

┃

┃

┃

┃

┗

<column>

1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┃

┣

┃

┃

┃

<association-override>

0回以上

Entityクラスの@ AssociationOverrideもしくは@AssociationOverridesで定義された値に追加されます。

┃

┃

┃

┃

┃

┃

┗

<join-column>

1回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┗

<attributes>

0または1回

要素自自体の定義はありません。

┃

┃

┃

┣

┃

┃

<id>

0回以上※1

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<column>

0または1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┃

┣

┃

<generated-value>

0または1回

プライマリキー値生成戦術を指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<temporal>

0または1回

DATE，TIME，TIMESTAMP型へマッピングを行うときに指定します。

┃

┃

┃

┃

┣

┃

<table-generator>

0または1回

テーブルジェネレータを追加します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┃

┃

┗

<sequence-generator>

0または1回

プライマリキーを作成するシーケンスジェネレータの設定を指定します。

┃

┃

┃

┣

┃

┃

<embedded-id>

0または1回※1

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┃

┃

┗

<attribute-override>

0回以上

Entityクラスの@AttributeOverrideもしくは@AttributeOverridesで定義された値に追加されます。

┃

┃

┃

┃

┃

┃

┗

<column>

1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┣

┃

┃

<basic>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<column>

0または1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<lob>

0または1回※2

Lob型へマッピングをするときに指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<temporal>

0または1回

DATE，TIME，TIMESTAMP型へマッピングをするときに指定します。

┃

┃

┃

┃

┗

<enumerated>

0または1回※2

列挙型へマッピングをするときに指定します。

┃

┃

┃

┣

┃

┃

<version>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<column>

0または1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┃

┃

┃

┗

<temporal>

0または1回

DATE，TIME，TIMESTAMP型へマッピングをするときに指定します。

┃

┃

┃

┣

┃

┃

<many-to-one>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上※4

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-table>

0または1回※4

多対多や片方向の一対多で使用する結合表を指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<inverse-join-column>

0回以上

被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┗

<cascade>

0または1回

カスケード可能な操作を指定します。

┃

┃

┃

┃

┣

┃

<cascade-all>

0または1回

すべての操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-persist>

0または1回

persist操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-merge>

0または1回

merge操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-remove>

0または1回

remove操作をカスケードします。

┃

┃

┃

┃

┗

<cascade-refresh>

0または1回

refresh操作をカスケードします。

┃

┃

┃

┣

┃

┃

<one-to-many>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┣

┃

<order-by>

0または1回

関連をコレクションに保持する際に付ける順序を指定します。

┃

┃

┃

┃

┣

┃

<map-key>

0または1回

Map型の関連としてマップキーを指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-table>

0または1回※3

多対多や片方向の一対多で使用する結合表を指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<inverse-join-column>

0回以上

被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上※3

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┗

<cascade>

0または1回

カスケード可能な操作を指定します。

┃

┃

┃

┃

┣

┃

<cascade-all>

0または1回

すべての操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-persist>

0または1回

persist操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-merge>

0または1回

merge操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-remove>

0または1回

remove操作をカスケードします。

┃

┃

┃

┃

┗

<cascade-refresh>

0または1回

refresh操作をカスケードします。

┃

┃

┃

┣

┃

┃

<one-to-one>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

┃

┃

<primary-key-join-column>

0回以上※5

Entityクラスのすべての@PrimaryKeyJoinColumnと@PrimaryKeyJoinColumns（デフォルト値も含む）を上書きします。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上※5

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-table>

0または1回※5

多対多や片方向の一対多で使用する結合表を指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<inverse-join-column>

0回以上

被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┗

<cascade>

0または1回

カスケード可能な操作を指定します。

┃

┃

┃

┃

┣

┃

<cascade-all>

0または1回

すべての操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-persist>

0または1回

persist操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-merge>

0または1回

merge操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-remove>

0または1回

remove操作をカスケードします。

┃

┃

┃

┃

┗

<cascade-refresh>

0または1回

refresh操作をカスケードします。

┃

┃

┃

┣

┃

┃

<many-to-many>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┣

┃

<order-by>

0または1回

関連をコレクションに保持する際に付ける順序を指定します。

┃

┃

┃

┃

┣

┃

<map-key>

0または1回

Map型の関連としてマップキーを指定します。

┃

┃

┃

┃

┣

┃

<join-table>

0または1回

多対多や片方向の一対多で使用する結合表を指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<join-column>

0回以上

所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┃

┃

┃

┣

┃

┃

<inverse-join-column>

0回以上

被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

┃

┃

┃

┃

┃

┃

┗

<unique-constraint>

0回以上

DDLにユニーク制約を付加します。

┃

┃

┃

┃

┃

┃

┗

<column-name>

1回以上

ユニーク制約を付加するカラムの名前を指定します。

┃

┃

┃

┃

┗

<cascade>

0または1回

カスケード可能な操作を指定します。

┃

┃

┃

┃

┣

┃

<cascade-all>

0または1回

すべての操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-persist>

0または1回

persist操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-merge>

0または1回

merge操作をカスケードします。

┃

┃

┃

┃

┣

┃

<cascade-remove>

0または1回

remove操作をカスケードします。

┃

┃

┃

┃

┗

<cascade-refresh>

0または1回

refresh操作をカスケードします。

┃

┃

┃

┣

┃

┃

<embedded>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┃

┃

┃

┗

<attribute-override>

0回以上

Entityクラスの@AttributeOverrideもしくは@AttributeOverridesで定義された値に追加されます。

┃

┃

┃

┃

┃

┃

┗

<column>

1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┃

┗

<transient>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┗

<embeddable>

0回以上

永続化ユニットの埋め込み可能クラスを定義します。

┣

┃

<description>

0または1回

永続化ユニットの埋め込み可能クラスの説明を付加します。

┗

<attributes>

0または1回

要素自体の定義はありません。

┣

┃

<basic>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

┃

┃

┃

┣

┃

┃

<column>

0または1回

Persistentフィールドのプロパティに，カラムのマッピングを指定します。

┃

┃

┣

┃

<lob>

0または1回※2

Lob型へマッピングをするときに指定します。

┃

┃

┃

┣

┃

┃

<temporal>

0または1回※2

DATE，TIME，TIMESTAMP型へマッピングをするときに指定します。

┃

┃

┗

<enumerated>

0または1回※2

列挙型へマッピングを行うときに指定します。

┗

<transient>

0回以上

フィールドやプロパティで指定したマッピングを上書きします。

注※1

<id>タグおよび<embedded-id>タグのどちらか一つを指定します。

注※2

<lob>タグ，<temporal>タグ，および<enumerated>タグのどれか一つを指定します。

注※3

<join-column>タグ，および<join-table>タグのどちらか一つを指定します。

注※4

<join-table>タグ，および<join-column>タグのどちらか一つを指定します。

注※5

<primary-key-join-column>タグ，<join-column>タグ，および<join-table>タグのどれか一つを指定します。

12.3.1　entity-mappings以下の要素

(1)　<entity-mappings>

ルートタグ。

指定できる属性を次の表に示します。

表12‒6　<entity-mappings>の属性

属性名

型

任意／必須

説明

version

orm:versionType

必須

JPAのバージョンを指定します。

(2)　<package>

package要素は，同一マッピングファイル内の要素や属性に記載されたクラスのパッケージを指定します。package要素は，パッケージ名付きのクラス名がクラスに指定され，package要素に指定されたパッケージ名と異なる場合に上書きされます。

(3)　<schema>

schema要素は，同一マッピングファイル内に記載されたエンティティにだけ適用されます。

schema要素は，次の要素や属性によって上書きされます。

マッピングファイル内に記載されたEntityクラスの@Tableや@SecondaryTableに明確に指定されたschema要素。

entity要素に定義されたtable要素やsecondary-table要素のschema属性。

(4)　<catalog>

catalog要素は，同一マッピングファイル内に記載されたエンティティにだけ適用されます。

catalog要素は，次の要素や属性によって上書きされます。

マッピングファイル内に記載されたEntityクラスの@Tableや@SecondaryTableに明確に指定されたcatalog要素。

entity要素に定義されたtable下位要素やsecondary-table下位要素のcatalog属性。

注意事項

catalog要素はデータベースによって，存在しない場合があります。CJPAプロバイダでサポートしているOracleとHiRDBではcatalog要素は存在しません。そのため，catalog要素を指定できません。指定した場合は，アプリケーション実行時に例外が発生します。

(5)　<access>

access要素は，同一マッピングファイル内に記載された，管理されたクラスで適用されます。

access要素は，次のアノテーションや属性によって上書きされます。

Entityクラスのアノテーションの指定位置によって決まるアクセスタイプ。

entity要素，mapped-superclass要素，およびembeddable要素で定義されたaccess属性。

注　指定値には，PROPERTYまたはFIELDを指定します。エンティティクラスのフィールドに対するアクセス方法の指定については，「8.12.3　エンティティクラスのフィールドに対するアクセス方法の指定」を参照してください。

(6)　<sequence-generator>

シーケンスジェネレータを追加します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒7　<sequence-generator>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.51　@SequenceGenerator」のname属性を参照してください。

sequence-name

xsd:string

任意

「8.22.51　@SequenceGenerator」のsequenceName属性を参照してください。

initial-value

xsd:int

任意

「8.22.51　@SequenceGenerator」のinitialValue属性を参照してください。

allocation-size

xsd:int

任意

「8.22.51　@SequenceGenerator」のallocationSize属性を参照してください。

12.3.2　persistence-unit-metadata以下の要素

(1)　<persistence-unit-metadata>

PersistenceUnit全体に関する定義を指定します。

(2)　<xml-mapping-metadata-complete>

xml-mapping-metadata-complete要素を指定すると，永続化ユニットのマッピングメタデータは抑止され，クラスで指定したアノテーションは無視されます。

xml-mapping-metadata-complete要素が指定され，XML要素が省略されると，デフォルト値が有効になります。

注意事項

アノテーションが指定されている場合，この要素を指定することによって，KDJE55532-Wのメッセージが出力されることがあります。

(3)　<persistence-unit-defaults>

永続化ユニットのデフォルト値を指定します。

(4)　<schema>

schema要素は，永続化ユニット内のすべてのEntityクラス，テーブルジェネレータ，および結合表に適用されます。

schema要素は，次の要素や属性によって上書きされます。

entity-mappings要素のschema要素。

Entityクラスの@Tableや@SecondaryTableに明確に指定されたschema属性。

entity要素のtable要素やsecondary-table要素に指定されたschema属性。

@TableGeneratorやtable-generator要素に明確に指定されたschema要素。

@JoinTableやjoin-table要素に明確に指定されたschema要素。

(5)　<catalog>

catalog要素は，永続化ユニット内のすべてのEntityクラス，テーブルジェネレータ，結合表に適用されます。

catalog要素は，次の要素や属性によって上書きされます。

entity-mappings要素のcatalog要素。

Entityクラスの@Tableや@SecondaryTableに明確に指定されたcatalog属性。

entity要素のtable要素やsecondary-table要素に指定されたcatalog属性。

@TableGeneratorやtable-generator要素に明確に指定されたcatalog要素。

@JoinTableやjoin-table要素に明確に指定されたcatalog要素。

注意事項

CJPAプロバイダでサポートしているOracleとHiRDBではcatalogは存在しません。そのため，catalogを指定できません。指定した場合，アプリケーション実行時に例外が発生します。

(6)　<access>

access要素は，永続化ユニット内のすべての管理されたクラスで適用されます。

access要素は，次のアノテーションや要素や属性によって上書きされます。

Entityクラスのアノテーションの指定位置によって決まるアクセスタイプ。

entity-mappings要素のaccess要素。

entity要素やmapped-superclass要素やembeddable要素で定義されたaccess属性。

注意事項

指定値には，PROPERTYまたはFIELDを指定します。エンティティクラスのフィールドに対するアクセス方法の指定については，「8.12.3　エンティティクラスのフィールドに対するアクセス方法の指定」を参照してください。

(7)　<cascade-persist>

cascade-persist要素は，永続化ユニット内のすべてのリレーションシップで適用されます。

cascade-persist要素の指定は，アノテーションかO/Rマッピングファイルで指定された値に加えてすべてのリレーションシップにカスケード永続化オプションを追加します。

注意事項

cascade-persist要素を指定すると，上書きや無効化することができません。

(8)　<entity-listeners>

entity-listeners要素は，永続化ユニットのデフォルトエンティティリスナを定義します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

12.3.3　table-generator以下の要素

(1)　<table-generator>

table-generator要素によって定義されたジェネレータは，永続化ユニットに適用されます。

定義されたジェネレータは，アノテーションで定義されたジェネレータに追加されます。アノテーションで同名のジェネレータが定義されたら，table-generator要素で定義したジェネレータが上書きされます。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒8　<table-generator>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.55　@TableGenerator」のname属性を参照してください。

table

xsd:string

任意

「8.22.55　@TableGenerator」のtable属性を参照してください。

catalog

xsd:string

任意

「8.22.55　@TableGenerator」のcatalog属性を参照してください。

schema

xsd:string

任意

「8.22.55　@TableGenerator」のschema属性を参照してください。

pk-column-name

xsd:string

任意

「8.22.55　@TableGenerator」のpkColumnName属性を参照してください。

value-column-name

xsd:string

任意

「8.22.55　@TableGenerator」のvalueColumnName属性を参照してください。

pk-column-value

xsd:string

任意

「8.22.55　@TableGenerator」のpkColumnValue属性を参照してください。

initial-value

xsd:int

任意

「8.22.55　@TableGenerator」のinitialValue属性を参照してください。

allocation-size

xsd:int

任意

「8.22.55　@TableGenerator」のallocationSize属性を参照してください。

12.3.4　named-query以下の要素

(1)　<named-query>

named-query要素によって定義された名前付きクエリは，永続化ユニットに適用されます。

定義された名前付きクエリは，アノテーションで定義された名前付きクエリに追加されます。アノテーションで同名の名前付きクエリが定義されたら，named-query要素で定義した名前付きクエリが上書きされます。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒9　<named-query>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.35　@NamedQuery」のname属性を参照してください。

12.3.5　named-native-query以下の要素

(1)　<named-native-query>

named-native-query要素によって定義された名前付きネイティブクエリは，永続化ユニットに適用されます。

定義された名前付きネイティブクエリは，アノテーションで定義された名前付きネイティブクエリに追加されます。アノテーションで同名の名前付きネイティブクエリが定義されたら，O/Rマッピングファイルのnamed-native-query要素で定義した名前付きネイティブクエリを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒10　<named-native-query>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.33　@NamedNativeQuery」のname属性を参照してください。

result-class

xsd:string

任意

「8.22.33　@NamedNativeQuery」のresultClass属性を参照してください。

result-set-mapping

xsd:string

任意

「8.22.33　@NamedNativeQuery」のresultSetMapping属性を参照してください。

12.3.6　sql-result-set-mapping以下の要素

(1)　<sql-result-set-mapping>

sql-result-set-mapping要素によって定義されたSQL結果セットマッピングは，永続化ユニットに適用されます。

定義されたSQL結果セットマッピングは，アノテーションで定義されたSQL結果セットマッピングに追加されます。アノテーションで同名のSQL結果セットマッピングが定義されたら，O/Rマッピングファイルのsql-result-set-mapping要素で定義したSQL結果セットマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒11　<sql-result-set-mapping>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.52　@SqlResultSetMapping」のname属性を参照してください。

12.3.7　mapped-superclass以下の要素

次に示す要素と属性は，要素や属性の対象であるマップドスーパークラスだけに適用されます。

(1)　<mapped-superclass>

mapped-superclass要素は，永続化ユニットのマップドスーパークラスを定義します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒12　<mapped-superclass>の属性

属性名

型

任意／必須

説明

class

xsd:string

必須

マップドスーパークラスのクラス名

access

orm:access-type

任意

access属性は，マップドスーパークラスのアクセスタイプを定義します。access属性は，マップドスーパークラスに与えたpersistence-unit-defaults要素（デフォルトとして指定した要素）やentity-mappings要素（永続化ユニット全体に有効な要素）で指定したアクセスタイプを上書きします。※1

metadata-complete※2

xsd:boolean

任意

metadata-complete属性がmapped-superclass要素自身に指定されたら，マップドスーパークラスや，マップドスーパークラスのフィールドやプロパティに指定されたアノテーションは無視されます。

metadata-completeがmapped-superclass要素に指定され，XML要素が省略されると，デフォルト値が有効になります。

注※1　指定値には，PROPERTYまたはFIELDを指定します。エンティティクラスのフィールドに対するアクセス方法の指定については，「8.12.3　エンティティクラスのフィールドに対するアクセス方法の指定」を参照してください。

注※2　アノテーションが指定されている場合，この要素を指定することによって，KDJE55532-Wのメッセージが出力されることがあります。

(2)　<id-class>

id-class要素は，マップドスーパークラスで指定した@IdClassを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒13　<id-class>の属性

属性名

型

任意／必須

説明

class

xsd:string

必須

「8.22.22　@IdClass」のvalue属性を参照してください。

(3)　<exclude-default-listeners>

exclude-default-listeners要素は，@ExcludeDefaultListenersがマップドスーパークラスに指定されたかどうかに関係なく適用されます。

exclude-default-listeners要素は，マップドスーパークラスとそのサブクラスのデフォルトエンティティリスナを抑止します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(4)　<exclude-superclass-listeners>

exclude-superclass-listeners要素は，@ExcludeSuperclassListenersがマップドスーパークラスに指定されたかどうかに関係なく適用されます。

exclude-superclass-listeners要素は，マップドスーパークラスとそのサブクラスのスーパークラスリスナを抑止します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(5)　<entity-listeners>

entity-listeners要素は，マップドスーパークラスの@EntityListenersを上書きします。

ほかの方法で抑止されない場合，これらのリスナはマップドスーパークラスとそのサブクラスで適用します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(6)　<pre-persist>，<post-persist>，<pre-remove>，<post-remove>，<pre-update>，<post-update>，<post-load>

これらの要素は，マップドスーパークラスで，対応するアノテーションによるライフサイクルコールバックメソッドの定義を上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒14　<pre-persist>，<post-persist>，<pre-remove>，<post-remove>，<pre-update>，<post-update>，<post-load>の属性

属性名

型

任意／必須

説明

method-name

xsd:string

必須

対象のメソッド名。

(7)　<id>

id要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒15　<id>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

プライマリキープロパティ，もしくはフィールドであることを指定します。

(8)　<embedded-id>

embedded-id要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒16　<embedded-id>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

複合プライマリキーであることを指定します。

(9)　<basic>

basic要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒17　<basic>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

型をマッピングするメソッドおよびフィールドを指定します。

fetch

orm:fetch-type

任意

Fetch戦略の値を指定します。

詳細は「8.22.5　@Basic」のfetch属性を参照してください。

optional

xsd:boolean

任意

フィールド（プロパティ）がnullを使用するかどうかを指定します。

詳細は「8.22.5　@Basic」のoptional属性を参照してください。

(10)　<version>

version要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒18　<version>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

versionプロパティもしくはフィールドであることを指定します。

(11)　<many-to-one>

many-to-one要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒19　<many-to-one>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

多対一リレーションシップのメソッドもしくはフィールドであることを指定します。

target-entity

xsd:string

任意

関連するEntityクラスを指定します。

詳細は「8.22.29　@ManyToOne」のtargetEntity属性を参照してください。

fetch

orm:fetch-type

任意

Fetch戦略の値を指定します。

詳細は「8.22.29　@ManyToOne」のfetch属性を参照してください。

optional

xsd:boolean

任意

すべての非プリミティブなフィールドおよびプロパティの値にnullを指定するかどうかを定義します。

詳細は「8.22.29　@ManyToOne」のoptional属性を参照してください。

(12)　<one-to-many>

one-to-many要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒20　<one-to-many>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

一対多リレーションシップのメソッドまたはフィールド。

target-entity

xsd:string

任意

関連するEntityクラスを指定します。詳細は「8.22.36　@OneToMany」のtargetEntity属性を参照してください。

fetch

orm:fetch-type

任意

Fetch戦略の値を指定します。

詳細は「8.22.36　@OneToMany」のfetch属性を参照してください。

mapped-by

xsd:string

任意

被所有者側のEntityクラスの要素に付与し，所有者側のEntityクラスで関係を保持しているフィールド（プロパティ）名を指定します。

詳細は「8.22.36　@OneToMany」のmappedBy属性を参照してください。

(13)　<one-to-one>

one-to-one要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒21　<one-to-one>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

一対一リレーションシップのメソッドまたはフィールド。

target-entity

xsd:string

任意

「8.22.37　@OneToOne」のtargetEntity属性を参照してください。

fetch

orm:fetch-type

任意

「8.22.37　@OneToOne」のfetch属性を参照してください。

optional

xsd:boolean

任意

「8.22.37　@OneToOne」のoptional属性を参照してください。

mapped-by

xsd:string

任意

「8.22.37　@OneToOne」のmappedBy属性を参照してください。

(14)　<many-to-many>

many-to-many要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒22　<many-to-many>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

多対多リレーションシップのメソッドまたはフィールド。

target-entity

xsd:string

任意

「8.22.28　@ManyToMany」のtargetEntity属性を参照してください。

fetch

orm:fetch-type

任意

「8.22.28　@ManyToMany」のfetch属性を参照してください。

mapped-by

xsd:string

任意

「8.22.28　@ManyToMany」のmappedBy属性を参照してください。

(15)　<embedded>

embedded要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒23　<embedded>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

埋め込みオブジェクトであるプロパティまたはフィールド。

(16)　<transient>

transient要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒24　<transient>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

永続的でないプロパティまたはフィールド。

12.3.8　entity以下の要素

次に示す要素と属性は，下位要素や属性の対象であるEntityクラスにだけ適用されます。

(1)　<entity>

entity要素は，永続化ユニットのエンティティを定義します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒25　<entity>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

name属性は，エンティティの名前を定義します。name属性は，@Entityのname要素によって定義されたエンティティ名を，明確に指定されたかデフォルトかに関係なく上書きします。

Entityクラスの名前を上書きした場合の動作は保証しません。

class

xsd:string

必須

エンティティのクラス名。

access

orm:access-type

任意

access属性は，Entityクラスのアクセスタイプを定義します。access属性は，Entityクラスに与えたpersistence-unit-defaults要素（デフォルトとして指定した要素）やentity-mappings要素（永続化ユニット全体に有効な要素）で指定したアクセスタイプを上書きします。※1

metadata-complete※2

xsd:boolean

任意

metadata-complete属性がentity要素自身に指定されたら，Entityクラスや，Entityクラスのフィールドやプロパティに指定されたアノテーションは無視されます。

metadata-completeがentity要素に指定され，XML要素が省略されると，デフォルト値が有効になります。

注※1　指定値には，PROPERTYまたはFIELDを指定します。エンティティクラスのフィールドに対するアクセス方法の指定については，「8.12.3　エンティティクラスのフィールドに対するアクセス方法の指定」を参照してください。

注※2　アノテーションが指定されている場合，この要素を指定することによって，KDJE55532-Wのメッセージが出力されることがあります。

(2)　<table>

table要素は，Entityクラスの@Table（デフォルト値も含む）を上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒26　<table>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.54　@Table」のname属性を参照してください。

catalog

xsd:string

任意

「8.22.54　@Table」のcatalog属性を参照してください。

schema

xsd:string

任意

「8.22.54　@Table」のschema属性を参照してください。

(3)　<secondary-table>

secondary-table要素は，Entityクラスのすべての@SecondaryTableと@SecondaryTables（デフォルト値も含む）を上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒27　<secondary-table>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.49　@SecondaryTable」のname属性を参照してください。

catalog

xsd:string

任意

「8.22.49　@SecondaryTable」のcatalog属性を参照してください。

schema

xsd:string

任意

「8.22.49　@SecondaryTable」のschema属性を参照してください。

(4)　<primary-key-join-column>

primary-key-join-column要素は，Entityクラスのすべての@PrimaryKeyJoinColumnと@PrimaryKeyJoinColumns（デフォルト値も含む）を上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒28　<primary-key-join-column>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.46　@PrimaryKeyJoinColumn」のname属性を参照してください。

referenced-column-name

xsd:string

任意

「8.22.46　@PrimaryKeyJoinColumn」のreferencedColumnName属性を参照してください。

column-definition

xsd:string

任意

「8.22.46　@PrimaryKeyJoinColumn」のcolumnDefinition属性を参照してください。

(5)　<id-class>

id-class要素は，Entityクラスに指定された@IdClassを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒29　<id-class>の属性

属性名

型

任意／必須

説明

value

xsd:string

必須

「8.22.22　@IdClass」のvalue属性を参照してください。

(6)　<inheritance>

inheritance要素は，Entityクラスの@Inheritance（デフォルト値も含む）を上書きします。

inheritance要素は，Entityクラスと，そのサブクラスで適用します（アノテーションやXML要素で指定したサブクラスが，別の方法で上書きされなかった場合）。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒30　<inheritance>の属性

属性名

型

任意／必須

説明

strategy

orm:inheritance-type

任意

「8.22.23　@Inheritance」のstrategy属性を参照してください。

(7)　<discriminator-value>

discriminator-value要素は，Entityクラスの@DiscriminatorValue（デフォルト値も含む）を上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(8)　<discriminator-column>

discriminator-column要素は，Entityクラスの@DiscriminatorColumn（デフォルト値も含む）を上書きします。

discriminator-column要素は，Entityクラスと，そのサブクラスで適用します（アノテーションやXML要素で指定したサブクラスが，別の方法で上書きされなかった場合）。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒31　<discriminator-column>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.8　@DiscriminatorColumn」のname属性を参照してください。

discriminator-type

orm:discriminator-type

任意

「8.22.8　@DiscriminatorColumn」のdiscriminatorType属性を参照してください。

column-definition

xsd:string

任意

「8.22.8　@DiscriminatorColumn」のcolumnDefinition属性を参照してください。

length

xsd:int

任意

「8.22.8　@DiscriminatorColumn」のlength属性を参照してください。

(9)　<sequence-generator>

sequence-generator要素によって定義されたジェネレータは，アノテーションによって定義されたジェネレータや，O/Rマッピングファイルで定義されたほかのジェネレータに加えられます。アノテーションで同名のジェネレータが定義されたら，sequence-generator要素で定義されたジェネレータで上書きします。

sequence-generator要素によって定義されたジェネレータは，永続化ユニットに適用されます。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒32　<sequence-generator>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.51　@SequenceGenerator」のname属性を参照してください。

sequence-name

xsd:string

任意

「8.22.51　@SequenceGenerator」のsequenceName属性を参照してください。

initial-value

xsd:int

任意

「8.22.51　@SequenceGenerator」のinitialValue属性を参照してください。

allocation-size

xsd:int

任意

「8.22.51　@SequenceGenerator」のallocationSize属性を参照してください。

(10)　<table-generator>

table-generator要素によって定義されたジェネレータは，アノテーションによって定義されたジェネレータや，O/Rマッピングファイルで定義されたほかのジェネレータに加えられます。アノテーションで同名のジェネレータが定義されたら，table-generator要素で定義されたジェネレータで上書きします。

table-generator要素によって定義されたジェネレータは，永続化ユニットに適用されます。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒33　<table-generator>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.55　@TableGenerator」のname属性を参照してください。

table

xsd:string

任意

「8.22.55　@TableGenerator」のtable属性を参照してください。

catalog

xsd:string

任意

「8.22.55　@TableGenerator」のcatalog属性を参照してください。

schema

xsd:string

任意

「8.22.55　@TableGenerator」のschema属性を参照してください。

pk-column-name

xsd:string

任意

「8.22.55　@TableGenerator」のpkColumnName属性を参照してください。

value-column-name

xsd:string

任意

「8.22.55　@TableGenerator」のvalueColumnName属性を参照してください。

pk-column-value

xsd:string

任意

「8.22.55　@TableGenerator」のpkColumnValue属性を参照してください。

initial-value

xsd:int

任意

「8.22.55　@TableGenerator」のinitialValue属性を参照してください。

allocation-size

xsd:int

任意

「8.22.55　@TableGenerator」のallocationSize属性を参照してください。

(11)　<named-query>

named-query要素によって定義された名前付きクエリは，アノテーションによって定義された名前付きクエリや，O/Rマッピングファイルで定義されたほかの名前付きクエリに加えられます。アノテーションで同名の名前付きクエリが定義されたら，named-query要素で定義された名前付きクエリで上書きします。

named-query要素によって定義された名前付きクエリは，永続化ユニットに適用されます。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒34　<named-query>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.35　@NamedQuery」のname属性を参照してください。

(12)　<named-native-query>

named-native-query要素によって定義された名前付きネイティブクエリは，アノテーションによって定義された名前付きネイティブクエリや，O/Rマッピングファイルで定義されたほかの名前付きネイティブクエリに加えられます。アノテーションで同名の名前付きネイティブクエリが定義されたら，named-native-query要素で定義された名前付きネイティブクエリで上書きします。

named-native-query要素によって定義された名前付きネイティブクエリは，永続化ユニットに適用されます。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒35　<named-native-query>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.33　@NamedNativeQuery」のname属性を参照してください。

result-class

xsd:string

任意

「8.22.33　@NamedNativeQuery」のresultClass属性を参照してください。

result-set-mapping

xsd:string

任意

「8.22.33　@NamedNativeQuery」のresultSetMapping属性を参照してください。

(13)　<sql-result-set-mapping>

sql-result-set-mapping要素によって定義されたSQL結果のマッピングは，アノテーションによって定義されたSQL結果のマッピングや，O/Rマッピングファイルで定義されたほかのSQL結果のマッピングに加えられます。アノテーションで同名のSQL結果のマッピングが定義されたら，sql-result-set-mapping要素で定義されたSQL結果のマッピングで上書きします。

sql-result-set-mapping要素によって定義されたSQL結果のマッピングは，永続化ユニットに適用されます。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒36　<sql-result-set-mapping>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.52　@SqlResultSetMapping」のname属性を参照してください。

(14)　<exclude-default-listeners>

exclude-default-listeners要素は，@ExcludeDefaultListenersがEntityクラスに指定されたかどうかに関係なく適用されます。

exclude-default-listeners要素は，Entityクラスとそのサブクラスのデフォルトエンティティリスナを抑止します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(15)　<exclude-superclass-listeners>

exclude-superclass-listeners要素は，@ExcludeSuperclassListenersがEntityクラスに指定されたかどうかに関係なく適用されます。

exclude-superclass-listeners要素は，Entityクラスとそのサブクラスのスーパークラスリスナを抑止します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(16)　<entity-listeners>

entity-listeners要素は，Entityクラスの@EntityListenersを上書きします。

ほかの方法で抑止されない場合，これらのリスナはEntityクラスとそのサブクラスで適用します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(17)　<pre-persist>，<post-persist>，<pre-remove>，<post-remove>，<pre-update>，<post-update>，<post-load>

これらの要素は，Entityクラスで，対応するアノテーションによるライフサイクルコールバックメソッドの定義を上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒37　<pre-persist>，<post-persist>，<pre-remove>，<post-remove>，<pre-update>，<post-update>，<post-load>の属性

属性名

型

任意／必須

説明

method-name

xsd:string

必須

対象のメソッド名。

(18)　<attribute-override>

attribute-override要素は，Entityクラスの@AttributeOverrideまたは@AttributeOverridesで定義された値に加えられます。attribute-override要素は，同一の属性名のAttributeOverride要素を上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒38　<attribute-override>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.3　@AttributeOverride」のname属性を参照してください。

(19)　<association-override>

association-override要素は，Entityクラスの@AssociationOverrideまたは@AssociationOverridesで定義された値に加えられます。association-override要素は，同一の属性名のAssociationOverride要素を上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒39　<association-override>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.1　@AssociationOverride」のname属性を参照してください。

(20)　<id>

id要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒40　<id>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

プライマリキープロパティまたはフィールド。

(21)　<embedded-id>

embedded-id要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒41　<embedded-id>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

複合プライマリキー。

(22)　<basic>

basic要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒42　<basic>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

型をマッピングするメソッドまたはフィールド。

fetch

orm:fetch-type

任意

「8.22.5　@Basic」のfetch属性を参照してください。

optional

xsd:boolean

任意

「8.22.5　@Basic」のoptional属性を参照してください。

(23)　<version>

version要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒43　<version>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

versionプロパティまたはフィールド。

(24)　<many-to-one>

many-to-one要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒44　<many-to-one>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

多対一リレーションシップのメソッドまたはフィールド。

target-entity

xsd:string

任意

「8.22.29　@ManyToOne」のtargetEntity属性を参照してください。

fetch

orm:fetch-type

任意

「8.22.29　@ManyToOne」のfetch属性を参照してください。

optional

xsd:boolean

任意

「8.22.29　@ManyToOne」のoptional属性を参照してください。

(25)　<one-to-many>

one-to-many要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒45　<one-to-many>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

一対多リレーションシップのメソッドまたはフィールド。

target-entity

xsd:string

任意

「8.22.36　@OneToMany」のtargetEntity属性を参照してください。

fetch

orm:fetch-type

任意

「8.22.36　@OneToMany」のfetch属性を参照してください。

mapped-by

xsd:string

任意

「8.22.36　@OneToMany」のmappedBy属性を参照してください。

(26)　<one-to-one>

one-to-one要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒46　<one-to-one>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

一対一リレーションシップのメソッドまたはフィールド。

target-entity

xsd:string

任意

「8.22.37　@OneToOne」のtargetEntity属性を参照してください。

fetch

orm:fetch-type

任意

「8.22.37　@OneToOne」のfetch属性を参照してください。

optional

xsd:boolean

任意

「8.22.37　@OneToOne」のoptional属性を参照してください。

mapped-by

xsd:string

任意

「8.22.37　@OneToOne」のmappedBy属性を参照してください。

(27)　<many-to-many>

many-to-many要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒47　<many-to-many>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

多対多リレーションシップのメソッドまたはフィールド。

target-entity

xsd:string

任意

「8.22.28　@ManyToMany」のtargetEntity属性を参照してください。

fetch

orm:fetch-type

任意

「8.22.28　@ManyToMany」のfetch属性を参照してください。

mapped-by

xsd:string

任意

「8.22.28　@ManyToMany」のmappedBy属性を参照してください。

(28)　<embedded>

embedded要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒48　<embedded>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

埋め込みオブジェクトであるプロパティまたはフィールド。

(29)　<transient>

transient要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒49　<transient>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

永続的でないプロパティまたはフィールド。

12.3.9　embeddable以下の要素

次に示す要素と属性は，要素や属性の対象である埋め込み可能クラスだけに適用されます。

(1)　<embeddable>

embeddable要素は，永続化ユニットの埋め込み可能クラスを定義します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒50　<embeddable>の属性

属性名

型

任意／必須

説明

class

xsd:string

必須

埋め込み可能クラスのクラス名。

access

orm:access-type

任意

access属性は，埋め込み可能クラスのアクセスタイプを定義します。access属性は，埋め込み可能クラスに与えたpersistence-unit-defaults要素（デフォルトとして指定した要素）やentity-mappings要素（永続化ユニット全体に有効な要素）で指定したアクセスタイプを上書きします。※1

metadata-complete※2

xsd:boolean

任意

metadata-complete属性がembeddable要素自身に指定されたら，埋め込み可能クラスや，埋め込み可能クラスのフィールドやプロパティに指定されたアノテーションは無視されます。

metadata-completeがembeddable要素に指定され，XML要素が省略されると，デフォルト値が有効になります。

注※1　指定値には，PROPERTYまたはFIELDを指定します。エンティティクラスのフィールドに対するアクセス方法の指定については，「8.12.3　エンティティクラスのフィールドに対するアクセス方法の指定」を参照してください。

注※2　アノテーションが指定されている場合，この要素を指定することによって，KDJE55532-Wのメッセージが出力されることがあります。

(2)　<basic>

basic要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒51　<basic>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

型をマッピングするメソッドまたはフィールド。

fetch

orm:fetch-type

任意

「8.22.5　@Basic」のfetch属性を参照してください。

optional

xsd:boolean

任意

「8.22.5　@Basic」のoptional属性を参照してください。

(3)　<transient>

transient要素は，フィールドやプロパティで指定したマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒52　<transient>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

永続的でないプロパティまたはフィールド。

12.3.10　その他の要素

(1)　<description>

説明を付加します。

(2)　<entity-listener>

エンティティリスナを指定します。

指定できる属性を次の表に示します。

表12‒53　<entity-listener>の属性

属性名

型

任意／必須

説明

class

xsd:string

必須

エンティティリスナのクラス名。

(3)　<pre-persist>，<post-persist>，<pre-remove>，<post-remove>，<pre-update>，<post-update>，<post-load>

ライフサイクルコールバックメソッドを指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒54　<pre-persist>，<post-persist>，<pre-remove>，<post-remove>，<pre-update>，<post-update>，<post-load>の属性

属性名

型

任意／必須

説明

method-name

xsd:string

必須

対象のメソッド名。

(4)　<unique-constraint>

DDLにユニーク制約を付加します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(5)　<column-name>

ユニーク制約を付加するカラムの名前を指定します。

@UniqueConstraintのcolumnNames属性と対応しています。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(6)　<query>

クエリ文字列を指定します。

@NamedQueryのquery属性および@NamedNativeQueryのquery属性と対応しています。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(7)　<hint>

クエリにヒントを付加します。

@NamedQueryのhints属性および@NamedNativeQueryのhints属性と対応しています。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒55　<hint>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.48　@QueryHint」のname属性を参照してください。

value

xsd:string

必須

「8.22.48　@QueryHint」のvalue属性を参照してください。

(8)　<entity-result>

ネイティブSQLのクエリ結果をマッピングするためのEntityクラスを指定します。

@SqlResultSetMappingのentities属性と対応しています。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒56　<entity-result>の属性

属性名

型

任意／必須

説明

entity-class

xsd:string

必須

「8.22.15　@EntityResult」のentityClass属性を参照してください。

discriminator-column

xsd:string

任意

「8.22.15　@EntityResult」のdiscriminatorColumn属性を参照してください。

(9)　<field-result>

ネイティブSQLのクエリ結果をマッピングするためのフィールドを指定します。

@EntityResultのfields属性と対応しています。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒57　<field-result>の属性

型

属性名

任意／必須

説明

xsd:string

name

必須

「8.22.19　@FieldResult」のname属性を参照してください。

xsd:string

column

必須

「8.22.19　@FieldResult」のcolumn属性を参照してください。

(10)　<column-result>

ネイティブSQLのクエリ結果をマッピングするためのカラムを指定します。

@SqlResultSetMappingのcolumns属性と対応しています。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒58　<column-result>の属性

型

属性名

任意／必須

説明

xsd:string

name

必須

「8.22.7　@ColumnResult」のname属性を参照してください。

(11)　<attributes>

attributes要素自体の機能はありません。

(12)　<column>

Persistentフィールドまたはプロパティに，カラムのマッピングを指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒59　<column>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.6　@Column」のname属性を参照してください。

unique

xsd:boolean

任意

「8.22.6　@Column」のunique属性を参照してください。

nullable

xsd:boolean

任意

「8.22.6　@Column」のnullable属性を参照してください。

insertable

xsd:boolean

任意

「8.22.6　@Column」のinsertable属性を参照してください。

updatable

xsd:boolean

任意

「8.22.6　@Column」のupdatable属性を参照してください。

column-definition

xsd:string

任意

「8.22.6　@Column」のcolumnDefinition属性を参照してください。

table

xsd:string

任意

「8.22.6　@Column」のtable属性を参照してください。

length

xsd:int

任意

「8.22.6　@Column」のlength属性を参照してください。

precision

xsd:int

任意

「8.22.6　@Column」のprecision属性を参照してください。

scale

xsd:int

任意

「8.22.6　@Column」のscale属性を参照してください。

(13)　<generated-value>

プライマリキー値生成戦術を指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒60　<generated-value>の属性

属性名

型

任意／必須

説明

strategy

orm:generation-type

任意

「8.22.20　@GeneratedValue」のstrategy属性を参照してください。

generator

xsd:string

任意

「8.22.20　@GeneratedValue」のgenerator属性を参照してください。

(14)　<temporal>

DATE，TIME，TIMESTAMP型へマッピングを行うときに指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(15)　<table-generator>

テーブルジェネレータを追加します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒61　<table-generator>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.55　@TableGenerator」のname属性を参照してください。

table

xsd:string

任意

「8.22.55　@TableGenerator」のtable属性を参照してください。

catalog

xsd:string

任意

「8.22.55　@TableGenerator」のcatalog属性を参照してください。

schema

xsd:string

任意

「8.22.55　@TableGenerator」のschema属性を参照してください。

pk-column-name

xsd:string

任意

「8.22.55　@TableGenerator」のpkColumnName属性を参照してください。

value-column-name

xsd:string

任意

「8.22.55　@TableGenerator」のvalueColumnName属性を参照してください。

pk-column-value

xsd:string

任意

「8.22.55　@TableGenerator」のpkColumnValue属性を参照してください。

initial-value

xsd:int

任意

「8.22.55　@TableGenerator」のinitialValue属性を参照してください。

allocation-size

xsd:int

任意

「8.22.55　@TableGenerator」のallocationSize属性を参照してください。

(16)　<attribute-override>

プロパティやフィールドのマッピングを上書きします。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒62　<attribute-override>の属性

属性名

型

任意／必須

説明

name

xsd:string

必須

「8.22.3　@AttributeOverride」のname属性を参照してください。

(17)　<lob>

Lob型へマッピングを行うときに指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(18)　<enumerated>

列挙型へマッピングを行うときに指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(19)　<join-column>

テーブルを結合するために，所有者側エンティティに対応する結合表の外部キーカラムを指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒63　<join-column>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.24　@JoinColumn」のname属性を参照してください。

referenced-column-name

xsd:string

任意

「8.22.24　@JoinColumn」のreferencedColumnName属性を参照してください。

unique

xsd:boolean

任意

「8.22.24　@JoinColumn」のunique属性を参照してください。

nullable

xsd:boolean

任意

「8.22.24　@JoinColumn」のnullable属性を参照してください。

insertable

xsd:boolean

任意

「8.22.24　@JoinColumn」のinsertable属性を参照してください。

updatable

xsd:boolean

任意

「8.22.24　@JoinColumn」のupdatable属性を参照してください。

column-definition

xsd:string

任意

「8.22.24　@JoinColumn」のcolumnDefinition属性を参照してください。

table

xsd:string

任意

「8.22.24　@JoinColumn」のtable属性を参照してください。

(20)　<join-table>

多対多（many-to-many）や片方向の一対多（one-to-many）で使用する結合表を指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒64　<join-table>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.26　@JoinTable」のname属性を参照してください。

catalog

xsd:string

任意

「8.22.26　@JoinTable」のcatalog属性を参照してください。

schema

xsd:string

任意

「8.22.26　@JoinTable」のschema属性を参照してください。

(21)　<inverse-join-column>

テーブルを結合するために，被所有者側エンティティに対応する結合表の外部キーカラムを指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒65　<inverse-join-column>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.24　@JoinColumn」のname属性を参照してください。

referenced-column-name

xsd:string

任意

「8.22.24　@JoinColumn」のreferencedColumnName属性を参照してください。

unique

xsd:boolean

任意

「8.22.24　@JoinColumn」のunique属性を参照してください。

nullable

xsd:boolean

任意

「8.22.24　@JoinColumn」のnullable属性を参照してください。

insertable

xsd:boolean

任意

「8.22.24　@JoinColumn」insertable属性を参照してください。

updatable

xsd:boolean

任意

「8.22.24　@JoinColumn」のupdatable属性を参照してください。

column-definition

xsd:string

任意

「8.22.24　@JoinColumn」のcolumnDefinition属性を参照してください。

table

xsd:string

任意

「8.22.24　@JoinColumn」のtable属性を参照してください。

(22)　<cascade>

カスケードできる操作を指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(23)　<cascade-all>

すべての操作をカスケードします。

(24)　<cascade-persist>

persist操作をカスケードします。

(25)　<cascade-merge>

merge操作をカスケードします。

(26)　<cascade-remove>

remove操作をカスケードします。

(27)　<cascade-refresh>

refresh操作をカスケードします。

(28)　<order-by>

関連をコレクションに保持する際に付ける順序を指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

(29)　<map-key>

Map型の関連としてマップキーを指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒66　<map-key>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.30　@MapKey」のname属性を参照してください。

(30)　<primary-key-join-column>

ほかのテーブルにJOINする外部キーとして使われる，プライマリキーカラムを指定します。

機能および属性の詳細については，「8.22　javax.persistenceパッケージに含まれるアノテーションのサポート範囲」を参照してください。

指定できる属性を次の表に示します。

表12‒67　<primary-key-join-column>の属性

属性名

型

任意／必須

説明

name

xsd:string

任意

「8.22.46　@PrimaryKeyJoinColumn」のname属性を参照してください。

referenced-column-name

xsd:string

任意

「8.22.46　@PrimaryKeyJoinColumn」のreferencedColumnName属性を参照してください。

column-definition

xsd:string

任意

「8.22.46　@PrimaryKeyJoinColumn」のcolumnDefinition属性を参照してください。

12.4　クエリヒント

CJPAプロバイダでは，O/Rマッピングファイルのnamed-query要素の下位要素であるhint要素にクエリヒントを指定できます。なお，クエリヒントは，@NamedQueryアノテーションの引数の＠Hintアノテーションにも指定できます。アノテーションに指定するクエリヒントについては，「8.22.48　@QueryHint」を参照してください。

O/Rマッピングファイルのnamed-query要素の下位要素であるhint要素に指定できるクエリヒントを次の表に示します。

表12‒68　CJPAプロバイダで使用できるクエリヒント

キー名称

説明

指定可能値

デフォルト

cosminexus.jpa.pessimistic-lock

悲観的ロックを使用するかどうかを指定します。

NoLock

悲観的ロックを使用しません。

Lock

悲観的ロックを使用します。

対象となるテーブルがすでにロックされている場合，解放されるまで待ちます。

Oracleの場合

SELECT … FOR UPDATEを発行します。

HiRDBの場合

SELECT … WITH EXCLUSIVE LOCKを発行します。

LockNoWait

悲観的ロックを使用します。

対象となるテーブルがすでにロックされている場合，例外が発生します。

Oracleの場合

SELECT … FOR UPDATE NO WAITを発行します。

HiRDBの場合

SELECT … WITH EXCLUSIVE LOCK NO WAITを発行します。

NoLock

注　指定できるデータ型はStringです。

注意事項

O/Rマッピングファイルに指定したクエリヒントに，指定可能範囲外の値が設定された場合は，アプリケーションを開始したタイミングで例外が発生します。なお，値の大文字と小文字は区別しません。

13　Webサーバ連携で使用するファイル

この章では，Webサーバ連携で使用するファイルの形式，格納先，機能，指定できるキーなどについて説明します。

13.1　Webサーバ連携で使用するファイルの一覧

Webサーバ連携で使用するファイルの一覧を，次の表に示します。

表13‒1　Webサーバ連携で使用するファイルの一覧

ファイル名

分類

概要

参照先

isapi_redirect.conf

Microsoft IIS用リダイレクタ動作定義ファイル

Microsoft IIS用リダイレクタの動作を定義します。

13.2.1

mod_jk.conf

HTTP Server用リダイレクタ動作定義ファイル

HTTP Server用リダイレクタの動作を定義します。

13.2.2

uriworkermap.properties

Microsoft IIS用マッピング定義ファイル

Microsoft IISへのリクエストでどのURLパターンがWebコンテナに転送されるかを定義します。

13.2.3

workers.properties

ワーカ定義ファイル

リダイレクタの動作を定義します。

13.2.4

13.2　Webサーバ連携で使用するファイルの詳細

13.2.1　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）

(1)　形式

次のようにキーを指定します。

<キー名称> = <値>

指定方法

改行までが値になります。

#で始まる行はコメントとみなされます。

値が存在しない行を定義した場合，その行は無視されます。キー名称として定義されていないパラメタを定義しても無視されます。

「キー名称=値」として1023文字までが有効となります。超えた部分は切り捨てられます。

(2)　ファイルの格納先

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.conf

(3)　機能

Microsoft IIS用リダイレクタの動作パラメタを定義します。

(4)　指定できるキー

指定できるキーとデフォルト値を次に示します。このキーに不正な値を指定した場合，動作は保証されません。なお，複数のキーを指定した場合，最後に指定した値が有効になります。

キー名称

内容

デフォルト値

connection_sharing

ワーカ間でコネクションを共有するかどうかを指定します。

trueを指定した場合：

同一ホスト，同一ポートへ接続するワーカは，ワーカ定義が異なってもコネクションを共有します。

falseを指定した場合：

ワーカ定義が異なるワーカ間のコネクションは共有しません。

true

connect_timeout

リクエスト送信時のWebコンテナに対するコネクション確立のタイムアウト値を0〜3600の整数（単位：秒）で指定します。

数値以外の文字列や範囲外の数値を指定した場合は，メッセージを出力し，デフォルト値を使用します。

タイムアウト値に0，またはTCPの持つデータ送信の再送タイマより長い時間を設定した場合，TCPの持つタイムアウト値になります。その場合，不正なタイムアウト値が指定されたことを示すメッセージは出力されません。

30

filter_priority

リダイレクタをISAPIフィルタとして登録する際の，優先順序を指定します。

指定できる文字列を次に示します。

high（優先順序を「高」にする）

medium（優先順序を「中」にする）

low（優先順序を「低」にする）

high

gateway_host

ゲートウェイのホスト名またはIPアドレスを指定します。

Hostヘッダのないリクエストをwelcomeファイルなどにリダイレクトする場合，Locationヘッダに指定するURLのホスト名部分が指定値になります。

なし

gateway_https_scheme

クライアントからのリクエストのスキームがhttpsであり，かつSSLアクセラレータなどを介すことでWebサーバへのスキームがhttpとなる場合に，trueを指定します。

trueを指定した場合，Webサーバへのリクエストのスキームがhttpsであるとみなされます。falseを指定した場合は，何も実行されません。

false

gateway_port

ゲートウェイのポート番号を指定します。Hostヘッダのないリクエストに対して，welcomeファイルなどにリダイレクトするとき，Locationヘッダに指定するURLのポート番号部分が指定値になります。このパラメタを指定した場合は，gateway_hostも必ず指定してください。

gateway_hostを指定してこのパラメタを省略した場合，httpによるアクセスの場合は80，httpsによるアクセスの場合は443が使用されます。

なし

log_file_dir

ログファイルの出力先ディレクトリを指定します。

相対パスで指定した場合：

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector以下のディレクトリ名を指します。

絶対パスで指定した場合：

記述されたディレクトリ名を指します。

なお，出力先として指定したディレクトリのアクセス権にUsersグループに対する書き込み権限を設定する必要があります。アクセス権を設定していない場合，ログファイルが出力されません。

log_file_prefixとtrace_log_file_prefixに同じ値を指定した場合は，このキーにtrace_log_file_dirとは異なる値を指定する必要があります。同じ値が指定された場合，リダイレクタは動作しません。

logs

log_file_num

リダイレクタ用ログファイルの最大数を指定します。この数を超えると古いログファイルは上書きされます。

1〜64の整数値を指定します。

5

log_file_prefix

ログファイル名のプリフィックスです。実際のログファイル名は，このキーの指定値に<通番>.logが付けられたものになります。

log_file_dirとtrace_log_file_dirに同じ値を指定した場合は，このキーにtrace_log_file_prefixとは異なる値を指定する必要があります。同じ値が指定された場合，リダイレクタは動作しません。

isapi_redirect

log_file_size

リダイレクタ用ログファイルの一つ当たりのサイズをバイト単位で指定します。

4096〜16777216の整数値を指定します。

4194304

log_level

リダイレクタ用ログファイルの出力レベルを指定します。指定するログレベルを一つだけ指定します。

debug，info，errorを指定できます。

error

prf_id

PRFデーモン起動時にPRF識別子に指定した文字列を指定します。

PRF_ID

receive_client_timeout

クライアントからPOSTデータを受信するときのタイムアウト時間を秒単位で指定します。

60〜3600の整数値を60（秒）の倍数で指定します。

指定された値が60の倍数になっていない場合は，60の倍数に切り上げた値がタイムアウト時間になります。

300

request_retry_count

リクエスト送信時のWebコンテナに対するコネクション確立，およびリクエスト送信のリトライ回数を，1〜16の整数（単位：回）で指定します。

リトライ回数には，初回のコネクション確立およびリクエスト送信処理も含まれます。

タイムアウトが発生した場合，リトライするケースは次のとおりです。

コネクション確立時にタイムアウトした場合

リクエストヘッダ送信時にタイムアウトした場合

上記処理以降の，リクエストボディの送信時にタイムアウトが発生した場合は，リトライは行いません。

リトライ回数に，範囲外の値や，整数値でない値などの異常値を設定した場合，デフォルト値が設定されます。

3

send_timeout

リクエスト送信のタイムアウト値を0〜3600の整数（単位：秒）で指定します。

数値以外の文字列や範囲外の数値を指定した場合は，メッセージを出力し，デフォルト値を使用します。

タイムアウト値に0，またはTCPの持つデータ送信の再送タイマより長い時間を設定した場合，TCPの持つタイムアウト値になります。その場合，不正なタイムアウト値が指定されたことを示すメッセージは出力されません。

100

trace_log

リダイレクタの保守用トレースログを出力するかどうかを指定します。出力する場合はtrueを，出力しない場合はfalseを指定します。

true

trace_log_file_dir

保守用トレースログファイルの出力先ディレクトリを指定します。

相対パスで記述した場合：

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector以下のディレクトリ名を指します。

絶対パスで記述した場合：

記述されたディレクトリ名を指します。

なお，出力先として指定したディレクトリのアクセス権にUsersグループに対する書き込み権限を設定する必要があります※。アクセス権を設定していない場合，ログファイルが出力されません。

log_file_prefixとtrace_log_file_prefixに同じ値を指定した場合は，このキーにlog_file_dirとは異なる値を指定する必要があります。同じ値が指定された場合，リダイレクタは動作しません。

logs

trace_log_file_num

保守用トレースログファイルの最大数を指定します。この数を超えると古いログファイルは上書きされます。

1〜64の整数値を指定します。

4

trace_log_file_prefix

保守用トレースログファイル名のプリフィックスを指定します。実際のログファイル名は，このキーの指定値に<通番>.logが付加されたものになります。

log_file_dirとtrace_log_file_dirに同じ値を指定した場合は，このキーにlog_file_prefixとは異なる値を指定する必要があります。同じ値が指定された場合，リダイレクタは動作しません。

iis_rd_trace

trace_log_file_size

保守用トレースログファイルの一つ当たりのサイズをバイト単位で指定します。

4096〜16777216の整数値を指定します。

16777216

worker_file

ワーカ定義ファイルの位置とファイル名を指定します。

相対パスで指定した場合：

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector以下のファイル名を指します。

絶対パスで指定した場合：

記述されたファイル名を指します。

workers.properties

worker_mount_file

マッピング定義ファイルの位置とファイル名を指定します。

相対パスで指定した場合：

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector以下のファイル名を指します。

絶対パスで指定した場合：

記述されたファイル名を指します。

uriworkermap.properties

注※　Microsoft IISと連携する場合

新規インストール時には，デフォルトのログ出力先ディレクトリは存在しません。ディレクトリを作成してアクセス権を設定するか，一つ上のディレクトリredirectorへアクセス権を設定してください。

また，リダイレクタのログ出力先ディレクトリを変更し，そのパスが途中までしか存在しない場合，存在する最下層のディレクトリに対してアクセス権を設定するか，指定したパスをすべて作成し，アクセス権を設定してください。

(5)　記述例

gateway_host=hostA
gateway_https_scheme=true
gateway_port=443

log_level=error
log_file_size=4194304
log_file_num=5
log_file_dir=logs
log_file_prefix=isapi_redirect
prf_id=prfid
trace_log=true
trace_log_file_size=16777216
trace_log_file_num=4
trace_log_file_dir=logs
trace_log_file_prefix=iis_rd_trace
receive_client_timeout=300
worker_file=workers.properties
worker_mount_file=uriworkermap.properties

(6)　注意事項

このファイルを編集してリダイレクタのユーザ定義を変更した場合，Webサーバを再起動する必要があります。変更した定義は，Webサーバを再起動したあとに反映されます。

13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）

(1)　形式

次のようにキーを指定します。

<キー名称> <値>

指定方法

改行までが値になります。

#で始まる行はコメントとみなされます。

キー名称と値は半角スペースで区切ります。また，値を複数指定する場合も半角スペースで区切ります。

指定する値がファイルパスでスペースを含む場合は，パス全体を""（ダブルクォーテーション）で囲む必要があります。

コメントの記述方法，および記述できる文字の種類などの記述形式は，HTTP Serverの仕様に従います。

キー名称の大文字小文字は区別しません。

(2)　ファイルの格納先

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥mod_jk.conf

UNIXの場合

/opt/Cosminexus/CC/web/redirector/mod_jk.conf

(3)　機能

リダイレクタの動作を定義します。

(4)　指定できるキー

モジュール定義

WebコンテナとHTTP Server間の通信を処理するためにライブラリを定義します。

形式

LoadModule jk_module <ライブラリ名>

ライブラリ名を絶対パスで指定します。なお，複数指定はできません。

指定例

Windowsの場合

LoadModule jk_module "<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥mod_jk.dll"

UNIXの場合

LoadModule jk_module /opt/Cosminexus/CC/web/redirector/mod_jk.so

注意事項

モジュール定義を指定するキーは，ほかのキーよりも前に記述する必要があります。

マッピング定義

HTTP ServerへのリクエストでどのURLパターンがWebコンテナに転送されるかを定義します。

形式

JkMount <URLパターン> <ワーカ名>

workers.propertiesのworker.listで指定されているワーカのどれかを記述します。URLパターンとワーカ名の組み合わせを複数記述できます。このファイルに不正な値を設定した場合，動作は保証されません。また，先頭がスラッシュ（/）から始まらないURLパターンを指定した場合，リダイレクタ起動時にエラーメッセージがログに出力され，指定した内容は無視されます。

拡張子の長さが0文字の拡張子指定のURLパターンを指定した場合（URLパターンの末尾が「/*.」の場合），メッセージKDJE41041-Wがログに出力され，指定した内容は無視されます。

JkMountキーについては，「5.4　ラウンドロビン方式によるリクエストの振り分け」，および「5.5　POSTデータサイズでのリクエストの振り分け」を参照してください。

リダイレクタ定義

次に示すキーを指定できます。ただし，このキーに不正な値を指定した場合，動作は保証されません。

なお，「関連情報」とは，指定したキーに関する情報の参照先です。マニュアル名称の「アプリケーションサーバ」を省略しています。

キー名称

内容

デフォルト値

関連情報

JkConnectTimeout

リクエスト送信時のWebコンテナに対するコネクション確立のタイムアウト値を，0〜3600の整数（単位：秒）で指定します。

数値以外の文字列や範囲外の数値を指定した場合は，メッセージを出力し，デフォルト値を使用します。

タイムアウト値に0，またはTCPの持つデータ送信の再送タイマより長い時間を設定した場合，TCPの持つタイムアウト値になります。その場合，不正なタイムアウト値が指定されたことを示すメッセージは出力されません。

30

JkGatewayHost

ゲートウェイのホスト名またはIPアドレスを指定します。

Hostヘッダのないリクエストに対してwelcomeファイルなどへリダイレクトする場合，Locationヘッダに指定するURLのホスト名部分が指定値になります。

なし

「5.10　Webコンテナへのゲートウェイ情報の通知」

JkGatewayHttpsScheme

クライアントからのリクエストのスキームがhttpsであり，かつSSLアクセラレータなどを介すことでWebサーバへのスキームがhttpとなる場合に，Onを指定します。

Onを指定した場合，Webサーバへのリクエストのスキームがhttpsであるとみなされます。Offを指定した場合，何も実行されません。

Off

「5.10　Webコンテナへのゲートウェイ情報の通知」

JkGatewayPort

ゲートウェイのポート番号を指定します。Hostヘッダのないリクエストをwelcomeファイルなどにリダイレクトする場合，Locationヘッダに指定するURLのポート番号部分が指定値となります。

このパラメタを指定した場合は，必ずJkGatewayHostも指定してください。

JkGatewayHostを指定してこのパラメタを省略した場合，httpによるアクセスであれば80，httpsによるアクセスであれば443が使用されます。

なし

「5.10　Webコンテナへのゲートウェイ情報の通知」

JkLogFileDir

ログファイルの出力先ディレクトリを指定します。Windowsの場合，相対パスまたは絶対パスで指定してください。UNIXの場合，絶対パスで指定してください。

相対パスで指定した場合：

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector以下のディレクトリ名を指します。

絶対パスで指定した場合：

記述されたディレクトリ名を指します。

なお，出力先として指定したディレクトリのアクセス権にHTTP Serverの実行アカウントの書き込み権限を設定する必要があります※1。アクセス権を設定していない場合，ログファイルが出力されません。

JkLogFilePrefixとJkTraceLogFilePrefixに同じ値を指定した場合は，このキーにJkTraceLogFileDirとは異なる値を指定する必要があります。同じ値が指定された場合，リダイレクタは動作しません。

Windowsの場合

logs

UNIXの場合

/opt/Cosminexus/CC/web/redirector/logs

JkLogFileNum

リダイレクタ用ログファイルの最大数を指定します。この値を超えると古いログファイルは上書きされます。次の範囲の整数値を指定してください。

Windowsの場合

1≦JkLogFileNum≦16

UNIXの場合

1≦JkLogFileNum≦64

5

JkLogFilePrefix

ログファイル名のプリフィックスです。実際のログファイル名は，指定値に<通番>.logが付加されたものとなります。

JkLogFileDirとJkTraceLogFileDirに同じ値を指定した場合は，このキーにJkTraceLogFilePrefixとは異なる値を指定する必要があります。同じ値が指定された場合，リダイレクタは動作しません。

hws_redirect

JkLogFileSize

リダイレクタ用ログファイルの一つ当たりのサイズ（バイト）を指定します。次の範囲の整数値を指定してください。

Windowsの場合

4096≦JkLogFileSize≦2147483647

UNIXの場合

4096≦JkLogFileSize≦16777216

4194304

JkLogLevel

リダイレクタ用ログファイルのメッセージログ，および保守用トレースログのログ出力レベルを指定します。指定するログレベルを一つだけ指定します。debug，info，error（デフォルト値），およびemergを指定できます。なお，emergは，Windowsの場合だけ指定できる値です。

これら以外の値を指定した場合は，errorが指定されたものとして動作します。

error

JkModulePriority

HTTP Serverへリダイレクタ以外の外部モジュールを登録する場合に，ほかの外部モジュールに対するリダイレクタの実行順位を指定します。

指定できる値を次に示します。

-10〜30の整数

REALLY_FIRST（整数値の-10に対応）

FIRST（整数値の0に対応）

MIDDLE（整数値の10に対応）

LAST（整数値の20に対応）

REALLY_LAST（整数値の30に対応）

実行順位は指定する値が小さい程高くなります。

FIRST

JkOptions

リクエストURLのURLデコードを行うかどうかを指定します。なお，このキーはUNIX用です。

ForwardURICompatUnparsed（デフォルト）：

リクエストURLのURLデコードを行いません。

ForwardURICompat：

リクエストURLのURLデコードを行います。

02-00ではURLデコードを行っていたため，URLデコードによって変換される文字列を含むURLを使用する場合，02-00と同様にURLデコードを行う必要があるときだけForwardURICompatを指定してください。

ForwardURICompatUnparsed

JkPrfId

PRFデーモン起動時にPRF識別子に指定した文字列を指定します。

PRF_ID

JkRequestRetryCount

リクエスト送信時のWebコンテナに対するコネクション確立，およびリクエスト送信のリトライ回数を，1〜16の整数（単位：回）で指定します。

リトライ回数には，初回のコネクション確立およびリクエスト送信処理も含まれます。

タイムアウトが発生した場合，リトライするケースは次のとおりです。

コネクション確立時にタイムアウトした場合

リクエストヘッダ送信時にタイムアウトした場合

上記処理以降の，リクエストボディの送信時にタイムアウトが発生した場合は，リトライは行いません。

リトライ回数に，範囲外の値や，整数値でない値などの異常値を設定した場合，デフォルト値が設定されます。

3

JkSendTimeout

リクエスト送信のタイムアウト値を0〜3600の整数（単位：秒）で指定します。

数値以外の文字列や範囲外の数値を指定した場合は，メッセージを出力し，デフォルト値を使用します。

タイムアウト値に0，またはTCPの持つデータ送信の再送タイマより長い時間を設定した場合，TCPの持つタイムアウト値になります。その場合，不正なタイムアウト値が指定されたことを示すメッセージは出力されません。

100

JkTraceLog

リダイレクタの保守用トレースログを出力するかどうかを指定します。出力する場合はOn（デフォルト値）を，出力しない場合はOffを指定します。

On

JkTraceLogFileDir

保守用トレースログファイルの出力先ディレクトリを指定します。Windowsの場合，相対パスまたは絶対パスで指定してください。UNIXの場合，絶対パスで指定してください。

相対パスで記述した場合：

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector以下のディレクトリ名を指します。

絶対パスで記述した場合：

記述されたディレクトリ名を指します。

JkLogFilePrefixとJkTraceLogFilePrefixに同じ値を指定した場合は，このキーにJkLogFileDirとは異なる値を指定する必要があります。同じ値が指定された場合，リダイレクタは動作しません。

Windowsの場合

logs

UNIXの場合

/opt/Cosminexus/CC/web/redirector/logs

JkTraceLogFileNum

保守用トレースログファイルの最大数を整数値で指定します。

Windowsの場合

1〜16

UNIXの場合

1〜64

この数を超えると古いログファイルは上書きされます。

4

JkTraceLogFilePrefix

保守用トレースログファイル名のプリフィックスを指定します。実際のログファイル名は，このキーの指定値に<通番>.logが付加されたものとなります。

JkLogFileDirとJkTraceLogFileDirに同じ値を指定した場合は，このキーにJkLogFilePrefixとは異なる値を指定する必要があります。同じ値が指定された場合，リダイレクタは動作しません。

hws_rd_trace

JkTraceLogFileSize

保守用トレースログファイルの一つ当たりのサイズを整数値（単位：バイト）で指定します。

Windowsの場合

4096〜2147483647

UNIXの場合

4096〜16777216

16777216

JkTranslateBackcompat

05-05以前のバージョンの互換用のキーです。

HTTP ServerへのリクエストがWebコンテナに転送させるURLパターンであった場合，リダイレクタよりあとに実行されるモジュールのtranslate_handler関数がHTTP Serverから呼び出されるようにするかどうかを指定します。

Onを指定した場合，リダイレクタの次に実行されるモジュールのtranslate_handler関数が呼び出されます。

Offを指定した場合，リダイレクタよりあとに実行されるモジュールのtranslate_handler関数は呼び出されません。

Off

JkWorkersFile

ワーカ定義ファイルのファイル名を指定します。Windowsの場合，相対パスまたは絶対パスで指定してください。UNIXの場合，絶対パスで指定してください。

相対パスで指定した場合：

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector以下のファイル名を指します。

絶対パスで指定した場合：

記述されたファイル名を指します。

Windowsの場合

workers.properties

UNIXの場合

/opt/Cosminexus/CC/web/redirector/workers.properties※2

注

複数のキーを指定した場合，最後に指定した値が有効になります。

注※1　HTTP Serverと連携する場合

新規インストール時には，デフォルトのログ出力先ディレクトリは存在しません。ディレクトリを作成してアクセス権を設定するか，一つ上のディレクトリredirectorにアクセス権を設定してください。

また，リダイレクタのログ出力先ディレクトリを変更し，そのパスが途中までしか存在しない場合，存在する最下層のディレクトリに対してアクセス権を設定するか，指定したパスをすべて作成し，アクセス権を設定してください。

注※2

/opt/Cosminexus/CC/web/redirector/workers.propertiesが存在しない場合，HTTP Serverは起動しません。

(5)　記述例

Windowsの場合

LoadModule jk_module "C:¥Program Files¥Hitachi¥Cosminexus¥CC¥web¥redirector¥mod_jk.dll"※

JkGatewayHost hostA
JkGatewayHttpsScheme On
JkGatewayPort 443

JkLogLevel error
JkLogFileSize 4194304
JkLogFileNum 5
JkLogFileDir logs
JkLogFilePrefix hws_redirect
JkPrfId prfid
JkTraceLog On
JkTraceLogFileSize 16777216
JkTraceLogFileNum 4
JkTraceLogFileDir logs
JkTraceLogFilePrefix hws_rd_trace
JkTranslateBackcompat Off
JkWorkersFile workers.properties

JkMount /examples/* worker1

注※

LoadModuleの指定は，ファイル上では1行で記述してください。

UNIXの場合

LoadModule jk_module /opt/Cosminexus/CC/web/redirector/mod_jk.so
JkWorkersFile /opt/Cosminexus/CC/web/redirector/workers.properties

JkLogLevel error
JkLogFileSize 4194304
JkLogFileNum 5
JkLogFileDir /opt/Cosminexus/CC/web/redirector/logs
JkLogFilePrefix hws_redirect

JkTraceLog On
JkTraceLogFileSize 16777216
JkTraceLogFileNum 4
JkTraceLogFileDir /opt/Cosminexus/CC/web/redirector/logs
JkTraceLogFilePrefix hws_rd_trace

JkMount /examples/* worker1

(6)　注意事項

Windowsの場合，リダイレクタのユーザ定義を変更するには，Webサーバを再起動する必要があります。変更した定義は，Webサーバを再起動したあとに反映されます。

UNIXの場合，リダイレクタのユーザ定義を変更して，変更内容を反映させるには，次の操作が必要です。

ファイルサイズまたはファイル面数を変更する場合

Webサーバを停止します。

ログファイルおよびHNTRLibが使用する管理ファイルを，移動または削除します。

＜HNTRLibが使用する管理ファイル＞

メッセージログファイルの場合：<JkLogFilePrefixの設定値>.mm

保守用トレースログファイルの場合：<JkTraceLogFilePrefixの設定値>.mm

Webサーバを起動します。

なお，HNTRLibが使用する管理ファイルのデフォルトの格納場所は次のとおりです。

<Application Serverのインストールディレクトリ>/CC/web/redirector/logs/mmap

ファイルサイズまたはファイル面数を変更しない場合

Webサーバを再起動します。

13.2.3　uriworkermap.properties（Microsoft IIS用マッピング定義ファイル）

(1)　形式

次のようにキーを指定します。

<キー名称> = <値>

指定方法

改行までが値になります。

#で始まる行はコメントとみなされます。

値が存在しない行を定義した場合，その行は無視されます。キー名称として定義されていないパラメタを定義しても無視されます。

「キー名称=値」として1023文字までが有効となります。超えた部分は切り捨てられます。

(2)　ファイルの格納先

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥uriworkermap.properties

(3)　機能

uriworkermap.propertiesは，Microsoft IISへのリクエストでどのURLパターンがWebコンテナに転送されるかを定義します。

(4)　指定できるキー

workers.propertiesのworker.listで指定されているワーカのどれかを記述します。URLパターンとワーカ名の組み合わせを複数記述できます。このファイルに不正な値を設定した場合，動作は保証されません。また，先頭がスラッシュ（/）から始まらないURLパターンを指定した場合，リダイレクタ起動時にエラーメッセージがログに出力され，指定した内容は無視されます。

拡張子の長さが0文字の拡張子指定のURLパターンを指定した場合（URLパターンの末尾が「/*.」の場合），メッセージKDJE41041-Wがログに出力され，指定した内容は無視されます。

<URLパターン> = <ワーカ名>

(5)　記述例

/examples/*=worker1

(6)　注意事項

リダイレクタのユーザ定義を変更した場合，Webサーバを再起動する必要があります。変更した定義は，Webサーバを再起動したあとに反映されます。

13.2.4　workers.properties（ワーカ定義ファイル）

(1)　形式

次のようにキーを指定します。

<キー名称> = <値>

指定方法

改行までが値になります。

#で始まる行はコメントとみなされます。

値が存在しない行を定義した場合，その行は無視されます。キー名称として定義されていないパラメタを定義しても無視されます。

「キー名称=値」として1023文字までが有効となります。超えた部分は切り捨てられます。

ワーカ名に使用できる文字は半角英数字，アンダースコア「_」，およびハイフン「-」です。これら以外の文字を指定した場合の動作は保証しません。

(2)　ファイルの格納先

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥workers.properties

UNIXの場合

/opt/Cosminexus/CC/web/redirector/workers.properties

(3)　機能

ワーカを定義し，ワーカごとにパラメタを設定して，リダイレクタの動作を定義します。

(4)　指定できるキー

ワーカ定義ファイルに指定できるキーと，ワーカごとの定義パラメタについて説明します。

(a)　ワーカ定義ファイルに指定できるキー

ワーカ，およびワーカごとの各パラメタを定義します。このキーに不正な値を設定した場合，動作は保証されません。

キー名称

内容

デフォルト値

worker.list

ワーカ名のリストを指定します。複数ある場合は，コンマ（,）で区切ります。一つ以上のワーカ名を必ず指定する必要があります。

mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル），またはuriworkermap.properties（Microsoft IIS用マッピング定義ファイル）で指定するワーカ名を指定します。

なし

worker.<ワーカ名>.<パラメタ>

ワーカごとの定義パラメタを指定します。worker.listに記述されたワーカごとに設定します。

定義パラメタについては，「13.2.4(4)(b)　ワーカごとの定義パラメタ」を参照してください。

なし

(b)　ワーカごとの定義パラメタ

定義できるパラメタ

内容

デフォルト値

関連情報

worker.<ワーカ名>.balanced_workers

負荷分散の対象となるワーカのリストを指定します。複数ある場合は，コンマ（,）で区切ります。

なし

worker.<ワーカ名>.cachesize

リダイレクタで再利用するワーカとのコネクション数を，1〜2147483647の整数で指定します。なお，このパラメタはWindows用です。

ワーカとのコネクションは，この設定値以内の場合はリダイレクタ内に保持し，該当ワーカへの通信に再利用され，接続先のJ2EEサーバが終了するまで解放しません。リクエストの多重度が設定値を超えた場合は，設定値を超えたリクエストだけをリクエスト単位にワーカとのコネクションの確立，解放を行います。

この値は次に示す式に従ってメモリを消費します。

（式）

メモリ消費量=（worker.<ワーカ名>.cachesizeの値）×10KB

64

worker.<ワーカ名>.default_worker

デフォルトワーカのワーカ名を指定します。POSTリクエスト転送先ワーカに指定したワーカと同じワーカを指定した場合，指定したワーカには，POSTデータサイズによる振り分け条件を満たすリクエスト，およびデフォルトワーカとして条件を満たすリクエストが転送されます。

なお，このパラメタにPOSTリクエスト転送先ワーカに指定していないワーカを指定し，そのワーカにworker.<ワーカ名>.post_dataが指定されている場合，worker.<ワーカ名>.post_data定義は無視されます。

ワーカ名の前後の空白文字（スペース，タブ，およびフォームフィード）は無視されます。

このパラメタの指定を省略した場合や空文字列を指定した場合など，転送条件を満たすワーカが存在しないリクエストに対してエラーが返されます。

なし

worker.<ワーカ名>.delegate_error_code

エラーページの委任機能を利用するエラーステータスコードを指定します※1。複数指定する場合はコンマ（,）で区切って指定します。

なし

worker.<ワーカ名>.host※2

ワーカのホスト名，またはIPアドレスを指定します。

なし

worker.<ワーカ名>.lbfactor

リクエストの負荷分散値を指定します。設定する値は0よりも大きくしてください。なお，値として小数値を指定することもできます。

1

worker.<ワーカ名>.port※2

ワーカのポート番号を，1〜65535の整数で指定します。

すでにほかのアプリケーションで使用，または確保されているポート番号は指定できません。

なし

worker.<ワーカ名>.post_data

<ワーカ名>に指定したワーカに転送するリクエストのContent-Lengthヘッダの値の上限値に1を加えた値を次のように指定します。

1〜2147483648の整数（単位：バイト）

1〜2097152の整数に「k」または「K」を付加した値（単位：キロバイト）

1〜2048の整数に「m」または「M」を付加した値（単位：メガバイト）

Content-Lengthヘッダの値が指定値未満のリクエストを，<ワーカ名>に指定したワーカに転送します。

worker.<ワーカ名>.post_size_workersパラメタに複数のワーカを設定している場合，リクエストのContent-Lengthヘッダの値が指定値未満，かつ指定値が最も小さいワーカにリクエストは転送されます。

worker.<POSTリクエスト振り分けワーカのワーカ名>.post_size_workersパラメタで指定した，ほかのワーカと同じ値は設定しないでください。

値の前後の空白文字（スペース，タブ，フォームフィード）は無視されます。

なし

worker.<ワーカ名>.post_size_workers

POSTリクエスト転送先ワーカのワーカ名のリストを指定します。複数指定する場合は，コンマ（,）で区切って指定します。ただし，同じワーカ名は指定できません。

ワーカ名の前後の空白文字（スペース，タブ，フォームフィード）は無視されます。

なし

worker.<ワーカ名>.receive_timeout

通信タイムアウト値を指定します。レスポンスデータを待つ時間を0〜3600の整数値（単位：秒）で指定します。0を指定した場合，レスポンスを受け取るまで待ち続け，通信タイムアウトにはしません。

3600

「5.6　通信タイムアウト（Webサーバ連携）」

worker.<ワーカ名>.type

ワーカのタイプを次に示すタイプから指定します。タイプごとの設定できるパラメタについては，「13.2.4(4)(c)　worker.<ワーカ名>.typeごとの定義パラメタ」を参照してください。なお，このパラメタはワーカごとに必ず指定する必要があります。

ajp13：

外部プロセスで動作しているWebコンテナへリクエストを転送するワーカです。

ajp12：

旧バージョンとの互換性を保つためのワーカです。ajp13が指定されたものとして動作します。

lb：

ラウンドロビンに基づく負荷分散機能を持つワーカです。

post_size_lb：

POSTリクエスト振り分けワーカです。HTTP Server使用時だけ指定できます。

なし

注※1

指定できるコードがコメント文で記載されています。必要に応じてコメントを外してください。

注※2

複数のワーカで同一のWebコンテナのホスト名およびポート番号を指定することもできます。

(c)　worker.<ワーカ名>.typeごとの定義パラメタ

定義できるパラメタ

ワーカのタイプ

ajp13

lb

post_size_lb

worker.<ワーカ名>.balanced_workers

×

○

×

worker.<ワーカ名>.cachesize※1

△

×

×

worker.<ワーカ名>.default_worker

×

×

△

worker.<ワーカ名>.delegate_error_code

△

×

×

worker.<ワーカ名>.host

○

×

×

worker.<ワーカ名>.lbfactor

△

×

×

worker.<ワーカ名>.port

○

×

×

worker.<ワーカ名>.post_data

×/○※2

×

×

worker.<ワーカ名>.post_size_workers

×

×

○

worker.<ワーカ名>.receive_timeout

△

×

×

（凡例）

○：必ず指定します。

△：任意に指定します。

×：指定できません。

注1

ajp12で指定できるパラメタは，ajp13と同じです。

注2

UNIXの場合，必ず指定する項目に値を指定しなかったとき，または指定した値が不正のとき，HTTP Serverは起動しません。

注※1

Windowsの場合だけ有効です。UNIXの場合，パラメタは無視されます。

注※2

POSTリクエスト転送先ワーカでは必須です。

(5)　記述例

worker.list=worker1
worker.worker1.port=8007
worker.worker1.host=localhost
worker.worker1.type=ajp13
#worker.worker1.cachesize=64
#worker.worker1.receive_timeout=3600
#worker.worker1.delegate_error_code=400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,422,423,424,500,501,502,503,504,505,507,510

#----------------------------------------------------------------
# Example setting for Loadbalancer.
#----------------------------------------------------------------
#worker.list=loadbalancer1
#
#worker.loadbalancer1.type=lb
#worker.loadbalancer1.balanced_workers=worker1,worker2
#
#worker.worker1.port=8007
#worker.worker1.host=host1
#worker.worker1.type=ajp13
#worker.worker1.cachesize=64
#worker.worker1.lbfactor=1
#worker.worker1.receive_timeout=3600
#worker.worker1.delegate_error_code=400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,422,423,424,500,501,502,503,504,505,507,510

#
#worker.worker2.port=8007
#worker.worker2.host=host2
#worker.worker2.type=ajp13
#worker.worker2.cachesize=64
#worker.worker2.lbfactor=1
#worker.worker2.receive_timeout=3600
#worker.worker2.delegate_error_code=400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,422,423,424,500,501,502,503,504,505,507,510
#----------------------------------------------------------------
# Example setting for post data size based worker.
#----------------------------------------------------------------
#worker.list=postsizelb1#worker.postsizelb1.type=post_size_lb
#worker.postsizelb1.post_size_workers=worker1,worker2
#worker.postsizelb1.default_worker=worker1
#
#worker.worker1.port=8007
#worker.worker1.host=host1
#worker.worker1.type=ajp13
#worker.worker1.post_data=100m
#worker.worker1.receive_timeout=3600
#worker.worker1.delegate_error_code=400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,422,423,424,500,501,502,503,504,505,507,510
#
#worker.worker2.port=8007
#worker.worker2.host=host2
#worker.worker2.type=ajp13
#worker.worker2.post_data=2048m
#worker.worker2.receive_timeout=3600
#worker.worker2.delegate_error_code=400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,422,423,424,500,501,502,503,504,505,507,510

(6)　注意事項

このファイルを編集してリダイレクタのユーザ定義を変更した場合，Webサーバを再起動する必要があります。変更した定義は，Webサーバを再起動したあとに反映されます。

14　性能解析トレース

性能解析トレースは，クライアントからのリクエストを処理するときにアプリケーションサーバの各機能が出力する性能解析情報（トレース情報），およびアプリケーションの処理が出力する性能解析情報（トレース情報）を収集する機能です。

この情報を基に，システムおよびアプリケーションの処理性能を解析できます。この章では，性能解析トレースを使用して，システムおよびアプリケーションの性能を解析する方法について説明します。ここでは，V9互換モードと推奨モードで差異がある項目について説明します。ここに記載がない場合は，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。なお，性能解析トレースによって性能解析情報が取得されるポイント（トレース取得ポイント）や，情報の取得範囲（PRFトレース取得レベル）については，「14.5　性能解析トレースのトレース取得ポイントとPRFトレース取得レベルの概要」から「14.13　CDIのトレース取得ポイント」を参照してください。

14.1　性能解析トレースの概要

性能解析トレースの格納場所は次のとおりです。

Windowsの場合

<環境変数PRFSPOOLの設定ディレクトリ>¥utt¥prf¥<PRF識別子>

UNIXの場合

$PRFSPOOL/utt/prf/<PRF識別子>

性能解析トレースの収集方法については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.　性能解析トレースを使用した性能解析」を参照してください。性能解析トレースには，セッショントレースも出力されている場合があります。

14.2　アプリケーションサーバの性能解析トレースの概要

トレースを出力するリダイレクタ，Webコンテナなどを，機能レイヤといいます。性能解析トレースでは，次の機能レイヤの入り口と出口でトレース情報を出力します。必要に応じて，各機能レイヤ内の処理のうち，性能に影響を与える処理ごとにも，トレース情報を出力します。アプリケーションの実行環境と該当する機能レイヤのうち，V9互換モードと推奨モードで差異がある項目を次の表に示します。

表14‒1　アプリケーションの実行環境と該当する機能レイヤ

機能レイヤ

アプリケーションの実行環境

J2EEアプリケーションの実行環境

バッチアプリケーションの実行環境

リダイレクタ

○

−

CJPAプロバイダ

○

−

（凡例）○：該当する　−：該当しない

参考

PRFトレースには，キー情報（ルートアプリケーション情報）が付与されます。J2EEアプリケーションの場合，リダイレクタまたはEJBクライアントで取得した情報になります。

J2EEアプリケーションのトランザクションがタイムアウトした場合やリダイレクタでのレスポンス受信時にタイムアウトが発生した場合，性能解析トレースに出力されるルートアプリケーション情報を使用して，タイムアウトしたトランザクションやリクエストを特定できます。

14.3　性能解析トレースファイルの出力情報（性能解析トレースの場合）

性能解析トレースでは，各機能レイヤのトレース情報を収集します。

各機能レイヤが出力する情報のうち，V9互換モードと推奨モードで差異がある項目を次の表に示します。

表14‒2　性能解析トレースファイルに出力する情報（性能解析トレースの場合）

トレース情報のヘッダ

説明

値の範囲

Thread

トレース情報を取得したプロセス内スレッドのスレッドID，およびスレッドのハッシュ値※1。

スレッドID：20けた以内の10進数が出力されます。

ハッシュ値：10けた以内の10進数が出力されます。

ProcessName

プロセス名。

32文字以内のプロセスを表す文字列※2が出力されます。

OPT※3

取得ポイントごとの付加情報。

514文字以内の16進数値文字列が出力されます。

注※1

CTMおよびリダイレクタで取得したトレース情報には，スレッドのハッシュ値は出力されない場合があります。

注※2

リダイレクタの場合，プロセス名称は次のように決定されます。

リダイレクタの場合

WebサーバとしてHTTP Serverを使用している場合は，"RD-{Webサーバ待ち受けポート番号}"がプロセス名称となります。Microsoft IISを使用している場合は，"Redirector"がプロセス名称となります。

注※3

機能レイヤによっては，「OPT」に入り口時刻が出力されるトレース取得ポイントがあります。入り口時刻とは，そのトレース取得ポイントのトレースに対応する入り口トレースが出力された時間を示します。例えば，リダイレクタのトレース取得ポイントの場合，WebサーバへのHTTPレスポンスボディ情報の送信完了時（0x8104）のトレース取得ポイントで出力される入り口時刻は，WebコンテナからのHTTPレスポンスボディ情報の送信開始時（0x8004）の時刻になります。

なお，入り口時刻は，「1970年1月1日00:00:00」からの通算時間が16バイトの値で出力されます。前半の8バイトの値は秒単位を，後半の8バイトの値はマイクロ秒単位を示します。ただし，リダイレクタの性能解析トレースの場合は，後半の8バイトはミリ秒単位を示します。

14.4　Webサーバのレスポンスタイムの解析

アプリケーションサーバの処理性能は，クライアントからデータベースなどのEISまでの一連の処理，およびその処理結果がクライアントに返却されるまでのリクエストの一連の処理で，リダイレクタやWebコンテナなどの機能レイヤから出力されるトレース情報を基に解析できます。

ここでは，Webサーバがクライアントからリクエストを受けてから返却するまでに掛かった時間を解析する方法を，例を使用して説明します。

リダイレクタに割り当てられたイベントID「0x8001」および「0x8101」をキーにして，Webサーバで収集した性能解析トレースファイルをフィルタリングします。フィルタリングに使用するイベントIDが示すトレース取得ポイントは次のとおりです。

表14‒3　フィルタリングに使用するイベントIDが示すトレース取得ポイント

イベントID

トレース取得ポイント

0x8001

Webコンテナへのリクエストヘッダ情報の送信

0x8101

Webコンテナからのレスポンス完了通知の受信

イベントID「0x8001」および「0x8101」をキーにして，性能解析トレースをフィルタリングした例を次に示します。

図14‒1　性能解析トレースファイルをフィルタリングした例

「0x8001」および「0x8101」のトレース取得時刻から，リクエストごとのレスポンスタイムを解析できます。図14-1の例では，クライアントアプリケーション情報の通信番号が「0x00000000000000c7」と「0x00000000000000cc」のリクエストのレスポンスタイムを比較すると，「0x00000000000000c7」のリクエストの方が処理に時間が掛かっていることがわかります。

14.4.1　タイムアウトが発生したリクエストの特定

ここでは，リダイレクタでのレスポンス受信時にタイムアウトが発生した場合に，性能解析トレースを利用してタイムアウトが発生したリクエストを特定する方法について説明します。

リダイレクタでのレスポンス受信時にタイムアウトが発生した場合，メッセージKDJE41019-Eが出力されます。このメッセージには，次の情報が出力されます。

リクエストのURI

Webサーバとの通信に使用するWebコンテナが動作するホストのIPアドレス

Webサーバとの通信に使用するWebコンテナのポート番号

Webサーバとの通信に使用するWebコンテナのファイルディスクリプタ

性能解析トレースのルートアプリケーション情報

メッセージに出力された性能解析トレースのルートアプリケーション情報を，性能解析トレースファイルに出力されたルートアプリケーション情報と突き合わせて確認することで，性能解析トレース中のどこでリクエストのタイムアウトが発生したかを確認できます。

タイムアウトが発生したリクエストは，該当するルートアプリケーション情報を出力しているリクエスト処理内の，次の表に示すイベントIDのトレース情報で確認できます。オペレーション名に出力されているURIで，該当するリクエストを特定してください。

表14‒4　タイムアウトしたリクエストを確認するために使用できる性能解析トレース

イベントID

説明

0x8000

リクエスト処理要求の取得後に出力された情報です。

オペレーション名として，リクエストのURIが出力されます。

0x8100

リダイレクタ処理の完了後に出力された情報です。

オペレーション名として，リクエストのURIが出力されます。

14.4.2　ルートアプリケーション情報を利用したログ調査

J2EEアプリケーションまたはバッチアプリケーション内で，アプリケーションサーバのAPIを使用すると，性能解析情報のルートアプリケーション情報の文字列表現を任意のタイミングでログファイルに出力できます。

ルートアプリケーション情報の文字列表現は，次の形式で出力されます（最大48文字）。

IPアドレス/プロセスID/通信番号
（例：10.209.15.130/1234/0x0000000000000001）

APIを使用してログファイルにルートアプリケーション情報を出力すると，ログファイルと性能解析トレースファイルを突き合わせた調査ができるようになります。

Webコンテナでは，新しいリクエストを受け付けた時点で，リクエスト単位で新しいルートアプリケーション情報が割り当てられます。新しいルートアプリケーション情報が割り当てられるトレースポイントを次に示します。

表14‒5　新しいルートアプリケーション情報が割り当てられるトレースポイント

条件

イベントID（処理内容）

処理内容

インプロセスHTTPサーバを使用している場合

0x8211

リクエスト取得時，リクエストヘッダ解析完了時

Webサーバと連携している場合※

0x8200

リクエスト取得時，リクエストヘッダ解析完了時

注※　Webサーバと連携している場合，リダイレクタで取得したルートアプリケーション情報が割り当てられます。リダイレクタまたはリダイレクタが使用するPRFトレース出力ライブラリのロードに失敗してルートアプリケーション情報が発行されなかった場合，Webコンテナで新しいルートアプリケーション情報が割り当てられます。

また，次のトレース取得ポイントでは，「IPアドレス/プロセスID/通信番号」が「0.0.0. 0/0/0x0000000000000000」と出力されることがあります。

0x8212

インプロセスHTTPサーバ使用時のWebクライアントからのデータ読み込み開始時

0x8312

インプロセスHTTPサーバ使用時のWebクライアントへのデータ書き込み開始時

「IPアドレス/プロセスID/通信番号」が「0.0.0. 0/0/0x0000000000000000」と出力されるのは，次の場合です。

HTTPリクエストヘッダを受信した場合

HTTPリクエストではない，不正なデータを受信した場合

リクエスト処理中に例外が発生した場合

なお，ルートアプリケーション情報の文字列表現での出力に使用するAPIは，com.hitachi.software.ejb.application.prfパッケージで提供されている，CprfTraceクラスのgetRootApInfoメソッドです。

J2EEアプリケーションまたはバッチアプリケーション開発時のルートアプリケーション情報の取得の実装については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「7.7.9　性能解析トレースファイルとスレッドダンプを対応づけた問題個所の調査」を参照してください。APIの詳細については，マニュアル「アプリケーションサーバ リファレンス API編」を参照してください。

14.5　性能解析トレースのトレース取得ポイントとPRFトレース取得レベルの概要

ここでは，トレース取得ポイントとPRFトレース取得レベルについて説明します。

14.5.1　トレース取得ポイント

トレース取得ポイントは大きく分けて，J2EEサーバの開始・終了時でのトレース取得と，各機能レイヤでの処理中のトレース取得およびアプリケーションのメソッドの開始・終了時でのトレース取得があります。

(1)　J2EEサーバの開始・終了時のトレース取得

J2EEサーバの開始処理の完了時，およびJ2EEサーバの終了処理の開始時に，トレース情報を取得できます。取得できるイベントIDと参照先を次に示します。

イベントID

0x8FFE〜0x8FFF

参照先

J2EEサーバの開始・終了時のトレース取得の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「8.24　J2EEサーバの開始・終了時のトレース取得ポイント」を参照してください。

(2)　各機能レイヤでのトレース取得

取得できるイベントIDと機能レイヤの対応を次の表に示します。

表14‒6　取得できるイベントIDと機能レイヤ

イベントID

機能レイヤ

図中の番号※

参照先

0x1101〜0x1102

0x1301〜0x1302

0x1401〜0x1406

0x2002〜0x2003

0x2101〜0x2104

0x3000〜0x3008

CTM

5

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.3

0x8000〜0x8004

0x8100〜0x8104

リダイレクタ

1

14.6

0x8200〜0x8203

0x8206〜0x8225

0x8300〜0x8303

0x8306〜0x8307

0x8311〜0x8325

0x8E01〜0x8E06

Webコンテナ

2

14.7，14.8，14.9，14.10

0x8401〜0x840A

0x8425〜0x8428

0x842D〜0x8434

0x8453〜0x8454

0x8460〜0x846D

0x8470〜0x8477

0x8490〜0x8491

0x84A0〜0x84D9

0x8C41

EJBコンテナ

6

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.9

0x8603〜0x861C

JNDI

4

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.10

0x8435〜0x843F

0x8811〜0x8820

0x8C41

JTA

7

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.11

0x8B00〜0x8B01

0x8B80〜0x8B89

0x8B8A〜0x8C03

0x8C10〜0x8C13

0x8C20〜0x8C41

0x8C60〜0x8C65

0x8C80〜0x8C93

0x8CC0〜0x8CD9

0x8D00〜0x8D19

0x8D42〜0x8D4D

0x8D60〜0x8D63

0x8D80〜0x8D89

0x8D8A〜0x8D8F

0x8D90〜0x8D99

DB Connector，JCAコンテナ

8

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.12

0x8E01〜0x8E06

RMI

3

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.13

0x9400〜0x9413

OTS

9

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.14

0x9C00〜0x9C03

標準出力／標準エラー出力／ユーザログ

−

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.15

0x9D00，0x9D01

DI

10

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.16

0xA100，0xA101

バッチアプリケーション実行機能

11

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.17

0xA500〜0xA5AF

JPA

12

14.11

0xA300〜0xA305

0xA310〜0xA315

0xA320〜0xA323

0xA330〜0xA331

0xA340〜0xA363

0xA370〜0xA381

0xA390〜0xA3C3

CJPAプロバイダ

13

14.12

0x842F

0x8430〜0x8432

0x8825

0x8826

0x8B86，0x8B87

0x8B8A〜0x8B93

0xAA00〜0xAA06

0xAA08〜0xAA0D

0xAA10〜0xAA19

TP1インバウンド連携機能

14

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.19

0xA600〜0xA60F

0xA610〜0xA619

0xA61E，0xA61F

0xA620〜0xA62F

0xA630〜0xA63F

0xA640〜0xA64F

0xA650〜0xA65F

0xA660〜0xA667

0xA61A，0xA61B

0xA668〜0xA66F

0xA670〜0xA67F

0xA686〜0xA68D

0xA692〜0xA69B

0xA69E，0xA69F

0xA6A0，0xA6A1

0xA6A6〜0xA6AB

CJMSプロバイダ

15

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.20

0xAD00〜0xAD15

0xAD80〜0xAD93

JavaMail

16

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.21

0xAF00〜0xAF13

JSF

17

マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の8.22

0xb002〜0xb009

CDI

18

14.13

（凡例）−：該当しない

注※　図14-2〜図14-5中の番号と対応しています。

PRFトレースを出力する機能レイヤとトレース取得ポイントについて，システムの構成ごとに次の図に示します。

図14‒2　機能レイヤとトレース取得ポイント（Webクライアント構成の場合）

図14‒3　機能レイヤとトレース取得ポイント（バッチアプリケーションを実行するシステムの場合）

図14‒4　機能レイヤとトレース取得ポイント（EJBクライアント/TPBrokerクライアント/TPBroker OTMクライアント構成（CTM使用）の場合）

図14‒5　機能レイヤとトレース取得ポイント（TP1インバウンド連携機能の場合）

トレース取得ポイントは，各機能レイヤ内でさらに詳細に分かれており，トレース取得ポイントによって，PRFトレース取得レベルが異なります。各機能レイヤの詳細なトレース取得ポイント，およびPRFトレース取得レベルについては，表14-6の参照先を参照してください。

参考

表14-6に示した機能レイヤのほか，Application Serverのプロセス，構成ソフトウェアおよび関連プログラムでも，PRFトレースが取得できるものがあります。

表14-6に示した以外でPRFトレースを取得できる機能レイヤとイベントIDの対応を，次の表に示します。

表14‒7　取得できるイベントIDと機能レイヤに示した以外でPRFトレースを取得できるイベントIDと機能レイヤの対応

イベントID

機能レイヤ

0x9000〜0x90FF

0xA400〜0xA4FF

SOAP通信基盤

0x9100〜0x91FF

TP1 Connector

TP1/Client/J

0x9200〜0x92FF

TP1/MQ Access

0x9300〜0x93FF

Reliable Messaging

0x9800〜0x9B6E

HCSCサーバ

0x9E00〜0x9EFF

Service Coordinator Interactive Workflow

0x9F00〜0x9FFF

HCSCサーバ（Object Accessアダプタ）

0xA000〜0xA0FF

HCSCサーバ（ファイルアダプタ）

0xA200〜0xA2FF

HCSCサーバ（Message Queueアダプタ）

0xAB00〜0xABFF

0xAC00〜0xACFF

HCSCサーバ（FTPアダプタ）

0xA400〜0xA4FF

JAX-WSエンジン

0xE000〜0xE0FF

Elastic Application Data store

(3)　アプリケーションのメソッドの開始・終了時トレース取得

アプリケーションのメソッドの開始時，および終了時にトレース情報を取得できます。取得できるトレース情報を次に示します。

メソッドの開始時刻，終了時刻

識別ID

パッケージ名，クラス名，メソッド名

メソッドで実行された最後の行の行番号

発生した例外またはエラーのクラス名

トレース情報の詳細については，マニュアル「アプリケーションサーバ 機能解説 保守／移行編」の「8.25　アプリケーションのトレース取得ポイント」を参照してください。

(4)　各トレースのリターンコード

各トレースのリターンコードは入口トレースの場合，常に「0」が出力されます。

出口トレースおよび呼び出し後トレースの場合，次のように出力されます。

正常終了：0

異常終了：0以外

14.5.2　PRFトレース取得レベル

性能解析トレースでは，次の4種類のPRFトレース取得レベルを設定してトレースを出力できます。レベルによって，トレース取得ポイントの数が異なります。トレース取得ポイント，およびPRFトレース取得レベルについては，表14-6の参照先を参照してください。

標準レベル

各機能レイヤの境界（入り口と出口）を識別できるトレース情報を出力します。

詳細レベル

標準レベルの出力内容に加えて，各機能レイヤ内処理のトレース情報も出力します。

保守レベル

障害発生時などの保守情報を取得するためのレベルです。

抑止レベル

トレース情報の出力を抑止するためのレベルです。RMIの機能レイヤにだけ設定できます。

Management Serverを利用して運用している場合は，簡易構築定義ファイルで，すべての機能レイヤに対して共通のレベルを設定して，トレース情報を出力します。

なお，次節以降は，トレース取得レベルが標準レベルと詳細レベルのトレース取得ポイントについて説明します。保守レベルは，障害発生時などの保守情報を取得するためのレベルのため，通常は収集する必要はありません。

14.6　リダイレクタのトレース取得ポイント

ここでは，リダイレクタのトレース取得ポイントと，取得できるトレース情報について説明します。

なお，PRFトレース取得レベルを「詳細」にしている場合，リクエスト処理のトレースとセッショントレースが出力されます。

14.6.1　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。なお，「0x8003」のポイントで，セッショントレースは出力されません。

表14‒8　リダイレクタでのトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0x8000

1

リクエスト処理要求の取得直後

A／B

0x8001

2

Webコンテナへのリクエストヘッダ情報の送信直後

A／B

0x8002

4

WebコンテナからのHTTPリクエストボディ情報の要求受信直後

B

0x8003

6

WebコンテナからのHTTPレスポンスヘッダ情報の受信直後

B

0x8004

8

WebコンテナからのHTTPレスポンスボディ情報の送信開始直後

B

0x8100

11

リダイレクタ処理完了直後

A／B

0x8101

10

Webコンテナからのレスポンス完了通知の受信直後

A／B

0x8102

3，5

WebコンテナへのHTTPリクエストボディ情報の送信直前

B

0x8103

7

HTTPレスポンスヘッダ情報の設定完了直後

B

0x8104

9

WebサーバへのHTTPレスポンスボディ情報の送信完了直後

B

（凡例）B：詳細　A／B：標準と詳細で異なる情報を取得

注※　図14-6中の番号と対応しています。

リダイレクタでのトレース取得ポイントを次の図に示します。

図14‒6　リダイレクタのトレース取得ポイント

コネクションは，通常，常設コネクションのために使い回されるため，リクエストのたびに切断されることはありません。コネクションは，通信で例外が発生した場合，または常設コネクションの上限数に達していた場合だけ切断されます。

次に示すポイントでは，トレース情報が出力される場合が制限されます。

3のポイント

ボディデータの形式がチャンク形式ではない場合にトレース情報が出力されます。ボディデータの形式がチャンク形式の場合，2と4のポイント間のWebサーバへのリクエストボディ要求およびWebコンテナへのリクエストボディ情報が送信されません。

4と5のポイント

Webコンテナからリクエストボディ情報の要求があった場合だけトレース情報が出力されます。また，4，5，8，9のポイントでは，リクエストボディ情報とレスポンスボディ情報が複数回クライアントに送信されることがあるため，トレース情報も複数回出力されることがあります。

また，次に示すポイントでは，無効なセッションIDを取得する場合や，セッションIDを取得しない場合があります。

1〜5のポイント

セッションIDを取得できます。ただし，リクエストヘッダのCookieまたはURLからセッションIDを取得するため，無効なセッションID（J2EEアプリケーションで破棄されたHttpSessionのIDまたは有効期限切れで破棄されたHttpSessionのID）を取得する場合があります。

また，有効なセッションIDを取得した場合も，J2EEアプリケーションでセッションが破棄されることがあります。

7〜11のポイント

セッションを生成した場合だけ，セッションIDを取得できます。

14.6.2　取得できるトレース情報

リダイレクタで取得できるトレース情報を次の表に示します。

表14‒9　リダイレクタで取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション※2

1

0x8000

A／B

クライアントのアドレス：HTTPメソッド

URI

※3

2

0x8001

A／B

コンテナのアドレス：ポート番号

−

※3

3，5

0x8102

B

送信サイズ

−

<入り口時刻><セッションID文字数:セッションID:取得方法>

4

0x8002

B

要求サイズ

−

<セッションID文字数:セッションID:取得方法>

6

0x8003

B

−

−

−

7

0x8103

B

−

−

※4

8

0x8004

B

送信サイズ

−

<セッションID文字数:セッションID:取得方法>

9

0x8104

B

送信できたサイズ

−

<入り口時刻><セッションID文字数:セッションID>

10

0x8101

A／B

コンテナのアドレス：ポート番号

−

※5

11

0x8100

A／B

クライアントのアドレス：HTTPメソッド

URI

※6

（凡例）B：詳細　A／B：標準と詳細で異なる情報を取得　−：該当なし

注※1　図14-6中の番号と対応しています。

注※2　セッションのCookieの名前を「JSESSIONID」以外の文字列に変更した場合，セッションID文字数，セッションID，および取得方法は出力されません。

注※3　レベルが「標準」の場合，何も出力されません。レベルが「詳細」の場合，セッションID文字数:セッションID:取得方法が出力されます。

注※4　正常に処理された場合，入り口時刻とセッションIDが表示されます。例外が発生した場合，入り口時刻に加え，4バイトの保守情報，およびセッションID文字数:セッションIDが表示されます。

注※5　レベルが「標準」の場合，入り口時刻が表示されます。レベルが「詳細」の場合，入り口時刻に加え，セッションID文字数:セッションIDが表示されます。

注※6　レベルが「標準」の場合，常に，入り口時刻とステータスコードが表示されます。ただし，Microsoft IIS使用時に例外が発生した場合は，入り口時刻とステータスコードに加え，4バイトの保守情報が表示されます。レベルが「詳細」の場合，レベルが「標準」の場合の情報に加え，セッションID文字数:セッションIDが表示されます。

14.7　Webコンテナのトレース取得ポイント（リクエスト処理のトレース）

ここでは，Webコンテナのトレース取得ポイントと，取得できるトレース情報について説明します。なお，Webコンテナでは，リクエスト処理のトレースとセッショントレースが出力されます。ここでは，リクエスト処理のトレースについて説明します。また，インプロセスHTTPサーバを使用したときのトレースポイントと取得できるトレース情報についても説明します。

14.7.1　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒10　Webコンテナでのトレース取得ポイントの詳細（リクエスト処理のトレース）

イベントID

図中の番号※1

トレース取得ポイント

レベル

0x8200※2

1

リクエスト取得・リクエストヘッダ解析完了直後

Webサーバ経由の場合

A

0x8201

簡易Webサーバ経由の場合

A

0x8202※3

3

サーブレット／JSPの呼び出し直前

A

0x8203

2

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの呼び出し直前

（web.xmlの<filter-mapping>タグの<dispatcher>タグを省略，または<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8206

4

RequestDispatcher経由のサーブレット／JSP呼び出し直前

B

0x8207

3

静的コンテンツの呼び出し

B

0x8300

8

リクエスト処理完了

Webサーバ経由の場合

A

0x8301

簡易Webサーバ経由の場合

A

0x8302

6

サーブレット／JSPの処理完了直後

A

0x8303

7

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの処理完了直後

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8306

5

RequestDispatcher経由のサーブレット／JSP処理完了直後

B

0x8307

6

静的コンテンツの処理完了直後（DefaultServlet）

B

（凡例）A：標準　B：詳細

注※1　図14-7中の番号と対応しています。

注※2　POSTリクエストの場合，クライアントからPOSTデータが来ないと，この区間で遅延することがあります。

注※3　JSPのコンパイルが必要な場合は，JSPのコンパイルを実行したあと，トレースを取得します。

Webコンテナでのトレース取得ポイントを次の図に示します。

図14‒7　Webコンテナのトレース取得ポイント（リクエスト処理のトレース）

14.7.2　取得できるトレース情報

Webコンテナで取得できるトレース情報を次の表に示します。

表14‒11　Webコンテナで取得できるトレース情報（リクエスト処理のトレース）

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8200

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

0x8201

A

HTTPメソッド

URI

−

2

0x8203

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

3

0x8202

A

クラス名またはJSPファイル名

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8207

B

−

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

4

0x8206

B

クラス名

ディスパッチのタイプ

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

5

0x8306

B

クラス名

ディスパッチのタイプ

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

6

0x8302

A

クラス名またはJSPファイル名

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻>＜例外名:セッションID文字数:セッションID>

0x8307

B

−

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

7

0x8303

B

クラス名

−

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

8

0x8300

A

HTTPメソッド

URI

正常時

<入り口時刻>ステータスコード

例外発生時

<入り口時刻><ステータスコード><例外名>

B

正常時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

例外発生時

<入り口時刻><ステータスコード><例外名:セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8301

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-7中の番号と対応しています。

参考

SOAPクライアント以外のリクエストを受信した場合，トレース情報のキー情報である「クライアントアプリケーション情報」には，常に0が表示されます。SOAPクライアントのリクエストを受信した場合だけ，「クライアントアプリケーション情報」が出力されます。

14.7.3　トレース取得ポイントとPRFトレース取得レベル（インプロセスHTTPサーバを使用した場合）

インプロセスHTTPサーバを使用した場合のイベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒12　インプロセスHTTPサーバでのトレース取得ポイントの詳細

イベントID

図中の番号※1

トレース取得ポイント

レベル

0x8202※2

5

サーブレット／JSP呼び出し直前

A／B

0x8203

4

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの呼び出し直前

（web.xmlの<filter-mapping>タグの<dispatcher>タグを省略，または<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8206

6

RequestDispatcher経由のサーブレット／JSP呼び出し直前

B

0x8207

5

静的コンテンツの呼び出し直前

B

0x8211

3

リクエスト取得時／リクエストヘッダ解析完了直後

A／B

0x8212

1

Webクライアントからのデータ読み込み開始直前

B

0x8213

8

Webクライアントへのデータ書き込み開始直前

B

0x8302

10

サーブレット／JSP処理完了直後

A

0x8303

11

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの処理完了直後

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8306

7

RequestDispatcher経由のサーブレット／JSP処理完了直後

B

0x8307

10

静的コンテンツの処理完了直後（DefaultServlet）

B

0x8311

12

リクエスト処理完了直後

A／B

0x8312

2

Webクライアントからのデータ読み込み完了直後

B

0x8313

9

Webクライアントへのデータ書き込み完了直後

B

（凡例）A：標準　B：詳細　A／B：標準と詳細で異なる情報を取得

注※1　図14-8中の番号と対応しています。

注※2　JSPのコンパイルが必要な場合は，JSPのコンパイルを実行したあと，トレースを取得します。

インプロセスHTTPサーバを使用した場合のトレース取得ポイントを次の図に示します。

図14‒8　インプロセスHTTPサーバのトレース取得ポイント

なお，1および2のポイントはリクエスト情報をクライアントから複数回受信することがあるため，トレース情報も複数回出力されることがあります。

8および9のポイントはレスポンス情報が複数回クライアントに送信されることがあるため，トレース情報も複数回出力されることがあります。

フィルタからリクエストボディ情報の要求や，レスポンスの送信を行った場合も，1および2または8および9のトレースは出力されます。

14.7.4　取得できるトレース情報

インプロセスHTTPサーバで取得できるトレース情報を次の表に示します。

表14‒13　インプロセスHTTPサーバで取得できるトレース情報（リクエスト処理のトレース）

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8212

B

要求サイズ

−

−

2

0x8312

B

読み込んだサイズ

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

3

0x8211

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

4

0x8203

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

5

0x8202

A

クラス名またはJSPファイル名

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8207

B

−

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

6

0x8206

B

クラス名

ディスパッチのタイプ

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

7

0x8306

B

クラス名

ディスパッチのタイプ

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

8

0x8213

B

書き込みサイズ

−

−

9

0x8313

B

書き込んだサイズ

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

10

0x8302

A

クラス名またはJSPファイル名

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8307

B

−

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

11

0x8303

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

12

0x8311

A

HTTPメソッド

URI

<入り口時刻><ステータスコード>

B

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-8中の番号と対応しています。

14.8　Webコンテナのトレース取得ポイント（セッショントレース）

ここでは，Webコンテナのトレースのトレース取得ポイントと，取得できるトレース情報について説明します。なお，Webコンテナでは，リクエスト処理のトレースとセッショントレースが出力されます。ここでは，セッショントレース，およびグローバルセッションについてのトレース取得ポイントと取得できるトレース情報について説明します。

14.8.1　トレース取得ポイントとPRFトレース取得レベル（セッショントレース）

セッショントレースに関連するトレースの，イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。なお，「0x8203」，「0x8202」，「0x8207」，「0x8206」および「0x8300」では，グローバルセッションについての情報も出力されます。

表14‒14　Webコンテナでのトレース取得ポイントの詳細（セッショントレース）

イベントID

図中の番号※1

トレース取得ポイント

レベル※2

0x8200

1

リクエスト取得・リクエストヘッダ解析完了直後（Webサーバ経由の場合）

A／B

0x8202

4，9

サーブレット／JSP呼び出し直前

A／B

0x8203

2，3

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの呼び出し直前

（web.xmlの<filter-mapping>タグの<dispatcher>タグを省略した場合，または<dispatcher>タグで"REQUEST"を指定したフィルタを呼び出した場合）

B

0x8206

7

RequestDispatcher経由のサーブレット／JSP呼び出し直前

B

0x8207

4，9

静的コンテンツ呼び出し直前（DefaultServlet）

B

0x8208

5

セッション生成後

B

0x8209

6

セッション破棄後

B

0x8210

17

セッションタイムアウト後

B

0x8211

1

リクエスト取得・リクエストヘッダ解析完了直後（インプロセスHTTPサーバ経由の場合）

A／B

0x8214

8

フォワード時に実行されるフィルタの呼び出し直前

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"FORWARD"を指定したフィルタを呼び出した場合）

B

0x8215

8

インクルード時に実行されるフィルタの呼び出し直前

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"INCLUDE"を指定したフィルタを呼び出した場合）

B

0x8216

2

エラーページに転送される際に実行されるフィルタの呼び出し直前

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"ERROR"を指定したフィルタを呼び出した場合）

B

0x8300

16

リクエスト処理完了直後（Webサーバ経由の場合）

A／B

0x8302

10，13

サーブレット／JSP処理完了直後

A／B

0x8303

14，15

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの処理完了直後

（web.xmlの<filter-mapping>タグの<dispatcher>タグで""REQUEST""を指定したフィルタの処理が完了した場合）

B

0x8306

12

RequestDispatcher経由のサーブレット／JSP処理完了直後

B

0x8307

10，13

静的コンテンツ処理完了直後（DefaultServlet）

B

0x8311

16

リクエスト処理完了直後（インプロセスHTTPサーバ経由の場合）

A／B

0x8314

11

フォワード時に実行されるフィルタの処理完了直後

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"FORWARD"を指定したフィルタの処理が完了した場合）

B

0x8315

11

インクルード時に実行されるフィルタの処理完了直後

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"INCLUDE"を指定したフィルタの処理が完了した場合）

B

0x8316

15

エラーページに転送される際に実行されるフィルタの処理完了直後

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"ERROR"を指定したフィルタの処理が完了した場合）

B

（凡例）A：標準　B：詳細　A／B：標準と詳細で異なる情報を取得

注※1　図14-9中の番号と対応しています。

注※2　セッショントレースについての情報はレベルが「詳細」の場合だけ出力されます。

Webコンテナでのセッショントレースのトレース取得ポイントを次の図に示します。

図14‒9　Webコンテナのトレース取得ポイント（セッショントレース）

それぞれのポイントで取得できるセッションIDについて説明します。

1のポイント

セッションIDを取得できます。ただし，リクエストヘッダのCookieまたはURLからセッションIDを取得するため，無効なセッションID（J2EEアプリケーションで破棄されたHttpSessionのIDまたは有効期限切れで破棄されたHttpSessionのID）を取得する場合があります。

また，有効なセッションIDを取得した場合も，J2EEアプリケーションでセッションが破棄される場合があります。

2，3，4，7，8，9のポイント

トレース取得ポイントで有効なセッションIDを取得できます。ただし，J2EEアプリケーションでセッションが破棄される場合があります。

また，これらのポイントでは，グローバルセッションIDも取得できます。取得できるグローバルセッションIDの内容は，トレース取得ポイントごとに異なります。

2のポイントは，一つのリクエストで最初にイベントID「0x8203」が出力されるトレース取得ポイントです。このトレース取得ポイントでは，Webクライアントからリクエストとして送信されたグローバルセッションIDが取得できます。ただし，このポイントでは，すでに無効になっているグローバルセッションIDが出力される場合もあります。

3，4，7，8，9のポイントで出力される，イベントIDが「0x8216」「0x8202」「0x8203」「0x8206」「0x8207」「0x8214」「0x8215」のトレースには，その時点で有効なグローバルセッションIDが取得できます。

5のポイント

J2EEアプリケーションでセッションが生成された場合だけ，トレース取得ポイントで有効なセッションIDを取得できます。ただし，J2EEアプリケーションでセッションが破棄される場合があります。

6のポイント

J2EEアプリケーションでセッションが破棄された場合だけ，トレース取得ポイントで無効になったセッションIDを取得できます。ただし，J2EEアプリケーションでセッションが破棄される場合があります。

10，11，12，13のポイント

トレース取得ポイントで有効なセッションIDを取得できます。ただし，J2EEアプリケーションでセッションが破棄される場合があります。

14，15のポイント

トレース取得ポイントで有効なセッションIDを取得できます。なお，このトレース取得ポイントでリクエスト処理が完了すると，以降のJ2EEアプリケーションでセッションが破棄されることはありません。

16のポイント

トレース取得ポイントで有効なセッションIDを取得できます。なお，このトレース取得ポイントでリクエスト処理が完了すると，以降のJ2EEアプリケーションでセッションが破棄されることはありません。

また，グローバルセッションを生成した場合，リクエスト処理が終了した時点で有効なグローバルセッションIDを取得できます。

17のポイント

有効期限を超えたセッションが破棄された場合だけ，無効になったセッションIDを取得できます。

14.8.2　取得できるトレース情報

セッショントレースについて，Webコンテナで取得できるトレース情報を次の表に示します。なお，イベントIDが「0x8202」，「0x8203」，「0x8206」，「0x8207」，「0x8214」，「0x8215」，「0x8300」および「0x8311」のトレース取得ポイントでは，グローバルセッションについての情報も出力されます。

表14‒15　Webコンテナで取得できるトレース情報（セッショントレース）

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8200

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

4，9

0x8202

A

クラス名（JSP呼び出し時はJSPファイル名）

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

2，3

0x8203

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

7

0x8206

B

クラス名

ディスパッチのタイプ

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

4，9

0x8207

B

−

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

5

0x8208

B

コンテキストルート名

セッション有効期間

<セッションID文字数:セッションID>

6

0x8209

B

コンテキストルート名

セッション生成時刻

<セッションID文字数:セッションID>

17

0x8210

B

コンテキストルート名

セッション有効期間:セッション生成時刻

<セッションID文字数:セッションID>

1

0x8211

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

8

0x8214

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

8

0x8215

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

2

0x8216

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

16

0x8300

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><例外名>

B

正常時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

例外発生時

<入り口時刻><ステータスコード><例外名:セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

10，13

0x8302

A

クラス名（JSP呼び出し時はJSPファイル名）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻>＜例外名:セッションID文字数:セッションID>

14，15

0x8303

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻>＜例外名:セッションID文字数:セッションID>

12

0x8306

B

クラス名

ディスパッチのタイプ

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻>＜例外名:セッションID文字数:セッションID>

10，13

0x8307

B

−

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻>＜例外名:セッションID文字数:セッションID>

16

0x8311

A

HTTPメソッド

URI

<入り口時刻><ステータスコード>

B

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

11

0x8314

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

11

0x8315

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

15

0x8316

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-9中の番号と対応しています。

14.9　Webコンテナのトレース取得ポイント（フィルタのトレース）

ここでは，フォワード時，またはインクルード時に呼び出されるフィルタを設定した場合のWebコンテナのトレースのトレース取得ポイントと，取得できるトレース情報について説明します。

なお，フォワード時，またはインクルード時に呼び出されるフィルタを設定した場合のWebコンテナでは，正常に処理が終了した場合と障害が発生した場合で取得できるトレース情報が異なります。ここでは，それぞれの場合について説明します。

なお，JSPのpageディレクティブでerrorPage属性を使用しエラーページを設定して，JSPで例外が発生した場合，リクエストのforwardでエラーページが表示されます。したがって，JSPでエラーページを表示する場合も，forward時のトレースが出力されます。

14.9.1　正常に処理が終了した場合のWebコンテナのトレース取得ポイント（フィルタのトレース）

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒16　正常終了時のWebコンテナでのトレース取得ポイントの詳細（フィルタのトレース）

イベントID

図中の番号※

トレース取得ポイント

レベル

0x8200

1

リクエスト取得・リクエストヘッダ解析完了直後（Webサーバ経由）

A／B

0x8201

1

リクエスト取得時・リクエストヘッダ解析完了直後（簡易Webサーバ経由）

A

0x8202

3

サーブレット／JSPの呼び出し直前

A／B

0x8202

6

サーブレット／JSPの呼び出し直前

A／B

0x8203

2

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの呼び出し直前（web.xmlの<filter-mapping>タグの<dispatcher>タグを省略，または<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8206

4

RequestDispatcher経由のサーブレット／JSP呼び出し直前

B

0x8207

6

静的コンテンツ呼び出し直前（DefaultServlet）

B

0x8211

1

リクエスト取得時・リクエストヘッダ解析完了直後（インプロセスHTTPサーバ経由）

A／B

0x8214

5

フォワード時に実行されるフィルタの呼び出し直前（web.xmlの<filter-mapping>タグの<dispatcher>タグで"FORWARD"を指定したフィルタ）

B

0x8215

5

インクルード時に実行されるフィルタの呼び出し直前

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"INCLUDE"を指定したフィルタ）

B

0x8300

12

リクエスト処理完了直後（Webサーバ経由）

A／B

0x8301

12

リクエスト処理完了直後（簡易Webサーバ経由）

A

0x8302

7

サーブレット／JSPの処理完了直後

A／B

0x8302

10

サーブレット／JSPの処理完了直後

A／B

0x8303

11

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8306

9

RequestDispatcher経由のサーブレット／JSP処理完了直後

B

0x8307

7

静的コンテンツ処理完了直後(DefaultServlet)

B

0x8311

12

リクエスト処理完了直後（インプロセスHTTPサーバ経由）

A／B

0x8314

8

フォワード時に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"FORWARD"を指定したフィルタ）

B

0x8315

8

インクルード時に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"INCLUDE"を指定したフィルタ）

B

（凡例）A：標準　B：詳細　A／B：標準と詳細で異なる情報を取得

注※　図14-10中の番号と対応しています。

フォワード時，またはインクルード時に呼び出されるフィルタを設定した場合のWebコンテナでのトレース取得ポイントを次の図に示します。

図14‒10　正常終了時のWebコンテナでのトレース取得ポイント（フィルタのトレース）

(2)　取得できるトレース情報

フォワード時，またはインクルード時に呼び出されるフィルタを設定した場合のWebコンテナで取得できるトレース情報を次の表に示します。

表14‒17　正常終了時のWebコンテナで取得できるトレース情報（フィルタのトレース）

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8200

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

0x8201

A

HTTPメソッド

URI

−

0x8211

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

2

0x8203

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

3

0x8202

A

クラス名（JSP呼び出しの場合はJSPファイル名）

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

4

0x8206

B

クラス名

ディスパッチのタイプコンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

5

0x8214

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8215

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

6

0x8202

A

クラス名（JSP呼び出しの場合はJSPファイル名）

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8207

B

−

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

7

0x8302

A

クラス名（JSP呼び出しの場合はJSPファイル名）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8307

B

−

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

8

0x8314

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8315

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

9

0x8306

B

クラス名

ディスパッチのタイプコンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

10

0x8302

A

クラス名（JSP呼び出しの場合はJSPファイル名）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

11

0x8303

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

12

0x8300

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><例外名>

B

正常時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

例外発生時

<入り口時刻><ステータスコード><例外名:セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8301

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><例外名>

0x8311

A

HTTPメソッド

URI

<入り口時刻><ステータスコード>

B

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-10中の番号と対応しています。

14.9.2　例外が発生した場合のWebコンテナのトレース取得ポイント（フィルタのトレース）

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒18　例外が発生した場合のWebコンテナでのトレース取得ポイントの詳細（フィルタのトレース）

イベントID

図中の番号※

トレース取得ポイント

レベル

0x8200

1

リクエスト取得・リクエストヘッダ解析完了直後（Webサーバ経由）

A／B

0x8201

1

リクエスト取得時・リクエストヘッダ解析完了直後（簡易Webサーバ経由）

A

0x8202

3

サーブレット／JSPの呼び出し直前

A／B

0x8202

8

サーブレット／JSPの呼び出し直前

A／B

0x8203

2

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの呼び出し直前（web.xmlの<filter-mapping>タグの<dispatcher>タグを省略，または<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8206

6

RequestDispatcher経由のサーブレット／JSP呼び出し直前

B

0x8207

8

静的コンテンツ呼び出し直前（DefaultServlet）

B

0x8211

1

リクエスト取得時・リクエストヘッダ解析完了直後（インプロセスHTTPサーバ経由）

A／B

0x8216

7

エラーページに転送される際に実行されるフィルタの呼び出し直前（web.xmlの<filter-mapping>タグの<dispatcher>タグで"ERROR"を指定したフィルタ）

B

0x8300

12

リクエスト処理完了直後（Webサーバ経由）

A／B

0x8301

12

リクエスト処理完了直後（簡易Webサーバ経由）

A

0x8302

4，9

サーブレット／JSPの処理完了直後

A／B

0x8303

5

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8306

11

RequestDispatcher経由のサーブレット／JSP処理完了直後

B

0x8307

9

静的コンテンツ処理完了直後(DefaultServlet)

B

0x8311

12

リクエスト処理完了直後（インプロセスHTTPサーバ経由）

A／B

0x8316

10

エラーページに転送される際に実行されるフィルタの処理完了直後

（web.xmlの<filter-mapping>タグの<dispatcher>タグで"ERROR"を指定したフィルタ）

B

（凡例）A：標準　B：詳細　A／B：標準と詳細で異なる情報を取得

注※　図14-11中の番号と対応しています。

例外が発生した場合のWebコンテナでのトレース取得ポイントを次の図に示します。

図14‒11　例外が発生した場合のWebコンテナでのトレース取得ポイント

(2)　取得できるトレース情報

フォワード時，またはインクルード時に呼び出されるフィルタを設定した場合のWebコンテナで取得できるトレース情報を次の表に示します。

表14‒19　例外が発生した場合のWebコンテナで取得できるトレース情報（フィルタのトレース）

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8200

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

0x8201

A

HTTPメソッド

URI

−

0x8211

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

2

0x8203

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

3

0x8202

A

クラス名（JSP呼び出しの場合はJSPファイル名）

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

4

0x8302

A

クラス名（JSP呼び出しの場合はJSPファイル名）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

5

0x8303

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

6

0x8206

B

クラス名

ディスパッチのタイプコンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

7

0x8216

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

8

0x8202

A

クラス名（JSP呼び出しの場合はJSPファイル名）

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8207

B

−

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

9

0x8302

A

クラス名（JSP呼び出しの場合はJSPファイル名）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8307

B

−

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻>＜例外名:セッションID文字数:セッションID>

10

0x8316

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

11

0x8306

B

クラス名

ディスパッチのタイプ

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

12

0x8300

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><例外名>

B

正常時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

例外発生時

<入り口時刻><ステータスコード><例外名:セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8301

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8311

A

HTTPメソッド

URI

<入り口時刻><ステータスコード>

B

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-11中の番号と対応しています。

14.10　Webコンテナのトレース取得ポイント（データベースセッションフェイルオーバ機能のトレース）

ここでは，データベースセッションフェイルオーバ機能を使用した場合のトレース取得ポイントと，取得できるトレース情報について説明します。

14.10.1　HTTPセッションを作成するリクエスト処理のトレース取得ポイントと取得できるトレース情報（データベースセッションフェイルオーバ機能のトレース）

HTTPセッションを作成するリクエスト処理のトレース取得ポイントと取得できるトレース情報について説明します。

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒20　HTTPセッションを作成するリクエスト処理のトレース取得ポイントの詳細（データベースセッションフェイルオーバ機能）

イベントID

図中の番号※

トレース取得ポイント

レベル

0x8200

1

リクエスト取得・リクエストヘッダ解析完了直後（Webサーバ経由）

A／B

0x8202

2

サーブレット／JSP呼び出し直前

A／B

0x8203

2

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの呼び出し直前（web.xmlの<filter-mapping>タグの<dispatcher>タグを省略，または<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8207

2

静的コンテンツ呼び出し直前（DefaultServlet）

B

0x8211

1

リクエスト取得・リクエストヘッダ解析完了直後（インプロセスHTTPサーバ経由）

A／B

0x8219

6

データベースセッションフェイルオーバ機能によるHTTPセッションの属性情報のシリアライズ開始直前

A

0x8222

8

データベースセッションフェイルオーバ機能によるWebアプリケーション処理後のデータベースアクセス開始直前

A

0x8223

3

データベースセッションフェイルオーバ機能によるHTTPセッション作成時のデータベースアクセス開始直前

A

0x8300

10

リクエスト処理完了直後（Webサーバ経由）

A／B

0x8302

5

サーブレット／JSP処理完了直後

A／B

0x8303

5

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8307

5

静的コンテンツ処理完了直後（DefaultServlet）

B

0x8311

10

リクエスト処理完了直後（インプロセスHTTPサーバ経由）

A／B

0x8316

5

エラーページに転送される際に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"ERROR"を指定したフィルタ）

B

0x8319

7

データベースセッションフェイルオーバ機能によるHTTPセッションの属性情報のシリアライズ終了直後

A

0x8322

9

データベースセッションフェイルオーバ機能によるWebアプリケーション処理後のデータベースアクセス終了直後

A

0x8323

4

データベースセッションフェイルオーバ機能によるHTTPセッション作成時のデータベースアクセス終了直後

A

（凡例）A：標準　B：詳細　A／B：標準と詳細で異なる情報を取得

注※　図14-12中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒12　HTTPセッションを作成するリクエスト処理のトレース取得ポイント（データベースセッションフェイルオーバ機能）

(2)　取得できるトレース情報

HTTPセッションを作成するリクエスト処理で取得できるトレース情報を次の表に示します。

表14‒21　HTTPセッションを作成するリクエスト処理で取得できるトレース情報（データベースセッションフェイルオーバ機能）

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8200

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

0x8211

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

2

0x8202

A

クラス名

（JSP呼び出し時はJSPファイル名）

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8207

B

−

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8203

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

3

0x8223

A

−

−

−

4

0x8323

A

完全性保障モードが有効な場合

排他を取得したレコード番号

完全性保障モードが無効な場合

-1

−

正常時

<入り口時刻><セッションID文字数:作成したHTTPセッションのセッションID>

例外発生時

<入り口時刻><例外名>

5

0x8302

A

クラス名

（JSP呼び出し時はJSPファイル名）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8307

B

−

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8303

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8316

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

6

0x8219

A

リクエストURL

−

<セッションID文字数:セッションID>

7

0x8319

A

リクエストURL

シリアライズ後のHTTPセッションの属性情報のサイズ（バイト）

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

8

0x8222

A

−

−

<セッションIDの文字数:HTTPセッションのセッションID>

9

0x8322

A

完全性保障モードが有効な場合

排他を解放したレコード番号

完全性保障モードが無効な場合

-1

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

10

0x8300

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><例外名>

B

正常時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

例外発生時

<入り口時刻><ステータスコード><例外名:セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8311

A

HTTPメソッド

URI

<入り口時刻><ステータスコード>

B

＜入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID＞

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-12中の番号と対応しています。

14.10.2　HTTPセッションを更新するリクエスト処理のトレース取得ポイントと取得できるトレース情報（データベースセッションフェイルオーバ機能のトレース）

HTTPセッションを更新するリクエスト処理のトレース取得ポイントと取得できるトレース情報について説明します。

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒22　HTTPセッションを更新するリクエスト処理のトレース取得ポイントの詳細（データベースセッションフェイルオーバ機能）

イベントID

図中の番号※1

トレース取得ポイント

レベル

0x8200

1

リクエスト取得・リクエストヘッダ解析完了直後（Webサーバ経由）

A／B

0x8202

6

サーブレット／JSP呼び出し直前

A／B

0x8203

6

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの呼び出し直前（web.xmlの<filter-mapping>タグの<dispatcher>タグを省略，または<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8207

6

静的コンテンツ呼び出し直前（DefaultServlet）

B

0x8211

1

リクエスト取得・リクエストヘッダ解析完了直後（インプロセスHTTPサーバ経由）

A／B

0x8219※2

8

データベースセッションフェイルオーバ機能によるHTTPセッションの属性情報のシリアライズ開始直前

A

0x8220

4

データベースセッションフェイルオーバ機能によるHTTPセッションの属性情報のデシリアライズ開始直前

A

0x8221

2

データベースセッションフェイルオーバ機能によるWebアプリケーション処理前のデータベースアクセス開始直前

A

0x8222※2

10

データベースセッションフェイルオーバ機能によるWebアプリケーション処理後のデータベースアクセス開始直前

A

0x8300

12

リクエスト処理完了直後（Webサーバ経由）

A／B

0x8302

7

サーブレット／JSP処理完了直後

A／B

0x8303

7

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8307

7

静的コンテンツ処理完了直後（DefaultServlet）

B

0x8311

12

リクエスト処理完了直後（インプロセスHTTPサーバ経由）

A／B

0x8316

7

エラーページに転送される時に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"ERROR"を指定したフィルタ）

B

0x8319※2

9

データベースセッションフェイルオーバ機能によるHTTPセッションの属性情報のシリアライズ終了直後

A

0x8320

5

データベースセッションフェイルオーバ機能によるHTTPセッションの属性情報のデシリアライズ終了直後

A

0x8321

3

データベースセッションフェイルオーバ機能によるWebアプリケーション処理前のデータベースアクセス終了直後

A

0x8322※2

11

データベースセッションフェイルオーバ機能によるWebアプリケーション処理後のデータベースアクセス終了直後

A

（凡例）A：標準　B：詳細　A／B：標準と詳細で異なる情報を取得

注※1　図14-13中の番号と対応しています。

注※2　HTTPセッションの参照専用リクエストの場合，出力されません。

トレース取得ポイントを次の図に示します。

図14‒13　HTTPセッションを更新するリクエスト処理のトレース取得ポイント（データベースセッションフェイルオーバ機能）

(2)　取得できるトレース情報

HTTPセッションを更新するリクエスト処理で取得できるトレース情報を次の表に示します。

表14‒23　HTTPセッションを更新するリクエスト処理で取得できるトレース情報（データベースセッションフェイルオーバ機能）

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8200

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

0x8211

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

2

0x8221

A

−

−

<セッションIDの文字数:リクエストで受信したセッションID>

3

0x8321

A

完全性保障モードが有効な場合

排他を取得したレコード番号

完全性保障モードが無効な場合

-1

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

4

0x8220

A

リクエストURL

デシリアライズ前のHTTPセッションの属性情報のサイズ（バイト）

<セッションID文字数:セッションID>

5

0x8320

A

リクエストURL

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

6

0x8202

A

クラス名

（JSP呼び出し時はJSPファイル名）

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8207

B

−

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8203

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

7

0x8302

A

クラス名

（JSP呼び出し時はJSPファイル名）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8307

B

−

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8303

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8316

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

8

0x8219

A

リクエストURL

−

<セッションID文字数:セッションID>

9

0x8319

A

リクエストURL

シリアライズ後のHTTPセッションの属性情報のサイズ（バイト）

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

10

0x8222

A

−

−

<セッションIDの文字数:HTTPセッションのセッションID>

11

0x8322

A

完全性保障モードが有効な場合

排他を解放したレコード番号

完全性保障モードが無効な場合

-1

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

12

0x8300

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><例外名>

B

正常時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

例外発生時

<入り口時刻><ステータスコード><例外名:セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8311

A

HTTPメソッド

URI

<入り口時刻><ステータスコード>

B

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-13中の番号と対応しています。

14.10.3　HTTPセッションを無効化するリクエスト処理のトレース取得ポイントと取得できるトレース情報（データベースセッションフェイルオーバ機能のトレース）

HTTPセッションを無効化するリクエスト処理のトレース取得ポイントと取得できるトレース情報について説明します。

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒24　HTTPセッションを無効化するリクエスト処理のトレース取得ポイントの詳細（データベースセッションフェイルオーバ機能）

イベントID

図中の番号※

トレース取得ポイント

レベル

0x8200

1

リクエスト取得・リクエストヘッダ解析完了直後（Webサーバ経由）

A／B

0x8202

6

サーブレット／JSP呼び出し直前

A／B

0x8203

6

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの呼び出し直前（web.xmlの<filter-mapping>タグの<dispatcher>タグを省略，または<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8207

6

静的コンテンツ呼び出し直前（DefaultServlet）

B

0x8211

1

リクエスト取得・リクエストヘッダ解析完了直後（インプロセスHTTPサーバ経由）

A／B

0x8220

4

データベースセッションフェイルオーバ機能によるHTTPセッションの属性情報のデシリアライズ開始直前

A

0x8221

2

データベースセッションフェイルオーバ機能によるWebアプリケーション処理前のデータベースアクセス開始直前

A

0x8224

7

データベースセッションフェイルオーバ機能によるHTTPセッション無効化時のデータベースアクセス開始直前

A

0x8300

10

リクエスト処理完了直後（Webサーバ経由）

A／B

0x8302

9

サーブレット／JSP処理完了直後

A／B

0x8303

9

リクエストを受信したサーブレット／JSPの実行前に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"REQUEST"を指定したフィルタ）

B

0x8307

9

静的コンテンツ処理完了直後（DefaultServlet）

B

0x8311

10

リクエスト処理完了直後（インプロセスHTTPサーバ経由）

A／B

0x8316

9

エラーページに転送される際に実行されるフィルタの処理完了直後（web.xmlの<filter-mapping>タグの<dispatcher>タグで"ERROR"を指定したフィルタ）

B

0x8320

5

データベースセッションフェイルオーバ機能によるHTTPセッションの属性情報のデシリアライズ終了直後

A

0x8321

3

データベースセッションフェイルオーバ機能によるWebアプリケーション処理前のデータベースアクセス終了直後

A

0x8324

8

データベースセッションフェイルオーバ機能によるHTTPセッション無効化時のデータベースアクセス終了直後

A

（凡例）A：標準　B：詳細　A／B：標準と詳細で異なる情報を取得

注※　図14-14中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒14　HTTPセッションを無効化するリクエスト処理のトレース取得ポイント（データベースセッションフェイルオーバ機能）

(2)　取得できるトレース情報

HTTPセッションを無効化するリクエスト処理で取得できるトレース情報を次の表に示します。

表14‒25　HTTPセッションを無効化するリクエスト処理で取得できるトレース情報（データベースセッションフェイルオーバ機能）

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8200

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

0x8211

A

HTTPメソッド

URI

−

B

<セッションID文字数:セッションID:取得方法>

2

0x8221

A

−

−

<セッションIDの文字数:リクエストで受信したセッションID>

3

0x8321

A

完全性保障モードが有効な場合

排他を取得したレコード番号

完全性保障モードが無効な場合

-1

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

4

0x8220

A

リクエストURL

デシリアライズ前のHTTPセッションの属性情報のサイズ（バイト）

<セッションID文字数:セッションID>

5

0x8320

A

リクエストURL

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

6

0x8202

A

クラス名

（JSP呼び出し時はJSPファイル名）

−

−

B

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8207

B

−

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8203

B

クラス名

コンテキストルート名

<セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

7

0x8224

A

−

−

<セッションIDの文字数:無効化したHTTPセッションのセッションID>

8

0x8324

A

完全性保障モードが有効な場合

排他を解放したレコード番号

完全性保障モードが無効な場合

-1

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

9

0x8302

A

クラス名

（JSP呼び出し時はJSPファイル名）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

B

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻>＜例外名:セッションID文字数:セッションID>

0x8307

B

−

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8303

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

0x8316

B

クラス名

コンテキストルート名

正常時

<入り口時刻><セッションID文字数:セッションID>

例外発生時

<入り口時刻><例外名:セッションID文字数:セッションID>

10

0x8300

A

HTTPメソッド

URI

正常時

<入り口時刻><ステータスコード>

例外発生時

<入り口時刻><ステータスコード><例外名>

B

正常時

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

例外発生時

<入り口時刻><ステータスコード><例外名:セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

0x8311

A

HTTPメソッド

URI

<入り口時刻><ステータスコード>

B

<入り口時刻><ステータスコード><セッションID文字数:セッションID:グローバルセッションID文字数:グローバルセッションID>

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-14中の番号と対応しています。

14.10.4　有効期限監視でHTTPセッションを無効化するリクエスト処理のトレース取得ポイントと取得できるトレース情報（データベースセッションフェイルオーバ機能のトレース）

有効期限監視でHTTPセッションを無効化するリクエスト処理のトレース取得ポイントと取得できるトレース情報について説明します。

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒26　有効期限監視でHTTPセッションを無効化するリクエスト処理のトレース取得ポイントの詳細（データベースセッションフェイルオーバ機能）

イベントID

図中の番号※

トレース取得ポイント

レベル

0x8210

3

セッションタイムアウト後

B

0x8225

1

データベース上のグローバルセッション情報の有効期限監視処理開始直前

A

0x8325

2

データベース上のグローバルセッション情報の有効期限監視処理終了直後

A

（凡例）A：標準　B：詳細

注※　図14-15中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒15　有効期限監視でHTTPセッションを無効化するリクエスト処理のトレース取得ポイント（データベースセッションフェイルオーバ機能）

(2)　取得できるトレース情報

有効期限監視でHTTPセッションを無効化するリクエスト処理で取得できるトレース情報を次の表に示します。

表14‒27　有効期限監視でHTTPセッションを無効化するリクエスト処理で取得できるトレース情報（データベースセッションフェイルオーバ機能）

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0x8225※2

A

−

−

−

2

0x8325※2

A

グローバルセッション情報の有効期限チェックを実施した場合

無効化したグローバルセッションの個数

グローバルセッション情報の有効期限チェックを実施しなかった場合

現在，有効期限チェックを担当しているJ2EEサーバのJ2EEサーバ名（IPアドレス）

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

3

0x8210

B

コンテキストルート名

セッション有効期間：セッション生成時刻

<セッションID文字数:セッションID>

（凡例）A：標準　B：詳細　−：該当なし

注※1　図14-15中の番号と対応しています。

注※2　完全性保障モードが無効な場合は，出力されません。

14.11　JPAでのトレース取得ポイント

ここでは，JPAのトレース取得ポイントと，取得できるトレース情報について説明します。

14.11.1　アプリケーション管理の永続化コンテキストを利用した場合のトレース取得ポイントと取得できるトレース情報

アプリケーション管理の永続化コンテキストを利用した場合のトレース取得ポイントと取得できるトレース情報について説明します。

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒28　アプリケーション管理の永続化コンテキストを利用した場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA500

1

EntityManagerFactory#createEntityManagerFactory()の処理開始

A

0xA501

2

EntityManagerFactory#createEntityManagerFactory()の処理終了

A

0xA502

1

EntityManagerFactory#createEntityManagerFactory(Map map)の処理開始

A

0xA503

2

EntityManagerFactory#createEntityManagerFactory(Map map)の処理終了

A

0xA504

1

EntityManagerFactory#isOpen()の処理開始

A

0xA505

2

EntityManagerFactory#isOpen()の処理終了

A

0xA506

1

EntityManagerFactory#close()の処理開始

A

0xA507

2

EntityManagerFactory#close()の処理終了

A

0xA508

1

EntityManager#find(Class<T> entityClass, Object primaryKey)の処理開始

A

0xA509

2

EntityManager#find(Class<T> entityClass, Object primaryKey)の処理終了

A

0xA50A

1

EntityManager#getReference(Class<T> entityClass, Object primaryKey)の処理開始

A

0xA50B

2

EntityManager#getReference(Class<T> entityClass, Object primaryKey)の処理終了

A

0xA50C

1

EntityManager#contains(Object entity)の処理開始

A

0xA50D

2

EntityManager#contains(Object entity)の処理終了

A

0xA50E

1

EntityManager#lock(Object entity, LockModeType lockMode)の処理開始

A

0xA50F

2

EntityManager#lock(Object entity, LockModeType lockMode)の処理終了

A

0xA510

1

EntityManager#merge(T entity)の処理開始

A

0xA511

2

EntityManager#merge(T entity)の処理終了

A

0xA512

1

EntityManager#persist(Object entity)の処理開始

A

0xA513

2

EntityManager#persist(Object entity)の処理終了

A

0xA514

1

EntityManager#refresh(Object entity)の処理開始

A

0xA515

2

EntityManager#refresh(Object entity)の処理終了

A

0xA516

1

EntityManager#remove(Object entity)の処理開始

A

0xA517

2

EntityManager#remove(Object entity)の処理終了

A

0xA518

1

EntityManager#clear()の処理開始

A

0xA519

2

EntityManager#clear()の処理終了

A

0xA51A

1

EntityManager#flush()の処理開始

A

0xA51B

2

EntityManager#flush()の処理終了

A

0xA51C

1

EntityManager#createQuery(String qlString)の処理開始

A

0xA51D

2

EntityManager#createQuery(String qlString)の処理終了

A

0xA51E

1

EntityManager#createNamedQuery(String name)の処理開始

A

0xA51F

2

EntityManager#createNamedQuery(String name)の処理終了

A

0xA520

1

EntityManager#createNativeQuery(String sqlString)の処理開始

A

0xA521

2

EntityManager#createNativeQuery(String sqlString)の処理終了

A

0xA522

1

EntityManager#createNativeQuery(String sqlString, Class resultClass)の処理開始

A

0xA523

2

EntityManager#createNativeQuery(String sqlString, Class resultClass)の処理終了

A

0xA524

1

EntityManager#createNativeQuery(String sqlString, String resultSetMapping)の処理開始

A

0xA525

2

EntityManager#createNativeQuery(String sqlString, String resultSetMapping)の処理終了

A

0xA526

1

EntityManager#setFlushMode(FlushModeType flushMode)の処理開始

A

0xA527

2

EntityManager#setFlushMode(FlushModeType flushMode)の処理終了

A

0xA528

1

EntityManager#getFlushMode()の処理開始

A

0xA529

2

EntityManager#getFlushMode()の処理終了

A

0xA52A

1

EntityManager#joinTransaction()の処理開始

A

0xA52B

2

EntityManager#joinTransaction()の処理終了

A

0xA52C

1

EntityManager#getTransaction()の処理開始

A

0xA52D

2

EntityManager#getTransaction()の処理終了

A

0xA52E

1

EntityManager#getDelegate()の処理開始

A

0xA52F

2

EntityManager#getDelegate()の処理終了

A

0xA530

1

EntityManager#isOpen()の処理開始

A

0xA531

2

EntityManager#isOpen()の処理終了

A

0xA532

1

EntityManager#close()の処理開始

A

0xA533

2

EntityManager#close()の処理終了

A

0xA534

1

EntityTransaction#begin()の処理開始

A

0xA535

2

EntityTransaction#begin()の処理終了

A

0xA536

1

EntityTransaction#commit()の処理開始

A

0xA537

2

EntityTransaction#commit()の処理終了

A

0xA538

1

EntityTransaction#rollback()の処理開始

A

0xA539

2

EntityTransaction#rollback()の処理終了

A

0xA53A

1

EntityTransaction#getRollbackOnly()の処理開始

A

0xA53B

2

EntityTransaction#getRollbackOnly()の処理終了

A

0xA53C

1

EntityTransaction#setRollbackOnly()の処理開始

A

0xA53D

2

EntityTransaction#setRollbackOnly()の処理終了

A

0xA53E

1

EntityTransaction#isActive()の処理開始

A

0xA53F

2

EntityTransaction#isActive()の処理終了

A

0xA540

1

Query#executeUpdate()の処理開始

A

0xA541

2

Query#executeUpdate()の処理終了

A

0xA542

1

Query#getResultList()の処理開始

A

0xA543

2

Query#getResultList()の処理終了

A

0xA544

1

Query#getSingleResult()の処理開始

A

0xA545

2

Query#getSingleResult()の処理終了

A

0xA546

1

Query#setFlushMode(FlushModeType flushMode)の処理開始

A

0xA547

2

Query#setFlushMode(FlushModeType flushMode)の処理終了

A

0xA548

1

Query#setFirstResult(int startPosition)の処理開始

B

0xA549

2

Query#setFirstResult(int startPosition)の処理終了

B

0xA54A

1

Query#setMaxResults(int maxResult)の処理開始

B

0xA54B

2

Query#setMaxResults(int maxResult)の処理終了

B

0xA54C

1

Query#setHint(String hintName, Object value)の処理開始

B

0xA54D

2

Query#setHint(String hintName, Object value)の処理終了

B

0xA54E

1

Query#setParameter(int position, Calendar value, TemporalType temporalType)の処理開始

B

0xA54F

2

Query#setParameter(int position, Calendar value, TemporalType temporalType)の処理終了

B

0xA550

1

Query#setParameter(int position, Date value, TemporalType temporalType)の処理開始

B

0xA551

2

Query#setParameter(int position, Date value, TemporalType temporalType)の処理終了

B

0xA552

1

Query#setParameter(int position, Object value)の処理開始

B

0xA553

2

Query#setParameter(int position, Object value)の処理終了

B

0xA554

1

Query#setParameter(String name, Calendar value, TemporalType temporalType)の処理開始

B

0xA555

2

Query#setParameter(String name, Calendar value, TemporalType temporalType)の処理終了

B

0xA556

1

Query#setParameter(String name, Date value, TemporalType temporalType)の処理開始

B

0xA557

2

Query#setParameter(String name, Date value, TemporalType temporalType)の処理終了

B

0xA558

1

Query#setParameter(String name, Object value)の処理開始

B

0xA559

2

Query#setParameter(String name, Object value)の処理終了

B

（凡例）A：標準　B：詳細

注※　図14-16中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒16　アプリケーション管理の永続化コンテキストを利用した場合のトレース取得ポイント

(2)　取得できるトレース情報

アプリケーション管理の永続化コンテキストを利用した場合に取得できるトレース情報を次の表に示します。

表14‒29　アプリケーション管理の永続化コンテキストを利用した場合に取得できるトレース情報

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA500

A

−

−

−

0xA502

A

−

−

−

0xA504

A

−

−

−

0xA506

A

−

−

−

0xA508

A

entityのクラス名

−

−

0xA50A

A

entityのクラス名

−

−

0xA50C

A

entityのクラス名

−

−

0xA50E

A

entityのクラス名

lockModeの値

−

0xA510

A

entityのクラス名

−

−

0xA512

A

entityのクラス名

−

−

0xA514

A

entityのクラス名

−

−

0xA516

A

entityのクラス名

−

−

0xA518

A

−

−

−

0xA51A

A

−

−

−

0xA51C

A

−

−

−

0xA51E

A

name

−

−

0xA520

A

−

−

−

0xA522

A

resultClassのクラス名

−

−

0xA524

A

resultSetMapping

−

−

0xA526

A

flushModeの値

−

−

0xA528

A

−

−

−

0xA52A

A

−

−

−

0xA52C

A

−

−

−

0xA52E

A

−

−

−

0xA530

A

−

−

−

0xA532

A

−

−

−

0xA534

A

−

−

−

0xA536

A

−

−

−

0xA538

A

−

−

−

0xA53A

A

−

−

−

0xA53C

A

−

−

−

0xA53E

A

−

−

−

0xA540

A

−

−

−

0xA542

A

−

−

−

0xA544

A

−

−

−

0xA546

A

flushModeの値

−

−

0xA548

B

startPositionの値

−

−

0xA54A

B

maxResultの値

−

−

0xA54C

B

hintName

valueのクラス名

−

0xA54E

B

positionの値

−

−

0xA550

B

positionの値

−

−

0xA552

B

positionの値

−

−

0xA554

B

nameの値

−

−

0xA556

B

nameの値

−

−

0xA558

B

nameの値

−

−

2

0xA501

A

−

−

正常時

<入り口時刻>

例外発生時

<入り口時刻><例外名>

0xA503

A

−

−

0xA505

A

−

−

0xA507

A

−

−

0xA509

A

−

−

0xA50B

A

−

−

0xA50D

A

−

−

0xA50F

A

−

−

0xA511

A

−

−

0xA513

A

−

−

0xA515

A

−

−

0xA517

A

−

−

0xA519

A

−

−

0xA51B

A

−

−

0xA51D

A

−

−

0xA51F

A

−

−

0xA521

A

−

−

0xA523

A

−

−

0xA525

A

−

−

0xA527

A

−

−

0xA529

A

−

−

0xA52B

A

−

−

0xA52D

A

−

−

0xA52F

A

−

−

0xA531

A

−

−

0xA533

A

−

−

0xA535

A

−

−

0xA537

A

−

−

0xA539

A

−

−

0xA53B

A

−

−

0xA53D

A

−

−

0xA53F

A

−

−

0xA541

A

−

−

0xA543

A

−

−

0xA545

A

−

−

0xA547

A

−

−

0xA549

B

−

−

0xA54B

B

−

−

0xA54D

B

−

−

0xA54F

B

−

−

0xA551

B

−

−

0xA553

B

−

−

0xA555

B

−

−

0xA557

B

−

−

0xA559

B

−

−

（凡例）A：標準　B：詳細　−：該当なし

注※　図14-16中の番号と対応しています。

14.11.2　コンテナ管理の永続化コンテキストを利用した場合のトレース取得ポイントと取得できるトレース情報

コンテナ管理の永続化コンテキストを利用した場合のトレース取得ポイントと取得できるトレース情報について説明します。ここでは，次の四つの場合に分けて説明します。

トランザクションスコープの永続化コンテキストをトランザクション内で利用した場合

トランザクションスコープの永続化コンテキストに関連づいているエンティティマネージャをトランザクション外で利用した場合

トランザクション外で生成されたQueryをトランザクション外で利用した場合

拡張永続化コンテキストを利用した場合

(1)　トレース取得ポイントとPRFトレース取得レベル

(a)　トランザクションスコープの永続化コンテキストをトランザクション内で利用した場合

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒30　トランザクションスコープの永続化コンテキストをトランザクション内で利用した場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA508

1

EntityManager#find(Class<T> entityClass, Object primaryKey)の処理開始

A

0xA509

6

EntityManager#find(Class<T> entityClass, Object primaryKey)の処理終了

A

0xA50A

1

EntityManager#getReference(Class<T> entityClass, Object primaryKey)の処理開始

A

0xA50B

6

EntityManager#getReference(Class<T> entityClass, Object primaryKey)の処理終了

A

0xA50C

1

EntityManager#contains(Object entity)の処理開始

A

0xA50D

6

EntityManager#contains(Object entity)の処理終了

A

0xA50E

1

EntityManager#lock(Object entity, LockModeType lockMode)の処理開始

A

0xA50F

6

EntityManager#lock(Object entity, LockModeType lockMode)の処理終了

A

0xA510

1

EntityManager#merge(T entity)の処理開始

A

0xA511

6

EntityManager#merge(T entity)の処理終了

A

0xA512

1

EntityManager#persist(Object entity)の処理開始

A

0xA513

6

EntityManager#persist(Object entity)の処理終了

A

0xA514

1

EntityManager#refresh(Object entity)の処理開始

A

0xA515

6

EntityManager#refresh(Object entity)の処理終了

A

0xA516

1

EntityManager#remove(Object entity)の処理開始

A

0xA517

6

EntityManager#remove(Object entity)の処理終了

A

0xA518

1

EntityManager#clear()の処理開始

A

0xA519

6

EntityManager#clear()の処理終了

A

0xA51A

1

EntityManager#flush()の処理開始

A

0xA51B

6

EntityManager#flush()の処理終了

A

0xA51C

1

EntityManager#createQuery(String qlString)の処理開始

A

0xA51D

6

EntityManager#createQuery(String qlString)の処理終了

A

0xA51E

1

EntityManager#createNamedQuery(String name)の処理開始

A

0xA51F

6

EntityManager#createNamedQuery(String name)の処理終了

A

0xA520

1

EntityManager#createNativeQuery(String sqlString)の処理開始

A

0xA521

6

EntityManager#createNativeQuery(String sqlString)の処理終了

A

0xA522

1

EntityManager#createNativeQuery(String sqlString, Class resultClass)の処理開始

A

0xA523

6

EntityManager#createNativeQuery(String sqlString, Class resultClass)の処理終了

A

0xA524

1

EntityManager#createNativeQuery(String sqlString, String resultSetMapping)の処理開始

A

0xA525

6

EntityManager#createNativeQuery(String sqlString, String resultSetMapping)の処理終了

A

0xA526

1

EntityManager#setFlushMode(FlushModeType flushMode)の処理開始

A

0xA527

6

EntityManager#setFlushMode(FlushModeType flushMode)の処理終了

A

0xA528

1

EntityManager#getFlushMode()の処理開始

A

0xA529

6

EntityManager#getFlushMode()の処理終了

A

0xA52A

1

EntityManager#joinTransaction()の処理開始

A

0xA52B

6

EntityManager#joinTransaction()の処理終了

A

0xA52C

1

EntityManager#getTransaction()の処理開始

A

0xA52D

6

EntityManager#getTransaction()の処理終了

A

0xA52E

1

EntityManager#getDelegate()の処理開始

A

0xA52F

6

EntityManager#getDelegate()の処理終了

A

0xA530

1

EntityManager#isOpen()の処理開始

A

0xA531

6

EntityManager#isOpen()の処理終了

A

0xA532

1

EntityManager#close()の処理開始

A

0xA533

6

EntityManager#close()の処理終了

A

0xA540

1

Query#executeUpdate()の処理開始

A

0xA541

6

Query#executeUpdate()の処理終了

A

0xA542

1

Query#getResultList()の処理開始

A

0xA543

6

Query#getResultList()の処理終了

A

0xA544

1

Query#getSingleResult()の処理開始

A

0xA545

6

Query#getSingleResult()の処理終了

A

0xA546

1

Query#setFlushMode(FlushModeType flushMode)の処理開始

A

0xA547

6

Query#setFlushMode(FlushModeType flushMode)の処理終了

A

0xA548

1

Query#setFirstResult(int startPosition)の処理開始

B

0xA549

6

Query#setFirstResult(int startPosition)の処理終了

B

0xA54A

1

Query#setMaxResults(int maxResult)の処理開始

B

0xA54B

6

Query#setMaxResults(int maxResult)の処理終了

B

0xA54C

1

Query#setHint(String hintName, Object value)の処理開始

B

0xA54D

6

Query#setHint(String hintName, Object value)の処理終了

B

0xA54E

1

Query#setParameter(int position, Calendar value, TemporalType temporalType)の処理開始

B

0xA54F

6

Query#setParameter(int position, Calendar value, TemporalType temporalType)の処理終了

B

0xA550

1

Query#setParameter(int position, Date value, TemporalType temporalType)の処理開始

B

0xA551

6

Query#setParameter(int position, Date value, TemporalType temporalType)の処理終了

B

0xA552

1

Query#setParameter(int position, Object value)の処理開始

B

0xA553

6

Query#setParameter(int position, Object value)の処理終了

B

0xA554

1

Query#setParameter(String name, Calendar value, TemporalType temporalType)の処理開始

B

0xA555

6

Query#setParameter(String name, Calendar value, TemporalType temporalType)の処理終了

B

0xA556

1

Query#setParameter(String name, Date value, TemporalType temporalType)の処理開始

B

0xA557

6

Query#setParameter(String name, Date value, TemporalType temporalType)の処理終了

B

0xA558

1

Query#setParameter(String name, Object value)の処理開始

B

0xA559

6

Query#setParameter(String name, Object value)の処理終了

B

0xA560

4

JPAプロバイダのEntityManagerのfind(Class<T> entityClass, Object primaryKey)の処理開始

B

0xA561

5

JPAプロバイダのEntityManagerのfind(Class<T> entityClass, Object primaryKey)の処理終了

B

0xA562

4

JPAプロバイダのEntityManagerのgetReference(Class<T> entityClass, Object primaryKey)の処理開始

B

0xA563

5

JPAプロバイダのEntityManagerのgetReference(Class<T> entityClass, Object primaryKey)の処理終了

B

0xA564

4

JPAプロバイダのEntityManagerのcontains(Object entity)の処理開始

B

0xA565

5

JPAプロバイダのEntityManagerのcontains(Object entity)の処理終了

B

0xA566

4

JPAプロバイダのEntityManagerのlock(Object entity, LockModeType lockMode)の処理開始

B

0xA567

5

JPAプロバイダのEntityManagerのlock(Object entity, LockModeType lockMode)の処理終了

B

0xA568

4

JPAプロバイダのEntityManagerのmerge(T entity)の処理開始

B

0xA569

5

JPAプロバイダのEntityManagerのmerge(T entity)の処理終了

B

0xA56A

4

JPAプロバイダのEntityManagerのpersist(Object entity)の処理開始

B

0xA56B

5

JPAプロバイダのEntityManagerのpersist(Object entity)の処理終了

B

0xA56C

4

JPAプロバイダのEntityManagerのrefresh(Object entity)の処理開始

B

0xA56D

5

JPAプロバイダのEntityManagerのrefresh(Object entity)の処理終了

B

0xA56E

4

JPAプロバイダのEntityManagerのremove(Object entity)の処理開始

B

0xA56F

5

JPAプロバイダのEntityManagerのremove(Object entity)の処理終了

B

0xA570

4

JPAプロバイダのEntityManagerのclear()の処理開始

B

0xA571

5

JPAプロバイダのEntityManagerのclear()の処理終了

B

0xA572

4

JPAプロバイダのEntityManagerのflush()の処理開始

B

0xA573

5

JPAプロバイダのEntityManagerのflush()の処理終了

B

0xA574

4

JPAプロバイダのEntityManagerのcreateQuery(String qlString)の処理開始

B

0xA575

5

JPAプロバイダのEntityManagerのcreateQuery(String qlString)の処理終了

B

0xA576

4

JPAプロバイダのEntityManagerのcreateNamedQuery(String name)の処理開始

B

0xA577

5

JPAプロバイダのEntityManagerのcreateNamedQuery(String name)の処理終了

B

0xA578

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString)の処理開始

B

0xA579

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString)の処理終了

B

0xA57A

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, Class resultClass)の処理開始

B

0xA57B

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, Class resultClass)の処理終了

B

0xA57C

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, String resultSetMapping)の処理開始

B

0xA57D

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, String resultSetMapping)の処理終了

B

0xA57E

4

JPAプロバイダのEntityManagerのsetFlushMode(FlushModeType flushMode)の処理開始

B

0xA57F

5

JPAプロバイダのEntityManagerのsetFlushMode(FlushModeType flushMode)の処理終了

B

0xA580

4

JPAプロバイダのEntityManagerのgetFlushMode()の処理開始

B

0xA581

5

JPAプロバイダのEntityManagerのgetFlushMode()の処理終了

B

0xA582

4

JPAプロバイダのEntityManagerのjoinTransaction()の処理開始

B

0xA583

5

JPAプロバイダのEntityManagerのjoinTransaction()の処理終了

B

0xA584

4

JPAプロバイダのEntityManagerのisOpen()の処理開始

B

0xA585

5

JPAプロバイダのEntityManagerのisOpen()の処理終了

B

0xA586

4

JPAプロバイダのQueryのexecuteUpdate()の処理開始

B

0xA587

5

JPAプロバイダのQueryのexecuteUpdate()の処理終了

B

0xA588

4

JPAプロバイダのQueryのgetResultList()の処理開始

B

0xA589

5

JPAプロバイダのQueryのgetResultList()の処理終了

B

0xA58A

4

JPAプロバイダのQueryのgetSingleResult()の処理開始

B

0xA58B

5

JPAプロバイダのQueryのgetSingleResult()の処理終了

B

0xA58C

4

JPAプロバイダのQueryのsetFlushMode(FlushModeType flushMode)の処理開始

B

0xA58D

5

JPAプロバイダのQueryのsetFlushMode(FlushModeType flushMode)の処理終了

B

0xA58E

4

JPAプロバイダのQueryのsetFirstResult(int startPosition)の処理開始

B

0xA58F

5

JPAプロバイダのQueryのsetFirstResult(int startPosition)の処理終了

B

0xA590

4

JPAプロバイダのQueryのsetMaxResults(int maxResult)の処理開始

B

0xA591

5

JPAプロバイダのQueryのsetMaxResults(int maxResult)の処理終了

B

0xA592

4

JPAプロバイダのQueryのsetHint(String hintName, Object value)の処理開始

B

0xA593

5

JPAプロバイダのQueryのsetHint(String hintName, Object value)の処理終了

B

0xA594

4

JPAプロバイダのQueryのsetParameter(int position, Calendar value, TemporalType temporalType)の処理開始

B

0xA595

5

JPAプロバイダのQueryのsetParameter(int position, Calendar value, TemporalType temporalType)の処理終了

B

0xA596

4

JPAプロバイダのQueryのsetParameter(int position, Date value, TemporalType temporalType)の処理開始

B

0xA597

5

JPAプロバイダのQueryのsetParameter(int position, Date value, TemporalType temporalType)の処理終了

B

0xA598

4

JPAプロバイダのQueryのsetParameter(int position, Object value)の処理開始

B

0xA599

5

JPAプロバイダのQueryのsetParameter(int position, Object value)の処理終了

B

0xA59A

4

JPAプロバイダのQueryのsetParameter(String name, Calendar value, TemporalType temporalType)の処理開始

B

0xA59B

5

JPAプロバイダのQueryのsetParameter(String name, Calendar value, TemporalType temporalType)の処理終了

B

0xA59C

4

JPAプロバイダのQueryのsetParameter(String name, Date value, TemporalType temporalType)の処理開始

B

0xA59D

5

JPAプロバイダのQueryのsetParameter(String name, Date value, TemporalType temporalType)の処理終了

B

0xA59E

4

JPAプロバイダのQueryのsetParameter(String name, Object value)の処理開始

B

0xA59F

5

JPAプロバイダのQueryのsetParameter(String name, Object value)の処理終了

B

0xA5A0

2

トランザクションスコープの永続化コンテキストを利用した際の永続化コンテキストの生成処理開始

A

0xA5A1

3

トランザクションスコープの永続化コンテキストを利用した際の永続化コンテキストの生成処理終了

A

0xA5A2

7

トランザクションスコープの永続化コンテキストを利用した際の永続化コンテキストの破棄処理開始

A

0xA5A3

8

トランザクションスコープの永続化コンテキストを利用した際の永続化コンテキストの破棄処理終了

A

（凡例）A：標準　B：詳細

注※　図14-17中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒17　トランザクションスコープの永続化コンテキストをトランザクション内で利用した場合のトレース取得ポイント

(b)　トランザクションスコープの永続化コンテキストに関連づいているエンティティマネージャをトランザクション外で利用した場合

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒31　トランザクションスコープの永続化コンテキストに関連づいているエンティティマネージャをトランザクション外で利用した場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA508

1

EntityManager#find(Class<T> entityClass, Object primaryKey)の処理開始

A

0xA509

8

EntityManager#find(Class<T> entityClass, Object primaryKey)の処理終了

A

0xA50A

1

EntityManager#getReference(Class<T> entityClass, Object primaryKey)の処理開始

A

0xA50B

8

EntityManager#getReference(Class<T> entityClass, Object primaryKey)の処理終了

A

0xA50C

1

EntityManager#contains(Object entity)の処理開始

A

0xA50D

8

EntityManager#contains(Object entity)の処理終了

A

0xA50E

1

EntityManager#lock(Object entity, LockModeType lockMode)の処理開始

A

0xA50F

8

EntityManager#lock(Object entity, LockModeType lockMode)の処理終了

A

0xA510

1

EntityManager#merge(T entity)の処理開始

A

0xA511

8

EntityManager#merge(T entity)の処理終了

A

0xA512

1

EntityManager#persist(Object entity)の処理開始

A

0xA513

8

EntityManager#persist(Object entity)の処理終了

A

0xA514

1

EntityManager#refresh(Object entity)の処理開始

A

0xA515

8

EntityManager#refresh(Object entity)の処理終了

A

0xA516

1

EntityManager#remove(Object entity)の処理開始

A

0xA517

8

EntityManager#remove(Object entity)の処理終了

A

0xA518

1

EntityManager#clear()の処理開始

A

0xA519

8

EntityManager#clear()の処理終了

A

0xA51A

1

EntityManager#flush()の処理開始

A

0xA51B

8

EntityManager#flush()の処理終了

A

0xA526

1

EntityManager#setFlushMode(FlushModeType flushMode)の処理開始

A

0xA527

8

EntityManager#setFlushMode(FlushModeType flushMode)の処理終了

A

0xA528

1

EntityManager#getFlushMode()の処理開始

A

0xA529

8

EntityManager#getFlushMode()の処理終了

A

0xA52A

1

EntityManager#joinTransaction()の処理開始

A

0xA52B

8

EntityManager#joinTransaction()の処理終了

A

0xA52C

1

EntityManager#getTransaction()の処理開始

A

0xA52D

8

EntityManager#getTransaction()の処理終了

A

0xA52E

1

EntityManager#getDelegate()の処理開始

A

0xA52F

8

EntityManager#getDelegate()の処理終了

A

0xA530

1

EntityManager#isOpen()の処理開始

A

0xA531

8

EntityManager#isOpen()の処理終了

A

0xA532

1

EntityManager#close()の処理開始

A

0xA533

8

EntityManager#close()の処理終了

A

0xA560

4

JPAプロバイダのEntityManagerのfind(Class<T> entityClass, Object primaryKey)の処理開始

B

0xA561

5

JPAプロバイダのEntityManagerのfind(Class<T> entityClass, Object primaryKey)の処理終了

B

0xA562

4

JPAプロバイダのEntityManagerのgetReference(Class<T> entityClass, Object primaryKey)の処理開始

B

0xA563

5

JPAプロバイダのEntityManagerのgetReference(Class<T> entityClass, Object primaryKey)の処理終了

B

0xA564

4

JPAプロバイダのEntityManagerのcontains(Object entity)の処理開始

B

0xA565

5

JPAプロバイダのEntityManagerのcontains(Object entity)の処理終了

B

0xA566

4

JPAプロバイダのEntityManagerのlock(Object entity, LockModeType lockMode)の処理開始

B

0xA567

5

JPAプロバイダのEntityManagerのlock(Object entity, LockModeType lockMode)の処理終了

B

0xA568

4

JPAプロバイダのEntityManagerのmerge(T entity)の処理開始

B

0xA569

5

JPAプロバイダのEntityManagerのmerge(T entity)の処理終了

B

0xA56A

4

JPAプロバイダのEntityManagerのpersist(Object entity)の処理開始

B

0xA56B

5

JPAプロバイダのEntityManagerのpersist(Object entity)の処理終了

B

0xA56C

4

JPAプロバイダのEntityManagerのrefresh(Object entity)の処理開始

B

0xA56D

5

JPAプロバイダのEntityManagerのrefresh(Object entity)の処理終了

B

0xA56E

4

JPAプロバイダのEntityManagerのremove(Object entity)の処理開始

B

0xA56F

5

JPAプロバイダのEntityManagerのremove(Object entity)の処理終了

B

0xA570

4

JPAプロバイダのEntityManagerのclear()の処理開始

B

0xA571

5

JPAプロバイダのEntityManagerのclear()の処理終了

B

0xA572

4

JPAプロバイダのEntityManagerのflush()の処理開始

B

0xA573

5

JPAプロバイダのEntityManagerのflush()の処理終了

B

0xA57E

4

JPAプロバイダのEntityManagerのsetFlushMode(FlushModeType flushMode)の処理開始

B

0xA57F

5

JPAプロバイダのEntityManagerのsetFlushMode(FlushModeType flushMode)の処理終了

B

0xA580

4

JPAプロバイダのEntityManagerのgetFlushMode()の処理開始

B

0xA581

5

JPAプロバイダのEntityManagerのgetFlushMode()の処理終了

B

0xA582

4

JPAプロバイダのEntityManagerのjoinTransaction()の処理開始

B

0xA583

5

JPAプロバイダのEntityManagerのjoinTransaction()の処理終了

B

0xA584

4

JPAプロバイダのEntityManagerのisOpen()の処理開始

B

0xA585

5

JPAプロバイダのEntityManagerのisOpen()の処理終了

B

0xA5A4

2

トランザクションスコープのEntityManagerのQuery生成以外のAPIを，トランザクションの存在しない状況で利用した際の永続化コンテキストの生成処理開始

A

0xA5A5

3

トランザクションスコープのEntityManagerのQuery生成以外のAPIを，トランザクションの存在しない状況で利用した際の永続化コンテキストの生成処理終了

A

0xA5A6

6

トランザクションスコープのEntityManagerのQuery生成以外のAPIを，トランザクションの存在しない状況で利用した際に生成した永続化コンテキストの破棄処理開始

A

0xA5A7

7

トランザクションスコープのEntityManagerのQuery生成以外のAPIを，トランザクションの存在しない状況で利用した際に生成した永続化コンテキストの破棄処理終了

A

（凡例）A：標準　B：詳細

注※　図14-18中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒18　トランザクションスコープの永続化コンテキストに関連づいているエンティティマネージャをトランザクション外で利用した場合のトレース取得ポイント

(c)　トランザクション外で生成されたQueryをトランザクション外で利用した場合

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒32　トランザクション外で生成されたQueryをトランザクション外で利用した場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA51C

1

EntityManager#createQuery(String qlString)の処理開始

A

0xA51D

6

EntityManager#createQuery(String qlString)の処理終了

A

0xA51E

1

EntityManager#createNamedQuery(String name)の処理開始

A

0xA51F

6

EntityManager#createNamedQuery(String name)の処理終了

A

0xA520

1

EntityManager#createNativeQuery(String sqlString)の処理開始

A

0xA521

6

EntityManager#createNativeQuery(String sqlString)の処理終了

A

0xA522

1

EntityManager#createNativeQuery(String sqlString, Class resultClass)の処理開始

A

0xA523

6

EntityManager#createNativeQuery(String sqlString, Class resultClass)の処理終了

A

0xA524

1

EntityManager#createNativeQuery(String sqlString, String resultSetMapping)の処理開始

A

0xA525

6

EntityManager#createNativeQuery(String sqlString, String resultSetMapping)の処理終了

A

0xA540

1，11

Query#executeUpdate()の処理開始

A

0xA541

6，16

Query#executeUpdate()の処理終了

A

0xA542

1，11

Query#getResultList()の処理開始

A

0xA543

6，16

Query#getResultList()の処理終了

A

0xA544

1，11

Query#getSingleResult()の処理開始

A

0xA545

6，16

Query#getSingleResult()の処理終了

A

0xA546

1，7

Query#setFlushMode(FlushModeType flushMode)の処理開始

A

0xA547

6，10

Query#setFlushMode(FlushModeType flushMode)の処理終了

A

0xA548

1，7

Query#setFirstResult(int startPosition)の処理開始

B

0xA549

6，10

Query#setFirstResult(int startPosition)の処理終了

B

0xA54A

1，7

Query#setMaxResults(int maxResult)の処理開始

B

0xA54B

6，10

Query#setMaxResults(int maxResult)の処理終了

B

0xA54C

1，7

Query#setHint(String hintName, Object value)の処理開始

B

0xA54D

6，10

Query#setHint(String hintName, Object value)の処理終了

B

0xA54E

1，7

Query#setParameter(int position, Calendar value, TemporalType temporalType)の処理開始

B

0xA54F

6，10

Query#setParameter(int position, Calendar value, TemporalType temporalType)の処理終了

B

0xA550

1，7

Query#setParameter(int position, Date value, TemporalType temporalType)の処理開始

B

0xA551

6，10

Query#setParameter(int position, Date value, TemporalType temporalType)の処理終了

B

0xA552

1，7

Query#setParameter(int position, Object value)の処理開始

B

0xA553

6，10

Query#setParameter(int position, Object value)の処理終了

B

0xA554

1，7

Query#setParameter(String name, Calendar value, TemporalType temporalType)の処理開始

B

0xA555

6，10

Query#setParameter(String name, Calendar value, TemporalType temporalType)の処理終了

B

0xA556

1，7

Query#setParameter(String name, Date value, TemporalType temporalType)の処理開始

B

0xA557

6，10

Query#setParameter(String name, Date value, TemporalType temporalType)の処理終了

B

0xA558

1，7

Query#setParameter(String name, Object value)の処理開始

B

0xA559

6，10

Query#setParameter(String name, Object value)の処理終了

B

0xA574

4

JPAプロバイダのEntityManagerのcreateQuery(String qlString)の処理開始

B

0xA575

5

JPAプロバイダのEntityManagerのcreateQuery(String qlString)の処理終了

B

0xA576

4

JPAプロバイダのEntityManagerのcreateNamedQuery(String name)の処理開始

B

0xA577

5

JPAプロバイダのEntityManagerのcreateNamedQuery(String name)の処理終了

B

0xA578

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString)の処理開始

B

0xA579

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString)の処理終了

B

0xA57A

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, Class resultClass)の処理開始

B

0xA57B

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, Class resultClass)の処理終了

B

0xA57C

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, String resultSetMapping)の処理開始

B

0xA57D

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, String resultSetMapping)の処理終了

B

0xA586

4，12

JPAプロバイダのQueryのexecuteUpdate()の処理開始

B

0xA587

5，13

JPAプロバイダのQueryのexecuteUpdate()の処理終了

B

0xA588

4，12

JPAプロバイダのQueryのgetResultList()の処理開始

B

0xA589

5，13

JPAプロバイダのQueryのgetResultList()の処理終了

B

0xA58A

4，12

JPAプロバイダのQueryのgetSingleResult()の処理開始

B

0xA58B

5，13

JPAプロバイダのQueryのgetSingleResult()の処理終了

B

0xA58C

4，8

JPAプロバイダのQueryのsetFlushMode(FlushModeType flushMode)の処理開始

B

0xA58D

5，9

JPAプロバイダのQueryのsetFlushMode(FlushModeType flushMode)の処理終了

B

0xA58E

4，8

JPAプロバイダのQueryのsetFirstResult(int startPosition)の処理開始

B

0xA58F

5，9

JPAプロバイダのQueryのsetFirstResult(int startPosition)の処理終了

B

0xA590

4，8

JPAプロバイダのQueryのsetMaxResults(int maxResult)の処理開始

B

0xA591

5，9

JPAプロバイダのQueryのsetMaxResults(int maxResult)の処理終了

B

0xA592

4，8

JPAプロバイダのQueryのsetHint(String hintName, Object value)の処理開始

B

0xA593

5，9

JPAプロバイダのQueryのsetHint(String hintName, Object value)の処理終了

B

0xA594

4，8

JPAプロバイダのQueryのsetParameter(int position, Calendar value, TemporalType temporalType)の処理開始

B

0xA595

5，9

JPAプロバイダのQueryのsetParameter(int position, Calendar value, TemporalType temporalType)の処理終了

B

0xA596

4，8

JPAプロバイダのQueryのsetParameter(int position, Date value, TemporalType temporalType)の処理開始

B

0xA597

5，9

JPAプロバイダのQueryのsetParameter(int position, Date value, TemporalType temporalType)の処理終了

B

0xA598

4，8

JPAプロバイダのQueryのsetParameter(int position, Object value)の処理開始

B

0xA599

5，9

JPAプロバイダのQueryのsetParameter(int position, Object value)の処理終了

B

0xA59A

4，8

JPAプロバイダのQueryのsetParameter(String name, Calendar value, TemporalType temporalType)の処理開始

B

0xA59B

5，9

JPAプロバイダのQueryのsetParameter(String name, Calendar value, TemporalType temporalType)の処理終了

B

0xA59C

4，8

JPAプロバイダのQueryのsetParameter(String name, Date value, TemporalType temporalType)の処理開始

B

0xA59D

5，9

JPAプロバイダのQueryのsetParameter(String name, Date value, TemporalType temporalType)の処理終了

B

0xA59E

4，8

JPAプロバイダのQueryのsetParameter(String name, Object value)の処理開始

B

0xA59F

5，9

JPAプロバイダのQueryのsetParameter(String name, Object value)の処理終了

B

0xA5A8

2

トランザクションスコープのEntityManagerのQuery生成APIまたはQueryによる検索・更新後に同一QueryオブジェクトのAPIを，トランザクションの存在しない状況で利用した際の永続化コンテキストの生成処理開始

A

0xA5A9

3

トランザクションスコープのEntityManagerのQuery生成APIまたはQueryによる検索・更新後に同一QueryオブジェクトのAPIを，トランザクションの存在しない状況で利用した際の永続化コンテキストの生成処理終了

A

0xA5AA

14

トランザクションスコープのEntityManagerのQuery生成APIまたはQueryによる検索・更新後に同一QueryオブジェクトのAPIを，トランザクションの存在しない状況で利用した際に生成した永続化コンテキストの破棄処理開始

A

0xA5AB

15

トランザクションスコープのEntityManagerのQuery生成APIまたはQueryによる検索・更新後に同一QueryオブジェクトのAPIを，トランザクションの存在しない状況で利用した際に生成した永続化コンテキストの破棄処理終了

A

（凡例）A：標準　B：詳細

注※　図14-19中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒19　トランザクション外で生成されたQueryをトランザクション外で利用した場合のトレース取得ポイント

(d)　拡張永続化コンテキストを利用した場合

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒33　拡張永続化コンテキストを利用した場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA508

3

EntityManager#find(Class<T> entityClass, Object primaryKey)の処理開始

A

0xA509

6

EntityManager#find(Class<T> entityClass, Object primaryKey)の処理終了

A

0xA50A

3

EntityManager#getReference(Class<T> entityClass, Object primaryKey)の処理開始

A

0xA50B

6

EntityManager#getReference(Class<T> entityClass, Object primaryKey)の処理終了

A

0xA50C

3

EntityManager#contains(Object entity)の処理開始

A

0xA50D

6

EntityManager#contains(Object entity)の処理終了

A

0xA50E

3

EntityManager#lock(Object entity, LockModeType lockMode)の処理開始

A

0xA50F

6

EntityManager#lock(Object entity, LockModeType lockMode)の処理終了

A

0xA510

3

EntityManager#merge(T entity)の処理開始

A

0xA511

6

EntityManager#merge(T entity)の処理終了

A

0xA512

3

EntityManager#persist(Object entity)の処理開始

A

0xA513

6

EntityManager#persist(Object entity)の処理終了

A

0xA514

3

EntityManager#refresh(Object entity)の処理開始

A

0xA515

6

EntityManager#refresh(Object entity)の処理終了

A

0xA516

3

EntityManager#remove(Object entity)の処理開始

A

0xA517

6

EntityManager#remove(Object entity)の処理終了

A

0xA518

3

EntityManager#clear()の処理開始

A

0xA519

6

EntityManager#clear()の処理終了

A

0xA51A

3

EntityManager#flush()の処理開始

A

0xA51B

6

EntityManager#flush()の処理終了

A

0xA51C

3

EntityManager#createQuery(String qlString)の処理開始

A

0xA51D

6

EntityManager#createQuery(String qlString)の処理終了

A

0xA51E

3

EntityManager#createNamedQuery(String name)の処理開始

A

0xA51F

6

EntityManager#createNamedQuery(String name)の処理終了

A

0xA520

3

EntityManager#createNativeQuery(String sqlString)の処理開始

A

0xA521

6

EntityManager#createNativeQuery(String sqlString)の処理終了

A

0xA522

3

EntityManager#createNativeQuery(String sqlString, Class resultClass)の処理開始

A

0xA523

6

EntityManager#createNativeQuery(String sqlString, Class resultClass)の処理終了

A

0xA524

3

EntityManager#createNativeQuery(String sqlString, String resultSetMapping)の処理開始

A

0xA525

6

EntityManager#createNativeQuery(String sqlString, String resultSetMapping)の処理終了

A

0xA526

3

EntityManager#setFlushMode(FlushModeType flushMode)の処理開始

A

0xA527

6

EntityManager#setFlushMode(FlushModeType flushMode)の処理終了

A

0xA528

3

EntityManager#getFlushMode()の処理開始

A

0xA529

6

EntityManager#getFlushMode()の処理終了

A

0xA52A

3

EntityManager#joinTransaction()の処理開始

A

0xA52B

6

EntityManager#joinTransaction()の処理終了

A

0xA52C

3

EntityManager#getTransaction()の処理開始

A

0xA52D

6

EntityManager#getTransaction()の処理終了

A

0xA52E

3

EntityManager#getDelegate()の処理開始

A

0xA52F

6

EntityManager#getDelegate()の処理終了

A

0xA530

3

EntityManager#isOpen()の処理開始

A

0xA531

6

EntityManager#isOpen()の処理終了

A

0xA532

3

EntityManager#close()の処理開始

A

0xA533

6

EntityManager#close()の処理終了

A

0xA540

3

Query#executeUpdate()の処理開始

A

0xA541

6

Query#executeUpdate()の処理終了

A

0xA542

3

Query#getResultList()の処理開始

A

0xA543

6

Query#getResultList()の処理終了

A

0xA544

3

Query#getSingleResult()の処理開始

A

0xA545

6

Query#getSingleResult()の処理終了

A

0xA546

3

Query#setFlushMode(FlushModeType flushMode)の処理開始

A

0xA547

6

Query#setFlushMode(FlushModeType flushMode)の処理終了

A

0xA548

3

Query#setFirstResult(int startPosition)の処理開始

B

0xA549

6

Query#setFirstResult(int startPosition)の処理終了

B

0xA54A

3

Query#setMaxResults(int maxResult)の処理開始

B

0xA54B

6

Query#setMaxResults(int maxResult)の処理終了

B

0xA54C

3

Query#setHint(String hintName, Object value)の処理開始

B

0xA54D

6

Query#setHint(String hintName, Object value)の処理終了

B

0xA54E

3

Query#setParameter(int position, Calendar value, TemporalType temporalType)の処理開始

B

0xA54F

6

Query#setParameter(int position, Calendar value, TemporalType temporalType)の処理終了

B

0xA550

3

Query#setParameter(int position, Date value, TemporalType temporalType)の処理開始

B

0xA551

6

Query#setParameter(int position, Date value, TemporalType temporalType)の処理終了

B

0xA552

3

Query#setParameter(int position, Object value)の処理開始

B

0xA553

6

Query#setParameter(int position, Object value)の処理終了

B

0xA554

3

Query#setParameter(String name, Calendar value, TemporalType temporalType)の処理開始

B

0xA555

6

Query#setParameter(String name, Calendar value, TemporalType temporalType)の処理終了

B

0xA556

3

Query#setParameter(String name, Date value, TemporalType temporalType)の処理開始

B

0xA557

6

Query#setParameter(String name, Date value, TemporalType temporalType)の処理終了

B

0xA558

3

Query#setParameter(String name, Object value)の処理開始

B

0xA559

6

Query#setParameter(String name, Object value)の処理終了

B

0xA560

4

JPAプロバイダのEntityManagerのfind(Class<T> entityClass, Object primaryKey)の処理開始

B

0xA561

5

JPAプロバイダのEntityManagerのfind(Class<T> entityClass, Object primaryKey)の処理終了

B

0xA562

4

JPAプロバイダのEntityManagerのgetReference(Class<T> entityClass, Object primaryKey)の処理開始

B

0xA563

5

JPAプロバイダのEntityManagerのgetReference(Class<T> entityClass, Object primaryKey)の処理終了

B

0xA564

4

JPAプロバイダのEntityManagerのcontains(Object entity)の処理開始

B

0xA565

5

JPAプロバイダのEntityManagerのcontains(Object entity)の処理終了

B

0xA566

4

JPAプロバイダのEntityManagerのlock(Object entity, LockModeType lockMode)の処理開始

B

0xA567

5

JPAプロバイダのEntityManagerのlock(Object entity, LockModeType lockMode)の処理終了

B

0xA568

4

JPAプロバイダのEntityManagerのmerge(T entity)の処理開始

B

0xA569

5

JPAプロバイダのEntityManagerのmerge(T entity)の処理終了

B

0xA56A

4

JPAプロバイダのEntityManagerのpersist(Object entity)の処理開始

B

0xA56B

5

JPAプロバイダのEntityManagerのpersist(Object entity)の処理終了

B

0xA56C

4

JPAプロバイダのEntityManagerのrefresh(Object entity)の処理開始

B

0xA56D

5

JPAプロバイダのEntityManagerのrefresh(Object entity)の処理終了

B

0xA56E

4

JPAプロバイダのEntityManagerのremove(Object entity)の処理開始

B

0xA56F

5

JPAプロバイダのEntityManagerのremove(Object entity)の処理終了

B

0xA570

4

JPAプロバイダのEntityManagerのclear()の処理開始

B

0xA571

5

JPAプロバイダのEntityManagerのclear()の処理終了

B

0xA572

4

JPAプロバイダのEntityManagerのflush()の処理開始

B

0xA573

5

JPAプロバイダのEntityManagerのflush()の処理終了

B

0xA574

4

JPAプロバイダのEntityManagerのcreateQuery(String qlString)の処理開始

B

0xA575

5

JPAプロバイダのEntityManagerのcreateQuery(String qlString)の処理終了

B

0xA576

4

JPAプロバイダのEntityManagerのcreateNamedQuery(String name)の処理開始

B

0xA577

5

JPAプロバイダのEntityManagerのcreateNamedQuery(String name)の処理終了

B

0xA578

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString)の処理開始

B

0xA579

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString)の処理終了

B

0xA57A

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, Class resultClass)の処理開始

B

0xA57B

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, Class resultClass)の処理終了

B

0xA57C

4

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, String resultSetMapping)の処理開始

B

0xA57D

5

JPAプロバイダのEntityManagerのcreateNativeQuery(String sqlString, String resultSetMapping)の処理終了

B

0xA57E

4

JPAプロバイダのEntityManagerのsetFlushMode(FlushModeType flushMode)の処理開始

B

0xA57F

5

JPAプロバイダのEntityManagerのsetFlushMode(FlushModeType flushMode)の処理終了

B

0xA580

4

JPAプロバイダのEntityManagerのgetFlushMode()の処理開始

B

0xA581

5

JPAプロバイダのEntityManagerのgetFlushMode()の処理終了

B

0xA582

4

JPAプロバイダのEntityManagerのjoinTransaction()の処理開始

B

0xA583

5

JPAプロバイダのEntityManagerのjoinTransaction()の処理終了

B

0xA584

4

JPAプロバイダのEntityManagerのisOpen()の処理開始

B

0xA585

5

JPAプロバイダのEntityManagerのisOpen()の処理終了

B

0xA586

4

JPAプロバイダのQueryのexecuteUpdate()の処理開始

B

0xA587

5

JPAプロバイダのQueryのexecuteUpdate()の処理終了

B

0xA588

4

JPAプロバイダのQueryのgetResultList()の処理開始

B

0xA589

5

JPAプロバイダのQueryのgetResultList()の処理終了

B

0xA58A

4

JPAプロバイダのQueryのgetSingleResult()の処理開始

B

0xA58B

5

JPAプロバイダのQueryのgetSingleResult()の処理終了

B

0xA58C

4

JPAプロバイダのQueryのsetFlushMode(FlushModeType flushMode)の処理開始

B

0xA58D

5

JPAプロバイダのQueryのsetFlushMode(FlushModeType flushMode)の処理終了

B

0xA58E

4

JPAプロバイダのQueryのsetFirstResult(int startPosition)の処理開始

B

0xA58F

5

JPAプロバイダのQueryのsetFirstResult(int startPosition)の処理終了

B

0xA590

4

JPAプロバイダのQueryのsetMaxResults(int maxResult)の処理開始

B

0xA591

5

JPAプロバイダのQueryのsetMaxResults(int maxResult)の処理終了

B

0xA592

4

JPAプロバイダのQueryのsetHint(String hintName, Object value)の処理開始

B

0xA593

5

JPAプロバイダのQueryのsetHint(String hintName, Object value)の処理終了

B

0xA594

4

JPAプロバイダのQueryのsetParameter(int position, Calendar value, TemporalType temporalType)の処理開始

B

0xA595

5

JPAプロバイダのQueryのsetParameter(int position, Calendar value, TemporalType temporalType)の処理終了

B

0xA596

4

JPAプロバイダのQueryのsetParameter(int position, Date value, TemporalType temporalType)の処理開始

B

0xA597

5

JPAプロバイダのQueryのsetParameter(int position, Date value, TemporalType temporalType)の処理終了

B

0xA598

4

JPAプロバイダのQueryのsetParameter(int position, Object value)の処理開始

B

0xA599

5

JPAプロバイダのQueryのsetParameter(int position, Object value)の処理終了

B

0xA59A

4

JPAプロバイダのQueryのsetParameter(String name, Calendar value, TemporalType temporalType)の処理開始

B

0xA59B

5

JPAプロバイダのQueryのsetParameter(String name, Calendar value, TemporalType temporalType)の処理終了

B

0xA59C

4

JPAプロバイダのQueryのsetParameter(String name, Date value, TemporalType temporalType)の処理開始

B

0xA59D

5

JPAプロバイダのQueryのsetParameter(String name, Date value, TemporalType temporalType)の処理終了

B

0xA59E

4

JPAプロバイダのQueryのsetParameter(String name, Object value)の処理開始

B

0xA59F

5

JPAプロバイダのQueryのsetParameter(String name, Object value)の処理終了

B

0xA5AC

1

拡張スコープの永続化コンテキストを利用した際の永続化コンテキストの生成処理開始

A

0xA5AD

2

拡張スコープの永続化コンテキストを利用した際の永続化コンテキストの生成処理終了

A

0xA5AE

7

拡張スコープの永続化コンテキストを利用した際のEntityManager.close()の処理開始

A

0xA5AF

8

拡張スコープの永続化コンテキストを利用した際のEntityManager.close()の処理終了

A

（凡例）A：標準　B：詳細

注※　図14-20中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒20　拡張永続化コンテキストを利用した場合のトレース取得ポイント

(2)　取得できるトレース情報

(a)　トランザクションスコープの永続化コンテキストをトランザクション内で利用した場合

トランザクションスコープの永続化コンテキストをトランザクション内で利用した場合に取得できるトレース情報を次の表に示します。

表14‒34　トランザクションスコープの永続化コンテキストをトランザクション内で利用した場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA508

A

entityのクラス名

−

−

0xA50A

A

entityのクラス名

−

−

0xA50C

A

entityのクラス名

−

−

0xA50E

A

entityのクラス名

lockModeの値

−

0xA510

A

entityのクラス名

−

−

0xA512

A

entityのクラス名

−

−

0xA514

A

entityのクラス名

−

−

0xA516

A

entityのクラス名

−

−

0xA518

A

−

−

−

0xA51A

A

−

−

−

0xA51C

A

−

−

−

0xA51E

A

name

−

−

0xA520

A

−

−

−

0xA522

A

resultClassのクラス名

−

−

0xA524

A

resultSetMapping

−

−

0xA526

A

flushModeの値

−

−

0xA528

A

−

−

−

0xA52A

A

−

−

−

0xA52C

A

−

−

−

0xA52E

A

−

−

−

0xA530

A

−

−

−

0xA532

A

−

−

−

0xA540

A

−

−

−

0xA542

A

−

−

−

0xA544

A

−

−

−

0xA546

A

flushModeの値

−

−

0xA548

B

startPositionの値

−

−

0xA54A

B

maxResultの値

−

−

0xA54C

B

hintName

valueのクラス名

−

0xA54E

B

positionの値

−

−

0xA550

B

positionの値

−

−

0xA552

B

positionの値

−

−

0xA554

B

nameの値

−

−

0xA556

B

nameの値

−

−

0xA558

B

nameの値

−

−

2

0xA5A0

A

−

−

−

3

0xA5A1

A

−

−

※2

4

0xA560

B

entityのクラス名

−

−

0xA562

B

entityのクラス名

−

−

0xA564

B

entityのクラス名

−

−

0xA566

B

entityのクラス名

lockModeの値

−

0xA568

B

entityのクラス名

−

−

0xA56A

B

entityのクラス名

−

−

0xA56C

B

entityのクラス名

−

−

0xA56E

B

entityのクラス名

−

−

0xA570

B

−

−

−

0xA572

B

−

−

−

0xA574

B

−

−

−

0xA576

B

name

−

−

0xA578

B

−

−

−

0xA57A

B

resultClassのクラス名

−

−

0xA57C

B

resultSetMapping

−

−

0xA57E

B

flushModeの値

−

−

0xA580

B

−

−

−

0xA582

B

−

−

−

0xA584

B

−

−

−

0xA586

B

−

−

−

0xA588

B

−

−

−

0xA58A

B

−

−

−

0xA58C

B

flushModeの値

−

−

0xA58E

B

startPositionの値

−

−

0xA590

B

maxResultの値

−

−

0xA592

B

hintName

valueのクラス名

−

0xA594

B

positionの値

−

−

0xA596

B

positionの値

−

−

0xA598

B

positionの値

−

−

0xA59A

B

nameの値

−

−

0xA59C

B

nameの値

−

−

0xA59E

B

nameの値

−

−

5

0xA561

B

−

−

※2

0xA563

B

−

−

※2

0xA565

B

−

−

※2

0xA567

B

−

−

※2

0xA569

B

−

−

※2

0xA56B

B

−

−

※2

0xA56D

B

−

−

※2

0xA56F

B

−

−

※2

0xA571

B

−

−

※2

0xA573

B

−

−

※2

0xA575

B

−

−

※2

0xA577

B

−

−

※2

0xA579

B

−

−

※2

0xA57B

B

−

−

※2

0xA57D

B

−

−

※2

0xA57F

B

−

−

※2

0xA581

B

−

−

※2

0xA583

B

−

−

※2

0xA585

B

−

−

※2

0xA587

B

−

−

※2

0xA589

B

−

−

※2

0xA58B

B

−

−

※2

0xA58D

B

−

−

※2

0xA58F

B

−

−

※2

0xA591

B

−

−

※2

0xA593

B

−

−

※2

0xA595

B

−

−

※2

0xA597

B

−

−

※2

0xA599

B

−

−

※2

0xA59B

B

−

−

※2

0xA59D

B

−

−

※2

0xA59F

B

−

−

※2

6

0xA509

A

−

−

※2

0xA50B

A

−

−

※2

0xA50D

A

−

−

※2

0xA50F

A

−

−

※2

0xA511

A

−

−

※2

0xA513

A

−

−

※2

0xA515

A

−

−

※2

0xA517

A

−

−

※2

0xA519

A

−

−

※2

0xA51B

A

−

−

※2

0xA51D

A

−

−

※2

0xA51F

A

−

−

※2

0xA521

A

−

−

※2

0xA523

A

−

−

※2

0xA525

A

−

−

※2

0xA527

A

−

−

※2

0xA529

A

−

−

※2

0xA52B

A

−

−

※2

0xA52D

A

−

−

※2

0xA52F

A

−

−

※2

0xA531

A

−

−

※2

0xA533

A

−

−

※2

0xA541

A

−

−

※2

0xA543

A

−

−

※2

0xA545

A

−

−

※2

0xA547

A

−

−

※2

0xA549

B

−

−

※2

0xA54B

B

−

−

※2

0xA54D

B

−

−

※2

0xA54F

B

−

−

※2

0xA551

B

−

−

※2

0xA553

B

−

−

※2

0xA555

B

−

−

※2

0xA557

B

−

−

※2

0xA559

B

−

−

※2

7

0xA5A2

A

−

−

−

8

0xA5A3

A

−

−

※2

（凡例）A：標準　B：詳細　−：該当なし

注※1　図14-17中の番号と対応しています。

注※2　正常に処理された場合，入り口時刻が表示されます。例外が発生した場合，入り口時刻と例外が表示されます。

(b)　トランザクションスコープの永続化コンテキストに関連づいているエンティティマネージャをトランザクション外で利用した場合

トランザクションスコープの永続化コンテキストに関連づいているエンティティマネージャをトランザクション外で利用した場合に取得できるトレース情報を次の表に示します。

表14‒35　トランザクションスコープの永続化コンテキストに関連づいているエンティティマネージャをトランザクション外で利用した場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA508

A

entityのクラス名

−

−

0xA50A

A

entityのクラス名

−

−

0xA50C

A

entityのクラス名

−

−

0xA50E

A

entityのクラス名

lockModeの値

−

0xA510

A

entityのクラス名

−

−

0xA512

A

entityのクラス名

−

−

0xA514

A

entityのクラス名

−

−

0xA516

A

entityのクラス名

−

−

0xA518

A

−

−

−

0xA51A

A

−

−

−

0xA526

A

flushModeの値

−

−

0xA528

A

−

−

−

0xA52A

A

−

−

−

0xA52C

A

−

−

−

0xA52E

A

−

−

−

0xA530

A

−

−

−

0xA532

A

−

−

−

2

0xA5A4

A

−

−

−

3

0xA5A5

A

−

−

※2

4

0xA560

B

entityのクラス名

−

−

0xA562

B

entityのクラス名

−

−

0xA564

B

entityのクラス名

−

−

0xA566

B

entityのクラス名

lockModeの値

−

0xA568

B

entityのクラス名

−

−

0xA56A

B

entityのクラス名

−

−

0xA56C

B

entityのクラス名

−

−

0xA56E

B

entityのクラス名

−

−

0xA570

B

−

−

−

0xA572

B

−

−

−

0xA57E

B

flushModeの値

−

−

0xA580

B

−

−

−

0xA582

B

−

−

−

0xA584

B

−

−

−

5

0xA561

B

−

−

※2

0xA563

B

−

−

※2

0xA565

B

−

−

※2

0xA567

B

−

−

※2

0xA569

B

−

−

※2

0xA56B

B

−

−

※2

0xA56D

B

−

−

※2

0xA56F

B

−

−

※2

0xA571

B

−

−

※2

0xA573

B

−

−

※2

0xA57F

B

−

−

※2

0xA581

B

−

−

※2

0xA583

B

−

−

※2

0xA585

B

−

−

※2

6

0xA5A6

A

−

−

−

7

0xA5A7

A

−

−

※2

8

0xA509

A

−

−

※2

0xA50B

A

−

−

※2

0xA50D

A

−

−

※2

0xA50F

A

−

−

※2

0xA511

A

−

−

※2

0xA513

A

−

−

※2

0xA515

A

−

−

※2

0xA517

A

−

−

※2

0xA519

A

−

−

※2

0xA51B

A

−

−

※2

0xA527

A

−

−

※2

0xA529

A

−

−

※2

0xA52B

A

−

−

※2

0xA52D

A

−

−

※2

0xA52F

A

−

−

※2

0xA531

A

−

−

※2

0xA533

A

−

−

※2

（凡例）A：標準　B：詳細　−：該当なし

注※1　図14-18中の番号と対応しています。

注※2　正常に処理された場合，入り口時刻が表示されます。例外が発生した場合，入り口時刻と例外が表示されます。

(c)　トランザクション外で生成されたQueryをトランザクション外で利用した場合

トランザクション外で生成されたQueryをトランザクション外で利用した場合に取得できるトレース情報を次の表に示します。

表14‒36　トランザクション外で生成されたQueryをトランザクション外で利用した場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA51C

A

−

−

−

0xA51E

A

name

−

−

0xA520

A

−

−

−

0xA522

A

resultClassのクラス名

−

−

0xA524

A

resultSetMapping

−

−

1，11

0xA540

A

−

−

−

0xA542

A

−

−

−

0xA544

A

−

−

−

1，7

0xA546

A

flushModeの値

−

−

0xA548

B

startPositionの値

−

−

0xA54A

B

maxResultの値

−

−

0xA54C

B

hintName

valueのクラス名

−

0xA54E

B

positionの値

−

−

0xA550

B

positionの値

−

−

0xA552

B

positionの値

−

−

0xA554

B

nameの値

−

−

0xA556

B

nameの値

−

−

0xA558

B

nameの値

−

−

2

0xA5A8

A

−

−

−

3

0xA5A9

A

−

−

※2

4

0xA574

B

−

−

−

0xA576

B

name

−

−

0xA578

B

−

−

−

0xA57A

B

resultClassのクラス名

−

−

0xA57C

B

resultSetMapping

−

−

4，12

0xA586

B

−

−

−

0xA588

B

−

−

−

0xA58A

B

−

−

−

4，8

0xA58C

B

flushModeの値

−

−

0xA58E

B

startPositionの値

−

−

0xA590

B

maxResultの値

−

−

0xA592

B

hintName

valueのクラス名

−

0xA594

B

positionの値

−

−

0xA596

B

positionの値

−

−

0xA598

B

positionの値

−

−

0xA59A

B

nameの値

−

−

0xA59C

B

nameの値

−

−

0xA59E

B

nameの値

−

−

5

0xA575

B

−

−

※2

0xA577

B

−

−

※2

0xA579

B

−

−

※2

0xA57B

B

−

−

※2

0xA57D

B

−

−

※2

5，13

0xA587

B

−

−

※2

0xA589

B

−

−

※2

0xA58B

B

−

−

※2

5，9

0xA58D

B

−

−

※2

0xA58F

B

−

−

※2

0xA591

B

−

−

※2

0xA593

B

−

−

※2

0xA595

B

−

−

※2

0xA597

B

−

−

※2

0xA599

B

−

−

※2

0xA59B

B

−

−

※2

0xA59D

B

−

−

※2

0xA59F

B

−

−

※2

6

0xA51D

A

−

−

※2

0xA51F

A

−

−

※2

0xA521

A

−

−

※2

0xA523

A

−

−

※2

0xA525

A

−

−

※2

6，16

0xA541

A

−

−

※2

0xA543

A

−

−

※2

0xA545

A

−

−

※2

6，10

0xA547

A

−

−

※2

0xA549

B

−

−

※2

0xA54B

B

−

−

※2

0xA54D

B

−

−

※2

0xA54F

B

−

−

※2

0xA551

B

−

−

※2

0xA553

B

−

−

※2

0xA555

B

−

−

※2

0xA557

B

−

−

※2

0xA559

B

−

−

※2

14

0xA5AA

A

−

−

−

15

0xA5AB

A

−

−

※2

（凡例）A：標準　B：詳細　−：該当なし

注※1　図14-19中の番号と対応しています。

注※2　正常に処理された場合，入り口時刻が表示されます。例外が発生した場合，入り口時刻と例外が表示されます。

(d)　拡張永続化コンテキストを利用した場合

拡張永続化コンテキストを利用した場合に取得できるトレース情報を次の表に示します。

表14‒37　拡張永続化コンテキストを利用した場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA5AC

A

−

−

−

2

0xA5AD

A

−

−

※2

3

0xA508

A

entityのクラス名

−

−

0xA50A

A

entityのクラス名

−

−

0xA50C

A

entityのクラス名

−

−

0xA50E

A

entityのクラス名

lockModeの値

−

0xA510

A

entityのクラス名

−

−

0xA512

A

entityのクラス名

−

−

0xA514

A

entityのクラス名

−

−

0xA516

A

entityのクラス名

−

−

0xA518

A

−

−

−

0xA51A

A

−

−

−

0xA51C

A

−

−

−

0xA51E

A

name

−

−

0xA520

A

−

−

−

0xA522

A

resultClassのクラス名

−

−

0xA524

A

resultSetMapping

−

−

0xA526

A

flushModeの値

−

−

0xA528

A

−

−

−

0xA52A

A

−

−

−

0xA52C

A

−

−

−

0xA52E

A

−

−

−

0xA530

A

−

−

−

0xA532

A

−

−

−

0xA540

A

−

−

−

0xA542

A

−

−

−

0xA544

A

−

−

−

0xA546

A

flushModeの値

−

−

0xA548

B

startPositionの値

−

−

0xA54A

B

maxResultの値

−

−

0xA54C

B

hintName

valueのクラス名

−

0xA54E

B

positionの値

−

−

0xA550

B

positionの値

−

−

0xA552

B

positionの値

−

−

0xA554

B

nameの値

−

−

0xA556

B

nameの値

−

−

0xA558

B

nameの値

−

−

4

0xA560

B

entityのクラス名

−

−

0xA562

B

entityのクラス名

−

−

0xA564

B

entityのクラス名

−

−

0xA566

B

entityのクラス名

lockModeの値

−

0xA568

B

entityのクラス名

−

−

0xA56A

B

entityのクラス名

−

−

0xA56C

B

entityのクラス名

−

−

0xA56E

B

entityのクラス名

−

−

0xA570

B

−

−

−

0xA572

B

−

−

−

0xA574

B

−

−

−

0xA576

B

name

−

−

0xA578

B

−

−

−

0xA57A

B

resultClassのクラス名

−

−

0xA57C

B

resultSetMapping

−

−

0xA57E

B

flushModeの値

−

−

0xA580

B

−

−

−

0xA582

B

−

−

−

0xA584

B

−

−

−

0xA586

B

−

−

−

0xA588

B

−

−

−

0xA58A

B

−

−

−

0xA58C

B

flushModeの値

−

−

0xA58E

B

startPositionの値

−

−

0xA590

B

maxResultの値

−

−

0xA592

B

hintName

valueのクラス名

−

0xA594

B

positionの値

−

−

0xA596

B

positionの値

−

−

0xA598

B

positionの値

−

−

0xA59A

B

nameの値

−

−

0xA59C

B

nameの値

−

−

0xA59E

B

nameの値

−

−

5

0xA561

B

−

−

※2

0xA563

B

−

−

※2

0xA565

B

−

−

※2

0xA567

B

−

−

※2

0xA569

B

−

−

※2

0xA56B

B

−

−

※2

0xA56D

B

−

−

※2

0xA56F

B

−

−

※2

0xA571

B

−

−

※2

0xA573

B

−

−

※2

0xA575

B

−

−

※2

0xA577

B

−

−

※2

0xA579

B

−

−

※2

0xA57B

B

−

−

※2

0xA57D

B

−

−

※2

0xA57F

B

−

−

※2

0xA581

B

−

−

※2

0xA583

B

−

−

※2

0xA585

B

−

−

※2

0xA587

B

−

−

※2

0xA589

B

−

−

※2

0xA58B

B

−

−

※2

0xA58D

B

−

−

※2

0xA58F

B

−

−

※2

0xA591

B

−

−

※2

0xA593

B

−

−

※2

0xA595

B

−

−

※2

0xA597

B

−

−

※2

0xA599

B

−

−

※2

0xA59B

B

−

−

※2

0xA59D

B

−

−

※2

0xA59F

B

−

−

※2

6

0xA509

A

−

−

※2

0xA50B

A

−

−

※2

0xA50D

A

−

−

※2

0xA50F

A

−

−

※2

0xA511

A

−

−

※2

0xA513

A

−

−

※2

0xA515

A

−

−

※2

0xA517

A

−

−

※2

0xA519

A

−

−

※2

0xA51B

A

−

−

※2

0xA51D

A

−

−

※2

0xA51F

A

−

−

※2

0xA521

A

−

−

※2

0xA523

A

−

−

※2

0xA525

A

−

−

※2

0xA527

A

−

−

※2

0xA529

A

−

−

※2

0xA52B

A

−

−

※2

0xA52D

A

−

−

※2

0xA52F

A

−

−

※2

0xA531

A

−

−

※2

0xA533

A

−

−

※2

0xA541

A

−

−

※2

0xA543

A

−

−

※2

0xA545

A

−

−

※2

0xA547

A

−

−

※2

0xA549

B

−

−

※2

0xA54B

B

−

−

※2

0xA54D

B

−

−

※2

0xA54F

B

−

−

※2

0xA551

B

−

−

※2

0xA553

B

−

−

※2

0xA555

B

−

−

※2

0xA557

B

−

−

※2

0xA559

B

−

−

※2

7

0xA5AE

A

−

−

−

8

0xA5AF

A

−

−

※2

（凡例）A：標準　B：詳細　−：該当なし

注※1　図14-20中の番号と対応しています。

注※2　正常に処理された場合，入り口時刻が表示されます。例外が発生した場合，入り口時刻と例外が表示されます。

14.12　CJPAプロバイダのトレース取得ポイント

ここでは，CJPAプロバイダのトレース取得ポイントと，取得できるトレース情報について説明します。

14.12.1　EntityManagerFactoryの取得／解放処理のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒38　EntityManagerFactoryの取得／解放処理のトレース取得ポイントの詳細

イベントID

図中の番号※1

トレース取得ポイント

レベル

0xA304※2

3

EntityManagerFactory#close()の処理開始

B

0xA305※2

4

EntityManagerFactory#close()の処理終了

B

0xA320※3

1

PersistenceProvider#createEntityManagerFactory(String, Map)の処理開始

A

0xA321※3

2

PersistenceProvider#createEntityManagerFactory(String, Map)の処理終了

A

0xA322※3

1

PersistenceProvider#createContainerEntityManagerFactory(PersistenceUnitInfo, Map)の処理開始

A

0xA323※3

2

PersistenceProvider#createContainerEntityManagerFactory(PersistenceUnitInfo, Map)の処理終了

A

（凡例）A：標準　B：詳細

注※1　図14-21中の番号と対応しています。

注※2　javax.persistence.EntityManagerFactoryの場合のトレース取得ポイントです。

注※3　javax.persistence.spi.PersistenceProviderの場合のトレース取得ポイントです。

トレース取得ポイントを次の図に示します。

図14‒21　EntityManagerFactoryの取得／解放処理のトレース取得ポイント

(2)　取得できるトレース情報

EntityManagerFactoryの取得／解放処理で取得できるトレース情報を次の表に示します。

表14‒39　EntityManagerFactoryの取得／解放処理で取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1※2

0xA320※3

A

−

−

−

0xA322

A

−

−

−

2※2

0xA321※3

A

−

−

※4

0xA323

A

−

−

※4

3※5

0xA304

B

−

−

−

4※5

0xA305

B

−

−

※4

（凡例）A：標準　B：詳細　−：該当なし

注※1　図14-21中の番号と対応しています。

注※2　javax.persistence.spi.PersistenceProviderの場合のトレース取得ポイントです。

注※3　CJPAプロバイダを使用した場合は出力されません。

注※4　例外が発生した場合，例外が表示されます。

注※5　javax.persistence.EntityManagerFactoryの場合のトレース取得ポイントです。

14.12.2　EntityManagerの取得処理のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒40　javax.persistence.EntityManagerFactoryの場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA300

1

EntityManagerFactory#createEntityManager()の処理開始

B

0xA301

2

EntityManagerFactory#createEntityManager()の処理終了

B

0xA302

1

EntityManagerFactory#createEntityManager(Map)の処理開始

B

0xA303

2

EntityManagerFactory#createEntityManager(Map)の処理終了

B

（凡例）B：詳細

注※　図14-22中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒22　javax.persistence.EntityManagerFactoryの場合のトレース取得ポイント

(2)　取得できるトレース情報

EntityManagerの取得処理で取得できるトレース情報を次の表に示します。

表14‒41　javax.persistence.EntityManagerFactoryの場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA300

B

−

−

−

0xA302

B

−

−

−

2

0xA301

B

−

−

※2

0xA303

B

−

−

※2

（凡例）B：詳細　−：該当なし

注※1　図14-22中の番号と対応しています。

注※2　例外が発生した場合，例外が表示されます。

14.12.3　EntityManagerの操作のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒42　javax.persistence.EntityManagerの場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA340

1

EntityManager#persist(Object)の処理開始

B

0xA341

2

EntityManager#persist(Object)の処理終了

B

0xA342

1

EntityManager#merge(T)の処理開始

B

0xA343

2

EntityManager#merge(T)の処理終了

B

0xA344

1

EntityManager#remove(Object)の処理開始

B

0xA345

2

EntityManager#remove(Object)の処理終了

B

0xA346

1

EntityManager#find(Class<T>, Object)の処理開始

B

0xA347

2

EntityManager#find(Class<T>, Object)の処理終了

B

0xA348

1

EntityManager#getReference(Class<T>, Object)の処理開始

B

0xA349

2

EntityManager#getReference(Class<T>, Object)の処理終了

B

0xA34A

1

EntityManager#flush()の処理開始

B

0xA34B

2

EntityManager#flush()の処理終了

B

0xA34C

1

EntityManager#lock(Object, LockModeType)の処理開始

B

0xA34D

2

EntityManager#lock(Object, LockModeType)の処理終了

B

0xA34E

1

EntityManager#refresh(Object)の処理開始

B

0xA34F

2

EntityManager#refresh(Object)の処理終了

B

0xA350

1

EntityManager#clear()の処理開始

B

0xA351

2

EntityManager#clear()の処理終了

B

0xA352

1

EntityManager#contains(Object)の処理開始

B

0xA353

2

EntityManager#contains(Object)の処理終了

B

0xA35E

1

EntityManager#joinTransaction()の処理開始

B

0xA35F

2

EntityManager#joinTransaction()の処理終了

B

（凡例）B：詳細

注※　図14-23の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒23　javax.persistence.EntityManagerの場合のトレース取得ポイント

(2)　取得できるトレース情報

EntityManagerの操作で取得できるトレース情報を次の表に示します。

表14‒43　javax.persistence.EntityManagerの場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA340

B

−

−

−

0xA342

B

−

−

−

0xA344

B

−

−

−

0xA346

B

−

−

−

0xA348

B

−

−

−

0xA34A

B

−

−

−

0xA34C

B

−

−

−

0xA34E

B

−

−

−

0xA350

B

−

−

−

0xA352

B

−

−

−

0xA35E

B

−

−

−

2

0xA341

B

−

−

※2

0xA343

B

−

−

※2

0xA345

B

−

−

※2

0xA347

B

−

−

※2

0xA349

B

−

−

※2

0xA34B

B

−

−

※2

0xA34D

B

−

−

※2

0xA34F

B

−

−

※2

0xA351

B

−

−

※2

0xA353

B

−

−

※2

0xA35F

B

−

−

※2

（凡例）B：詳細　−：該当なし

注※1　図14-23中の番号と対応しています。

注※2　例外が発生した場合，例外が表示されます。

14.12.4　EntityManagerの解放処理のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒44　 javax.persistence.EntityManagerの場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA360

1

EntityManager#close()の処理開始

B

0xA361

2

EntityManager#close()の処理終了

B

（凡例）B：詳細

注※　図14-24中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒24　javax.persistence.EntityManagerの場合のトレース取得ポイント

(2)　取得できるトレース情報

EntityManagerの解放処理で取得できるトレース情報を次の表に示します。

表14‒45　javax.persistence.EntityManagerの場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA360

B

−

−

−

2

0xA361

B

−

−

※2

（凡例）B：詳細　−：該当なし

注※1　図14-24の番号と対応しています。

注※2　例外が発生した場合，例外が表示されます。

14.12.5　Queryの操作のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒46　Query操作のトレース取得ポイントの詳細

イベントID

図中の番号※1

トレース取得ポイント

レベル

0xA354※2

1

EntityManager#createQuery(String)の処理開始

B

0xA355※2

2

EntityManager#createQuery(String)の処理終了

B

0xA356※2

1

EntityManager#createNamedQuery(String)の処理開始

B

0xA357※2

2

EntityManager#createNamedQuery(String)の処理終了

B

0xA358※2

1

EntityManager#createNativeQuery(String)の処理開始

B

0xA359※2

2

EntityManager#createNativeQuery(String)の処理終了

B

0xA35A※2

1

EntityManager#createNativeQuery(String, Class)の処理開始

B

0xA35B※2

2

EntityManager#createNativeQuery(String, Class)の処理終了

B

0xA35C※2

1

EntityManager#createNativeQuery(String, String)の処理開始

B

0xA35D※2

2

EntityManager#createNativeQuery(String, String)の処理終了

B

0xA370※3

5

Query#getResultList()の処理開始

B

0xA371※3

6

Query#getResultList()の処理終了

B

0xA372※3

5

Query#getSingleResult()の処理開始

B

0xA373※3

6

Query#getSingleResult()の処理終了

B

0xA374※3

5

Query#executeUpdate()の処理開始

B

0xA375※3

6

Query#executeUpdate()の処理終了

B

0xA376※3

3

Query#setParameter(String, Object)の処理開始

B

0xA377※3

4

Query#setParameter(String, Object)の処理終了

B

0xA378※3

3

Query#setParameter(String, Date, TemporalType)の処理開始

B

0xA379※3

4

Query#setParameter(String, Date, TemporalType)の処理終了

B

0xA37A※3

3

Query#setParameter(String, Calendar, TemporalType)の処理開始

B

0xA37B※3

4

Query#setParameter(String, Calendar, TemporalType)の処理終了

B

0xA37C※3

3

Query#setParameter(int, Object)の処理開始

B

0xA37D※3

4

Query#setParameter(int, Object)の処理終了

B

0xA37E※3

3

Query#setParameter(int, Date, TemporalType)の処理開始

B

0xA37F※3

4

Query#setParameter(int, Date, TemporalType)の処理終了

B

0xA380※3

3

Query#setParameter(int, Calendar, TemporalType)の処理開始

B

0xA381※3

4

Query#setParameter(int, Calendar, TemporalType)の処理終了

B

（凡例）B：詳細

注※1　図14-25中の番号と対応しています。

注※2　javax.persistence.EntityManagerの場合のトレース取得ポイントです。

注※3　javax.persistence.Queryの場合のトレース取得ポイントです。

トレース取得ポイントを次の図に示します。

図14‒25　Query操作のトレース取得ポイント

(2)　取得できるトレース情報

Queryの操作で取得できるトレース情報を次の表に示します。

表14‒47　Query操作で取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1※2

0xA354

B

−

−

−

0xA356

B

−

−

−

0xA358

B

−

−

−

0xA35A

B

−

−

−

0xA35C

B

−

−

−

2※2

0xA355

B

−

−

※3

0xA357

B

−

−

※3

0xA359

B

−

−

※3

0xA35B

B

−

−

※3

0xA35D

B

−

−

※3

3※4

0xA376

B

−

−

−

0xA378

B

−

−

−

0xA37A

B

−

−

−

0xA37C

B

−

−

−

0xA37E

B

−

−

−

0xA380

B

−

−

−

4※4

0xA377

B

−

−

※3

0xA379

B

−

−

※3

0xA37B

B

−

−

※3

0xA37D

B

−

−

※3

0xA37F

B

−

−

※3

0xA381

B

−

−

※3

5※4

0xA370

B

−

−

−

0xA372

B

−

−

−

0xA374

B

−

−

−

6※4

0xA371

B

−

−

※3

0xA373

B

−

−

※3

0xA375

B

−

−

※3

（凡例）B：詳細　−：該当なし

注※1　図14-25中の番号と対応しています。

注※2　javax.persistence.EntityManagerの場合のトレース取得ポイントです。

注※3　例外が発生した場合，例外が表示されます。

注※4　javax.persistence.Queryの場合のトレース取得ポイントです。

14.12.6　EntityTransactionの操作のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒48　EntityTransactionの操作のトレース取得ポイントの詳細

イベントID

図中の番号※1

トレース取得ポイント

レベル

0xA310※2

3

EntityTransaction#begin()の処理開始

B

0xA311※2

4

EntityTransaction#begin()の処理終了

B

0xA312※2

5

EntityTransaction#commit()の処理開始

B

0xA313※2

6

EntityTransaction#commit()の処理終了

B

0xA314※2

5

EntityTransaction#rollback()の処理開始

B

0xA315※2

6

EntityTransaction#rollback()の処理終了

B

0xA362※3

1

EntityManager#getTransaction()の処理開始

B

0xA363※3

2

EntityManager#getTransaction()の処理終了

B

（凡例）B：詳細

注※1　図14-26中の番号と対応しています。

注※2　javax.persistence.EntityTransactionの場合のトレース取得ポイントです。

注※3　javax.persistence.EntityManagerの場合のトレース取得ポイントです。

トレース取得ポイントを次の図に示します。

図14‒26　EntityTransactionの操作のトレース取得ポイント

(2)　取得できるトレース情報

EntityTransactionの操作で取得できるトレース情報を次の表に示します。

表14‒49　EntityTransactionの場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1※2

0xA362

B

−

−

−

2※2

0xA363

B

−

−

※3

3※4

0xA310

B

−

−

−

4※4

0xA311

B

−

−

※3

5※4

0xA312

B

−

−

−

0xA314

B

−

−

−

6※4

0xA313

B

−

−

※3

0xA315

B

−

−

※3

（凡例）B：詳細　−：該当なし

注※1　図14-26中の番号と対応しています。

注※2　javax.persistence.EntityManagerの場合のトレース取得ポイントです。

注※3　例外が発生した場合，例外が表示されます。

注※4　javax.persistence.EntityTransactionの場合のトレース取得ポイントです。

14.12.7　ユーザへのコールバックメソッドのトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒50　ユーザへのコールバックメソッドでのトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA390

1

PrePersist()コールバックメソッドの呼び出し直前

A

0xA391

2

PrePersist()コールバックメソッドからリターンした直後

A

0xA392

1

PostPersist()コールバックメソッドの呼び出し直前

A

0xA393

2

PostPersist()コールバックメソッドからリターンした直後

A

0xA394

1

PreRemove()コールバックメソッドの呼び出し直前

A

0xA395

2

PreRemove()コールバックメソッドからリターンした直後

A

0xA396

1

PostRemove()コールバックメソッドの呼び出し直前

A

0xA397

2

PostRemove()コールバックメソッドからリターンした直後

A

0xA398

1

PreUpdate()コールバックメソッドの呼び出し直前

A

0xA399

2

PreUpdate()コールバックメソッドからリターンした直後

A

0xA39A

1

PostUpdate()コールバックメソッドの呼び出し直前

A

0xA39B

2

PostUpdate()コールバックメソッドからリターンした直後

A

0xA39C

1

PostLoad()コールバックメソッドの呼び出し直前

A

0xA39D

2

PostLoad()コールバックメソッドからリターンした直後

A

（凡例）A：標準

注※　図14-27中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒27　ユーザへのコールバックメソッドのトレース取得ポイント

(2)　取得できるトレース情報

ユーザへのコールバックメソッドで取得できるトレース情報を次の表に示します。

表14‒51　ユーザへのコールバックメソッドで取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA390

A

ユーザが指定したコールバックメソッド名

−

−

0xA392

A

−

−

0xA394

A

−

−

0xA396

A

−

−

0xA398

A

−

−

0xA39A

A

−

−

0xA39C

A

−

−

2

0xA391

A

ユーザが指定したコールバックメソッド名

−

※2

0xA393

A

−

※2

0xA395

A

−

※2

0xA397

A

−

※2

0xA399

A

−

※2

0xA39B

A

−

※2

0xA39D

A

−

※2

（凡例）A：標準　−：該当なし

注※1　図14-27中の番号と対応しています。

注※2　例外が発生した場合，例外が表示されます。

14.12.8　エンティティクラスのバイナリ変換のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒52　エンティティクラスのバイナリ変換でのトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA330

1

エンティティクラスに対するバイナリ変換処理の開始直前

B

0xA331

2

エンティティクラスに対するバイナリ変換処理の完了直後

B

（凡例）B：詳細

注※　図14-28中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒28　エンティティクラスのバイナリ変換でのトレース取得ポイント

ポイント

JPAを使用するアプリケーションでは，エンティティクラス以外のクラスの場合でも，そのクラスがクラスローダからローディングされるタイミングでこれらのトレース情報が取得されます。

(2)　取得できるトレース情報

エンティティクラスのバイナリ変換で取得できるトレース情報を次の表に示します。

表14‒53　エンティティクラスのバイナリ変換で取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA330

B

−

−

−

2

0xA331

B

−

−

※2

（凡例）B：詳細　−：該当なし

注※1　図14-28中の番号と対応しています。

注※2　例外が発生した場合，例外が表示されます。

14.12.9　トランザクションマネージャとのトランザクション連携処理のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒54　トランザクションマネージャとのトランザクション連携処理のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA39E

1

永続化コンテキストとトランザクションを関連づける処理の開始直前

B

0xA39F

2

永続化コンテキストとトランザクションを関連づける処理の完了直後

B

0xA3A0

3

JTAトランザクション決着の前処理の開始直前

B

0xA3A1

4

JTAトランザクション決着の前処理の終了直後

B

0xA3A2

5

JTAトランザクション決着の後処理の開始直前

B

0xA3A3

6

JTAトランザクション決着の後処理の終了直後

B

（凡例）B：詳細

注※　図14-29中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒29　トランザクションマネージャとのトランザクション連携処理のトレース取得ポイント

(2)　取得できるトレース情報

トランザクションマネージャとのトランザクション連携処理で取得できるトレース情報を次の表に示します。

表14‒55　トランザクションマネージャとのトランザクション連携処理で取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA39E

B

−

−

−

2

0xA39F

B

−

−

※2

3

0xA3A0

B

−

−

−

4

0xA3A1

B

−

−

※2

5

0xA3A2

B

−

afterCompletion()の引数で渡されたトランザクションのステータス(javax.transaction.Statusのint値)

−

6

0xA3A3

B

−

−

※2

（凡例）B：詳細　−：該当なし

注※1　図14-29中の番号と対応しています。

注※2　例外が発生した場合，例外が表示されます。

14.12.10　DB Connectorのコネクション操作のトレース取得ポイントと取得できるトレース情報

(1)　トレース取得ポイントとPRFトレース取得レベル

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒56　DB Connectorのコネクション操作のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xA3A4

1

DataSource#getConnection()の呼び出し直前

B

0xA3A5

2

DataSource#getConnection()からリターンした直後

B

0xA3A6

1

DataSource#getConnection(String, String)の呼び出し直前

B

0xA3A7

2

DataSource#getConnection(String, String)からリターンした直後

B

0xA3A8

1

DriverManager#getConnection(String, Properties)の呼び出し直前

B

0xA3A9

2

DriverManager#getConnection(String, Properties)からリターンした直後

B

0xA3AA

1

DriverManager#getConnection(String, String, String)の呼び出し直前

B

0xA3AB

2

DriverManager#getConnection(String, String, String)からリターンした直後

B

0xA3AC

9

Connection#close()の呼び出し直前

B

0xA3AD

10

Connection#close()からリターンした直後

B

0xA3AE

7

Connection#commit()の呼び出し直前

B

0xA3AF

8

Connection#commit()からリターンした直後

B

0xA3B0

3

Connection#createStatement()の呼び出し直前

B

0xA3B1

4

Connection#createStatement()からリターンした直後

B

0xA3B2

3

Connection#prepareCall(String)の呼び出し直前

B

0xA3B3

4

Connection#prepareCall(String)からリターンした直後

B

0xA3B4

3

Connection#prepareCall(String, int, int)の呼び出し直前

B

0xA3B5

4

Connection#prepareCall(String, int, int)からリターンした直後

B

0xA3B6

3

Connection#prepareStatement(String)の呼び出し直前

B

0xA3B7

4

Connection#prepareStatement(String)からリターンした直後

B

0xA3B8

3

Connection#prepareStatement(String, int, int)の呼び出し直前

B

0xA3B9

4

Connection#prepareStatement(String , int, int)からリターンした直後

B

0xA3BA

7

Connection#rollback()の呼び出し直前

B

0xA3BB

8

Connection#rollback()からリターンした直後

B

0xA3BC

5

Statement#executeQuery(String)の呼び出し直前

B

0xA3BD

6

Statement#executeQuery(String)からリターンした直後

B

0xA3BE

5

Statement#executeUpdate(String)の呼び出し直前

B

0xA3BF

6

Statement#executeUpdate(String)からリターンした直後

B

0xA3C0

5

PreparedStatement#executeUpdate()の呼び出し直前

B

0xA3C1

6

PreparedStatement#executeUpdate()からリターンした直後

B

0xA3C2

5

PreparedStatement#executeQuery()の呼び出し直前

B

0xA3C3

6

PreparedStatement#executeQuery()からリターンした直後

B

（凡例）B：詳細

注※　図14-30中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒30　DB Connectorのコネクション操作のトレース取得ポイント

(2)　取得できるトレース情報

DB Connectorのコネクション操作で取得できるトレース情報を次の表に示します。

表14‒57　DB Connectorのコネクション操作で取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xA3A4

B

−

−

−

0xA3A6

B

−

−

−

0xA3A8

B

−

−

−

0xA3AA

B

−

−

−

2

0xA3A5

B

−

−

※2

0xA3A7

B

−

−

※2

0xA3A9

B

−

−

※2

0xA3AB

B

−

−

※2

3

0xA3B0

B

−

−

−

0xA3B2

B

−

−

−

0xA3B4

B

−

−

−

0xA3B6

B

−

−

−

0xA3B8

B

−

−

−

4

0xA3B1

B

−

−

※2

0xA3B3

B

−

−

※2

0xA3B5

B

−

−

※2

0xA3B7

B

−

−

※2

0xA3B9

B

−

−

※2

5

0xA3BC

B

−

−

−

0xA3BE

B

−

−

−

0xA3C0

B

−

−

−

0xA3C2

B

−

−

−

6

0xA3BD

B

−

−

※2

0xA3BF

B

−

−

※2

0xA3C1

B

−

−

※2

0xA3C3

B

−

−

※2

7

0xA3AE

B

−

−

−

0xA3BA

B

−

−

−

8

0xA3AF

B

−

−

※2

0xA3BB

B

−

−

※2

9

0xA3AC

B

−

−

−

10

0xA3AD

B

−

−

※2

（凡例）B：詳細　−：該当なし

注※1　図14-30中の番号と対応しています。

注※2　例外が発生した場合，例外が表示されます。

14.13　CDIのトレース取得ポイント

ここでは，CDIのトレース取得ポイントと，取得できるトレース情報について説明します。

14.13.1　CDIのトレース取得ポイントと取得できるトレース情報

CDIのトレース取得ポイントと取得できるトレース情報について説明します。ここでは，次の二つの場合に分けて説明します。

JSFとCDIを組み合わせて利用する場合

サーブレットとCDIを組み合わせて利用する場合

(1)　トレース取得ポイントとPRFトレース取得レベル

(a)　JSFとCDIを組み合わせて利用する場合

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒58　JSFとCDIを組み合わせて利用する場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xb002

1

CDIを利用するために必要なJSFの設定の読み込み処理開始

A

0xb003

2

CDIを利用するために必要なJSFの設定の読み込み処理終了（正常終了）

A

0xb004

3

CDIを利用するために必要なJSFの準備の処理開始

A

0xb005

4

CDIを利用するために必要なJSFの準備の処理終了（正常終了）

A

0xb006

5

EL評価準備の処理開始

B

0xb007

6

EL評価準備の処理終了（正常終了）

B

（凡例）A：標準　B：詳細

注※　図14-31および図14-32中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒31　JSFとCDIを組み合わせて利用する場合のトレース取得ポイント（JSFの設定の読み込みと準備処理時）

図14‒32　JSFとCDIを組み合わせて利用する場合のトレース取得ポイント（EL評価処理時）

(b)　サーブレット・フィルタ・リスナとCDIを組み合わせて利用する場合

イベントID，トレース取得ポイント，およびPRFトレース取得レベルについて，次の表に示します。

表14‒59　サーブレット・フィルタ・リスナとCDIを組み合わせて利用する場合のトレース取得ポイントの詳細

イベントID

図中の番号※

トレース取得ポイント

レベル

0xb008

1

サーブレット・フィルタ・リスナのインスタンス生成の処理開始

A

0xb009

2

サーブレット・フィルタ・リスナのインスタンス生成の処理終了（正常終了）

A

（凡例）A：標準

注※　図14-33中の番号と対応しています。

トレース取得ポイントを次の図に示します。

図14‒33　サーブレット・フィルタ・リスナとCDIを組み合わせて利用する場合のトレース取得ポイント

(2)　取得できるトレース情報

(a)　JSFとCDIを組み合わせて利用する場合

JSFとCDIを組み合わせて利用する場合に取得できるトレース情報を次の表に示します。

表14‒60　JSFとCDIを組み合わせて利用する場合に取得できる場合に取得できるトレース情報

図中の番号※1

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xb002※2

A

WeldFacesConfigProvider

−

Webコンテナのコンテキスト情報

2

0xb003※2

A

WeldFacesConfigProvider

−

入口時刻

3

0xb004※2

A

WeldApplicationFactory

−

−

4

0xb005※2

A

WeldApplicationFactory

−

入口時刻

5

0xb006※3

B

WeldApplication

−

−

6

0xb007※3

B

WeldApplication

−

入口時刻

（凡例）A：標準　B：詳細　−：該当なし

注※1　図14-31および図14-32中の番号と対応しています。

注※2　CDIを利用するために必要なJSFの設定の読み込みと，CDIを利用するために必要なJSFの準備のトレース情報はアプリケーション開始時に取得します。

注※3　EL評価準備のトレース情報は，FacesServletが初期化処理時とJSFで指定されているEL式の評価実行時に取得します。

(b)　CDIからサーブレットを呼び出す場合

CDIからサーブレットを呼び出す場合に取得できるトレース情報を次の表に示します。

表14‒61　CDIからサーブレットを呼び出す場合に取得できるトレース情報

図中の番号※

イベントID

レベル

取得できる情報

インタフェース名

オペレーション名

オプション

1

0xb008

A

CDIServiceImpl

−

次の情報が出力されます。

Managedクラス

クラス名

コンテキストルート

2

0xb009

A

CDIServiceImpl

−

入口時刻

（凡例）A：標準　−：該当なし

注※　図14-33中の番号と対応しています。

なお，トレース情報は，サーブレット・フィルタ・リスナのインタフェース生成時に取得します。

15　出力されるログ情報とログ取得の設定

この章では，出力されるログ情報とログ取得の設定について説明します。

15.1　機能ごとに出力されるログ情報

特定の機能を利用したときに出力されるログ情報について説明します。

ここでは，次の機能を利用したときに出力されるログ情報について説明します。

CJPAプロバイダの稼働ログ

15.1.1　CJPAプロバイダの稼働ログ

ここでは，CJPAプロバイダが出力する稼働ログのメッセージについて，ログ出力のカテゴリごとに説明します。

(1)　カテゴリがSQLの場合

SQL [aa....aa] SQL = bb....bb

aa....aa：永続化ユニット名

bb....bb：発行するSQL文

説明

JPAがSQLを発行します。

SQL [aa....aa] PARAM = bb....bb

aa....aa：永続化ユニット名

bb....bb：?パラメタ(プレースホルダ)の設定値

説明

SQL文の?パラメタ（プレースホルダ）に値を設定します。

bb....bbには，?パラメタ（プレースホルダ）に設定された値を文字表現に変換した結果が出力されます。文字や数値の場合はそのまま出力されます。ただし，例えばバイナリデータがjavaのbyte型配列に格納されていると，byte型配列に対してtoStringメソッドを実行して，「[B@f7ba93」のような表記で出力されます。

SQL [aa....aa] RETURN = bb....bb

aa....aa：永続化ユニット名

bb....bb：戻り値

説明

PreparedStatement#executeUpdate()の戻り値です。戻り値はSQL文を実行した結果の行数です。詳細についてはJavadocの「java.sql.PreparedStatement」を参照してください。

(2)　カテゴリがTRANSACTIONの場合

TRN [aa....aa] JPA processing was bound to a JTA transaction. (status = bb....bb)

aa....aa：永続化ユニット名

bb....bb：JTAトランザクションに参加したときのトランザクションの状態

説明

JTAトランザクションに参加しました。トランザクションの状態（ステータス）を示す文字列を出力します。状態を示す文字列の詳細については，Javadocの「javax.transaction.Status」を参照してください。

TRN [aa....aa] A JTA transaction was committed. (status = bb....bb)

aa....aa：永続化ユニット名

bb....bb：JTAトランザクションが決着したときのトランザクションの状態

説明

JTAトランザクションの決着が通知されました。JTAから渡される，トランザクションが決着したときの状態（ステータス）を示す文字列を出力します。状態を示す文字列の詳細については，Javadocの「javax.transaction.Status」を参照してください。

TRN [aa....aa] An EntityTransaction started.

aa....aa：永続化ユニット名

説明

EntityTransactionを開始しました。

TRN [aa....aa] An EntityTransaction was committed.

aa....aa：永続化ユニット名

説明

EntityTransactionをコミットしました。

TRN [aa....aa] An EntityTransaction was rolled back.

aa....aa：永続化ユニット名

説明

EntityTransactionをロールバックしました。

15.2　インプロセスHTTPサーバのログ取得の設定

ここでは，インプロセスHTTPサーバのログ取得で設定できる項目について説明します。

インプロセスHTTPサーバでは，アプリケーション開発のサポート，運用時の性能解析，および障害発生時のトラブルシューティングのために，アクセスログ，性能解析トレース，スレッドトレース，および通信トレースを出力します。これらのファイルでは，ファイル面数やファイルサイズを簡易構築定義ファイルで変更できます。

インプロセスHTTPサーバのログ取得で変更できる設定項目と，項目に対応する簡易構築定義ファイルのパラメタを次の表に示します。

表15‒1　インプロセスHTTPサーバのログ取得の設定項目

ログおよびトレース

項目

対応する簡易構築定義ファイルのパラメタ

アクセスログ

アクセスログの出力の有無

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.enabled

（デフォルトではアクセスログが出力されます）

アクセスログのファイル名

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.filename

アクセスログのファイルサイズ

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.filesize

アクセスログのファイル面数

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.filenum

アクセスログのフォーマット名

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.format_list※

アクセスログの出力形式

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.<フォーマット名>※

アクセスログ出力時のフォーマット

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.access_log.inprocess_http.usage_format※

性能解析トレース

−

ほかの性能解析トレースと同様に，日常的なシステム運用の作業で，cprfedコマンドを実行するときに取得条件などを指定します。性能解析トレースファイルの取得については，「14.　性能解析トレース」を参照してください。

スレッドトレース

スレッドトレースのファイル面数

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.thread_trace.inprocess_http.filenum

スレッドトレースのファイルサイズ

スレッドトレースのファイルサイズ＝（（（A+B）×32,786）＋32,914）バイト

A＝論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.max_connectionsパラメタの値

B＝論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.send_timeoutパラメタの値が0の場合0，0以外の場合1

通信トレース

通信トレースのファイル面数

論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.logger.communication_trace.inprocess_http.filenum

通信トレースのファイルサイズ

通信トレースのファイルサイズ＝（（（A+B）×172,050）＋128）バイト

A＝論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.max_connectionsパラメタの値

B＝論理J2EEサーバ（j2ee-server）の<configuration>タグ内のwebserver.connector.inprocess_http.send_timeoutパラメタの値が0の場合は0，0以外の場合は1

（凡例）−：該当しない

注※　アクセスログでは，これらのキーでフォーマットを定義することで，ログの出力形式をカスタマイズできます。インプロセスHTTPサーバのアクセスログのカスタマイズについては，「6.17.2　インプロセスHTTPサーバのアクセスログのカスタマイズ」を参照してください。

16　システム設計ガイド（V9互換モード）

この章では，J2EEアプリケーションを実行するシステムのパフォーマンスをチューニングする方法について説明します。

パフォーマンスチューニングによって動作環境を最適化することで，システムの性能を最大限に生かせるようになります。

バッチアプリケーション実行基盤のパフォーマンスチューニングについて検討する場合は，マニュアル「アプリケーションサーバ システム設計ガイド」の「9.　パフォーマンスチューニング（バッチアプリケーション実行基盤）」を参照してください。

16.1　パフォーマンスチューニングで考慮すること

この節では，J2EEアプリケーション実行基盤のパフォーマンスチューニングで考慮することについて説明します。

16.1.1　パフォーマンスチューニングの観点

J2EEアプリケーション実行基盤のパフォーマンスチューニングは，次の観点で実施します。

同時実行数の最適化

Enterprise Beanの呼び出し方法の最適化

データベースアクセス方法の最適化

タイムアウトの設定

Webアプリケーションの動作の最適化

CTMの動作の最適化

そのほかの項目のチューニング

それぞれのポイントについて説明します。

(1)　同時実行数の最適化

同時実行数の最適化は，処理を多重化してCPUの処理能力を最大限に引き出して，システムのスループットを向上させることを目的とします。しかし，次のような場合，多重化しただけではスループットが向上しません。場合によっては，スループットが低下するおそれがあります。

入出力処理，排他処理などのボトルネックがある場合

最大スループットに到達している場合

CPUの利用率が飽和した状態で多重度以上の負荷を掛けた場合

実行待ちキューのサイズが不適切な場合

階層的な最大実行数の設定が不適切な場合

パフォーマンスチューニングでは，これらを考慮しながら適切なチューニングを実施して，同時実行数の最適化を図ります。

(2)　Enterprise Beanの呼び出し方法の最適化

Enterprise Beanの呼び出し方法の最適化は，同じJ2EEアプリケーションや同じJ2EEサーバ内のコンポーネントを呼び出すときに，ローカルインタフェースやリモートインタフェースのローカル呼び出し機能を利用することで，不要なネットワークアクセスを削減することを目的とします。

次の機能を利用することで，RMI-IIOP通信によって発生する不要なネットワークアクセスを削減できます。

ローカルインタフェースの利用

リモートインタフェースのローカル呼び出し機能の利用

また，引数や戻り値の渡し方を参照渡しにすることで，さらに処理性能を向上できる場合があります。パフォーマンスチューニングでは，アプリケーションやシステムの特徴によってこれらの機能を有効に活用して，処理性能の向上を図ります。

(3)　データベースアクセス方法の最適化

データベースアクセス方法の最適化は，処理に時間が掛かるコネクションやステートメントを事前に生成しておくことで，データベースアクセス時のオーバーヘッドを削減することを目的とします。

パフォーマンスチューニングでは，次に示す機能を有効に活用することで，データベースアクセス処理を最適化し，スループットを向上させます。

コネクションプーリング

ステートメントプーリング（PreparedStatementおよびCallableStatementのプーリング）

(4)　タイムアウトの設定

タイムアウトの設定は，システムのトラブル発生を検知して，リクエストの応答が返らなくなることを防ぎ，適宜リソースを解放することを目的とします。

設定できるタイムアウトには，次の種類があります。

Webフロントシステムのタイムアウト

バックシステムのタイムアウト

トランザクションのタイムアウト

データベースのタイムアウト

(5)　Webアプリケーションの動作の最適化

Webアプリケーションの動作の最適化は，コンテンツの配置方法の検討やキャッシュの利用によって不要なネットワークアクセスを削減して処理速度を速めたり，負荷分散によってシステムのスループットの向上を図ったりすることを目的とします。

なお，Webサーバとして，リダイレクタモジュールを組み込んだWebサーバと連携する場合と，インプロセスHTTPサーバを使用している場合で，チューニングできる項目が異なります。

Webサーバと連携する場合には，次の処理ができます。

静的コンテンツとWebアプリケーションでの処理の振り分け

静的コンテンツのキャッシュ

セッション情報に応じたリクエストの振り分け

インプロセスHTTPサーバを使用する場合は，次の処理ができます。

静的コンテンツとWebアプリケーションの配置の切り分け

静的コンテンツのキャッシュ

(6)　CTMの動作の最適化

CTMの動作の最適化は，CTMで使用するプロセス間の通信間隔を最適化して通信負荷を軽減したり，トラブル発生時に迅速に検知して対処したりすることで，システムとしての性能を向上させることを目的とします。また，CTMによってリクエストの処理に優先順位を付けることで，重要なリクエストをすばやく処理するようにもチューニングできます。

(7)　そのほかの項目のチューニング

アプリケーションサーバでは，(1)〜(6)で説明した項目以外にも，チューニングできる項目があります。必要に応じてチューニングを実施してください。

16.1.2　アプリケーションの種類ごとにチューニングできる項目

チューニング項目は，アプリケーションの種類によって異なります。アプリケーションに含まれるコンポーネントごとのチューニング項目について，次に示します。

表16‒1　サーブレットとJSPで構成されるアプリケーション（Webアプリケーション）のチューニング項目

チューニング項目

利用できる機能

参照先

リクエスト処理スレッド数の最適化（インプロセスHTTPサーバを使用する場合）

リクエスト処理スレッド数の制御（インプロセスHTTPサーバを使用する場合）※

16.3.1

同時実行数の最適化

Webアプリケーションでの同時実行スレッド数制御（Webコンテナ単位，Webアプリケーション単位，またはURLグループ単位）

16.3.2

データベースアクセス方法の最適化

コネクションプーリング

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.5.1」

ステートメントプーリング

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.5.2」

タイムアウトの設定

Webフロントシステムでのタイムアウトの設定

16.4.2

J2EEアプリケーションのメソッド実行時間に対するタイムアウトの設定

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.7」

Webアプリケーションの動作の最適化

静的コンテンツとWebアプリケーションの配置の切り分け

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.7.1」

静的コンテンツのキャッシュ

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.7.2」

リダイレクタによるリクエストの振り分け（Webサーバ連携の場合）

5.2

そのほかの項目のチューニング

Persistent Connectionの制御（インプロセスHTTPサーバを使用する場合）

16.6

注※　Webサーバと連携する場合は，Webサーバの機能を使用してチューニングしてください。

表16‒2　Enterprise Beanで構成されるアプリケーションのチューニング項目

チューニング項目

利用できる機能

参照先

同時実行数の最適化

Stateless Session Beanのインスタンスプーリング

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.3.5」

Stateful Session Beanのセッション制御

Message-driven Beanのインスタンスプーリング

CTMによる同時実行数制御※（CTMを使用している場合）

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.3.6」

Enterprise Beanの呼び出し方法の最適化

ローカルインタフェースの使用

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.4.1」

リモートインタフェースのローカル呼び出し最適化

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.4.2」

リモートインタフェースの参照渡し

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.4.3」

データベースアクセス方法の最適化

コネクションプーリング

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.5.1」

ステートメントプーリング

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.5.2」

タイムアウトの設定

バックシステムでのタイムアウトの設定

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.3」

トランザクションタイムアウトの設定

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.4」

データベースでのタイムアウトの設定

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.6」

J2EEアプリケーションのメソッド実行時間に対するタイムアウトの設定

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.7」

注※　Stateless Session Beanだけが対象です。

また，CTMを使用したシステムの場合に設定できる，CTMの動作のチューニング項目を次の表に示します。CTMは，アプリケーションがStateless Session Beanで構成されている場合に使用できます。

表16‒3　CTMの動作についてのチューニング項目

チューニング項目

利用できる機能

参照先

CTMの動作の最適化

CTMドメインマネジャおよびCTMデーモンの稼働状態を監視する間隔のチューニング

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.8.1」

負荷状況監視間隔のチューニング

「アプリケーションサーバ システム設計ガイド」の「8.8.2」

CTMデーモンのタイムアウト閉塞の設定

「アプリケーションサーバ システム設計ガイド」の「8.8.3」

CTMで振り分けるリクエストの優先順位の設定

「アプリケーションサーバ システム設計ガイド」の「8.8.4」

16.2　チューニングの方法

この節では，チューニングの方法について説明します。チューニングの方法は，設定対象の種類によって異なります。

16.2.1　J2EEサーバおよびWebサーバ（リダイレクタを含む）のチューニング

J2EEサーバおよびWebサーバ（リダイレクタを含む）のチューニングには，Smart Composer機能の簡易構築定義ファイルを使用します。簡易構築定義ファイルでは，<configuration>タグ下の<logical-server-type>に設定対象とする論理サーバの種類（J2EEサーバまたはWebサーバ）を指定して，<param>タグ下でパラメタ名とその値を設定します。簡易構築定義ファイルの詳細については，マニュアル「アプリケーションサーバリファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

参考

Smart Composer機能を使用できない場合，Webサーバ（リダイレクタを含む）のチューニングはファイルを編集して定義します。

Smart Composer機能を使用できない場合に，Webサーバ（リダイレクタを含む）のチューニングに使用するファイルについて，次の表に示します。

表16‒4　Smart Composer機能を使用できない場合にWebサーバ（リダイレクタを含む）のチューニングに使用するファイル

対象

チューニング方法

Webサーバ

httpsd.confの編集

Webサーバ（リダイレクタ）

mod_jk.conf（HTTP Serverの場合）の編集

isapi_redirect.conf（Microsoft IISの場合）の編集

workers.properties（ワーカの設定の場合）の編集

mod_jk.confの詳細については，「13.2.2　mod_jk.conf（HTTP Server用リダイレクタ動作定義ファイル）」を参照してください。isapi_redirect.confの詳細については，「13.2.1　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。workers.propertiesの詳細については，「13.2.4　workers.properties（ワーカ定義ファイル）」を参照してください。httpsd.confの詳細については，マニュアル「HTTP Server」を参照してください。

16.3　同時実行数を最適化する

この節では，アプリケーションのリクエストの同時実行数を最適化するための考え方とチューニング方法について説明します。

16.3.1　Webサーバでのリクエスト処理スレッド数を制御する

Webフロントシステムの場合，Webブラウザなどのクライアントからのリクエストは，Webサーバが作成するリクエスト処理スレッドによって処理されます。リクエスト処理スレッド数を適切に制御することで，処理性能の向上が図れます。

ここでは，Webサーバでのリクエスト処理スレッド数を制御する目的と，チューニングの指針について説明します。

なお，ここでは，インプロセスHTTPサーバを使用している場合のチューニングの方法について説明します。

参考

Webサーバ連携時にHTTP Serverを使用している場合は，HTTP Serverの設定で同様のチューニングができます。詳細は，マニュアル「HTTP Server」を参照してください。

また，Smart Composer機能を使用してシステムを構築する場合，Webサーバでのリクエスト処理スレッド数の設定は，抽象パラメタの利用によって設定できます。抽象パラメタとは，互いに関連のあるパラメタを一つにまとめたパラメタです。抽象パラメタを利用することで，Webサーバのリクエスト処理スレッド数の設定を，同時実行スレッド数などの関連するパラメタと一緒に定義できます。抽象パラメタについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「付録I　Smart Composer機能で使用できる抽象パラメタ（V9互換モードの場合）」を参照してください。

(1)　リクエスト処理スレッド数を制御する目的

リクエスト処理スレッド数をJ2EEサーバが動作しているホストの性能やクライアントからのアクセス状況に合わせてチューニングすることで，性能向上を図れます。

リクエスト処理スレッドの生成は，負荷が高い処理です。リクエスト処理スレッドをあらかじめ生成してプールしておくことで，Webブラウザなどのクライアントからのリクエスト処理要求時の負荷を軽くして，処理性能を高めることができます。

インプロセスHTTPサーバを使用する場合，J2EEサーバ起動時にリクエスト処理スレッドをまとめて生成してプールしておき，Webブラウザなどのクライアントからリクエスト処理要求があった場合にそれを利用するようにできます。これによって，リクエスト処理要求時の処理性能の向上を図れます。なお，プールしているスレッドの数を監視しておくことで，プールしているスレッド数が少なくなった場合はさらに追加生成して，プールに確保しておくこともできます。

ただし，使用しないスレッドを大量にプールしておくと，むだなリソースを消費します。このため，システムの処理内容に応じて，プールするリクエスト処理スレッド数を適切に制御し，場合によっては不要なスレッドを削除することが必要です。

リクエスト処理スレッドの制御では，これらを考慮して，パラメタに適切な値を設定してください。

(2)　設定の指針

リクエスト処理スレッド数の制御では，次のパラメタを使用してチューニングできます。

J2EEサーバ起動時に生成するリクエスト処理スレッドの数

Webクライアントとの接続数（リクエスト処理スレッド数）の上限数

接続数の上限を超えた場合のTCP/IPのListenキュー（バックログ）の最大値

予備スレッド数の最大数および最小数

J2EEサーバ起動時に生成したリクエスト処理スレッド数を維持するかどうかの選択

これらのパラメタを設定するときには，次の点に留意してください。

提供するサービスの内容によっては，J2EEサーバ起動直後から大量のリクエストを処理する必要があります。この場合は，J2EEサーバ起動時に生成するリクエスト処理スレッドの数に，大きな値を指定してください。

予備スレッド数の最大数を大きくしておくと，クライアントからのアクセスが急に増加した場合にも，処理性能を下げることなく迅速に対応できます。ただし，多くの予備スレッドをプールしておくと，多くのリソースが消費されます。このため，急な増加が予想されるアクセス数を見積もって，適切な数の予備スレッドがプールされるように，注意して設定してください。

一定数のリクエスト処理スレッドは確保した状態で，それを超えるリクエスト処理スレッドの増減を最大数と最小数を指定して制御したい場合は，J2EEサーバ起動時に生成したリクエスト処理スレッド数を維持する設定にしてください。これによって，システムとして最低確保しておきたい数のリクエスト処理スレッドを確保した状態で，クライアントからのアクセスピーク時のリクエスト処理スレッド数の増減に対応できます。未使用のリクエスト処理スレッド数が予備スレッド数の最大値を超えている場合も，J2EEサーバ起動時に生成した数のリクエスト処理スレッドは維持されます。

一度作成したスレッドを削除しないでプールし続けたい場合は，予備スレッド数の最大数を，Webクライアントとの最大接続数と同じ値にしてください。

このほか，Webアプリケーションの同時実行スレッド数との関係についても留意してください。Webアプリケーションの同時実行スレッド数については，「16.3.2　Webアプリケーションの同時実行数を制御する」を参照してください。

16.3.2　Webアプリケーションの同時実行数を制御する

Webアプリケーションの同時実行数制御では，Webフロントシステムの場合に，WebサーバがWebブラウザなどのクライアントから受け付けたリクエストの処理を，同時に幾つのスレッドで実行するかを制御します。

同時実行スレッド数は，URLグループ単位，Webアプリケーション単位，またはWebコンテナ単位で制御できます。同時実行スレッド数は，Webサーバ連携の場合，インプロセスHTTPサーバを使用する場合，どちらの場合も制御できます。

(1)　同時実行スレッド数制御の違い

Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数制御の違いは次のとおりです。

Webコンテナ単位

Webコンテナ全体で同時にリクエストを処理するスレッド数を設定できます。

Webアプリケーション単位

Webコンテナ上で動作するWebアプリケーションごとに，同時にリクエストを処理するスレッド数を設定できます。

URLグループ単位

リクエストをWebアプリケーション内の特定の業務処理（業務ロジック）に対応するURLに振り分ける場合，振り分け先URLの処理ごとに，同時にリクエストを処理するスレッド数を設定できます。

Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数の関係を次の図に示します。

図16‒1　Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位の同時実行スレッド数の関係

注意事項

Webコンテナ単位の最大同時実行スレッド数の制御は，Webアプリケーション単位での同時実行スレッド数の制御を無効にした場合だけ有効になります。

Webアプリケーション単位での同時実行スレッド数の制御を有効にする場合，Webコンテナ単位の最大同時実行スレッド数のチェックは，Webアプリケーション単位での同時実行スレッド数制御で実施されます。詳細はマニュアル「アプリケーションサーバ 機能解説基本・開発編(Webコンテナ)」の「2.15.6　同時実行スレッド数および実行待ちキューサイズの設定例（Webアプリケーション単位）」を参照してください。

Webアプリケーションに対するリクエストの実行は，Webコンテナ単位，Webアプリケーション単位，およびURLグループ単位に設定した同時実行スレッド数に制限されます。Webコンテナ単位，Webアプリケーション単位およびURLグループ単位に設定した同時実行スレッド数を超えるリクエストは，それぞれの実行待ちキューに入ります。

(2)　選択の指針

同時実行スレッド数制御の単位を選択するときの指針について説明します。

なお，同時実行スレッド数を制御する機能の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.13　同時実行スレッド数の制御の概要」を参照してください。

Webアプリケーション単位の選択の指針

Webアプリケーション単位の同時実行数を制御することで，J2EEサーバがTCP接続要求だけではなく，Webアプリケーションの実行待ちキューを管理できるようになります。このため，J2EEサーバ上で実行するWebアプリケーションが一つだけの場合でも，Webアプリケーション単位の同時実行スレッド数を設定することをお勧めします。

Webアプリケーション単位での同時実行スレッド数の設定は，Webコンテナ単位で設定する場合に比べて，次のような利点があります。

Webアプリケーションごとの同時実行スレッド数に上限を設けることで，特定の業務に対応するWebアプリケーションへのリクエストが増大した場合に，そのWebアプリケーションがWebコンテナ全体の処理能力を占有しないようにできます。これによって，ほかの業務も滞りなく実行できます。

CPUやI／O処理に掛かる負荷が異なる複数のWebアプリケーションがWebコンテナ上にある場合，それぞれの条件に適した同時実行スレッド数が設定できます。

Webアプリケーションごとにリクエストの実行待ちキューサイズが設定できるので，Webアプリケーションの特徴に応じた実行待ちキュー管理ができます。また，Webアプリケーション単位の実行待ちキュー以上のリクエストが送信された場合には，クライアントにHTTPレスポンスコードで通知できます。

なお，Webアプリケーション単位の同時実行スレッド数は，稼働中のJ2EEサーバでも動的に変更できます。稼働中のJ2EEサーバで実行するWebアプリケーションの同時実行スレッド数の動的変更の手順については，マニュアル「アプリケーションサーバ 機能解説基本・開発編(Webコンテナ)」の「2.17.2　同時実行スレッド数の動的変更の流れ」を参照してください。

URLグループ単位の選択の指針

Webアプリケーション単位で同時実行スレッド数を制御している場合に，さらに業務ロジック単位で同時実行スレッド数の制御をしたいときには，URLグループ単位で同時実行スレッド数を制御します。

Webアプリケーションが次のような業務ロジックを含む場合，URLグループ単位の設定を検討してください。

ほかの処理に影響を受けないで優先して実行したい業務ロジック

ほかの処理に比べて処理時間が掛かる，またはCPUやI／Oの負荷が大きい業務ロジック

URLグループ単位での同時実行スレッド数の設定は，Webアプリケーション単位だけの設定に比べて，次のような利点があります。

重要度が高い業務ロジック（URLグループ）には，確実に実行するためのスレッド数を割り当てられます。これによって，ほかの業務ロジックに対するリクエスト数が増大した場合も，Webアプリケーション全体の同時実行スレッド数をその業務ロジックに占有されないで，重要度が高い業務ロジックを実行できます。

処理時間が掛かる業務ロジック（URLグループ）の同時実行数に上限を設けることで，特定の業務ロジックによってWebアプリケーション全体の同時実行数が占有されないように制御できます。

Webアプリケーション内にCPUやI／Oの負荷が異なる複数の業務ロジック（URLグループ）がある場合は，業務ロジックに応じた同時実行数が設定できます。

Webアプリケーション内の業務ロジック（URLグループ）ごとにリクエストの待ち行列長（実行待ちキューのキューサイズ）が設定できるので，業務ロジックの特徴に応じた実行待ちキューを管理できます。また，このURLグループ単位の実行待ちキューがあふれた場合，クライアントにHTTPレスポンスコード503（Service Temporarily Unavailable）を通知できます。

16.4　タイムアウトを設定する

アプリケーションサーバのシステムでは，トラブル発生時にリクエストの応答が戻ってこない状態になることを防ぐために，幾つかのポイントにタイムアウトを設定できます。

この節では，システム全体でタイムアウトが設定できるポイントと，設定する場合の指針について説明します。

参考

TP1インバウンド連携機能を使用してOpenTP1からアプリケーションサーバを呼び出す場合，この節で説明する内容のほか，OpenTP1側の設定を考慮したタイムアウトの設定が必要です。詳細は，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「4.　OpenTP1からのアプリケーションサーバの呼び出し（TP1インバウンド連携機能）」を参照してください。

16.4.1　タイムアウトが設定できるポイント

J2EEアプリケーションを実行するシステムでは，次の図に示すポイントにタイムアウトが設定できます。なお，次の図は，クライアントがWebブラウザの場合です。また，Webサーバ連携をする場合とインプロセスHTTPサーバを使用する場合で，ポイントが異なります。

図16‒2　タイムアウトが設定できるポイント（Webサーバ連携の場合）

なお，クライアントがEJBクライアントの場合は，WebコンテナをEJBクライアントに置き換えてください。EJBクライアントからデータベースまでの範囲のタイムアウトが設定できます。

また，インプロセスHTTPサーバを使用する場合は，リダイレクタは該当しません。このため，タイムアウトを設定するポイントとして，ポイント2〜5と13は該当しません。インプロセスHTTPサーバを使用する場合にタイムアウトが設定できるポイントについて，次の図に示します。

図16‒3　タイムアウトが設定できるポイント（インプロセスHTTPサーバの場合）

それぞれのポイントに設定するタイムアウトは，次の表に示すような用途で使い分けられます。

表16‒5　各ポイントに設定するタイムアウトの目的とデフォルトのタイムアウト設定

ポイント

タイムアウトの種類

主な用途

1

サーバ側で設定するクライアントからのリクエスト受信およびクライアントへのデータ送信のタイムアウト

Webサーバ連携の場合

通信路の障害，またはWebサーバの障害の検知

インプロセスHTTPサーバの場合

通信路の障害，または不正なクライアントからのアクセスの検知

2

リダイレクタ側で設定するWebコンテナへのリクエスト送信処理のうち，コネクション確立のタイムアウト

通信路の障害またはWebコンテナの障害検知

3

リダイレクタ側で設定するWebコンテナへのリクエスト送信処理のうち，リクエストヘッダおよびリクエストボディ送信のタイムアウト

通信路の障害またはWebコンテナの障害検知

4

リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

5

Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト

通信路の障害またはWebサーバの障害検知

6

Webアプリケーションで設定するメソッドの実行時間のタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど）

7

EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIネーミングサービス呼び出しのタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

8※

EJBクライアント側で設定するCTMからのEnterprise Bean呼び出しのタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど），または通信路の障害の検知

9

EJBで設定するメソッドの実行時間のタイムアウト

J2EEサーバの業務処理の障害（無限ループ，デッドロックなど）

10

EJBコンテナ側で設定するデータベースのトランザクションタイムアウト

データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

11

DB Connectorで設定するコネクション取得時のタイムアウト

コネクション取得時の障害検知（通信路の障害またはリソース枯渇）

12

データベースのタイムアウト

データベースサーバの障害（サーバダウンまたはデッドロックなど）の検知，またはリソースの長時間占有防止

13

Webコンテナ側で設定するリダイレクタへのレスポンス送信のタイムアウト

通信路の障害またはリダイレクタの障害検知

注※　CTMを使用している場合にだけ存在するポイントです。CTMを利用しない構成の場合，ポイント7の範囲はWebコンテナからEJBコンテナにEJBリモート呼び出しを実行してから，EJBコンテナからWebコンテナに実行結果が送信されるまでの間になります。

これらのタイムアウトの基本的な設定指針は次のとおりです。

タイムアウト値の設定は，呼び出し元（WebクライアントまたはEJBクライアント）に近いほど大きな値を設定するのが原則です。このため，次の関係で設定することを推奨します。

ポイント1<ポイント5

ポイント4>ポイント6>ポイント7

ポイント7=ポイント8>ポイント9>ポイント10

ポイント10>ポイント11

ポイント9>ポイント12

ポイント1<ポイント13

4，7，10，12のポイントのタイムアウト値を設定する場合は，呼び出し処理に通常どの程度の時間が掛かっているかを見極めた上で，呼び出す処理（業務）ごとに算出して設定してください。

なお，1〜13のポイントは，システムでの位置づけによって，次の三つに分けられます。

Webフロントシステムで意識する必要があるポイント（1〜6，および13）

詳細は，「16.4.2　Webフロントシステムでのタイムアウトを設定する」を参照してください。

バックシステムで意識する必要があるポイント（7〜9）

詳細は，マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.3　バックシステムでのタイムアウトを設定する」を参照してください。

データベース接続時に意識する必要があるポイント（10〜12）

このポイントは，さらにトランザクションでのタイムアウト，DB Connectorでのタイムアウト，およびデータベースでのタイムアウトに分けて意識する必要があります。

詳細は，マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.4　トランザクションタイムアウトを設定する」，「8.6.6　データベースでのタイムアウトを設定する」を参照してください。

それぞれのポイントでの設定については，「16.4.3　タイムアウトを設定するチューニングパラメタ」，またはマニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.8　タイムアウトを設定するチューニングパラメタ」を参照してください。

参考

それぞれのポイントのデフォルト値は次のとおりです。

ポイント

デフォルト値

1

300秒

2

30秒

3

100秒

4

3,600秒

5

600秒

6

設定されていません。タイムアウトしません。

7

設定されていません。レスポンスを待ち続けます。

8

ポイント7と同じ値がEnterprise Bean呼び出し時に自動的に引き継がれて設定されます。

9

設定されていません。タイムアウトしません。

10

180秒

11

タイムアウトの設定個所ごとに異なります。

物理コネクション確立時のタイムアウト：8秒

コネクション枯渇時のコネクション取得要求のタイムアウト：30秒

コネクション障害検知時のタイムアウト：5秒

12

データベースの種類とタイムアウトの設定個所ごとに異なります。

HiRDBの場合

ロック解放待ちタイムアウト：180秒

レスポンスタイムアウト：0秒（HiRDBクライアントはHiRDBサーバからの応答があるまで待ち続けます）

リクエスト間隔タイムアウト：600秒

Oracleの場合（グローバルトランザクションを使用するとき）

ロック解放待ちタイムアウト：60秒

SQL Serverの場合

メモリ取得待ちタイムアウト：-1（-1を指定した場合の動作は，SQL Serverのドキュメントを参照してください）

ロック解放待ちタイムアウト：-1（ロックが解放されるまで待ち続けます）

XDM/RD E2の場合

ロック解放待ちタイムアウト：なし（タイムアウト時間を監視しません）

SQL実行CPU時間タイムアウト：10秒

SQL実行経過時間タイムアウト：0秒（タイムアウト時間を監視しません）

トランザクション経過時間タイムアウト：600秒

レスポンスタイムアウト：0秒（HiRDBクライアントはXDM/RD E2サーバからの応答があるまで待ち続けます）

13

600秒

16.4.2　Webフロントシステムでのタイムアウトを設定する

ここでは，Webフロントシステムでのタイムアウトの設定について説明します。

Webフロントシステムのタイムアウトを設定する場合は，システム全体のタイムアウトのうち，次の図に示す，1〜6および13のポイントについて意識する必要があります。この番号は，図16-2または図16-3と対応しています。

ポイント

インプロセスHTTPサーバを使用する場合，設定できるのは1と6のポイントです。2〜5，および13のポイントは該当しません。

図16‒4　Webフロントシステムの場合に意識するタイムアウトのポイント（1〜6，および13のポイント）

Webサーバでのクライアントからのリクエスト受信，およびクライアントへのデータ送信待ち時間（1のポイント）

Webブラウザからの要求が滞った場合に，タイムアウトによってリダイレクタのリソースを解放します。また，Webブラウザへの応答が滞った場合（Webブラウザが受信しない場合）に，タイムアウトによってリダイレクタおよびJ2EEサーバ内のWebコンテナのリソースを解放します。

Webサーバ連携の場合，これらの待ち時間には，同じ値が設定されます。

インプロセスHTTPサーバを使用する場合，クライアントからのリクエスト受信待ち時間と，クライアントへのデータ送信待ち時間には，それぞれ異なる値を指定できます。

Webサーバに登録したリダイレクタでのWebコンテナへのリクエスト送信待ち時間（2および3のポイント）

リダイレクタからWebコンテナへのリクエスト送信時に，Webコンテナ自体のトラブル，またはリダイレクタとWebコンテナ間の通信路でのトラブルによって制御が戻らなくなった場合に，タイムアウトによってリダイレクタのリソースを解放します。また，同時にWebブラウザにエラーを通知します。Webサーバと連携する場合にだけ設定できるポイントです。

ポイント2はWebコンテナとのコネクション確立の待ち時間，ポイント3はWebコンテナへのリクエスト送信処理の待ち時間です。

Webサーバに登録したリダイレクタでのWebコンテナからのデータ受信待ち時間（4のポイント）

J2EEアプリケーションで何かのトラブルが発生して制御が戻らなくなった場合に，タイムアウトによってリダイレクタのリソースを解放します。また，同時にWebブラウザにエラーを通知します。Webサーバと連携する場合にだけ設定できるポイントです。

ポイント

設定の単位はワーカです。このため，業務によって処理に掛かる時間が異なる場合は，業務に対応するWebアプリケーション単位でワーカを定義してタイムアウトを設定することをお勧めします。

Webコンテナでのリダイレクタからのデータ受信待ち時間（5のポイント）

ブラウザからの要求が滞ったときに，J2EEサーバ（Webコンテナ）のリソースを解放します。Webサーバと連携する場合にだけ設定できるポイントです。

Webコンテナ上でのリクエスト処理待ち時間（6のポイント）

J2EEアプリケーションの実行時間監視機能を利用します。

マニュアル「アプリケーションサーバ システム設計ガイド」の「8.6.7　J2EEアプリケーションのメソッドタイムアウトを設定する」を参照してください。

Webコンテナからリダイレクタへのレスポンス送信待ち時間（13のポイント）

Webコンテナからリダイレクタへのレスポンス送信時に，リダイレクタ自体のトラブル，またはリダイレクタとWebコンテナ間の通信路でのトラブルによって制御が戻らなくなった場合に，タイムアウトによってWebコンテナのリソースを解放します。また，同時にWebブラウザにエラーを通知します。Webサーバと連携する場合にだけ設定できるポイントです。

16.4.3　タイムアウトを設定するチューニングパラメタ

ここでは，タイムアウトの設定で使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

図16-2または図16-3のポイント1のタイムアウトを設定するチューニングパラメタです。使用するWebサーバによって設定個所が異なります。

Webサーバ連携の場合は，Webサーバ単位に設定します。ファイル編集によって設定します。

表16‒6　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウトのチューニングパラメタ（Webサーバ連携の場合）

設定項目

設定個所

クライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

httpsd.confのTimeoutディレクティブ

注　WebサーバとしてMicrosoft IISを使用しているときには，isapi_redirect.confのreceive_client_timeoutキーを編集してください。

インプロセスHTTPサーバの場合は，J2EEサーバ単位に設定します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表16‒7　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウトのチューニングパラメタ（インプロセスHTTPサーバの場合）

設定項目

設定対象

設定個所（パラメタ名）

クライアントからのリクエスト受信のタイムアウト

論理J2EEサーバ（j2ee-server）

webserver.connector.inprocess_http.receive_timeout

クライアントへのデータ送信のタイムアウト

論理J2EEサーバ（j2ee-server）

webserver.connector.inprocess_http.send_timeout

(2)　リダイレクタ側で設定するWebコンテナへのデータ送信のタイムアウト

図16-2のポイント2，およびポイント3のタイムアウトを設定するチューニングパラメタです。リダイレクタ側で設定するタイムアウトのチューニングパラメタについて説明します。なお，これらのチューニングパラメタは，Webサーバ連携の場合だけ指定できます。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表16‒8　リダイレクタ側で設定するタイムアウトのチューニングパラメタ

ポイント

設定項目

設定対象

設定個所（パラメタ名）※

2

リクエスト送信時のWebコンテナに対するコネクション確立のタイムアウト

論理Webサーバ（web-server）

JkConnectTimeout

3

リクエスト送信のタイムアウト

論理Webサーバ（web-server）

JkSendTimeout

注※　WebサーバとしてMicrosoft IISを使用しているときには，isapi_redirect.confのconnect_timeoutキーを編集してください。

(3)　リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト

図16-2のポイント4のタイムアウトを設定するチューニングパラメタです。

リダイレクタのワーカ定義単位で設定します。リダイレクタ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表16‒9　リダイレクタ側で設定するタイムアウトのチューニングパラメタ

設定項目

設定対象

設定個所（パラメタ名）

レスポンスデータ待ちの通信タイムアウト

論理Webサーバ（web-server）

worker.<ワーカ名>.receive_timeout

Webサーバ連携の場合だけ指定できます。

(4)　Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト

図16-2のポイント5のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表16‒10　Webコンテナ側で設定するタイムアウトのチューニングパラメタ

設定項目

設定対象

設定個所（パラメタ名）

リダイレクタからの応答待ちのタイムアウト

論理J2EEサーバ（j2ee-server）

webserver.connector.ajp13.receive_timeout

Webサーバ連携の場合だけ指定できます。

(5)　Webコンテナ側で設定するリダイレクタへのデータ受信のタイムアウト

図16-2のポイント13のタイムアウトを設定するチューニングパラメタです。

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタについて説明します。

次の表に示す項目は，Smart Composer機能で設定します。パラメタは，簡易構築定義ファイルに定義します。

表16‒11　Webコンテナ側で設定するタイムアウトのチューニングパラメタ

設定項目

設定対象

パラメタ名

レスポンス送信処理のタイムアウト

論理J2EEサーバ（j2ee-server）

webserver.connector.ajp13.send_timeout

Webサーバ連携の場合だけ指定できます。

16.5　Webアプリケーションの動作を最適化する

この節では，Webアプリケーションのパフォーマンスチューニングの方法について説明します。Webフロントシステムの場合に検討してください。

ここでは，次の3種類のチューニング方法について説明します。

静的コンテンツとWebアプリケーションの配置を切り分ける

静的コンテンツをキャッシュする

リダイレクタを使用してリクエストを振り分ける（Webサーバ連携の場合）

16.5.1　Webアプリケーションの動作を最適化するためのチューニングパラメタ

ここでは，Webアプリケーションの動作を最適化するために使用するチューニングパラメタの設定方法についてまとめて示します。

(1)　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

静的コンテンツとWebアプリケーションの配置の切り分けは，Webサーバの動作を定義するファイルのパラメタとして指定します。設定個所，ファイルおよびパラメタは，使用するWebサーバの種類によって異なります。

Webサーバ連携でHTTP Serverを使用している場合は，リダイレクタモジュールを使用して切り分けます。インプロセスHTTPサーバを使用している場合は，リバースプロキシサーバ（HTTP Server）に配置しているリバースプロキシモジュールを使用して切り分けます。

設定方法および設定個所を次に示します。

表16‒12　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

使用するWebサーバ

設定方法

設定個所

HTTP Server

（リダイレクタモジュールを使用した切り分け※1）

Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理Webサーバ（web-server)

パラメタ名

JkMount

インプロセスHTTPサーバ

（リバースプロキシモジュールを使用した切り分け）

ファイル編集

定義ファイル

httpsd.conf

設定対象

リバースプロキシサーバ

パラメタ名

ProxyPassディレクティブ※2

注※1　WebサーバとしてMicrosoft IISを使用しているときは，uriworkermap.propertiesで設定します。

注※2　httpsd.confの詳細については，マニュアル「HTTP Server」を参照してください。

(2)　静的コンテンツをキャッシュするためのチューニングパラメタ

静的コンテンツをキャッシュするためのチューニングパラメタについて説明します。これらのチューニングパラメタは，Webコンテナ単位またはWebアプリケーション単位に設定します。

Webコンテナ単位に設定するチューニングパラメタの設定方法について，次の表に示します。これらの項目は，Smart Composer機能で設定します。

表16‒13　静的コンテンツをキャッシュするためのチューニングパラメタ（Webコンテナ単位で設定する項目）

設定項目

設定個所

静的コンテンツのキャッシュを使用するかどうかの選択

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.enabled

Webアプリケーション単位のメモリサイズの上限値の設定

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.size

キャッシュする静的コンテンツのファイルサイズの上限値の設定

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.static_content.cache.filesize.threshold

Webアプリケーション単位に設定するチューニングパラメタについて示します。Webアプリケーション単位に設定する項目は，web.xmlを直接編集するか，サーバ管理コマンドを使用して設定します。デプロイ前のWebアプリケーションに設定する場合は，web.xmlを編集してください。デプロイ後のWebアプリケーションに設定する場合は，サーバ管理コマンド（cjsetappprop）を使用してください。

設定内容を次の表に示します。

表16‒14　静的コンテンツをキャッシュするためのチューニングパラメタ（Webアプリケーション単位で設定する項目）

設定項目

設定内容※

静的コンテンツのキャッシュを使用するかどうかの選択

<param-name>タグ

com.hitachi.software.web.static_content.cache.enabled

<param-value>タグ

（設定値）

Webアプリケーション単位のメモリサイズの上限値の設定

<param-name>タグ

com.hitachi.software.web.static_content.cache.size

<param-value>タグ

（設定値）

キャッシュする静的コンテンツのファイルサイズの上限値の設定

<param-name>タグ

com.hitachi.software.web.static_content.cache.filesize.threshold

<param-value>タグ

（設定値）

注

（設定値）に設定できる値の詳細については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.19.2　DDでの定義（Webアプリケーション単位での設定）」を参照してください。

注※

web.xmlを直接編集する場合，<web-app>タグ内に<context-param>タグを追加して，<context-param>タグ内に<param-name>タグおよび<param-value>タグを追加します。

サーバ管理コマンドを使用する場合，WAR属性ファイルの<hitachi-war-property>タグ内に<context-param>タグを追加して，<context-param>タグ内に<param-name>タグおよび<param-value>タグを追加します。

(3)　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ

リダイレクタによってリクエストを振り分けるためのチューニングパラメタは，Webサーバの動作を定義するファイルのパラメタとして指定します。

なお，この定義は，Webサーバ連携の場合だけできます。インプロセスHTTPサーバを使用している場合は定義できません。

設定方法および設定個所を次に示します。

表16‒15　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ

設定項目

設定方法

設定個所

URLパターンのマッピング定義※

Smart Composer機能

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

JkMount

注※　WebサーバとしてMicrosoft IISを使用しているときは，uriworkermap.propertiesで設定します。

16.6　そのほかの項目のチューニング

ここでは，前の節までに説明した項目以外のチューニング項目について説明します。

ここで説明するのは，次の項目です。

Persistent Connectionについてのチューニング

この項目は，Webフロントシステムの場合で，インプロセスHTTPサーバを使用するときにチューニングを検討してください。

HTTP/1.1では，WebクライアントとWebサーバ間で確立したTCPコネクションを持続して，複数のHTTPリクエスト間で使用し続けるためのPersistent Connectionが定義されています。Persistent Connectionを使用することによって，WebクライアントとWebサーバ間でコネクション接続に掛かる時間を短縮し，通信トラフィックを軽減できます。

ただし，Persistent Connectionを使用すると，特定のWebクライアントがリクエスト処理スレッドを占有することになるため，サーバ全体の処理性能が低下することがあります。このため，Persistent Connectionを有効に活用し，かつサーバ処理性能を維持できるようにチューニングする必要があります。

インプロセスHTTPサーバを使用する場合，Persistent Connectionについて，次の項目がチューニングできます。

Persistent Connection数の上限値

この上限値を超えるTCPコネクションについては，リクエスト処理終了後に切断されます。これによって，新規接続を処理するスレッドが確保でき，リクエスト処理スレッドを特定のクライアントに占有されることを防げます。

Persistent Connectionのリクエスト処理回数の上限値

同じWebクライアントから連続してリクエスト要求があった場合も，この上限値を超えると，リクエスト処理終了後に一度TCPコネクションが切断されます。

これによってリクエスト処理スレッドを特定のクライアントに占有され続けることを防げます。

Persistent Connectionのタイムアウト

Persistent Connectionのリクエスト待ち時間にタイムアウトを設定できます。指定したタイムアウト時間を超えてリクエスト処理要求がない場合は，TCPコネクションが切断されます。これによって，使用されていない状態でTCPコネクションが占有され続けることを防げます。

これらの項目は，Smart Composer機能で使用する簡易構築定義ファイルのパラメタとして指定します。Persistent Connectionについて設定するチューニングパラメタについて次の表に示します。

表16‒16　Persistent Connectionについて設定するチューニングパラメタ

設定項目

設定個所

Persistent Connection数の上限値

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.connector.inprocess_http.persistent_connection.max_connections

リクエスト処理回数の上限値

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.connector.inprocess_http.persistent_connection.max_requests

タイムアウト

定義ファイル

簡易構築定義ファイル

設定対象

論理J2EEサーバ（j2ee-server）

パラメタ名

webserver.connector.inprocess_http.persistent_connection.timeout

なお，各パラメタの詳細については，「11.2　論理J2EEサーバで指定できるパラメタ」を参照してください。

16.7　アプリケーションサーバが使用するTCP/UDPのポート番号

デフォルト値が「（浮動）」のポートは，ポート番号を明示的に固定しない場合にアプリケーションサーバによって自動的に番号が付けられるポートです。

アプリケーションサーバが使用するTCP/UDPのポート番号の説明を次の表に示します。なお，ご使用のOSによっては，ネットワーク単位ではなくホスト単位でファイアウォールが設定されているものがあります。これらのファイアウォールでは，localhost（127.0.0.1）以外との通信は，同一ホスト内でもファイアウォールのフィルタリングの対象になる場合があります。この場合は，ホスト内でしか通信しないポートであっても，フィルタで通信を許可する設定にしてください。

表16‒17　アプリケーションサーバが使用するTCP/UDPのポート番号

項番

プロセス

説明

デフォルト値

(1)

J2EEサーバ

EJBコンテナのリクエスト受付ポート。

（浮動）

(2)

管理用通信ポート。

28008

(3)

Webサーバ（リダイレクタ）からのリクエスト受付ポート。

8007

(4)

トランザクションサービス使用時のトランザクションリカバリ処理通信ポート。

トランザクションサービス使用時に必要です。

20302

(5)

インプロセスで起動するネーミングサービスのリクエスト受付ポート。

900

(6)

インプロセスHTTPサーバのリクエスト受付ポート。

インプロセスHTTPサーバを使用するときに必要です。

80

(7)

RMIレジストリのリクエスト受付ポート。

23152

(8)

共有キューを使用して複数システム間でのアプリケーション連携をする場合のイベント受信用ポート。

20351

(9)

稼働情報取得時のリクエスト受付ポート。

23550

(10)

OpenTP1からのRPC要求を待ち受けるポート。

23700

(11)

OpenTP1からの同期点要求を待ち受けるポート。

23900

(12)

運用監視エージェント

運用監視エージェントの通信用ポート。

（浮動）

(13)

スマートエージェント

スマートエージェントの通信用ポート環境変数。

UDPによる双方向通信に必要です。

14000

(14)

ネーミングサービス

ネーミングサービスのリクエスト受付ポート引数（TPBrokerが利用）。

900

(15)

運用管理エージェント

運用管理エージェントがManagement Serverとの通信に使用するポート。

20295

(16)

サーバ通信エージェント

サーバ通信エージェントが仮想サーバマネージャとの通信に使用するポート。

20580

(17)

Management Server

Management Serverのhttpポート。

28080

(18)

Management Serverの終了要求ポート。

ホスト内通信に必要です。

28005

(19)

Management Serverの内部通信ポート。

ホスト内通信に必要です。

28009

(20)

Managerリモート管理機能への接続ポート。

28099

(21)

Managerリモート管理機能へのクライアント接続ポート。

（浮動）

(22)

HTTP Server

HTTP Serverのhttpポート。

80

(23)

HTTP Serverのhttpsポート。

443

(24)

サーバ管理コマンド

サーバ管理コマンドがJ2EEサーバと通信するポート。

（浮動）

(25)

CTMレギュレータ

CTMレギュレータがEJBクライアントからのリクエストを受け付けるポートの基底値。基底値＋プロセス数だけ使用します。

CTM使用時に必要です。

（浮動）

(26)

CTMデーモン

CTMデーモンがEJBクライアントからのリクエストを受け付けるポート。

CTM使用時に必要です。

（浮動）

(27)

CTMデーモンがほかのデーモンやJ2EEサーバなどと通信するポート。

CTM使用時に必要です。

20138

(28)

CTMドメインマネジャ

CTMドメインマネジャがほかのCTMドメインマネジャと通信するポート。

CTM使用時に，TCPおよびUDP通信（ブロードキャスト）をするために必要です。

20137

(29)

CJMSPブローカー

CJMSプロバイダのブローカーがリソースアダプタやコマンドからのリクエストを受け付けるためのポート。

7676

(30)

CJMSプロバイダのブローカーがリソースアダプタとコネクションを確立するためのポート。

（浮動）

(31)

CJMSプロバイダのブローカーがコマンドとコネクションを確立するためのポート。

（浮動）

(32)

Management Server

08-50モードの仮想サーバマネージャ（Management Server）がvCenter Serverの接続処理を行うための，内部で起動するプロセス（Agent for vCenter Server）のポート。

28089

(33)

HCSC-Managerから利用されるManagement Serverの内部通信用ポート。

28900

アプリケーションサーバのプロセスが使用するTCP/UDPのポート番号について，次の図に示します。(x)は表の項番と対応しています。

図16‒5　アプリケーションサーバが使用するTCP/UDPのポート番号

これ以外の凡例については，マニュアル「アプリケーションサーバ システム設計ガイド」の「3.2　システム構成の説明について」を参照してください。

ポート番号の指定個所を次の表に示します。表の項番は図中の項番と対応しています。

表16‒18　アプリケーションサーバが使用するTCP/UDPのポート番号の指定個所

項番

定義ファイル

設定対象

パラメタ名※1

(1)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

vbroker.se.iiop_tp.scm.iiop_tp.listener.port

(2)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.http.port

(3)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

webserver.connector.ajp13.port

(4)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.distributedtx.recovery.port

(5)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

webserver.connector.inprocess_http.port

(6)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.rmi.naming.port

(7)

Connector属性ファイル

Reliable Messaging

<config-property>タグに指定するRMSHPort※2

(8)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.rmi.remote.listener.port

(9)

Connector属性ファイル

TP1インバウンドアダプタ

<config-property>タグに指定するscd_port※3

(10)

Connector属性ファイル

TP1インバウンドアダプタ

<config-property>タグに指定するtrn_port※3

(11)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

mngagent.connector.port

(12)

簡易構築定義ファイル

論理スマートエージェント（smart-agent）

smartagent.port

(13)

簡易構築定義ファイル

論理J2EEサーバ（j2ee-server）

ejbserver.naming.port

(14)

adminagent.properties

運用管理エージェント

adminagent.adapter.portキー

(15)

sinaviagent.properties※4

サーバ通信エージェント

sinaviagent.portキー

(16)

mserver.properties

Management Server

webserver.connector.http.portキー

(17)

mserver.properties

Management Server

webserver.shutdown.portキー

(18)

mserver.properties

Management Server

webserver.connector.ajp13.portキー

(19)

mserver.properties

Management Server

com.cosminexus.mngsvr.management.portキー

(20)

mserver.properties

Management Server

com.cosminexus.mngsvr.management.listen.portキー

(21)

簡易構築定義ファイル

論理Webサーバ

（web-server）

Listen

(22)

簡易構築定義ファイル

論理Webサーバ

（web-server）

Listen

(23)

usrconf.properties（サーバ管理コマンド用システムプロパティファイル）

サーバ管理コマンド

vbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(24)

簡易構築定義ファイル

論理CTM（component-transaction-monitor）

ctm.RegOption

(25)

簡易構築定義ファイル

論理CTM（component-transaction-monitor）

ctm.EjbPort

(26)

簡易構築定義ファイル

論理CTM（component-transaction-monitor）

ctm.port

(27)

簡易構築定義ファイル

論理CTMドメインマネジャ（ctm-domain-manager）

cdm.port

(28)

config.properties

CJMSPブローカー

imq.portmapper.portキー

(29)

config.properties

CJMSPブローカー

imq.jms.tcp.portキー

(30)

config.properties

CJMSPブローカー

imq.admin.tcp.portキー

(31)

vmx.properties

08-50モードの仮想サーバマネージャ（Management Server）

vmx.vcenterserver.agent.portキー

(32)

mserver.properties

Management Server

ejbserver.naming.portキー

注※1　設定ファイルが簡易構築定義ファイルの場合は，<configuration>タグ内の<param-name>の指定値を指します。

注※2　RMSHPortは，リソースアダプタReliable Messagingのプロパティ定義で指定するコンフィグレーションプロパティです。RMSHPortについては，マニュアル「Reliable Messaging」の「6.　コンフィグレーションプロパティ」を参照してください。

注※3　scd_portおよびtrn_portは，リソースアダプタTP1インバウンドアダプタのプロパティ定義で指定するコンフィグレーションプロパティです。scd_portおよびtrn_portについては，マニュアル「アプリケーションサーバ 機能解説基本・開発編(コンテナ共通機能)」の「4.12.2　リソースアダプタの設定」を参照してください。

注※4　サーバ通信エージェントの詳細については，サーバ通信エージェントのドキュメントを参照してください。

参考

運用管理ポータルまたはファイル編集によってアプリケーションサーバを構築している場合のTCP/UDPのポートの設定個所を次に示します。

表16‒19　運用管理ポータルまたはファイル編集によってアプリケーションサーバを構築している場合のTCP/UDPのポートの設定個所

項番

運用管理ポータルで構築している場合の設定個所

ファイル編集で構築している場合の設定個所

(1)

［EJBコンテナの設定］画面の「オプション」の「通信ポート番号」

usrconf.propertiesのvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(2)

［J2EEサーバの基本設定］画面の「コンテナの設定」の「簡易Webサーバのポート番号」

usrconf.propertiesのejbserver.http.portキー

(3)

［Webコンテナの設定］画面の「Webサーバとの接続」の「ポート番号」

usrconf.propertiesのwebserver.connector.ajp13.portキー

(4)

［トランザクションの設定］画面の「トランザクションに関する設定」の「JTAリカバリの固定ポート番号」

usrconf.propertiesのejbserver.distributedtx.recovery.portキー

(5)

［ネーミングの設定］画面の「インプロセス選択時の設定」の「ポート番号」

usrconf.propertiesのejbserver.naming.portキー

(6)

［Webコンテナの設定］画面の「インプロセスHTTPサーバ機能の使用」の「ポート番号」

usrconf.propertiesのwebserver.connector.inprocess_http.portキー

(7)

［通信の設定］画面の「RMIレジストリの設定」の「ポート番号」

usrconf.propertiesのejbserver.rmi.naming.portキー

(8)

Connector属性ファイルの<config-property>タグに指定するRMSHPort※1

Connector属性ファイルの<config-property>タグに指定するRMSHPort※1

(9)

［通信の設定］画面の「RMIレジストリの設定」の「通信ポート番号」

usrconf.propertiesのejbserver.rmi.remote.listener.portキー

(10)

TP1インバウンドアダプタのConnector属性ファイルのリソースアダプタの<config-property>タグに指定するscd_port

TP1インバウンドアダプタのConnector属性ファイルのリソースアダプタの<config-property>タグに指定するscd_port

(11)

TP1インバウンドアダプタのConnector属性ファイルのリソースアダプタの<config-property>タグに指定するtrn_port

TP1インバウンドアダプタのConnector属性ファイルのリソースアダプタの<config-property>タグに指定するtrn_port

(12)

［J2EEコンテナの設定］画面の「運用監視エージェントの設定」の「ポート番号」

mngagent.<実サーバ名>.propertiesのmngagent.connector.portキー

(13)

［スマートエージェントの設定］画面の「スマートエージェントに関する設定」の「監視ポート番号」

環境変数OSAGENT_PORT

(14)

CORBAネーミングサービスをインプロセスで起動する場合

［J2EEサーバの基本設定］画面の「利用するネーミングサービスの設定」の「インプロセス用のポート番号」

CORBAネーミングサービスをアウトプロセスで起動する場合

［ホスト内のサーバの設定］画面の「ネーミングサービスの設定」の「ネーミングサービスのポート番号」

CORBAネーミングサービスをインプロセスまたはアウトプロセスで自動起動する場合

usrconf.propertiesのejbserver.naming.portキー

CORBAネーミングサービスを手動起動する場合

nameservコマンドのコマンド引数に「-Dvbroker.se.iiop_tp.scm.iiop_tp.listener.port=<ポート番号>」を指定。

(15)

adminagent.propertiesのadminagent.adapter.portキー

adminagent.propertiesのadminagent.adapter.portキー

(16)

sinaviagent.propertiesのsinaviagent.portキー※2

sinaviagent.propertiesのsinaviagent.portキー

(17)

［ネットワークの設定］画面の「Management Server接続HTTPポート番号」

mserver.propertiesのwebserver.connector.http.portキー

(18)

［ネットワークの設定］画面の「Management Server終了要求受信ポート番号」

mserver.propertiesのwebserver.shutdown.portキー

(19)

［ネットワークの設定］画面の「Management Server内部通信用ポート番号」

mserver.propertiesのwebserver.connector.ajp13.portキー

(20)

mserver.propertiesのcom.cosminexus.mngsvr.management.portキー

mserver.propertiesのcom.cosminexus.mngsvr.management.portキー

(21)

mserver.propertiesのcom.cosminexus.mngsvr.management.listen.portキー

mserver.propertiesのcom.cosminexus.mngsvr.management.listen.portキー

(22)

［ホスト内のサーバの設定］画面の「J2EEサーバの設定」の「ポート番号」の「http」

httpsd.confのListenディレクティブまたはPortディレクティブ

(23)

［ホスト内のサーバの設定］画面の「J2EEサーバの設定」の「ポート番号」の「https」

httpsd.confのListenディレクティブまたはPortディレクティブ

(24)

usrconf.properties（サーバ管理コマンド用システムプロパティファイル）のvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

usrconf.properties（サーバ管理コマンド用システムプロパティファイル）のvbroker.se.iiop_tp.scm.iiop_tp.listener.portキー

(25)

［レギュレータの設定］画面の「CTMレギュレータの設定」の「設定ファイル」

ctmregltdコマンドまたはctmstartコマンドの引数-CTMEjbPort

(26)

［スケジューリングの設定］画面の「詳細設定」の「EJBリクエスト受信ポート番号」

ctmstartコマンドの引数-CTMEjbPort

(27)

［CTMの基本設定］画面の「基本設定」の「ポート番号」

ctmstartコマンドの引数-CTMPort

(28)

［CTMドメインマネジャの基本設定］画面の「ポート番号」

ctmdmstartコマンドの引数-CTMPort

(29)

config.propertiesのimq.portmapper.portキー

config.propertiesのimq.portmapper.portキー

(30)

config.propertiesのimq.jms.tcp.portキー

config.propertiesのimq.jms.tcp.portキー

(31)

config.propertiesのimq.admin.tcp.portキー

config.propertiesのimq.admin.tcp.portキー

(32)

vmx.propertiesのvmx.vcenterserver.agent.portキー

vmx.propertiesのvmx.vcenterserver.agent.portキー

(33)

mserver.propertiesのejbserver.naming.portキー

mserver.propertiesのejbserver.naming.portキー

注※1　RMSHPortは，リソースアダプタReliable Messagingのプロパティ定義で指定するコンフィグレーションプロパティです。RMSHPortについては，マニュアル「Reliable Messaging」の「6.　コンフィグレーションプロパティ」を参照してください。

注※2　サーバ通信エージェントの詳細については，サーバ通信エージェントのドキュメントを参照してください。

注意事項

サーバの待ち受けポートの注意事項（UNIXの場合）

UNIXの場合，次の条件がすべて重なるときは，待ち受けをしていないTCPポートに対して，接続に成功してしまうことがあります。

待ち受けをしていないポートに対して接続試行を実行する

接続対象が自ホストであり，かつ一時ポート番号の範囲（OSが動的に割り当てるポートの範囲）である

この現象が発生した場合，想定したプロセスとの通信ができないで，タイムアウトなどが発生します。この現象を回避するためには，サーバの待ち受けポートに一時ポート番号の範囲以外の値を指定してください。一時ポート番号の範囲は，次のファイルで確認できます。

AIXの場合

最小値（32768）：no -o tcp_ephemeral_low

最大値（65535）：no -o tcp_ephemeral_high

Linuxの場合

/proc/sys/net/ipv4/ip_local_port_range

なお，サーバの待ち受けポートの設定方法は，各OSのマニュアルを参照してください。

17　Webアプリケーションで使用するコマンド

この章では，Webアプリケーションで使用するコマンドについて説明します。ここでは，推奨モードと異なる内容だけ説明します。

17.1　Webアプリケーションで使用するコマンドの詳細

Webアプリケーションで使用するコマンドの格納先を次に示します。

コマンドの格納先

Webアプリケーションで使用するコマンドは，次のディレクトリに格納されています。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥web¥bin¥V9

UNIXの場合

/opt/Cosminexus/CC/web/bin/V9

17.2　cjjspc（JSPの事前コンパイル）

推奨モードとV9互換モードでは，JSPの事前コンパイルのコマンドが異なります。V9互換モードでJSPの事前コンパイルを実行する場合は，V9互換モード用のcjjspcコマンドを使用してください。cjjspcコマンドの入力形式，機能などについては，マニュアル「アプリケーションサーバリファレンス コマンド編」の「cjjspc（JSPの事前コンパイル）」を参照してください。

第4編　その他互換機能

18　基本・開発機能の互換機能（EJB 2.1とServlet 2.4でのアノテーションの利用）

この章では，基本・開発機能の互換機能のうち，EJB 2.1とServlet 2.4でのアノテーションの利用について説明します。

この機能は互換機能のため推奨しません。Java EE標準の，EJB3.0/Servet2.5以降でのアノテーションの利用を検討してください。

18.1　EJB 2.1とServlet 2.4でのアノテーションの利用

アプリケーションサーバでは，EJB 2.1とServlet 2.4でアプリケーションサーバ独自のアノテーションを利用できます。この節では，EJB 2.1とServlet 2.4でのアノテーションの利用について説明します。

この節の構成を次の表に示します。

表18‒1　この節の構成（EJB 2.1とServlet 2.4でのアノテーションの利用）

分類

タイトル

参照先

解説

ロード対象のクラスとロード時に必要なクラスパス

18.1.1

EJB 2.1とServlet 2.4でのアノテーション参照抑止機能

18.1.2

実装

javax.annotationパッケージに含まれるアノテーションのサポート範囲

18.1.3

javax.ejbパッケージに含まれるアノテーションのサポート範囲

18.1.4

設定

実行環境での設定（J2EEサーバ単位の設定）

18.1.5

アノテーション参照抑止機能の設定変更

18.1.6

注意事項

アノテーションの利用時の注意事項

18.1.7

注　「運用」について，この節での説明はありません。

18.1.1　ロード対象のクラスとロード時に必要なクラスパス

アノテーション情報は，次のような操作を実行したときに読み込まれます。

リソースの追加（cjaddapp）※

インポート時（cjimportapp）

インポート時（cjimportres）

インポート時（cjimportlibjar）※

開始時（cjstartapp）

リプレース時（cjreplaceapp）

リロード時（cjreloadapp）

注※

対象となるのはライブラリJARのクラスです。

アノテーション情報を読み込むためには，まずクラスをロードする必要があります。

J2EE1.4以前に準拠したJ2EEアプリケーションでアノテーション情報を読み込むためにロードするクラスを次の図に示します。

図18‒1　アノテーション情報を読み込むためにロードするクラス

EJB-JAR（ejb-jar.xmlのバージョンが2.1）に含まれるクラスファイルまたはWAR（web.xmlのバージョンが2.4）に含まれるクラスファイルからアノテーション情報を読み込む場合のアノテーションは，アプリケーションサーバ独自の仕様です。また，アプリケーションサーバでは，アプリケーションサーバ独自の仕様によって，J2EE 1.4の場合でもejb-jar.xmlの省略とアノテーションの使用ができます。

なお，J2EE 1.4以前に準拠したJ2EEアプリケーションの場合，EJB-JAR（ejb-jar.xmlのバージョンが2.1，またはejb-jar.xmlが省略されたもの）やWAR（web.xmlのバージョンが2.4）からライブラリJARを使用することはできません。指定しても無視されます。

アノテーション情報を取得するためにクラスをロードするかどうかは，各モジュールのバージョン，およびJ2EEサーバで設定されているプロパティに依存します。

モジュールのバージョンがEJB-JAR（2.1）またはWAR（2.4）の場合のアノテーション情報を取得するかどうかの条件を次の表に示します。

表18‒2　モジュールのバージョンがEJB-JAR（2.1）またはWAR（2.4）の場合

モジュール

J2EEサーバのプロパティ

ejbserver.deploy.applications.metadata_complete

falseまたはプロパティを省略時

true

EJB-JAR（2.1）

○

−

WAR（2.4）

WEB-INF/classes以下

○

−

WEB-INF/lib/JARファイル

−

−

（凡例）

○：アノテーション情報を取得する

−：アノテーション情報を取得しない

18.1.2　EJB 2.1とServlet 2.4でのアノテーション参照抑止機能

アノテーション参照抑止機能は，J2EEアプリケーション中のアノテーションの参照（解析処理）を実施するかどうかを設定する機能です。アノテーション参照抑止機能を使用すると，アノテーションを使用しない場合に，アノテーションの解析処理を抑止することができます。

EJB 2.1またはServlet 2.4でのアノテーションの利用は，アプリケーションサーバで拡張された機能です。このため，アノテーションを利用している場合に，アノテーションの参照を抑止したいときは，アプリケーションサーバ独自のアノテーション参照抑止機能を使用します。

なお，EJB 2.1またはServlet 2.4でのアノテーションの参照抑止機能は，J2EEサーバ単位だけで設定できます。モジュール単位の参照抑止は設定できません。また，J2EEサーバ単位のアノテーションの参照抑止機能を有効にした場合，アノテーションを記述したEJB 2.1またはServlet 2.4のモジュールを含むJ2EEアプリケーションは使用できなくなります。

18.1.3　javax.annotationパッケージに含まれるアノテーションのサポート範囲

javax.annotationパッケージのアノテーションの適用範囲を説明します。ここでは，WARファイル（Servlet 2.4対応）およびEJB-JARファイル（EJB2.1対応）のコンポーネントごとに記述できるアノテーションを説明します。

(1)　EJB-JARファイル（EJB2.1対応）

EJB-JARファイルに記述できるアノテーションの一覧を示します。

表18‒3　EJB-JARファイル（EJB2.1対応）に記述できるアノテーション（javax.annotationパッケージ）

アノテーション名

Enterprise Bean

例外クラス

その他のクラス

インタフェース

Session Bean

Entity Bean

Message-driven Bean

@Resource※

−

○

−

×

−

−

@Resources※

−

○

−

×

−

−

（凡例）

○：対応する。

×：アプリケーションサーバでは対応しない。

−：標準仕様で対応していない。

注※

アプリケーションサーバでは，EJB2.1仕様，またはServlet2.4仕様のアプリケーションでもサポートしています。

(2)　WARファイル（Servlet 2.4対応）

WARファイルに記述できるアノテーションの一覧を示します。

表18‒4　WARファイル（Servlet 2.4対応）に記述できるアノテーション（javax.annotationパッケージ）

アノテーション名

Servlet仕様

JSP仕様

その他のクラス

サーブレット

サーブレットフィルタ

イベントリスナ

JSPファイル

タグハンドラ

タグライブラリイベントリスナ

クラシックタグハンドラ

シンプルタグハンドラ

@Resource※1

○

○

○

−

○

○※2

×

−

@Resources※1

○

○

○

−

○

○

×

−

（凡例）

○：対応する。

×：アプリケーションサーバでは対応しない。

−：標準仕様で対応していない。

注※1

アプリケーションサーバでは，EJB2.1仕様，またはServlet2.4仕様のアプリケーションでもサポートしています。

注※2

Servlet2.4仕様のWebアプリケーションではメソッドおよびフィールドに対するDIができません。

18.1.4　javax.ejbパッケージに含まれるアノテーションのサポート範囲

javax.ejbパッケージのアノテーションの適用範囲を説明します。ここでは，WARファイル（Servlet 2.4対応）およびEJB-JARファイル（EJB2.1対応）のコンポーネントごとに記述できるアノテーションを説明します。

(1)　WARファイル（Servlet 2.4対応）

WARファイルに記述できるアノテーションの一覧を示します。

表18‒5　WARファイル（Servlet 2.4対応）に記述できるアノテーション（javax.ejbパッケージ）

アノテーション名

Servlet仕様

JSP仕様

その他のクラス

サーブレット

サーブレットフィルタ

イベントリスナ

JSPファイル

タグハンドラ

タグライブラリイベントリスナ

クラシックタグハンドラ

シンプルタグハンドラ

@EJB※1

○

○

○

−

○

○※2

×

−

@EJBs※1

○

○

○

−

○

○

×

−

（凡例）

○：対応する。

×：アプリケーションサーバでは対応しない。

−：標準仕様で対応していない。

注※1

アプリケーションサーバでは，EJB2.1仕様，またはServlet2.4仕様のアプリケーションでもサポートしています。

注※2

Servlet2.4仕様のWebアプリケーションではメソッドおよびフィールドに対するDIができません。

(2)　EJB-JARファイル（EJB2.1対応）

EJB-JARファイルに記述できるアノテーションの一覧を示します。

表18‒6　EJB-JARファイル（EJB2.1対応）に記述できるアノテーション（javax.ejbパッケージ）

アノテーション名

Enterprise Bean

例外クラス

その他のクラス

インタフェース

Session Bean

Entity Bean

Message-driven Bean

@EJB※

−

○

−

×

−

−

@EJBs※

−

○

−

×

−

−

（凡例）

○：対応する。

×：アプリケーションサーバでは対応しない。

−：標準仕様で対応していない。

注※

アプリケーションサーバでは，EJB2.1仕様，またはServlet2.4仕様のアプリケーションでもサポートしています。

18.1.5　実行環境での設定（J2EEサーバ単位の設定）

EJB 2.1またはServlet 2.4のモジュールに対するアノテーション参照抑止機能の定義は，J2EEサーバ単位に設定します。設定した内容は，そのJ2EEサーバにデプロイされているすべてのJ2EEアプリケーションに適用されます。

J2EEサーバ単位でアノテーションの参照を抑止する設定は，簡易構築定義ファイルを編集して行います。論理J2EEサーバ（j2ee-server）の<configuration>タグ内に，次のパラメタで設定します。

キー名称

内容

省略値

導入されたバージョン

ejbserver.deploy.applications.metadata_complete

アノテーションを記述できるアプリケーションのうち，次のアプリケーションでアノテーション参照抑止機能を有効にするかどうかを指定します。

EJB 2.1

Servlet 2.4

trueを指定した場合：

アノテーションを参照しません。

falseを指定した場合：

アノテーションを参照します。

false

07-50

このパラメタは，usrconf.properties（J2EEサーバ用ユーザプロパティファイル）にも指定できます。

アノテーションの参照を抑止する設定をした場合，設定したJ2EEサーバの起動時に，アノテーションの参照を抑止することを示すメッセージが出力されます。J2EEサーバ起動前または起動後にアノテーションの参照を抑止しているかどうかの設定を確認する場合は，簡易構築定義ファイルの<configuration>タグ内のパラメタ「ejbserver.deploy.applications.metadata_complete」に設定された値を参照してください。

注意事項

J2EEサーバでejbserver.deploy.applications.metadata_completeにtrueを指定した場合，アノテーションを記述したEJB 2.1またはServlet 2.4のモジュールを含むJ2EEアプリケーションは使用できなくなります。

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

18.1.6　アノテーション参照抑止機能の設定変更

アノテーション参照抑止機能の設定を変更する場合について説明します。

(1)　モジュール単位の設定（DDのmetadata-complete属性の値）を変更する場合

DDのmetadata-complete属性を変更する場合は，metadata-complete属性を変更したアプリケーションを作成して，J2EEサーバに再度インポートする必要があります。

metadata-complete属性を変更した場合，リデプロイ機能（-replaceDDオプションを指定したcjreplaceappコマンド）によってアプリケーションを入れ替えようとすると，エラーになり，入れ替え処理は中断されます。

(2)　J2EEサーバ単位の設定（簡易構築定義ファイルのejbserver.deploy.applications.metadata_completeの値）を変更する場合

アプリケーションインポート後にejbserver.deploy.applications.metadata_completeの値を変更する場合について説明します。

trueからfalseに変更した場合は，アプリケーションのアノテーションが参照されるようになります。特に対処は不要です。

falseからtrueに変更した場合は，アノテーションが参照されなくなります。これに伴い，アプリケーションが正常に動作しなくなることがあります。アプリケーションが正常に動作しなくなった場合は，次の対処を実施してください。

アーカイブ形式のアプリケーションの場合

アノテーション参照抑止機能の設定を見直してください。または，J2EEアプリケーションの実装およびDDの設定を見直して，アノテーションを参照しなくても正しく動作するように設定を変更してください。変更後，アプリケーションを再度インポートしてください。

展開ディレクトリ形式のアプリケーションの場合

アノテーション参照抑止機能の設定を見直してください。または，J2EEアプリケーションの実装およびDDの設定を見直して，アノテーションを参照しなくても正しく動作するように設定を変更してください。変更後，アプリケーションを再開始してください。

18.1.7　アノテーションの利用時の注意事項

EJB 2.1，Servlet 2.4のモジュールに定義されたアノテーションの情報は，DDに定義しても上書きはされません。

これらのモジュールに定義できるのは，アプリケーションサーバ独自のアノテーションです。DDによって上書きすることはできません。

19　クラスタコネクションプール機能を使用するための設定

この章では，クラスタコネクションプール機能について説明します。

この機能は互換機能のため推奨しません。Oracle RACの機能による代替を検討してください。

19.1　クラスタコネクションプール機能

この節では，クラスタコネクションプール機能について説明します。

この節の構成を次の表に示します。

表19‒1　この節の構成（クラスタコネクションプール機能）

分類

タイトル

参照先

解説

Oracle RACを使用したOracleへの接続

19.1.1

クラスタコネクションプールの概要

19.1.2

使用するリソースアダプタ

19.1.3

クラスタコネクションプールの動作

19.1.4

手動によるコネクションプールの停止・開始の流れ

19.1.5

設定

コネクションプールをクラスタ化するために必要な設定

19.1.6

注　「実装」および「運用」について，この機能固有の説明はありません。

クラスタコネクションプール機能は，データベースをクラスタ構成にしているシステムの場合に，最適な動作をするための機能です。Oracle RACを使用したOracleへの接続の場合に使用できます。クラスタコネクションプール機能を使用することで，障害発生時やメンテナンス時の可用性の低下を防ぐことができます。クラスタコネクションプール機能の使用時に，データベースノードに障害が発生した場合，およびデータベースノードのメンテナンスを行う場合の動作について説明します。

データベースノードに障害が発生した場合

OS，ハード，ソフト障害など，コネクションが取得できない状況になった場合，障害が発生しているデータベースノードに接続しているコネクションプールを自動で一時停止できます（自動一時停止機能）。J2EEアプリケーションからリソースアダプタにコネクションの取得要求が出された場合でも，一時停止されたコネクションプールにはコネクションの取得要求が出されないため，TCP/IPのタイムアウトまで処理が中断することはありません。これによって，J2EEアプリケーションは，ほかの正常なデータベースノードに接続しているコネクションプールからコネクションを取得し，業務を継続できます。

また，データベースノードの障害が回復した時に，自動でコネクションプールを再開できます（自動再開機能）。コネクションプールが再開されると，自動的に回復したデータベースノードから再びアクセスされるため，データベースノード回復時にcjclearpoolコマンドを実行して，コネクションプールを削除する必要はありません。

データベースノードのメンテナンスを行う場合

データベースノードのメンテナンスを行う場合，コマンドを使用して任意のタイミングでメンバコネクションプールを一時停止できます（手動一時停止機能）。これによって，そのデータベースノードを切り離して，メンテナンスを行えます。

また，メンテナンスが終了して再開する時に，コマンドを使用して任意のタイミングでコネクションプールを再開できます（手動再開機能）。

なお，クラスタコネクションプール機能では，コネクション取得時に障害を検知した場合，正常なほかのメンバリソースアダプタからコネクションを取得します。その際，アプリケーションでエラーは発生しません。

この節では，Oracle RAC機能を使用してクラスタ化したOracleとの接続方法，およびコネクションプールをクラスタ化する場合のコネクションプール（クラスタコネクションプール）の特徴，および機能について説明します。

19.1.1　Oracle RACを使用したOracleへの接続

Oracle RACを使用したOracleへの接続方法は，Oracleのバージョン，または負荷分散に使用する機能によって異なります。なお，接続できるトランザクションの種類はローカルトランザクションです。

Oracleのバージョン，負荷分散に使用する機能および使用するRARファイルの対応については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6.7　Oracleと接続する場合の前提条件と注意事項」を参照してください。

負荷分散に使用する機能ごとに，Oracleへの接続方法について説明します。

(1)　アプリケーションサーバの機能を使用した接続

アプリケーションサーバのクラスタコネクションプール機能を使用して，Oracle RACに接続します。アプリケーションサーバがデータベースアクセスの負荷を分散します。

クラスタコネクションプール機能の詳細については，19.1.2以降の説明を参照してください。

(a)　負荷分散処理の流れと設定

クラスタコネクションプール機能を使用した場合の負荷分散処理の流れと設定を次の図に示します。

図19‒1　クラスタコネクションプール機能を使用した接続

この図では，3台構成のOracle RACシステムで，データベースノード1にはインスタンス1，データベースノード2にはインスタンス2，データベースノード3にはインスタンス3があります。データベースに接続するための設定を次に示します。

インスタンス1，2，3に対応したメンバリソースアダプタ用DB Connector M1，M2，M3を生成します。また，メンバリソースアダプタに振り分ける機能を持つルートリソースアダプタ用DB Connector Rも生成します。

J2EEアプリケーションはルートリソースアダプタ用DB Connector Rに関連づけます。

この設定によって，J2EEアプリケーション1，2からのデータベースアクセスはデータベースノード1，2，3に分散されます。

(b)　データベース障害発生時と回復時の動作

データベース障害が発生した場合，アプリケーションサーバが障害を検知します。障害が発生したデータベースに対応するメンバリソースアダプタが閉塞され，残っているインスタンスで処理が続行されます。

データベース障害が回復するとアプリケーションサーバは自動で閉塞を解除します。また，手動でも閉塞を解除できます。

(2)　Oracleの機能を使用した接続

DB ConnectorからOracle RACに接続し，Oracle RACの機能でデータベースアクセスの負荷を分散します。

(a)　負荷分散処理の流れと設定

Oracle RACの機能を使用した場合の負荷分散処理の流れと設定を次の図に示します。

図19‒2　Oracle RACの機能を使用した接続

この図では，3台構成のOracle RACシステムで，データベースノード1にはインスタンス1，データベースノード2にはインスタンス2，データベースノード3にはインスタンス3があります。データベースに接続するための設定について説明します。

それぞれのインスタンスに分散して接続するDB Connector Aを生成します。

DB Connector Aは，グローバルデータベース名またはサービス名を使用するように設定します。

J2EEアプリケーション1，および2をDB Connector Aに関連づけます。

この設定によって，J2EEアプリケーション1，および2からのデータベースアクセスはデータベースノード1，2，3に分散されます。

(b)　データベース障害発生時と回復時の動作

データベース障害が発生した場合，Oracle RAC機能によって障害が発生したインスタンスが切り離され，残っているインスタンスで処理が続行されます。

アプリケーションサーバのコネクションプールを使用している場合，データベース回復時には次のどちらかの操作を実行してください。コネクションプールがクリアされ，これ以降のアクセスが正常に分散されます。

cjclearpoolコマンドを実行する。

J2EEサーバを再起動する。

19.1.2　クラスタコネクションプールの概要

クラスタ化されたコネクションプールのことをクラスタコネクションプールといいます。ここでは，クラスタコネクションプールの構成，およびクラスタコネクションプールで使用できる機能について説明します。

(1)　クラスタコネクションプールの構成

クラスタコネクションプールは，各データベースノードと接続するメンバリソースアダプタと，それら複数のメンバリソースアダプタを束ねるルートリソースアダプタで構成されています。ルートリソースアダプタとメンバリソースアダプタについて説明します。

ルートリソースアダプタ

クラスタ化したコネクションプール（クラスタコネクションプール）を使用するときに，J2EEアプリケーションからアクセスされるリソースアダプタです。ルートリソースアダプタは，メンバリソースアダプタを束ねる役割を持ちます。ルートリソースアダプタでは，ルートリソースアダプタに対する処理要求をメンバリソースアダプタに振り分けます。なお，ルートリソースアダプタは，コネクションプールを持ちません。

メンバリソースアダプタ

クラスタ化されている個々のデータベースノードに接続するリソースアダプタです。メンバリソースアダプタは，必ずルートリソースアダプタを経由してアクセスされます。メンバリソースアダプタのコネクションプールのことを，メンバコネクションプールといいます。

コネクションプールをクラスタ化しているときのコネクション取得時の処理の流れを次の図に示します。

図19‒3　コネクション取得時の処理の流れ

J2EEアプリケーションは，ルートリソースアダプタに対しコネクション取得要求をする。

ルートリソースアダプタは，メンバコネクションプールを一つ選択し，コネクション取得要求を出す。

メンバコネクションプールからコネクションが選択され，J2EEアプリケーションに返す。

(2)　前提条件

クラスタコネクションプール機能を利用できるデータベースは，Oracle RAC機能を使用している場合だけです。使用できるJDBCドライバは，Oracle JDBC Thin Driverです。

(3)　データベース接続で使用できるJ2EEコンポーネントおよび機能

クラスタコネクションプール機能を使用している場合に，データベース接続で使用できるJ2EEコンポーネントおよび機能を次の表に示します。

表19‒2　データベース接続で使用できるJ2EEコンポーネントおよび機能（クラスタコネクションプール機能）

項目

Oracle（クラスタコネクションプール機能を使用した場合）

J2EEコンポーネント

Servlet/JSP

○

Stateless Session Bean

○

Stateful Session Bean

○

Singleton Session Bean

○

Entity Bean（BMP）

○

Entity Bean（CMP1.1）

×

Entity Bean（CMP2.0）

×

Message-driven Bean

×

使用できる機能

コネクションプーリング

○

コネクションプールのウォーミングアップ

○

コネクションプールの情報表示（cjlistpoolコマンド）

○

コネクションプールのクリア

○

リソースへの接続テスト

○

コネクションの障害検知

○

ステートメントプーリング

○

ステートメントキャンセル

　○※

ステートメントsetQueryTimeoutメソッド

　○※

コネクションIDのPRFトレース出力

○

障害調査用SQLの出力

○

（凡例）○：使用できる　×：使用できない

注※　Oracleに接続する場合の注意事項があります。注意事項については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.6.7　Oracleと接続する場合の前提条件と注意事項」を参照してください。

注意事項

リソースアダプタを使用する場合，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておく必要があります。リソースアダプタを使用しているJ2EEアプリケーションをカスタマイズするときに，J2EEアプリケーションからリソースアダプタへのリファレンスを解決しておいてください。

(4)　使用できるリソース接続とトランザクション管理の機能

ルートリソースアダプタ，およびメンバリソースアダプタで使用できる機能については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3.4　リソースアダプタの機能」を参照してください。

19.1.3　使用するリソースアダプタ

ルートリソースアダプタおよびメンバリソースアダプタで実行できるコマンド，設定の概要，および注意事項について説明します。

(1)　実行できるコマンド

ルートリソースアダプタおよびメンバリソースアダプタごとの，コマンドの実行可否を次の表に示します。なお，これ以外のコマンドについてはどちらのリソースアダプタでも実行できます。

表19‒3　ルートリソースアダプタおよびメンバリソースアダプタのコマンドの実行可否

コマンド

リソースアダプタの種類

ルートリソースアダプタ

メンバリソースアダプタ

cjstartrar

○

○

cjstoprar

○

○

cjtestres

○

○

cjlistrar

○

○

cjclearpool

×

○

cjlistpool

×

○

cjsuspendpool

×

○

cjresumepool

×

○

（凡例）　○：実行できる　　×：実行できない

(2)　DB Connectorの設定

ルートリソースアダプタおよびメンバリソースアダプタのDB Connectorで設定する項目を次の表に示します。

表19‒4　ルートリソースアダプタおよびメンバリソースアダプタのDB Connectorで設定する項目

設定項目

リソースアダプタの種類

ルートリソースアダプタ

メンバリソースアダプタ

トランザクションサポートレベル

×

　○※1

ログ取得の可否

○

○

データベース接続情報

−

○

DB Connector固有の設定（ステートメントプールなど）

−

○

セキュリティ情報（ユーザ名，パスワード）

×

　○※2

コネクションプールサイズ

×

○

クラスタコネクションプール固有の設定

○

−

（凡例）○：設定が必要　×：設定は不要　−：設定項目がない

注※1　一つのクラスタコネクションプールを構成するメンバリソースアダプタのトランザクションサポートレベルは，すべて同じにする必要があります。

注※2　一つのクラスタコネクションプールを構成するメンバリソースアダプタのユーザ名は，すべて同じにする必要があります。

DB Connectorの設定の詳細については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2　データベースと接続するための設定」，または「19.6　Connector属性ファイル」を参照してください。

(3)　ルートリソースアダプタについての注意事項

cjclearpoolコマンドは実行できません。実行した場合は，メッセージが出力され，コマンドが異常終了します。クラスタコネクションプール内のコネクションをcjclearpoolコマンドでクリアする場合は，メンバリソースアダプタに対してコマンドを実行してください。

cjlistpoolコマンドは実行できません。実行した場合は，メッセージが出力され，コマンドが異常終了します。クラスタコネクションプール内のコネクションプールの情報を表示する場合は，cjlistpoolコマンドの-resnameにメンバリソースアダプタの表示名を指定するか，-resallを指定して実行してください。

一つのクラスタコネクションプール内で，コンテナ管理でのサインオンとコンポーネント管理でのサインオンを混在して使用できません。コンポーネント管理でのサインオンを使用する場合は，ルートリソースアダプタに属するすべてのメンバリソースアダプタのユーザ名を空白にしてください。

ルートリソースアダプタは，ルートリソースアダプタに属するすべてのメンバリソースアダプタが開始状態の場合に開始できます。これ以外の場合に，ルートリソースアダプタを開始すると，コンソールまたは画面にエラーメッセージが出力され，リソースアダプタの開始に失敗します。

(4)　メンバリソースアダプタについての注意事項

メンバリソースアダプタでは，次の機能が前提となります。これらの機能は，デフォルトで有効となり，無効にすることはできません。

コネクションプーリング

コネクションプールの最大値に0より大きい値を設定してください。0以下の値を設定した場合，コネクションプールの最大値と最小値にデフォルト値が指定されたものとして動作します。

コネクション取得時のコネクションの障害検知

コネクション取得時のコネクションの障害検知およびコネクション障害検知のタイムアウトは，設定値に関係なく有効となります。

コネクション枯渇時のコネクション取得待ち

コネクション枯渇時のコネクション取得待ちは，設定値に関係なく有効となります。

loginTimeout

loginTimeoutのプロパティに0よりも大きい値を設定してください。0以下の値を設定した場合はデフォルト値が指定されたものとして動作します。

メンバリソースアダプタでは，次の機能を使用できません。これらの機能は，デフォルトで無効となり，有効にすることはできません。

コネクションの取得リトライ

J2EEリソースのユーザ指定名前空間

メンバコネクションプール内のコネクションは，すべて同じデータベースノードに接続している必要があるため，データベースで接続先を変更する機能は使用しないでください。次にその機能の例を挙げます。なお，各機能を無効にする設定については，オラクルのマニュアルを参照してください。

クライアント・ロード・バランシング機能

接続時フェイルオーバー機能

データベースサービス

リスナによる負荷分散機能

メンバリソースアダプタにアクセスするときは，必ずルートリソースアダプタを経由します。そのため，次の個所には設定できません。

J2EEアプリケーションのリソースリファレンス

CMP Entity Beanのマッピング定義

メンバリソースアダプタは，所属するルートリソースアダプタが停止状態の場合に停止できます。開始状態のときに，メンバリソースアダプタを停止すると，コンソールまたは画面にエラーメッセージが出力され，リソースアダプタの停止に失敗します。

メンバコネクションプールの閉塞および一時停止時，コネクションを破棄するために，コネクションプールから未使用コネクションを取り除きます。この際，コネクションの破棄が完了していない時点でコネクションプールが再開されると，コネクションプール内のコネクションとコネクションプールから取り除いた未使用コネクションの総数が，コネクションプールのコネクション数の最大値を一時的に超える場合があります。

19.1.4　クラスタコネクションプールの動作

コネクションプールをクラスタ化した場合に使用できる機能と動作について説明します。クラスタコネクションプールでは次の機能を実行できます。

コネクションプールの一時停止

コネクションプールの再開

また，コネクションプールの状態，およびコネクションの取得要求を受けたときの，コネクションプールの選択方式についても説明します。

(1)　コネクションプールの一時停止

メンバコネクションプールを閉塞および一時停止できます。一時停止を実行すると，メンバコネクションプールが閉塞し一時停止します。

J2EEアプリケーションがルートリソースアダプタにコネクション取得要求をした場合，閉塞または一時停止したメンバコネクションプールにはコネクション取得要求は出されません。

次の場合にメンバコネクションプールを一時停止してください。

データベースノードに障害が発生した場合

データベースノードのメンテナンスをする場合

なお，一時停止の方法には次の2とおりがあります。

自動一時停止

手動一時停止

参考

一時停止処理では，J2EEアプリケーションで使用し終わったコネクションを破棄し，コネクションプール内のすべてのコネクションを破棄してから，コネクションプールを一時停止します。ネットワーク障害やデータベースノード障害が発生した場合，ネットワークのタイムアウトまで待ってからコネクションを破棄するため，閉塞してから一時停止するまでに時間が掛かることがあります。

(a)　自動一時停止

データベースノードの障害時にメンバコネクションプールを自動で一時停止できます。障害を検知すると，メンバコネクションプールは自動的に閉塞状態になり，そのあと一時停止します。

コネクションの取得時に次の現象が発生した場合，データベースノードに障害が発生したと判断し，メンバコネクションプールが自動的に一時停止します。

コネクション取得時のコネクションの障害検知がタイムアウトした場合

物理コネクションの取得に失敗した場合

物理コネクションの取得がタイムアウトした場合

コネクション管理スレッドが枯渇した場合

この機能は，デフォルトで有効となっています。有効/無効の設定は，ルートリソースアダプタのプロパティとして設定します。リソースアダプタの設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「5.4　リソースアダプタのプロパティ定義」を参照してください。

(b)　手動一時停止

データベースノードのメンテナンスをする場合などに，cjsuspendpoolコマンドを実行することで，コネクションプールを手動で一時停止できます。手動一時停止は，メンバコネクションプールが開始状態，開始予約状態，自動一時停止状態，および自動一時停止予約状態の場合に実行できます。メンバコネクションプールが自動一時停止状態の場合にcjsuspendpoolコマンドを実行すると，手動一時停止状態になります。これによって，自動一時停止後に自動再開させない運用ができます。手動での一時停止手順については，「19.1.5(2)　コネクションプールの一時停止」を参照してください。コマンドの詳細については，「cjsuspendpool（メンバコネクションプールの一時停止）」を参照してください。

注意事項

cjsuspendpoolコマンドで手動一時停止したコネクションプールは，自動で再開されません。手動で再開してください。

(2)　コネクションプールの再開

一時停止したメンバコネクションプールを再開できます。J2EEアプリケーションからルートリソースアダプタにコネクション取得要求をした時に，再開したメンバコネクションプールには再びコネクションの取得要求が出されるようになります。

なお，コネクションプールを再開するには，未使用のコネクション管理スレッドの個数が，コネクションプールのコネクション数の最大数以上必要です。

次の場合にコネクションプールを再開してください。

データベースノードの障害が回復した場合

データベースノードのメンテナンスが終了した場合

再開の方法には次の2とおりがあります。

自動再開

手動再開

参考

コネクションプールが停止されている場合に，未使用のコネクション管理スレッドの個数がコネクションプールのコネクション数の最大数になると，メッセージが出力されます。cjresumepoolコマンドの実行に失敗した場合は，出力されたメッセージを確認してから再度コマンドを実行してください。

コネクションプールのウォーミングアップ機能が有効な場合には，コネクションプールの設定で定義した最小値までコネクションをプールしてから，メンバコネクションプールを開始します。コネクションをプーリングしているときにコネクションの生成に失敗した場合は，メンバコネクションプールは一時停止状態に戻ります。また，コネクションプールのウォーミングアップ機能が無効な場合は，すぐに開始状態になります。

(a)　自動再開

自動一時停止したメンバコネクションプールを自動で再開できます。

自動一時停止したメンバコネクションプールでは，データベースノードの状態をチェックするために，一定間隔で物理コネクションの取得要求を出します。このとき，コネクションの取得に成功すると，データベースノードが回復したと判断し，自動的に再開処理が行われます。また，自動一時停止したメンバコネクションプールを自動再開させない運用にするには，自動一時停止後に手動一時停止してください。再開時には，手動再開してください。

なお，ルートリソースアダプタが停止状態の場合，自動再開処理は行われません。ただし，メンバコネクションプールが自動再開中状態の場合にルートリソースアダプタを停止したときは，実行中の自動再開処理が継続されます。

この機能は，デフォルトで有効となっています。有効/無効の切り替えや，データベースノードの状態をチェックする間隔の設定は，ルートリソースアダプタのプロパティとして設定します。リソースアダプタの設定については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「5.4　リソースアダプタのプロパティ定義」を参照してください。

(b)　手動再開

自動一時停止または手動一時停止したコネクションプールを手動で再開できます。手動再開するには，cjresumepoolコマンドを使用します。手動再開は，コネクションプールが次の状態の場合に実行できます。

自動一時停止状態

手動一時停止状態

自動一時停止予約状態

手動一時停止予約状態

手動での手動再開手順については，「19.1.5(3)　コネクションプールの再開」を参照してください。コマンドの詳細については，「cjresumepool（メンバコネクションプールの再開始）」を参照してください。

(3)　コネクションプールの状態

コネクションプールの状態は，メンバコネクションプールの場合だけ存在するものです。なお，コネクションプールの状態は，J2EEサーバやリソースアダプタの再起動後も維持されます。

メンバコネクションプールの状態は次の方法で確認できます。手動一時停止または手動再開をする場合は，コマンドを実行する前にコネクションプールの状態を確認してください。

cjlistrarコマンド

cjlistrarコマンドは，デプロイされているすべてのリソースアダプタについて，リソースアダプタ名とリソースアダプタの状態を標準出力に出力します。-clusterpoolを指定した場合には，メンバコネクションプールの状態も表示できます。

コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistrar（リソースアダプタの一覧表示）」を参照してください。

cjlistpoolコマンド

cjlistpoolコマンドは，コネクションプールの情報を表示するコマンドです。メンバリソースアダプタの場合は，メンバコネクションプールの状態も表示できます。メンバリソースアダプタのコネクション情報の表示例については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「3.15.4　コネクションプールの情報表示」を参照してください。

コマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistpool（コネクションプールの一覧表示）」を参照してください。

ここでは，メンバコネクションプールの状態について説明します。

メンバコネクションプールの状態は，J2EEサーバやメンバリソースアダプタを再起動しても維持されます。コネクションプールの状態を確認する方法については，「19.1.5(1)　コネクションプールの状態の確認」を参照してください。

なお，メンバリソースアダプタ以外のコネクションプールには状態はありません。

(a)　コネクションプールの状態遷移

メンバコネクションプールの状態遷移を次の図に示します。

図19‒4　メンバコネクションプールの状態遷移（手動で一時停止を実行する場合）

図19‒5　メンバコネクションプールの状態遷移（自動で一時停止が実行される場合）

なお，J2EEサーバの開始時にコネクションプールが再開中状態，または閉塞状態の場合，コネクションプールは一時停止状態に遷移します。

それぞれの状態の詳細について次の表に示します。

表19‒5　メンバコネクションプールの状態

番号

状態

メッセージに表示される状態

説明

1

開始状態

running

コネクションプールが処理を受け付けている状態です。ルートリソースアダプタへのコネクション取得要求時には，開始状態のコネクションプールだけに処理が行われます。

2

開始予約状態

runningReserved

コネクションプールが開始状態のときにリソースアダプタが停止された状態です。開始予約状態のコネクションプールは，リソースアダプタの開始時に開始状態になります。リソースアダプタをデプロイした直後は，この状態になります。

3

自動再開中状態

resumingAutomatically

自動再開機能によって，コネクションプールが再開処理を行っている状態です。再開処理が成功すると開始状態になります。再開処理が失敗すると，自動一時停止状態に戻ります。自動再開中状態のコネクションプールには，ルートリソースアダプタへのコネクション取得要求時に処理が出されません。

4

手動再開中状態

resumingManuallyFromSuspendedAutomatically

resumingManuallyFromSuspendedManually

resumingManually

自動一時停止状態，または手動一時停止状態のときにcjresumepoolコマンドを実行して，コネクションプールが再開処理を行っている状態です。再開処理が成功すると，開始状態になります。再開処理が失敗すると，コマンド実行前の状態に戻ります。手動再開中状態のコネクションプールには，ルートリソースアダプタへのコネクション取得要求時に処理が出されません。

5

自動閉塞状態

blockedAutomatically

自動一時停止機能によって，コネクションプールが閉塞されて，一時停止処理を行っている状態です。一時停止処理が完了すると，自動一時停止状態になります。自動閉塞状態のコネクションプールには，ルートリソースアダプタへのコネクション取得要求時に処理が出されません。

6

手動閉塞状態

blockedManually

cjsuspendpoolコマンドによって，コネクションプールが閉塞され，一時停止処理を行っている状態です。一時停止処理が完了すると，手動一時停止状態になります。手動閉塞状態のコネクションプールには，ルートリソースアダプタへのコネクション取得要求時に処理が出されません。

7

自動一時停止状態

suspendedAutomatically

自動一時停止機能によって，コネクションプールが一時停止された状態です。コネクションプール内にコネクションは存在しません。自動一時停止状態のコネクションプールには，ルートリソースアダプタへのコネクション取得要求時に処理が出されません。

8

手動一時停止状態

suspendedManually

cjsuspendpoolコマンドによって，コネクションプールが一時停止された状態です。コネクションプール内にコネクションは存在しません。手動一時停止状態のコネクションプールには，ルートリソースアダプタへのコネクション取得要求時に処理が出されません。

9

自動一時停止予約状態

suspendedAutomaticallyReserved

コネクションプールが自動一時停止状態のときにリソースアダプタを停止した状態です。自動一時停止予約状態のコネクションプールは，リソースアダプタの開始時に自動一時停止状態になります。なお，このとき，コネクションプールのウォーミングアップ機能は無効になります。

10

手動一時停止予約状態

suspendedManuallyReserved

コネクションプールが手動一時停止状態のときにリソースアダプタを停止した状態です。手動一時停止予約状態のコネクションプールは，リソースアダプタの開始時に手動一時停止状態になります。なお，このとき，コネクションプールのウォーミングアップ機能は無効になります。

注　番号は，図19-4および図19-5中の番号を示します。

(b)　コネクションプールの状態によるコマンド実行の可否

コネクションプールの状態によって，実行できるコマンドと実行できないコマンドがあります。コネクションプールの状態ごとに，各コマンドの実行の可否を次に示します。

表19‒6　コネクションプールの状態によるコマンド実行の可否

コマンド

コネクションプールの状態

開始

開始予約

自動再開中/手動再開中

自動閉塞/手動閉塞

自動一時停止

手動一時停止

自動一時停止予約

手動一時停止予約

cjstartrar

×

○

×

×

×

×

○

○

cjstoprar

○

×

△※1

△※2

○

○

×

×

cjclearpool

○

×

×

×

×

×

×

×

cjlistrar

○

○

○

○

○

○

○

○

cjsuspendpool

○

○

×

×

○

×

○

×

cjresumepool

×

×

×

×

○

○

○

○

cjstopsv(通常停止時)

○

○

△※1

△※2

○

○

○

○

cjstopsv(強制停止時)

○

○

○

○

○

○

○

○

（凡例）　○：実行できる　△：制限あり　×：実行できない

注※1　コマンドは受け付けられますが，開始または一時停止状態になってから処理が実行されます。

注※2　コマンドは受け付けられますが，一時停止状態になってから処理が実行されます。

(4)　コネクションプールの選択方式

J2EEアプリケーションがルートリソースアダプタにコネクションの取得要求を出した時に，メンバコネクションプールが一つ選択されます。このときメンバコネクションプールが選択される方式は，ラウンドロビン方式です。

選択対象のコネクションプールは，開始状態のメンバコネクションプールです。コネクションに空きがあるメンバコネクションプールが優先的に選択されます。

ただし，コネクション枯渇状態のメンバコネクションプールしかない場合は，コネクション取得要求が待ち状態になります。さらに，コネクション取得待ちのタイムアウトが発生すると，コネクションの取得に失敗します。また，コネクション取得要求が待ち状態の場合にコネクションプールが閉塞されたときは，コネクション取得要求が再開され，次の優先度のメンバコネクションプールからコネクションの取得を試みます。すべてのメンバコネクションプールからコネクションが取得できない場合には，コネクションの取得に失敗します。

なお，開始状態のメンバコネクションプールがない場合にコネクション取得要求があったときには，コネクションの取得に失敗します。

また，各メンバコネクションプールの最大サイズを設定する場合，次の指針に従って設定します。

メンバコネクションプールの最大サイズ（数）＝システムで許容される最大同時接続数÷データベースノードの数

19.1.5　手動によるコネクションプールの停止・開始の流れ

ここでは，クラスタコネクションプールの流れについて説明します。データベースに発生した障害に対応する場合や，データベースをメンテナンスする場合，一部のコネクションプールを手動で停止，再開始することで，システム全体を止めることなくデータベースをメンテナンスできます。一部のコネクションプールを手動で停止，再開始して，データベースをメンテナンスする作業は次の流れで行います。

コネクションプールの状態を確認する（(1)参照）

サーバ管理コマンドを使用して実行します。

コネクションプールを一時停止する（(2)参照）

サーバ管理コマンドを使用して実行します。

コネクションプールを再開する（(3)参照）

サーバ管理コマンドを使用して実行します。

コネクションプールの状態を確認する（(1)参照）

サーバ管理コマンドを使用して実行します。

(1)　コネクションプールの状態の確認

クラスタ構成のデータベースをメンテナンスする前，およびメンテナンスしたあとに，コネクションプールの状態を確認します。

コネクションプールの状態の詳細については「19.1.4(3)　コネクションプールの状態」を参照してください。

コネクションプールの状態の確認は，cjlistrarコマンドで実行できます。

cjlistrarコマンドの実行形式と実行例を次に示します。

実行形式

cjlistrar <サーバ名> -clusterpool

実行例

cjlistrar MyServer -clusterpool

(2)　コネクションプールの一時停止

ここでは，コネクションプールを一時停止する手順について説明します。

コネクションプールの一時停止は，cjsuspendpoolコマンドで実行できます。cjsuspendpoolコマンドを実行すると，コネクションプールが閉塞されて一時停止状態になり，コネクション取得要求を受け付けなくなります。

cjsuspendpoolコマンドは，コネクションプールが次の状態の場合に実行できます。

開始

開始予約

自動一時停止

自動一時停止予約

コネクションプールの状態を確認する方法については，「19.1.5(1)　コネクションプールの状態の確認」を参照してください。

cjsuspendpoolコマンドの実行形式と実行例を次に示します。

実行形式

cjsuspendpool ＜サーバ名＞ -resname ＜一時停止対象となるメンバリソースアダプタの表示名＞

実行例

cjsuspendpool MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

(3)　コネクションプールの再開

ここでは，コネクションプールを再開する手順について説明します。

コネクションプールの再開は，cjresumepoolコマンドで実行できます。cjresumepoolコマンドを実行すると，コネクションプールは手動再開中状態になり，再開処理が実行されます。再開処理が完了すると，コネクションプールは開始状態になり，コネクション取得要求を受け付けるようになります。

cjresumepoolコマンドは，コネクションプールが次の場合に実行できます。

使用されていないコネクション管理スレッドが，コネクションプールのコネクションの最大値以上ある

コネクションプールが，手動一時停止，手動一時停止予約，自動一時停止，または自動一時停止予約の状態である

コネクションプールの状態を確認する方法については，「19.1.5(1)　コネクションプールの状態の確認」を参照してください。

cjresumepoolコマンドの実行形式と実行例を次に示します。

実行形式

cjresumepool ＜サーバ名＞ -resname ＜再開対象となるメンバリソースアダプタの表示名＞

実行例

cjresumepool MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

なお，cjresumepoolコマンドを実行したあと，コネクションプールの状態を確認して，再開処理が正しく実行されたかどうかを確認してください。コネクションプールの状態を確認する方法については，「19.1.5(1)　コネクションプールの状態の確認」を参照してください。

19.1.6　コネクションプールをクラスタ化するために必要な設定

コネクションプールをクラスタ化するためには，DB Connectorのプロパティ設定が必要になります。DB Connectorのプロパティ設定については，「19.3　データベースと接続するための設定（クラスタコネクションプールの場合）」を参照してください。

19.2　リソース接続

この節では，クラスタコネクションプール機能のリソースアダプタの設定の流れ（クラスタコネクションプールを使用する場合）について説明します。

19.2.1　リソースアダプタの設定の流れ（クラスタコネクションプールを使用する場合）

コネクションプールをクラスタ化している場合の，データベースに接続するときのリソースアダプタの設定の流れを次の図に示します。

図19‒6　クラスタコネクションプールでのリソースアダプタの設定の流れ

図中の1.〜10.について説明します。

サーバ管理コマンドを使用してメンバリソースアダプタをインポートします。

cjimportresコマンドを使用して，メンバリソースアダプタをインポートします。

インポートするリソースアダプタについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3.2　リソースアダプタの種類」を参照してください。

サーバ管理コマンドを使用してメンバリソースアダプタをデプロイします。

cjdeployrarコマンドを使用して，メンバリソースアダプタをデプロイします。

サーバ管理コマンドを使用してメンバリソースアダプタのプロパティを定義します。

cjgetrarpropコマンドでConnector属性ファイルを取得し，ファイル編集後に，cjsetrarpropコマンドで編集内容を反映させます。

メンバリソースアダプタとルートリソースアダプタのプロパティ定義では設定できる項目が異なります。メンバリソースアダプタおよびルートリソースアダプタで設定できるプロパティ定義の項目については，「19.1　クラスタコネクションプール機能」を参照してください。

使用する機能ごとに設定するリソースアダプタのプロパティについては，それぞれ次の個所を参照してください。

リソース接続とトランザクション管理機能を使用するための設定

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.4.12　実行環境での設定」

パフォーマンスチューニングのための機能

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.14.10　実行環境での設定」

フォールトトレランスのための機能

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.15.13　実行環境での設定」

J2EEリソースの別名の設定

マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「2.6.6　J2EEリソースの別名の設定」

サーバ管理コマンドを使用してメンバリソースアダプタの接続テストを実施します。

cjtestresコマンドを使用して，メンバリソースアダプタの接続テストを実施します。

メンバリソースアダプタの接続テストでの検証内容については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.17　リソースへの接続テスト」を参照してください。

また，1.〜4.までの流れを，メンバリソースアダプタの数だけ繰り返します。

サーバ管理コマンドを使用してメンバリソースアダプタを開始します。

ルートリソースアダプタの接続テストを実施する場合には，あらかじめメンバリソースアダプタを開始しておいてください。cjstartrarコマンドを使用して，メンバリソースアダプタを開始します。

サーバ管理コマンドを使用してルートリソースアダプタをインポートします。

cjimportresコマンドを使用して，ルートリソースアダプタをインポートします。

インポートするリソースアダプタについては，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.3.2　リソースアダプタの種類」を参照してください。

サーバ管理コマンドを使用してルートリソースアダプタをデプロイします。

cjdeployrarコマンドを使用してルートリソースアダプタをデプロイします。

サーバ管理コマンドを使用してルートリソースアダプタのプロパティを定義します。

cjgetrarpropコマンドでConnector属性ファイルを取得し，ファイル編集後に，cjsetrarpropコマンドで編集内容を反映させます。

サーバ管理コマンドを使用してルートリソースアダプタの接続テストを実施します。

cjtestresコマンドを使用して，ルートリソースアダプタの接続テストを実施します。

ルートリソースアダプタの接続テストでの検証内容については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「3.17　リソースへの接続テスト」を参照してください。

サーバ管理コマンドを使用してメンバリソースアダプタを停止します。

ルートリソースアダプタの接続テストを実施した場合には，メンバリソースアダプタを停止してください。cjstoprarコマンドを使用して，メンバリソースアダプタを停止します。

サーバ管理コマンドでの操作については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「3.　サーバ管理コマンドの基本操作」を参照してください。また，コマンドについては，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「2.4　J2EEサーバで使用するリソース操作コマンド」を参照してください。属性ファイルについては，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.　リソースの設定で使用する属性ファイル」を参照してください。

注意事項

コネクションプールをクラスタ化する場合，J2EEアプリケーションからルートリソースアダプタへのリファレンスを解決しておく必要があります。ルートリソースアダプタを使用しているJ2EEアプリケーションのプロパティを定義するときに，J2EEアプリケーションからルートリソースアダプタへのリファレンスを解決しておいてください。

19.3　データベースと接続するための設定（クラスタコネクションプールの場合）

DB Connectorで，Oracle RACのクラスタ化されたデータベースに接続する場合，コネクションプールをクラスタ化して使うことができます。クラスタコネクションプールの詳細については，「19.1　クラスタコネクションプール機能」を参照してください。

この節では，DB Connectorのコネクションプールをクラスタ化するための設定について説明します。

19.3.1　クラスタコネクションプールの概要

クラスタ化されたコネクションプールをクラスタコネクションプールといいます。ルートリソースアダプタとメンバリソースアダプタで構成されます。メンバリソースアダプタのコネクションプールをメンバコネクションプールといいます。

DB Connectorのクラスタコネクションプールを使用するための作業と状態の制御方法を次に示します。

(1)　クラスタコネクションプールの設定

クラスタコネクションプールを使用するためには，クラスタコネクションプールを使用できるリソースアダプタの設定が必要です。

クラスタコネクションプール用のDB Connectorの設定は，次の手順で実施します。

なお，手順1，2は，必要なメンバリソースアダプタの数だけ繰り返してください。

メンバリソースアダプタ用DB Connectorを設定します。

メンバリソースアダプタ用DB Connectorを，次の手順で設定します。

メンバリソースアダプタ用のDB ConnectorのRARファイルをインポートします。

プロパティを定義します。

DB Connectorをデプロイします。

接続を確認します。

正しく接続できるかどうかは，接続テストで確認できます。

メンバリソースアダプタ用DB Connectorを開始します。

ルートリソースアダプタ用DB Connectorを設定します。

ルートリソースアダプタ用DB Connectorを，次の手順で設定します。

ルートリソースアダプタ用のDB ConnectorのRARファイルをインポートします。

プロパティを定義します。

DB Connectorをデプロイします。

接続を確認します。

正しく接続できるかどうかは，接続テストで確認できます。

ルートリソースアダプタ用DB Connectorを開始します。

ルートリソースアダプタは，J2EEアプリケーションから直接アクセスされるので，デプロイしたルートリソースアダプタは，J2EEアプリケーションのプロパティ設定でリファレンスを解決する必要があります。詳細については，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「9.3.3　リソースアダプタのリファレンス定義」を参照してください。

参考

DB Connectorのプロパティを新規に設定する場合，Component Containerが提供しているテンプレートファイルが利用できます。

Connector属性ファイルのテンプレートファイルは，次に示すディレクトリに格納されています。

Windowsの場合

<Application Serverのインストールディレクトリ>¥CC¥admin¥templates¥

UNIXの場合

/opt/Cosminexus/CC/admin/templates/

このテンプレートファイルを使用すると，DB Connectorをインポートする前に，Connector属性ファイルを編集しておくことができます。なお，テンプレートファイルはコピーして使用してください。

Connector属性ファイルのテンプレートファイル名については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.13　Connector属性ファイルのテンプレートファイル」を参照してください。

なお，すでにプロパティが設定されているDB Connectorのプロパティを変更する場合は，テンプレートファイルは使用しないでください。インポートしたDB ConnectorのConnector属性を取得して，Connector属性ファイルを編集してください。

(2)　クラスタコネクションプールの状態と実行できる操作

メンバコネクションプールは，データベースの障害や保守などの場合，手動で一時停止できます。一時停止状態になると，ルートリソースアダプタへのコネクション取得要求時に処理が実行されません。

また，一時停止したメンバコネクションプールは，手動で再開できます。ルートリソースアダプタへのコネクション取得要求時には，開始状態のコネクションプールだけ処理が実行されます。

コネクションプールの状態制御については，「19.1.4　クラスタコネクションプールの動作」を参照してください。

(3)　リソースアダプタの種類による機能差異

リソースアダプタの種類で，使用できる機能を次に示します。

表19‒7　リソースアダプタの種類による機能一覧

機能

リソースアダプタの種類

ルートリソースアダプタ

メンバリソースアダプタ

コネクションプーリング

×

◎

コネクションプールのウォーミングアップ

×

○

コネクションシェアリング・アソシエーション

×

○

ステートメントプーリング

×

○

DataSourceオブジェクトのキャッシング

○

×

DB Connectorのコンテナ管理でのサインオンの最適化

×

○

コネクション障害検知

×

◎

コネクション障害検知のタイムアウト

×

◎

コネクション枯渇時のコネクション取得待ち

×

◎

コネクション取得リトライ

×

×

コネクションプール情報表示

×

○

コネクションプールクリア

×

○

コネクション自動クローズ

×

○

コネクションスイーパ

×

○

接続テスト

○

○

コネクションプール数調節機能

×

○

コネクションプール情報の表示

×

○

コネクションプールの一時停止※

×

○

コネクションプールの再開※

×

○

J2EEリソースのユーザ指定名前空間機能

○

×

（凡例）　◎：必ず有効になる　○：使用できる　×：使用できない

注※　コネクションプールをクラスタで使用しない場合，コネクションプールの一時停止および再開は実行できません。

DB Connectorの属性を設定するリソースアダプタの種類を次に示します。

表19‒8　リソースアダプタの種類と属性設定

設定項目

リソースアダプタの種類

ルートリソースアダプタ

メンバリソースアダプタ

トランザクションサポートレベル

×

○

ログ取得可否

○

○

データベース接続情報

−

○

DB Connector固有の設定（ステートメントプールなど）

−

○

セキュリティ情報（ユーザ名，パスワード）

×

○

コネクションプールサイズ

×

○

クラスタコネクションプール固有の設定

○

−

（凡例）　○：設定要　×：設定不要　−：設定項目なし

19.3.2　メンバリソースアダプタ用DB Connectorの設定

メンバリソースアダプタ用DB Connectorを，次の手順で設定します。

メンバリソースアダプタ用のDB Connectorをインポートします。

プロパティを定義します。

メンバリソースアダプタ用のDB Connectorをデプロイします。

接続を確認します。

(1)　メンバリソースアダプタ用のDB Connectorのインポート

次に示すコマンドを実行してメンバリソースアダプタ用のDB Connectorをインポートします。

(a)　実行形式

cjimportres ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -type rar -f ＜ファイルパス＞

＜ファイルパス＞には，RARファイルを指定してください。

RARファイルは，次のディレクトリに格納されています。

Windowsの場合

＜Application Serverのインストールディレクトリ＞¥CC¥DBConnector¥ClusterPool¥

UNIXの場合

/opt/Cosminexus/CC/DBConnector/ClusterPool/

メンバリソースアダプタとしてインポートするRARファイルについて説明します。

DBConnector_Oracle_CP_ClusterPool_Member.rar

クラスタコネクションプールのメンバリソースアダプタです。ローカルトランザクションまたはトランザクションなし（トランザクションサポートレベルにLocalTransactionまたはNoTransactionを指定する）で使用します。Oracle JDBC Thin DriverのConnectionPoolDataSourceを使用して，Oracleに接続します。

J2EEアプリケーションのリソースリファレンスに設定して使用することはできません。

(b)　実行例

cjimportres MyServer -type rar -f "c:¥Program Files¥Hitachi¥Cosminexus¥CC¥DBConnector¥ClusterPool¥DBConnector_Oracle_CP_ClusterPool_Member.rar"

cjimportresコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjimportres（リソースのインポート）」を参照してください。

(2)　メンバリソースアダプタ用のDB Connectorのプロパティ定義

メンバリソースアダプタ用のDB Connectorのプロパティを定義します。プロパティを定義する手順については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2.2　DB Connectorのプロパティ定義」を参照してください。ここでは，メンバリソースアダプタ用のDB Connectorのプロパティの設定項目を説明します。

(a)　メンバリソースアダプタ用DB Connectorの一般情報

設定できるDB Connectorの一般情報属性（<outbound-resourceadapter>タグ）の設定項目を次に示します。

項目

必須

対応するタグ

トランザクションサポートのレベル※

○

<transaction-support>

再認証のサポート有無

○

<reauthentication-support>

（凡例）　○：必須

注※　一つのクラスタコネクションプールを構成するメンバリソースアダプタのトランザクションサポートレベルは，すべて同じにしてください。

プロパティの設定項目については，マニュアル「アプリケーションサーバ リファレンス 定義編(アプリケーション／リソース定義)」の「4.1.1　Connector属性ファイルの指定内容」を参照してください。

(b)　メンバリソースアダプタ用コンフィグレーションプロパティ

メンバリソースアダプタ用DB Connectorのコンフィグレーションプロパティ（<config-property>タグ）と設定内容は，対応するリソースアダプタ（DBConnector_Oracle_CP.rar）と同じです。対応するリソースアダプタのコンフィグレーションプロパティについては，マニュアル「アプリケーションサーバアプリケーション設定操作ガイド」の「4.2.2　DB Connectorのプロパティ定義」を参照してください。

(c)　実行時プロパティ

メンバリソースアダプタ用DB Connectorの実行時プロパティ（<outbound-resourceadapter> - <connection-definition> - <connector-runtime>タグ）の設定項目を次に示します。

項目

対応するタグ

プロパティ名

<property-name>

プロパティのデータ型

<property-type>

プロパティの値

<property-value>

定義するプロパティの数だけ，上記の設定を繰り返してください。

プロパティ名（<property-name>）には，次の項目を設定します。

プロパティ項目

プロパティ名（<property-name>）の設定項目

ユーザ名※

User

パスワード※

Password

コネクションプールにプールするコネクションの最小値

MinPoolSize

コネクションプールにプールするコネクションの最大値

MaxPoolSize

ログを出力するかどうかの選択

LogEnabled

コネクションの最終利用時刻から，コネクションを自動破棄（コネクションスイーパ）するかを判定するまでの時間

ConnectionTimeout

コネクションの自動破棄（コネクションスイーパ）が動作する間隔

SweeperInterval

コネクション枯渇時のコネクション取得要求をキューで管理する場合の待ち時間の最大値

RequestQueueTimeout

コネクションプール監視のアラート出力を有効にするかどうかの選択

WatchEnabled

コネクションプールを監視する間隔

WatchInterval

コネクションプール使用状態を監視するしきい値

WatchThreshold

コネクションプール監視結果のファイルを出力するかどうかの選択

WatchWriteFileEnabled

コネクション数調節機能が動作する間隔

ConnectionPoolAdjustmentInterval

コネクションプールのウォーミングアップ機能を有効にするかどうかの選択

Warmup

注※　一つのクラスタコネクションプールを構成するメンバリソースアダプタのユーザ名は，すべて同じにしてください。

注意事項

メンバリソースアダプタでは，次の項目は設定の有無に関係なく，常に「有効」になります。

プロパティ項目

有効値

プロパティ名（<property-name>）の設定項目

コネクションプールにプールするコネクションの最小値

コネクションプーリング機能は常に有効

「MinPoolSize」，「MaxPoolSize」に「0」を設定しても，デフォルト値の「10」が仮定されます。

MinPoolSize

コネクションプールにプールするコネクションの最大値

MaxPoolSize

プール内のコネクションに障害が発生しているかどうかをチェックする方法の選択

常に「1」（コネクション取得時の障害検知）

ValidationType

コネクション枯渇時にコネクション取得要求をキューで管理するかどうかの選択

常に「true」

RequestQueueEnable

ネットワーク障害検知機能のタイムアウトを有効にするかどうかの選択

常に「true」

NetworkFailureTimeout

また，実行時プロパティのコネクションリトライ回数（「RetryCount」）とコネクションリトライ待ち時間（「RetryInterval」）の設定に関係なく，コネクション取得リトライ機能は，常に無効となります。

(3)　メンバリソースアダプタ用のDB Connectorのデプロイ

メンバリソースアダプタ用のDB Connectorは，デプロイするとJ2EEリソースアダプタとして使用できます。なお，デプロイしたあとで，プロパティを定義することもできます。デプロイ後に定義する場合は，該当するメンバリソースアダプタ用のDB Connectorが所属するルートリソースアダプタと，メンバリソースアダプタ用のDB Connectorを停止した状態で実行してください。プロパティを定義する方法については，「19.3.2(2)　メンバリソースアダプタ用のDB Connectorのプロパティ定義」を参照してください。

次に示すコマンドを実行してメンバリソースアダプタ用のDB Connectorをデプロイします。

実行形式

cjdeployrar ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -resname ＜メンバリソースアダプタ用のDB Connector表示名＞

実行例

cjdeployrar MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

cjdeployrarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjdeployrar（リソースアダプタのデプロイ）」を参照してください。

(4)　メンバリソースアダプタ用のDB Connectorの接続テスト

メンバリソースアダプタ用のDB Connectorに設定した情報が正しいかどうか，接続テストで検証します。

次に示すコマンドを実行して，メンバリソースアダプタ用のDB Connectorの接続テストを実施します。

実行形式

cjtestres ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -type rar -resname ＜メンバリソースアダプタ用のDB Connectorの表示名＞

実行例

cjtestres -type rar -resname DB_Connector_for_Oracle_ClusterPool_Member

cjtestresコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjtestres（リソースの接続テスト）」を参照してください。

注意事項

一度接続テストをしたメンバリソースアダプタ用のDB Connectorは，J2EEサーバを再起動するまで削除できません。メンバリソースアダプタ用のDB Connectorを削除する場合は，そのメンバリソースアダプタ用のDB Connectorが所属するルートリソースアダプタとメンバリソースアダプタ用のDB Connectorを停止してから，J2EEサーバを再起動してください。

19.3.3　ルートリソースアダプタ用DB Connectorの設定

ルートリソースアダプタ用DB Connectorを，次の手順で設定します。

ルートリソースアダプタ用のDB Connectorをインポートします。

プロパティを定義します。

ルートリソースアダプタ用のDB Connectorをデプロイします。

接続を確認します。

(1)　ルートリソースアダプタ用のDB Connectorのインポート

次に示すコマンドを実行してルートリソースアダプタ用のDB Connectorをインポートします。

(a)　実行形式

cjimportres ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -type rar -f ＜ファイルパス＞

＜ファイルパス＞には，RARファイルを指定してください。

RARファイルは，次のディレクトリに格納されています。

Windowsの場合

＜Application Serverのインストールディレクトリ＞¥CC¥DBConnector¥ClusterPool¥

UNIXの場合

/opt/Cosminexus/CC/DBConnector/ClusterPool/

ルートリソースアダプタとしてインポートするRARファイルについて説明します。

DBConnector_CP_ClusterPool_Root.rar

クラスタコネクションプールのルートリソースアダプタです。属するメンバリソースアダプタがローカルトランザクションまたはトランザクションなし（トランザクションサポートレベルにLocalTransactionまたはNoTransactionを指定する）で，データベースに接続する場合に使用します。

J2EEアプリケーションのリソースリファレンスに設定して使用します

(b)　実行例

cjimportres MyServer -type rar -f "c:¥Program Files¥Hitachi¥Cosminexus¥CC¥DBConnector¥ClusterPool¥DBConnector_CP_ClusterPool_Root.rar"

cjimportresコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjimportres（リソースのインポート）」を参照してください。

(2)　ルートリソースアダプタ用のDB Connectorのプロパティ定義

ルートリソースアダプタ用のDB Connectorのプロパティを定義します。プロパティを定義する手順については，マニュアル「アプリケーションサーバ アプリケーション設定操作ガイド」の「4.2.2　DB Connectorのプロパティ定義」を参照してください。ここでは，ルートリソースアダプタ用のDB Connectorのプロパティの設定項目を説明します。

ルートリソースアダプタ用のDB Connectorで，有効なプロパティを次に示します。下記以外の項目は，設定しても無視されます。

ルートリソースアダプタ用のDB Connectorの説明（<description>）

ルートリソースアダプタ用のDB Connector名称（<display-name>）

コンフィグレーションプロパティ（<outbound-resourceadapter> - <connection-definition> - <config-property>）

実行時プロパティ（<outbound-resourceadapter> - <connection-definition> - <connector-runtime>）のログを出力するかどうかの選択（<LogEnabled>）

別名情報（<outbound-resourceadapter> - <connection-definition> - <connector-runtime> - <resource-external-property>）

コンフィグレーションプロパティの設定項目を次に示します。

項目

対応するタグ

コンフィグレーションプロパティ名

<config-property-name>

コンフィグレーションプロパティのデータ型

<config-property-type>

コンフィグレーションプロパティの値

<config-property-value>

定義するコンフィグレーションプロパティの数だけ，上記の設定を繰り返してください。

DBConnector_CP_ClusterPool_Root.rarを使用する場合の，コンフィグレーションプロパティの設定項目と設定例を次の表に示します。

表19‒9　DBConnector_CP_ClusterPool_Root.rarを使用する場合のコンフィグレーションプロパティの設定例

項目名

設定例

algorithm

RoundRobin

enableAutoPoolSuspend

true

enableAutoPoolResume

true

dbCheckInterval

30

memberResourceAdapterName1

DB_Connector_for_Oracle_ClusterPool_Member1

memberResourceAdapterName2

DB_Connector_for_Oracle_ClusterPool_Member2

logLevel

ERROR

コンフィグレーションプロパティ名（<config-property-name>）の「memberResourceAdapterName[n]」プロパティは，メンバリソースアダプタの表示名を設定します。memberResourceAdapterName[n]は，デフォルトでは優先度2まで定義してあります。さらに，メンバリソースアダプタを指定する場合には，プロパティを追加してください。優先度nは，1〜100の範囲で指定してください。nは，連続している必要はありません。

(3)　ルートリソースアダプタ用のDB Connectorのデプロイ

ルートリソースアダプタ用のDB Connectorは，デプロイするとJ2EEリソースアダプタとして使用できます。なお，デプロイしたあとで，プロパティを定義することもできます。デプロイ後に定義する場合は，該当するルートリソースアダプタ用のDB Connectorを停止した状態で実行してください。プロパティを定義する方法については，「19.3.3(2)　ルートリソースアダプタ用のDB Connectorのプロパティ定義」を参照してください。

次に示すコマンドを実行してルートリソースアダプタ用のDB Connectorをデプロイします。

実行形式

cjdeployrar ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -resname ＜ルートリソースアダプタ用のDB Connector表示名＞

実行例

cjdeployrar MyServer -resname DB_Connector_for_ClusterPool_Root

cjdeployrarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjdeployrar（リソースアダプタのデプロイ）」を参照してください。

(4)　ルートリソースアダプタ用のDB Connectorの接続テスト

ルートリソースアダプタ用のDB Connectorに設定した情報が正しいかどうか，接続テストで検証します。

次に示すコマンドを実行して，ルートリソースアダプタ用のDB Connectorの接続テストを実施します。

実行形式

cjtestres ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -type rar -resname ＜ルートリソースアダプタ用のDB Connectorの表示名＞

実行例

cjtestres -type rar -resname DB_Connector_for_ClusterPool_Root

cjtestresコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjtestres（リソースの接続テスト）」を参照してください。

注意事項

一度接続テストをしたルートリソースアダプタ用のDB Connectorは，J2EEサーバを再起動するまで削除できません。ルートリソースアダプタ用のDB Connectorを削除する場合は，ルートリソースアダプタ用のDB Connectorを停止してから，J2EEサーバを再起動してください。

19.3.4　メンバリソースアダプタ用DB Connectorの開始と停止

(1)　メンバリソースアダプタ用のDB Connectorの開始

次に示すコマンドを実行してメンバリソースアダプタ用のDB Connectorを開始します。

実行形式

cjstartrar ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -resname ＜メンバリソースアダプタ用のDB Connectorの表示名＞

実行例

cjstartrar MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

cjstartrarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstartrar（リソースアダプタの開始）」を参照してください。

(2)　メンバリソースアダプタ用のDB Connectorの停止

次に示すコマンドを実行して，メンバリソースアダプタ用のDB Connectorを停止します。

実行形式

cjstoprar ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -resname ＜メンバリソースアダプタ用のDB Connectorの表示名＞

実行例

cjstoprar MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

cjstoprarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstoprar（リソースアダプタの停止）」を参照してください。

注意事項

メンバリソースアダプタが所属するルートリソースアダプタを停止してから，メンバリソースアダプタを停止してください。

19.3.5　ルートリソースアダプタ用DB Connectorの開始と停止

(1)　ルートリソースアダプタ用のDB Connectorの開始

次に示すコマンドを実行してルートリソースアダプタ用のDB Connectorを開始します。

実行形式

cjstartrar ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -resname ＜ルートリソースアダプタ用のDB Connectorの表示名＞

実行例

cjstartrar MyServer -resname DB_Connector_for_ClusterPool_Root

cjstartrarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstartrar（リソースアダプタの開始）」を参照してください。

注意事項

ルートリソースアダプタに所属するメンバリソースアダプタを開始してから，ルートリソースアダプタを開始してください。

(2)　ルートリソースアダプタ用のDB Connectorの停止

次に示すコマンドを実行して，ルートリソースアダプタ用のDB Connectorを停止します。

実行形式

cjstoprar ［＜サーバ名称＞］ ［-nameserver ＜プロバイダURL＞］ -resname ＜ルートリソースアダプタ用のDB Connectorの表示名＞

実行例

cjstoprar MyServer -resname DB_Connector_for_ClusterPool_Root

cjstoprarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjstoprar（リソースアダプタの停止）」を参照してください。

注意事項

J2EEアプリケーション中のJ2EEリソースがルートリソースアダプタ用のDB Connectorを参照している場合は，J2EEアプリケーションを停止してから，ルートリソースアダプタ用のDB Connectorを停止してください。

19.3.6　コネクションプールの状態の確認

クラスタコネクションプールで使用しているコネクションプールの状態は，次の二つの方法で参照できます。

cjlistrarコマンドで，デプロイされているすべてのリソースアダプタの，リソースアダプタ名とメンバコネクションプールの状態を参照します。

cjlistpoolコマンドで，メンバコネクションプールの情報を参照します。

メンバコネクションプールの情報を参照して，必要に応じてメンバコネクションプールを閉塞/一時停止/再開します。コネクションプールの状態定義については，「19.1.4　クラスタコネクションプールの動作」を参照してください。

(1)　コネクションプールの状態の参照

デプロイされているすべてのリソースアダプタについて，リソースアダプタ名とリソースアダプタの状態が表示されます。リソースアダプタがクラスタコネクションプールのメンバリソースアダプタの場合には，コネクションプールの状態も表示されます。

次に示すコマンドを実行して，コネクションプールの状態を参照します。

実行形式

cjlistrar ［＜サーバ名＞］ ［-nameserver ＜プロバイダURL＞］ -clusterpool

実行例

cjlistrar MyServer -clusterpool

cjlistrarコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistrar（リソースアダプタの一覧表示）」を参照してください。

(2)　メンバコネクションプールの情報の参照

コネクションプールの情報が表示されます。リソースアダプタがクラスタコネクションプールのメンバリソースアダプタの場合には，メンバコネクションプールの情報も表示されます。

次に示すコマンドを実行して，すべてのリソースアダプタのコネクションプール情報を参照します。

実行形式

cjlistpool ［＜サーバ名＞］ ［-nameserver ＜プロバイダURL＞］ -resall

実行例

cjlistpool MyServer -resall

特定のリソースアダプタについて，コネクションプールの情報を表示する場合は次のコマンドを実行します。

実行形式

cjlistpool ［＜サーバ名＞］ -resname ＜リソースアダプタの表示名＞

実行例

cjlistpool MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

リソースアダプタのコネクションプール情報が表示されます。

cjlistpoolコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjlistpool（コネクションプールの一覧表示）」を参照してください。

注意事項

cjlistpoolコマンドは，ルートリソースアダプタに対しては実行できません。

19.3.7　コネクションプールの一時停止

データベースの障害や保守などの場合，メンバコネクションプールを手動で一時停止できます。一時停止したコネクションプールは，コネクション取得要求を受け付けません。

次のコマンドを実行して，クラスタコネクションプールのメンバコネクションプールを一時停止します。

実行形式

cjsuspendpool ［＜サーバ名＞］ ［-nameserver ＜プロバイダURL＞］ -resname ＜一時停止対象となるメンバリソースアダプタの表示名＞

実行例

cjsuspendpool MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

cjsuspendpoolコマンドの詳細については，「cjsuspendpool（メンバコネクションプールの一時停止）」を参照してください。

注意事項

cjsuspendpoolコマンドを使用して，手動で一時停止したコネクションプールは，自動再開はできません。cjresumepoolコマンドで手動再開してください。

19.3.8　コネクションプールの再開

一時停止したメンバコネクションプールは手動で再開できます。J2EEアプリケーションがルートリソースアダプタにコネクション取得要求をしたときに，再開したコネクションプールは，再びコネクション取得要求を受け付けることができるようになります。

次のコマンドを実行して，クラスタコネクションプールのメンバコネクションプールを再開します。

実行形式

cjresumepool ［＜サーバ名＞］ ［-nameserver ＜プロバイダURL＞］ -resname ＜再開対象となるメンバリソースアダプタの表示名＞

実行例

cjresumepool MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

cjresumepoolコマンドの詳細については，「cjresumepool（メンバコネクションプールの再開始）」を参照してください。

19.4　設定する項目と操作の概要

次のリソースアダプタの設定でのアプリケーション設定操作の概要を示します。

データベースと接続するための設定（クラスタコネクションプールの場合）

19.4.1　データベースと接続するための設定（クラスタコネクションプールの場合）

DB Connectorのコネクションプールをクラスタ化で使用する場合に必要な作業です。

表19‒10　データベースと接続するための設定（クラスタコネクションプールの場合）の概要

設定項目

内容

参照先

メンバリソースアダプタ用DB Connectorの設定

メンバリソースアダプタ用DB Connectorをインポート，設定，接続テストまで実行します。

19.3.2

ルートリソースアダプタ用DB Connectorの設定

ルートリソースアダプタ用DB Connectorをインポート，設定，接続テストまで実行します。

19.3.3

メンバリソースアダプタ用DB Connectorの開始と停止

メンバリソースアダプタ用DB Connectorを開始します。また，開始状態にあるメンバリソースアダプタ用DB Connectorを停止します。

19.3.4

ルートリソースアダプタ用DB Connectorの開始と停止

ルートリソースアダプタ用DB Connectorを開始します。また，開始状態にあるルートリソースアダプタ用DB Connectorを停止します。

19.3.5

コネクションプールの状態の確認

メンバコネクションプールの状態を参照します。

19.3.6

コネクションプールの一時停止

メンバコネクションプールを一時停止の状態にします。

19.3.7

コネクションプールの再開

一時停止の状態のメンバコネクションプールを再開します。

19.3.8

19.5　J2EEサーバで使用するリソース操作コマンド

ここでは，J2EEサーバで使用するリソース操作コマンドのうち，cjresumepool（メンバコネクションプールの再開始）およびcjsuspendpool（メンバコネクションプールの一時停止）について説明します。

cjresumepool（メンバコネクションプールの再開始）

形式

cjresumepool [<サーバ名称>] [-nameserver <プロバイダURL>]
             -resname <リソースアダプタ表示名>
             [-resname <リソースアダプタ表示名> ...]

機能

指定したクラスタコネクションプールのメンバコネクションプールを再開します。一度に複数のメンバコネクションプールの再開もできます。再開に失敗したメンバコネクションプールがあった場合でも，すべてのメンバコネクションプールに対して再開を試みます。一つでも再開できなかった場合は，異常終了します。

リソースアダプタが開始状態の場合，このコマンドを実行すると，メンバコネクションプールは手動再開中状態になります。次に，メンバコネクションプールのウォーミングアップ機能が有効な場合は，メンバコネクションプール内にコネクションをプールし，その後，メンバコネクションプールは開始状態となります。

リソースアダプタが停止状態の場合，このコマンドを実行すると，メンバコネクションプールは開始予約状態になります。

引数

<サーバ名称>

接続先J2EEサーバ名称を指定します。サーバ名称を省略したときは，ホスト名称がサーバ名称として使用されます。

-nameserver <プロバイダURL>

CORBAネーミングサービスへのアクセスプロトコル，CORBAネーミングサービスが稼働しているホスト名，およびそれが使用しているポート番号を次に示す形式で指定します。

<プロトコル名称>::<ホスト名称>:<ポート番号>

指定内容の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「2.1.2　プロバイダURLについて」を参照してください。

-resname <リソースアダプタ表示名>

再開対象となるメンバリソースアダプタの表示名を指定します。

クラスタコネクションプールのメンバリソースアダプタでないリソースアダプタを指定した場合，異常終了となります。

この引数は，指定したリソースアダプタの開始/停止状態に関係なく，このコマンド自体を実行できます。ただし，メンバコネクションプールの状態によって，コマンドを実行できる場合とできない場合があります。詳細は次の表を参照してください。

メンバコネクションプールの状態

コマンドの実行可否

自動一時停止状態

手動一時停止状態

自動一時停止予約状態

手動一時停止予約状態

実行可能

開始状態

開始予約状態

自動再開中状態

手動再開中状態

自動閉塞状態

手動閉塞状態

実行不可

入力例

cjresumepool MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

戻り値

0：

正常終了しました。

1：

異常終了しました。

2：

排他エラーによってコマンドが実行できません。

3：

タイムアウトエラーが発生しました。

9：

管理者特権がないため，コマンドが実行できません（Windows Server 2012，Windows Server 2008，Windows 8，Windows 7またはWindows Vistaの場合）。

注意事項

コマンドの引数にサーバ名称を指定する場合，コマンド名の直後にする必要があります。そのほかの引数は，サーバ名称より後ろ（サーバ名称を省略した場合はコマンド名の後ろ）にあれば順序は任意です。ただし，オプション名と値の順序の入れ替え（例：<アプリケーション名> -name）やオプション名と値を非対応にすること（例：-nameserver <アプリケーション名> -name <プロバイダURL>）はできません。

コマンドの引数にサーバ名称を指定する場合，cjsetupコマンドで指定したサーバ名称と大文字・小文字を一致させた文字列を指定する必要があります。cjsetupコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjsetup（J2EEサーバのセットアップとアンセットアップ）」を参照してください。

cjsuspendpool（メンバコネクションプールの一時停止）

形式

cjsuspendpool [<サーバ名称>] [-nameserver <プロバイダURL>]
              -resname <リソースアダプタ表示名>
              [-resname <リソースアダプタ表示名> ...]

機能

クラスタコネクションプールのメンバコネクションプールを一時停止します。一度に複数のメンバコネクションプールの一時停止もできます。一時停止に失敗したメンバコネクションプールがある場合でも，すべてのメンバコネクションプールに対して一時停止を試みます。どれか一つでも一時停止できなかった場合は異常終了となります。

リソースアダプタが開始状態のときに，このコマンドを実行すると，メンバコネクションプールは手動閉塞状態になり，コマンドは終了します。その後，J2EEサーバでは一時停止処理が行われます。一時停止処理が完了すると，メンバコネクションプールは手動一時停止状態になります。

リソースアダプタが停止状態のときに，このコマンドを実行すると，メンバコネクションプールは手動一時停止予約状態になります。

引数

<サーバ名称>

接続先J2EEサーバ名称を指定します。サーバ名称を省略したときは，ホスト名称がサーバ名称として使用されます。

-nameserver <プロバイダURL>

CORBAネーミングサービスへのアクセスプロトコル，CORBAネーミングサービスが稼働しているホスト名，およびそれが使用しているポート番号を次に示す形式で指定します。

<プロトコル名称>::<ホスト名称>:<ポート番号>

指定内容の詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「2.1.2　プロバイダURLについて」を参照してください。

-resname <リソースアダプタ表示名>

一時停止対象となるメンバリソースアダプタの表示名を指定します。

クラスタコネクションプールのメンバリソースアダプタの表示名以外を指定した場合，異常終了となります。

この引数は，指定したリソースアダプタの開始/停止状態に関係なく，このコマンド自体を実行できます。ただし，メンバコネクションプールの状態によって，コマンドを実行できる場合とできない場合があります。詳細は次の表を参照してください。

メンバコネクションプールの状態

コマンドの実行可否

開始状態

開始予約状態

自動一時停止状態

自動一時停止予約状態

実行可能

手動一時停止状態

手動一時停止予約状態

自動再開中状態

手動再開中状態

自動閉塞状態

手動閉塞状態

実行不可

入力例

cjsuspendpool MyServer -resname DB_Connector_for_Oracle_ClusterPool_Member

戻り値

0：

正常終了しました。

1：

異常終了しました。

2：

排他エラーによってコマンドが実行できません。

3：

タイムアウトエラーが発生しました。

9：

管理者特権がないため，コマンドが実行できません（Windows Server 2012，Windows Server 2008，Windows 8，Windows 7またはWindows Vistaの場合）。

注意事項

コマンドの引数にサーバ名称を指定する場合，コマンド名の直後にする必要があります。そのほかの引数は，サーバ名称より後ろ（サーバ名称を省略した場合はコマンド名の後ろ）にあれば順序は任意です。ただし，オプション名と値の順序の入れ替え（例：<データソース表示名> -resname）やオプション名と値を非対応にすること（例：-nameserver <データソース表示名> -resname <プロバイダURL>）はできません。

コマンドの引数にサーバ名称を指定する場合，cjsetupコマンドで指定したサーバ名称と大文字・小文字を一致させた文字列を指定する必要があります。cjsetupコマンドの詳細については，マニュアル「アプリケーションサーバ リファレンス コマンド編」の「cjsetup（J2EEサーバのセットアップとアンセットアップ）」を参照してください。

19.6　Connector属性ファイル

Connector属性ファイルは，リソースアダプタの属性を取得，編集する場合に使用するファイルです。

19.6.1　DB Connectorに設定する<config-property>タグに指定できるプロパティ

次に示すDB Connectorに設定する<config-property>タグに指定できる値について説明します。

クラスタコネクションプールを使用してOracleに接続する場合（ルートリソースアダプタ）

クラスタコネクションプールを使用してOracleに接続する場合（メンバリソースアダプタ）

(1)　クラスタコネクションプールを使用してOracleに接続する場合（ルートリソースアダプタ）

DBConnector_CP_ClusterPool_Root.rar

トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

指定できるプロパティについては，次の表を参照してください。

表19‒11　DBConnector_CP_ClusterPool_Root.rarを使用する場合に指定できるプロパティ

config-property-name

config-property-type

config-property-value

algorithm

java.lang.String

クラスタコネクションプール機能のコネクションプール選択方式を指定します。

RoundRobin

最後に選択したコネクションプールの次の優先度のコネクションプールから優先度順に，コネクションの取得を試みます。優先度が最も低いコネクションプールに達した場合には，優先度が最も高いコネクションプールが選択されます。すべてのコネクションプールからコネクションが取得できない場合は，例外となります。

クラスタデータベースがアクティブ/アクティブ構成で，各インスタンスで負荷分散を図る場合に指定します。

デフォルト値はRoundRobinです。

dbCheckInterval

java.lang.Integer

一時停止状態のコネクションプールで，DBノードの状態をチェックする間隔を，2〜2147483647の整数（単位：秒）で指定します。有効範囲外の値を指定した場合には，デフォルト値となります。デフォルト値は30です。

メンバリソースアダプタでOracle JDBC Thin Driverを使用するときは，各メンバリソースアダプタのloginTimeoutプロパティの値よりも長い時間を指定してください。

enableAutoPoolResume

java.lang.Boolean

コネクションプールの自動再開機能を有効とするか，無効とするかを指定します。

trueを設定した場合

コネクションプールの自動再開機能が有効となります。

falseを設定した場合

コネクションプールの自動再開機能が無効となります。

デフォルト値はtrueです。

enableAutoPoolSuspend

java.lang.Boolean

コネクションプールの自動一時停止機能を有効とするか，無効とするかを指定します。

trueを設定した場合

コネクションプールの自動一時停止機能が有効となります。

falseを設定した場合

コネクションプールの自動一時停止機能が無効となります。

デフォルト値はtrueです。

logLevel

java.lang.String

DB Connectorが出力するログ・トレースのレベルを指定します。

次の値が指定できます。

0またはERROR

10またはWARNING

20またはINFORMATION

デフォルト値は，0またはERRORです。

memberResourceAdapterName[n]

java.lang.String

優先度nのメンバリソースアダプタの表示名を指定します。このプロパティは，デフォルトでは定義されていないので，必要に応じて追加してください。nは1〜100の範囲で指定します。

memberResourceAdapterName1

java.lang.String

優先度1のメンバリソースアダプタの表示名を指定します。優先度は値が小さいほど高くなります。

memberResourceAdapterName2

java.lang.String

優先度2のメンバリソースアダプタの表示名を指定します。

(2)　クラスタコネクションプールを使用してOracleに接続する場合（メンバリソースアダプタ）

DBConnector_Oracle_CP_ClusterPool_Member.rar

トランザクション管理をしない場合，またはローカルトランザクションを使用する場合に使用します。

指定できるプロパティについては，次の表を参照してください。

表19‒12　DBConnector_Oracle_CP_ClusterPool_Member.rarを使用する場合に指定できるプロパティ

config-property-name

config-property-type

config-property-value

CallableStatementPoolSize

「機能解説 基本・開発編(コンテナ共通機能)」−「3.14.4」

java.lang.Integer

コネクションプールに割り当てられるコネクションごとのCallableStatementのプール数を設定します。デフォルトは10です。

0を指定した場合，ステートメントをプールしません。

CancelStatement

java.lang.Boolean

トランザクションタイムアウトやアプリケーション強制停止時に，Statementクラス，CallableStatementクラスおよびPreparedStatementクラスで実行中のSQLをキャンセルするかどうかを指定します。

trueを指定した場合

実行中のSQLをキャンセルします。

falseを指定した場合

実行中のSQLをキャンセルしません。

デフォルト値はtrueです。

専用サーバ接続をする場合は，falseを指定してください。

ConnectionIDUpdate

java.lang.Boolean

コネクションIDをDataSource#getConnectionメソッドごとに更新するかどうかを指定します。

trueを指定した場合

DataSource#getConnectionメソッドのたびにコネクションIDを生成します。

falseを指定した場合

最初のDataSource#getConnectionメソッドでコネクションIDを生成し，そのあとは更新しません。

デフォルト値はfalseです。

databaseName

java.lang.String

Oracleサーバ上の特定のデータベース名（SID）を指定します。設定された値は，Oracle JDBC Thin DriverのDataSource系インタフェースのsetDatabaseNameメソッドに渡されます。

loginTimeout

java.lang.Integer

データベースへの接続試行のタイムアウトを，1〜2147483647の整数（単位：ミリ秒）で指定します。

有効範囲外の値を指定した場合には，デフォルト値が使用されます。デフォルト値は8000です。設定された値は秒単位に切り上げてOracle JDBC Thin DriverのDataSource系インタフェースのsetLoginTimeoutメソッドに渡されます。

logLevel

java.lang.String

DB Connectorが出力するログ・トレースのレベルを指定します。

次の値が指定できます。

0またはERROR

10またはWARNING

20またはINFORMATION

デフォルトは，0またはERRORです。

portNumber

java.lang.Integer

Oracleのサーバが要求をリスニングするポート番号を指定します。デフォルトは1521番ポートです。設定された値は，Oracle JDBC Thin DriverのDataSource系インタフェースのsetPortNumberメソッドに渡されます。

PreparedStatementPoolSize

「機能解説 基本・開発編(コンテナ共通機能)」−「3.14.4」

java.lang.Integer

コネクションプールに割り当てられるコネクションごとのPreparedStatementのプール数を設定します。デフォルトは10です。

0を指定した場合，ステートメントをプールしません。

serverName

java.lang.String

Oracleサーバのホスト名またはIPアドレスを指定します。設定された値は，Oracle JDBC Thin DriverのDataSource系インタフェースのsetServerNameメソッドに渡されます。

url

java.lang.String

Oracle JDBC Thin Driverがデータベースに接続するために必要なJDBC URLを指定します。設定された値はOracle JDBC Thin DriverのsetURLメソッドに渡されます。

このプロパティに値が設定された場合，databaseName，portNumber，serverNameで指定された値は無視されます。また，ユーザがurlで指定を行う場合はJDBC URLにthinドライバを指定します。

（例）

jdbc:oracle:thin:@ServerA:1521:service1

20　スレッドの非同期並行処理

この章では，Timer and Work Manager for Application Serversに準拠したTimerManagerおよびWorkManagerによるスレッドの非同期並行処理について説明します。

この機能は互換機能のため推奨しません。Java EE標準の，Concurrency Utilities for Java EEの使用を検討してください。

20.1　この章の構成

スレッドの非同期並行処理の機能と参照先を次の表に示します。

表20‒1　スレッドの非同期並行処理の機能

機能名

参照先

スレッドの非同期並行処理の概要

20.2

TimerManagerを使用した非同期タイマ処理

20.3

WorkManagerを使用した非同期スレッド処理

20.4

20.2　スレッドの非同期並行処理の概要

アプリケーションサーバでは，Java EE環境で非同期タイマ処理や非同期スレッド処理などのスレッドの非同期並行処理を実行できます。

Java EEの標準仕様では，サーブレットから新しいスレッドを生成したりEJBがスレッドを管理したりできません。また，スレッドの非同期並行処理は原則的に推奨されていません。そのため，アプリケーションサーバでは，Java EE環境でスレッドの非同期並行処理を実現するために，CommonJが定めたTimer and Work Manager for Application Serversの仕様に基づいたAPIを提供します。

スレッドの非同期並行処理を実現するためのAPIの概要を次に示します。

TimerManager

Timer for Application Serversの仕様に準拠したAPIです。このAPIを使用すると，実行間隔を指定してスレッドの非同期処理をスケジューリングできます。この機能を非同期タイマ処理と呼びます。

WorkManager

Work Manager for Application Serversの仕様に準拠したAPIです。このAPIを使用すると，スレッドの非同期処理ができます。この機能を非同期スレッド処理と呼びます。

TimerManagerおよびWorkManagerは，EJBまたはサーブレットから使用できます。

アプリケーションサーバの，Timer and Work Manager for Application Serversへの対応状況については，「20.2.3　Timer and Work Manager for Application Serversとの対応」を参照してください。

20.2.1　スレッドの非同期並行処理の流れ

スレッドの非同期並行処理を実行するには，EJBおよびサーブレットからTimerManagerまたはWorkManagerをルックアップします。ここでは，TimerManagerを使用した非同期タイマ処理，およびWorkManagerを使用した非同期スレッド処理の流れについて説明します。

TimerManagerを使用した非同期タイマ処理の流れ

TimerManagerを使用した非同期タイマ処理の流れを次の図に示します。

図20‒1　TimerManagerを使用した非同期タイマ処理の流れ

EJBおよびサーブレットは，実行する非同期並行処理を呼び出す，スケジュール元となります。

TimerManagerは，JNDIによるルックアップ時に作成されます。実行する処理の実体は，TimerManagerが提供するリスナであるTimerListenerに実装します。TimerListenerは，必要に応じてJNDIやJCAにアクセスして処理を実行します。

WorkManagerを使用した非同期スレッド処理の流れ

WorkManagerを使用した非同期スレッド処理の流れを次の図に示します。

図20‒2　WorkManagerを使用した非同期スレッド処理の流れ

EJBおよびサーブレットは，実行する非同期並行処理を呼び出す，スケジュール元となります。

WorkManagerは，アプリケーション開始時に作成されます。JNDIによってルックアップされた場合は，アプリケーション開始時に作成されたWorkManagerを返します。実行する処理の実体は，WorkManagerが提供するWorkまたはWorkListenerに実装します。WorkまたはWorkListenerは，必要に応じてJNDIやJCAにアクセスして処理を実行します。

20.2.2　スレッドの非同期並行処理で使用できるJava EEの機能

非同期並行処理として実行する処理の中では，Java EEの機能を使用できます。Java EEの機能を使用できるTimerManagerおよびWorkManagerのAPIを次に示します。

TimerManager

TimerListener.timerExpired

設定した時間に達したときに実行されるメソッドです。

StopTimerListener.timerStop

TimerManager.stopメソッドが実行されたとき，またはアプリケーションが停止したときに実行されるメソッドです。

CancelTimerListener.timerCancel

TimerManager.cancelメソッドが実行されたときに実行されるメソッドです。

WorkManager

Work.run

WorkManagerで非同期に実行される処理メソッドです。

WorkListener.workAccepted

スケジュールしたWorkをWorkManagerが受け付けるときに実行されるメソッドです。

WorkListener.workCompleted

スケジュールされたWorkのrunメソッドが終了した直後に実行されるメソッドです。

WorkListener.workRejected

スケジュールしたWorkをWorkManagerが受け付けたあとに，スケジュール処理を継続できなくなった場合に実行されるメソッドです。

WorkListener.workStarted

スケジュールされたWorkのrunメソッドが実行される直前に実行されるメソッドです。

それぞれのAPIの詳細については，Timer and Work Manager for Application ServersのAPI仕様を参照してください。

TimerManagerおよびWorkManagerで使用できるJava EE機能を次の表に示します。

表20‒2　TimerManagerおよびWorkManagerで使用できるJava EEの機能

機能名

使用可否

参照先

Enterprise Beanの呼び出し

×

−

ネーミングサービス

○※

(1)

トランザクションサービスとリソース接続

○※

(2)

ログとトレースの出力

○

(3)

コンテナ拡張ライブラリの利用

○

(4)

メソッドキャンセル

×

−

（凡例）

○：使用できる

×：使用できない

−：該当なし

注※

ただし，一部の機能については使用できません。使用できる機能については，「参照先」の列に示す情報を参照してください。

次に，TimerManagerおよびWorkManagerで使用できる機能を詳細に分類して説明します。また，それぞれの機能を使用する場合の注意事項についても説明します。

(1)　ネーミングサービス

ネーミングサービスとして提供する機能がTimerManagerおよびWorkManagerで使用できるかどうかを次の表に示します。

表20‒3　ネーミングサービスの機能の使用可否

機能名

使用可否

JNDIを使用したDB Connectorのルックアップ

○

JNDIを使用したJava Mailのルックアップ

×

JNDIを使用したJavaBeansリソースのルックアップ

×

JNDIを使用したEntityManagerのルックアップ

×

JNDIを使用したEntityManagerFactoryのルックアップ

×

JNDIを使用したTimerManagerのルックアップ

×※1

JNDIを使用したWorkManagerのルックアップ

×※1

JNDIを使用したユーザトランザクションのルックアップ

○※2

（凡例）

○：使用できる

×：使用できない

注※1　TimerManagerやWorkManagerのスケジュールの延長で，さらにTimerManagerやWorkManagerを呼び出すことはできません。

注※2　スケジュール元が，CMTでトランザクションを管理するEJBの場合は，java:comp/UserTransactionでルックアップできません。必ずHITACHI_EJB/SERVERS/<J2EEサーバ名>/SERVICES/UserTransactionを使用してルックアップしてください。

注意事項

スケジュール元で取得したDB ConnectorやユーザトランザクションをWorkManagerまたはTimerManager中で使用しないでください。必ず実行した処理を実装したTimerListenerまたはWork内で取得してください。

(2)　トランザクションサービスとリソース接続

リソースアダプタには，DB Connectorだけを使用できます。TimerManagerおよびWorkManagerで使用できるDB Connectorを次の表に示します。

表20‒4　DB Connectorの使用可否

DB Connector名

使用可否

DBConnector_HiRDB_Type4_CP.rar

○

DBConnector_HiRDB_Type4_XA.rar

○

DBConnector_Oracle_CP.rar

○

DBConnector_Oracle_XA.rar

○

DBConnector_MySQL_CP.rar

×

DBConnector_PostgreSQL_CP.rar

×

DBConnector_HiRDB_Type4_CP_Cosminexus_RM.rar

×

DBConnector_HiRDB_Type4_XA_Cosminexus_RM.rar

×

DBConnector_Oracle_CP_Cosminexus_RM.rar

×

DBConnector_Oracle_XA_Cosminexus_RM.rar

×

DBConnector_CP_ClusterPool_Root.rar

×

DBConnector_Oracle_CP_ClusterPool_Member.rar

×

（凡例）

○：使用できる

×：使用できない

DB Connectorを使用する場合，トランザクションサポートレベルには，NoTransaction，LocalTransaction，またはXATransactionを指定してください。DB Connectorのコネクションを取得するには，DB Connectorの別名を設定する必要があります。JNDIによるルックアップでは，設定した別名を使用して，DB Connectorのコネクションを取得してください。DB Connectorの別名を使用したコネクションの取得方法については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「2.6　Enterprise BeanまたはJ2EEリソースへの別名付与（ユーザ指定名前空間機能）」を参照してください。

リソース接続およびトランザクションサービスとして提供する機能がTimerManagerおよびWorkManagerで使用できるかどうかを次の表に示します。

表20‒5　トランザクションサービスの機能の使用可否

機能名

使用可否

トランザクション

（ユーザトランザクション）

ローカルトランザクション

○

グローバルトランザクション

○

トランザクションの自動決着※1

△

トランザクションタイムアウト

○

コネクションプーリング

DB Connectorによるコネクションプーリング

○

コネクションプールのウォーミングアップ

○

コネクション数調節

○

コネクションシェアリング※2

△

コネクションアソシエーション

×

DB Connectorのステートメントプーリング

○

コネクションの障害検知

○

コネクション枯渇時のコネクション取得待ち

○

コネクション取得リトライ

○

コネクション自動クローズ

×

コネクションスイーパ

○

障害調査用SQLの出力

○

（凡例）

○：使用できる

△：一部の機能が使用できない

×：使用できない

注※1　ユーザトランザクションは，リスナの処理メソッドからリターンする前に決着する必要があります。トランザクションが決着していない場合，例外が発生しなくてもトランザクションはロールバックされて，メッセージ（KDJE43179-W）が出力されます。

注※2　シェアリングできるコネクションの範囲は，デフォルトで設定される「同一トランザクション」だけです。

注意事項

取得したDB Connectorのコネクションは自動でクローズされないため，必ずメソッド内でコネクションをクローズするように設定してください。

(3)　ログとトレースの出力

ログとトレースを出力する機能がTimerManagerおよびWorkManagerで使用できるかどうかを次の表に示します。

表20‒6　ログとトレースの機能の使用可否

機能名

使用可否

ユーザログ

○

性能解析トレース

○

（凡例）

○：使用できる

参考

性能解析トレースのオペレーション名について

TimerManagerおよびWorkManagerの性能解析トレースでは，スケジュールごとに一意の番号を取得できます。この情報は，トレース情報のオペレーション名に出力されます。取得できるトレース情報の詳細については，マニュアル「アプリケーションサーバ機能解説 保守／移行編」の「8.　性能解析トレースのトレース取得ポイントとPRFトレース取得レベル」を参照してください。

(4)　コンテナ拡張ライブラリの利用

コンテナ拡張ライブラリの機能は，TimerManagerおよびWorkManagerを使用しない場合と同様に使用できます。

20.2.3　Timer and Work Manager for Application Serversとの対応

Timer and Work Manager for Application Serversの仕様で，ベンダ依存と規定されている仕様には，アプリケーションサーバでは対応していません。また，CommonJが提供するAPIとアプリケーションサーバが提供するAPIには，仕様差があります。ここでは，アプリケーションサーバが対応していないTimer for Application Serversの仕様，アプリケーションサーバが対応していないWork Manager for Application Serversの仕様，およびCommonJとアプリケーションサーバで動作が異なるAPIについて説明します。

(1)　アプリケーションサーバが対応していないTimer for Application Serversの仕様

アプリケーションサーバが対応していないTimer for Application Serversの仕様について次の表に示します。

表20‒7　アプリケーションサーバが対応していないTimer for Application Serversの仕様（ベンダ依存機能）

アプリケーションサーバが対応していない仕様

備考

最大スケジューリング数のカスタマイズ

最大スケジューリング数は50です。変更できません。

TimerManagerのリスナを実装するクラス

Java EEのコンポーネントを継承しない一般のJavaオブジェクト以外のオブジェクト（EJBやサーブレットなど）

javax.ejb.EnterpriseBeanを継承するクラスをスケジュールした場合，エラーになります。それ以外の場合はエラーチェックをしません。

実行スレッドへのトランザクションコンテキストの継承項目

スケジュール元のトランザクション状態に関係なく，トランザクションなしとなります。CMTのNOT_SUPPORTEDに相当します。

実行スレッドへのJ2EEコンテキストの継承項目のカスタマイズ

継承される項目は一定です。

実行スレッドで使用できるJava EEの機能

使用できる機能については「20.2.2　スレッドの非同期並行処理で使用できるJava EEの機能」を参照してください。

なお，Timer for Application Serversでは，J2EEアプリケーション中で使用できるコンポーネントについて規定されていません。アプリケーションサーバの場合にTimerManagerで使用できるコンポーネントについては，「20.3.5　TimerManagerを使用したアプリケーションの開発」を参照してください。

(2)　アプリケーションサーバが対応していないWork Manager for Application Serversの仕様

アプリケーションサーバが対応していないWork Manager for Application Serversの仕様について次の表に示します。

表20‒8　アプリケーションサーバが対応していないWork Manager for Application Serversの仕様（ベンダ依存機能）

アプリケーションサーバが対応していない仕様

備考

WorkManagerを使用した非同期スレッド処理のリモートでの実行

WorkItemをリモートで実行した場合，ローカルで実行されるダミーのRemoteWorkItemを返します。

最大スケジューリング数のカスタマイズ

最大スケジューリング数には制限がありません。

TimerManagerのリスナを実装するクラス

Java EEのコンポーネントを継承しない一般のJavaオブジェクト以外のオブジェクト（EJBやサーブレットなど）

javax.ejb.EnterpriseBeanを継承するクラスをスケジュールした場合，エラーになります。それ以外の場合，エラーチェックはしません。

アプリケーションの開始以外のタイミングでのWorkManagerの作成

WorkManagerはアプリケーションの開始時にだけ作成されます。

実行スレッドへのトランザクションコンテキストの継承項目

スケジュール元のトランザクション状態に関係なく，トランザクションなしとなります。CMTのNOT_SUPPORTEDに相当します。

実行スレッドへのJ2EEコンテキストの継承項目のカスタマイズ

継承される項目は一定です。

実行スレッドで使用できるJava EEの機能

使用できる機能については「20.2.2　スレッドの非同期並行処理で使用できるJava EEの機能」を参照してください。

なお，Work Manager for Application Serversでは，J2EEアプリケーション中で使用できるコンポーネントについて規定されていません。アプリケーションサーバの場合にWorkManagerで使用できるコンポーネントについては，「20.4.4　WorkManagerを使用したアプリケーションの開発」を参照してください。

(3)　CommonJとアプリケーションサーバで動作が異なるAPI

CommonJとアプリケーションサーバで動作が異なるAPIを次の表に示します。

表20‒9　CommonJとアプリケーションサーバで動作が異なるAPI

クラス

メソッド

アプリケーションサーバでの動作

commonj.timers.TimerManager

schedule(TimerListener listener,Date time)

listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

schedule(TimerListener listener,long delay)

listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

schedule(TimerListener listener,Date firstTime,long period)

listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

schedule(TimerListener listener,long delay,long period)

listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

scheduleAtFixedRate(TimerListener listener,Date firstTime,long period)

listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

scheduleAtFixedRate (TimerListener listener,long delay,long period)

listenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

commonj.work.WorkManager

schedule(Work work)

workがnullの場合，WorkExceptionを返します。

schedule(Work work,WorkListener wl)

workがnullの場合，WorkExceptionを返します

WorkListenerがjavax.ejb.EnterpriseBeanを継承している場合，IllegalArgumentExceptionを返します。

20.3　TimerManagerを使用した非同期タイマ処理

この節では，TimerManagerを使用した非同期タイマ処理について説明します。

この節の構成を次に示します。

表20‒10　この節の構成（TimerManagerを使用した非同期タイマ処理）

分類

タイトル

参照先

解説

TimerManagerを使用したスレッドのスケジューリング方式

20.3.1

TimerManagerのライフサイクル

20.3.2

TimerManagerのステータス遷移

20.3.3

TimerManagerの多重スケジュール数

20.3.4

実装

TimerManagerを使用したアプリケーションの開発

20.3.5

注　「設定」「運用」および「注意事項」について，この機能固有の説明はありません。

TimerManagerを使用した非同期タイマ処理では，Java EE環境で，実行間隔を指定してスレッドの非同期処理をスケジューリングできます。バックグラウンドでは，コンテナで管理されたスレッドを使用するため，安全にタスクを実行できます。

スケジューリングする処理は，TimerListenerで実装します。スケジュール元となるEJBやサーブレットでTimerManagerのメソッドを実行することで，TimerListenerに実装した処理がスケジューリングされます。また，TimerManagerのscheduleメソッドから返されたTimerを使用することで，スケジュールの応答やキャンセルができます。

TimerManagerを使用するには，EJB属性やサーブレット属性の<resource-ref>タグに，TimerManagerに関する情報を定義します。EJBやサーブレットは，デプロイ時に<res-ref-name>タグに定義した名前でルックアップしてTimerManagerを使用します。

20.3.1　TimerManagerを使用したスレッドのスケジューリング方式

TimerManagerを使用したスレッドのスケジューリングには，次の二つの方式があります。

1回だけ処理を実行する

一定の間隔で処理を繰り返し実行する

それぞれのスケジューリング方式の概要を次に示します。

(1)　1回だけ処理を実行する

指定した時間に，1回だけ処理を実行する方式です。処理が実行されると，TimerManagerは破棄されます。

(2)　一定の間隔で処理を繰り返し実行する

一定の間隔で処理を繰り返し実行するには，次の二つの方法があります。

fixed-rate（処理を開始する間隔を指定して繰り返し実行する）

fixed-delay（処理の終了から次の処理の開始までの間隔を指定して繰り返し実行する）

スケジューリングされた処理は，TimerManagerを停止するか，対応するTimerのcancelメソッドが実行されるまで，処理を実行し続けます。

それぞれの方法の概要を次に示します。

fixed-rate（処理を開始する間隔を指定して繰り返し実行する）

一定の間隔で処理を繰り返し開始していく方式です。fixed-rateでは，次の内容を指定します。

最初の処理を開始するタイミング

次のどちらかの方法で指定します。

開始時刻を指定する場合

scheduleAtFixedRateメソッドの引数であるfirstTimeをDate型で指定します。

アプリケーションを開始してから処理を実行するまでの経過時間を指定する場合

scheduleAtFixedRateメソッドの引数であるdelayをlong型で指定します。単位はミリ秒です。

前の処理を開始してから次の処理を開始するまでの間隔

scheduleAtFixedRateメソッドの引数であるperiodをlong型で指定します。単位はミリ秒です。

fixed-rateの処理のイメージを次の図に示します。この図では，アプリケーションの開始から最初の処理を開始するまでの時間を2秒，前の処理を開始してから次の処理を開始するまでの時間を3秒としています。

図20‒3　fixed-rateの処理のイメージ

fixed-rateの処理では，前に実行された処理時間がperiodに指定した時間より長かった場合，前に実行された処理が終わった直後に次の処理が開始されます。この図では，3回目の処理時間がperiodで指定した時間である3秒より長かったため，3回目の処理が終わった直後に4回目の処理が開始されています。

fixed-delay（処理の終了から次の処理の開始までの間隔を指定して繰り返し実行する）

前の処理が終了してから，一定の間隔を置いて処理を繰り返し開始していく方式です。fixed-delayでは，次の内容を指定します。

最初の処理を開始するタイミング

次のどちらかの方法で指定します。

開始時刻を指定する場合

scheduleメソッドの引数であるfirstTimeをDate型で指定します。

アプリケーションを開始してから処理を実行するまでの経過時間を指定する場合

scheduleメソッドの引数であるdelayをlong型で指定します。単位はミリ秒です。

前の処理が終了してから次の処理を開始するまでの間隔

scheduleメソッドの引数であるperiodをlong型で指定します。単位はミリ秒です。

fixed-delayの処理のイメージを次の図に示します。この図では，アプリケーションの開始から最初の処理を開始するまでの時間，および前の処理が終了してから次の処理を開始するまでの時間を2秒としています。

図20‒4　fixed-delayの処理のイメージ

20.3.2　TimerManagerのライフサイクル

ここでは，TimerManagerのライフサイクルについて説明します。

TimerManagerは，アプリケーション中でJNDIによってルックアップされた時に作成されます。ルックアップされるたびに，新しいTimerManagerが作成されます。作成されたTimerManagerは，アプリケーション中でstopメソッドを実行して，明示的に停止することをお勧めします。stopメソッドを実行しないで自動でTimerManagerを停止することもできますが，その場合，TimerManagerが停止するまでアプリケーションも停止しません。そのため，TimerManagerの停止処理に伴って，アプリケーションの停止にも時間が掛かることがあります。

また，TimerManagerは永続化されません。そのため，JavaVMが終了した場合，作成されたTimerManagerおよびスケジュールされたタイマは破棄されます。

TimerManagerのライフサイクルを次の図に示します。

図20‒5　TimerManagerのライフサイクル

20.3.3　TimerManagerのステータス遷移

TimerManagerは，サスペンド（一時停止），リジューム（再開）などによる閉塞や，停止の処理に伴って，ステータスが遷移します。そのときのTimerManagerのステータスは，isStoppedメソッド，isStoppingメソッド，isSuspendedメソッドなどを使用して確認できます。TimerManagerのステータス遷移を次の図に示します。

図20‒6　TimerManagerのステータス遷移

それぞれのステータスの詳細について次の表に示します。

表20‒11　TimerManagerのステータス

図中の番号※

ステータス

説明

1

running

TimerManagerが実行中の状態です。新規スケジュールの受付と実行ができます。

2

suspending

サスペンド実行中の状態です。サスペンドが実行されたときに，実行中のタスクが残っていることを示します。実行中のタスクがなくなるとステータスがsuspendedに遷移します。

3

suspended

すべてのタスクがサスペンドされている状態です。ステータスがsuspendedのときは，スケジューリングされたすべてのタスクは実行されません。ステータスがsuspendedのタスクは，リジュームされた時に実行されます。

4

stopping

TimerManagerの停止処理が実行中の状態です。停止処理が実行されたときに，実行中のタスクが残っていることを示します。実行中のタスクがなくなるとステータスがstoppedに遷移します。

5

stopped

TimerManagerが停止した状態です。すべてのタスクが停止されて，それ以降実行されないことを示しています。一度停止したTimerManagerは再開できません。

注※　番号は，図20-6の番号を示します。

20.3.4　TimerManagerの多重スケジュール数

TimerManagerでスケジュールされたタイマ処理では，スレッドプールで管理されたスレッドを使用します。タイマ処理がスケジュールされると，スレッドプールで管理されたスレッドが一つ割り当てられます。スレッドプールに空きスレッドがある場合は，空きスレッドが使用されます。スレッドプールに空きスレッドがない場合は，新しいスレッドが生成されて使用されます。スレッドプールに生成されたスレッドは，TimerManagerが停止するまでプールされます。

同時に使用できるスレッドのインスタンスごとの最大数は，50です。なお，スケジュールしたタイマ処理が待機中の場合も，スレッドは割り当てられます。そのため，同時にスケジュールできる処理の最大数は，タイマ処理の状態に関係なく50です。

すでに生成されたスレッドが最大数に達している場合，スケジュールされたタイマ処理はキューに格納されて，スレッドに空きができるまで待機します。空きスレッドができ次第，キューに格納されたタイマ処理が実行されます。

51以上のスレッドを同時にスケジュールする場合は，複数のTimerManagerを使用してください。

20.3.5　TimerManagerを使用したアプリケーションの開発

ここでは，TimerManagerを使用したアプリケーションの開発について説明します。

TimerManagerを使用する場合の，アプリケーションを構成するコンポーネントの使用可否を次の表に示します。

表20‒12　TimerManagerを使用する場合のアプリケーションを構成するコンポーネントの使用可否

コンポーネント

使用可否

EJBクライアント

×

リソースアダプタ

×

JavaBeansリソース

×

サーブレット／JSP※

○

EJB

Stateless Session Bean

EJB2.1以前

CMT

○

BMT

○

EJB3.0

×

Stateful Session Bean

×

Entity Bean

×

Message-driven Bean

×

（凡例）

○：使用できる

×：使用できない

注※　サーブレットリスナやフィルタでも使用できます。

TimerManagerを使用するアプリケーションの開発の流れは次のとおりです。

スケジュール元となるEJBまたはサーブレットの属性を定義する

TimerManagerのリスナに実行する処理を実装する

スケジュール元となるEJBまたはサーブレットを作成する

TimerManagerを使用するJ2EEアプリケーションをコンパイルする

それぞれの作業の詳細を次に示します。

(1)　スケジュール元となるEJBまたはサーブレットの属性を定義する

TimerManagerを使用するEJBまたはサーブレットの属性をDDに定義します。TimerManagerを使用するための定義は，アノテーションでは実施できません。

TimerManagerを使用するために定義する必要がある属性を次の表に示します。

表20‒13　TimerManagerを使用するために定義する必要がある属性

タグ名

説明

＜ルートタグ＞

−

┣

┃

┃

<description>

任意で設定してください。

┣

┃

┃

┃

<res-ref-name>

JNDI ENC名（JNDIルックアップに使用する名前）を指定してください。

┣

┃

┃

┃

<res-type>

次の内容を設定してください。

「commonj.timers.TimerManager」

┣

┃

┃

<res-auth>

設定した値は無視されます。

┣

┃

┃

┃

┃

<res-sharing-scope>

「Unshareable」を設定してください。ただし，「Shareable」を設定しても，「Unshareable」設定時と同様に動作します（ルックアップされるたびに新しいTimerManagerが作成されます）。

┣

┃

┃

<mapped-name>

設定した値は無視されます。

┣

┃

┃

<injection-target>

設定した値は無視されます。

┗

<linked-to>

設定した値は無視されます。

サーブレットでTimerManagerを使用する場合のweb.xmlの定義例を次に示します。

<web-app>
  <display-name>TimerManagerSample</display-name>
  <servlet>
    <servlet-name>SampleServlet</servlet-name>
    <display-name>SampleServlet</display-name>
    <servlet-class>SampleServlet</servlet-class>
  </servlet>
  ・・・
  <resource-ref>
    <res-ref-name>timer/MyTimer</res-ref-name>
    <res-type>commonj.timers.TimerManager</res-type>
    <res-auth>Container</res-auth>
    <res-sharing-scope>Unshareable</res-sharing-scope>
  </resource-ref>
</web-app>

TimerManagerは，アプリケーション中でJNDIによるルックアップが実行されるたびに作成されます。作成されたTimerManagerは，stopメソッドの実行時，またはアプリケーション終了時に破棄されます。なお，TimerManagerは必要に応じて複数定義することもできます。

(2)　TimerManagerのリスナに実行する処理を実装する

TimerManagerを使用するには，実行する処理を実装したリスナを作成する必要があります。リスナのインタフェースには，必ず実装するものと，必要に応じて実装するものがあります。必ず実装するインタフェースと必要に応じて実装するインタフェースを次に示します。

必ず実装するインタフェース

TimerListener

必要に応じて実装するインタフェース

StopTimerListener

CancelTimerListener

APIの詳細については，Timer and Work Manager for Application ServersのAPIの仕様を参照してください。

TimerListener，StopTimerListenerおよびCancelTimerListenerを実装したクラスの例を次に示します。

public class MyTimerListener
        implements TimerListener,StopTimerListener, CancelTimerListener {
    private int count = 0;

        public MyTimerListener() {
        }
        public void timerStop(Timer timer) {
                System.out.println("Timer stopped: " + timer);
        }

        public void timerCancel(Timer timer) {
                System.out.println("Timer cancelled: " + timer);
        }

        public void timerExpired(Timer timer) {
                System.out.println("Timer expired !");
                    if(count++ > 10) {
                //規定回数に到達したためキャンセル
                timer.cancel();
            } else {
             System.out.println("The next timer will fire at : " +
                                   timer.getScheduledExecutionTime());
            }
        }
}

(3)　スケジュール元となるEJBまたはサーブレットを作成する

TimerManagerを使用するには，スケジュール元となるEJBまたはサーブレットに，属性に定義したTimerManagerのJNDI名のルックアップ，およびTimerManagerの処理のスケジューリングを実装します。

属性に定義したTimerManagerのJNDIを使用したルックアップ

属性に定義したTimerManagerのJNDI名をルックアップしてTimerManagerを取得します。ルックアップにはjava:comp/envを使用します。TimerManagerを取得する例を次に示します。

InitialContext ic = new InitialContext();
TimerManager tm = (TimerManager)ic.lookup
                     ("java:comp/env/timer/MyTimer");

TimerManagerの処理のスケジューリング

TimerManagerの処理のスケジューリングは，TimerManagerのscheduleメソッドを呼び出して実行します。TimerManager処理のスケジューリングの例を次に示します。

InitialContext ctx = new InitialContext();
TimerManager mgr = (TimerManager)
              ctx.lookup("java:comp/env/timer/MyTimer");
TimerListener listener = new MyTimerListener();
mgr.schedule(listener, 1000*60,1000*10);
mgr.stop();

(4)　TimerManagerを使用するJ2EEアプリケーションをコンパイルする

TimerManagerを使用するJ2EEアプリケーションをコンパイルする場合は，次のJARファイルを含めてください。

＜Application Serverのインストールディレクトリ＞¥CC¥lib¥ejbserver.jar

20.4　WorkManagerを使用した非同期スレッド処理

この節では，WorkManagerを使用した非同期スレッド処理について説明します。

この節の構成を次に示します。

表20‒14　この節の構成（WorkManagerを使用した非同期スレッド処理）

分類

タイトル

参照先

解説

デーモンWorkと非デーモンWork

20.4.1

非デーモンWorkで使用するスレッドプールとキューについて

20.4.2

WorkManager，デーモンWorkおよび非デーモンWorkのライフサイクル

20.4.3

実装

WorkManagerを使用したアプリケーションの開発

20.4.4

設定

実行環境での設定

20.4.5

注　「運用」および「注意事項」について，この機能固有の説明はありません。

WorkManagerを使用した非同期スレッド処理では，Java EE環境で，スレッドの非同期処理を実行できます。バックグラウンドでは，コンテナで管理されたスレッドを使用するため，安全にタスクを実行できます。

非同期で実行する処理は，Workで実装します。スケジュール元となるEJBやサーブレットでWorkManagerのscheduleメソッドを実行することで，Workに実装した処理がスケジューリングされます。また，WorkManagerのscheduleメソッドから返されたWorkItemを使用することで，スケジュールの状態を確認できます。

WorkManagerを使用するには，EJB属性やサーブレット属性の<resource-ref>タグに，WorkManagerに関する情報を定義します。EJBやサーブレットは，デプロイ時に<res-ref-name>タグに定義した名前でルックアップしてWorkManagerを使用します。

20.4.1　デーモンWorkと非デーモンWork

WorkManagerでは，デーモンWork（長寿命Work）と非デーモンWork（短寿命Work）の2種類のWorkを作成できます。それぞれのWorkの概要を次に示します。

デーモンWork（長寿命Work）

デーモンWorkは，scheduleメソッドの実行時に作成されて，サーブレットやEJBのリクエスト処理が終了しても実行され続けます。また，WorkManagerの終了時に破棄されます。デーモンWorkは，スレッドプールのスレッドではなく，常に新しく作成されたスレッドで実行されます。

非デーモンWork（短寿命Work）

非デーモンWorkは，scheduleメソッドの実行時に作成されて，runメソッドの処理の終了時に破棄されます。非デーモンWorkは，スレッドプールで管理されたスレッドおよびキューを使用します。

20.4.2　非デーモンWorkで使用するスレッドプールとキューについて

非デーモンWorkは，スレッドプールとキューを使用して処理されます。処理で使用されるスレッドプールおよびキューは，DDで定義したWorkManager単位で作成されます。なお，スレッドプールにプールできるスレッドの最大サイズを設定します。次に，非デーモンWorkがスケジュールされたとき，プールできるスレッドの最大サイズと，プール内のスレッド数の関係と動作について説明します。

プール内のスレッドが，スレッドプールの最大スレッド数より少ない場合

新しいスレッドを作成して，非デーモンWorkを実行します。なお，スレッドは，スレッドプールの中に空きスレッドがあるかどうかに関係なく，生成されます。

プール内に，スレッドプールの最大スレッド数で設定した数だけスレッドがある場合

スレッドプールの中の空きスレッドを使用して非デーモンWorkを実行します。空きスレッドがないときには，スケジュールされた非デーモンWorkはキューに格納されます。キューに格納された非デーモンWorkは，空きスレッドができると実行されます。

スレッドプールの最大スレッド数は，デフォルトで10となっています。最大スレッド数を変更したい場合は，「20.4.5　実行環境の設定」を参照してください。なお，キューサイズには制限はありません。

ポイント

WorkManagerを停止しようとするときには，実行中のWorkManagerおよびキューに格納されたWorkManagerの処理がすべて終了されてから停止処理が開始されます。また，キュー格納時にWorkManagerが停止された場合でも，キューに格納されたWorkManagerは実行されます。

20.4.3　WorkManager，デーモンWorkおよび非デーモンWorkのライフサイクル

ここでは，WorkManager，デーモンWorkおよび非デーモンWorkのライフサイクルについて説明します。

(1)　WorkManagerのライフサイクル

WorkManagerは，アプリケーション開始時に作成されます。アプリケーション中でルックアップされると，アプリケーション開始時に作成されたWorkManagerが返されます。複数回ルックアップされても，アプリケーション開始時に作成された同じWorkManagerが呼び出されます。WorkManagerは，アプリケーションの停止時に破棄されます。

また，WorkManagerは永続化されません。そのため，JavaVMが終了した場合，作成されたWorkManagerおよびスケジュールされた非同期処理は破棄されます。

WorkManagerのライフサイクルを次の図に示します。

図20‒7　WorkManagerのライフサイクル

(2)　デーモンWorkのライフサイクル

デーモンWorkは，scheduleメソッドの実行時に作成されます。また，WorkManagerの停止時（WorkManagerに対応するアプリケーションの停止時）に破棄されます。WorkManagerの停止時には，WorkManagerはデーモンWorkのreleaseメソッドを実行したあと，すべてのデーモンWorkが終了するまで待機します。

デーモンWorkのライフサイクルを次の図に示します。

図20‒8　デーモンWorkのライフサイクル

(3)　非デーモンWorkのライフサイクル

非デーモンWorkは，scheduleメソッドの実行時に作成されます。また，runメソッドの処理が完了すると終了します。非デーモンWorkの実行中の場合またはキューで実行待ちの場合にWorkManagerを停止したとき（対応するアプリケーションを停止したとき），非デーモンWorkが停止するまで待機してから終了します。

非デーモンWorkのライフサイクルを次の図に示します。

図20‒9　非デーモンWorkのライフサイクル

20.4.4　WorkManagerを使用したアプリケーションの開発

ここでは，WorkManagerを使用したアプリケーションの開発について説明します。

WorkManagerを使用する場合の，アプリケーションを構成するコンポーネントの使用可否を次の表に示します。

表20‒15　WorkManagerを使用する場合のアプリケーションを構成するコンポーネントの使用可否

コンポーネント

使用可否

EJBクライアント

×

リソースアダプタ

×

JavaBeansリソース

×

サーブレット／JSP※

○

EJB

Stateless Session Bean

EJB2.1以前

CMT

○

BMT

○

EJB3.0

×

Stateful Session Bean

×

Entity Bean

×

Message-driven Bean

×

（凡例）

○：使用できる

×：使用できない

注※　サーブレットリスナやフィルタでも使用できます。

WorkManagerを使用するアプリケーションの開発の流れは次のとおりです。

スケジュール元となるEJBまたはサーブレットの属性を定義する

Workおよびリスナに実行する処理を実装する

スケジュール元となるEJBまたはサーブレットを作成する

WorkManagerを使用するJ2EEアプリケーションをコンパイルする

それぞれの作業の詳細を次に示します。

(1)　スケジュール元となるEJBまたはサーブレットの属性を定義する

WorkManagerを使用するEJBまたはサーブレットの属性をDDに定義します。属性は，EJBまたはサーブレットの属性定義ファイルで定義します。アノテーションで定義することはできません。

WorkManagerを使用するために定義する必要がある属性を次の表に示します。

表20‒16　WorkManagerを使用するために定義する必要がある属性

タグ名

説明

＜ルートタグ＞

−

┣

┃

┃

<description>

任意で設定してください。

┣

┃

┃

┃

<res-ref-name>

JNDI ENC名（JNDIルックアップに使用する名前）を指定してください。

┣

┃

┃

<res-type>

次の内容を設定してください。

「commonj.work.WorkManager」

┣

┃

┃

<res-auth>

設定した値は無視されます。

┣

┃

┃

┃

┃

┃

┃

<res-sharing-scope>

「Shareable」を設定してください。ただし，「Unshareable」を設定しても，「Shareable」設定時と同様に動作します（WorkManagerはアプリケーション開始時に作成されて，ルックアップ時には同じWorkManagerが返ります）。

┣

┃

┃

<mapped-name>

設定した値は無視されます。

┣

┃

┃

<injection-target>

設定した値は無視されます。

┗

<linked-to>

設定した値は無視されます。

サーブレットでWorkManagerを使用する場合のweb.xmlの定義例を次に示します。

<web-app>
  <display-name>WorkManagerSample</display-name>
  <servlet>
    <servlet-name>SampleServlet</servlet-name>
    <display-name>SampleServlet</display-name>
    <servlet-class>SampleServlet</servlet-class>
  </servlet>
  <resource-ref>
    <res-ref-name>wm/MyWorkManager</res-ref-name>
    <res-type>commonj.work.WorkManager</res-type>
    <res-auth>Container</res-auth>
    <res-sharing-scope>Shareable</res-sharing-scope>
  </resource-ref>
</web-app>

WorkManagerは，アプリケーションの開始時に，属性の定義に従って自動で作成されます。属性で定義した数のWorkManagerが作成されます。

(2)　Workおよびリスナに実行する処理を実装する

WorkManagerを使用するには，実行する処理を実装したWorkおよびリスナを作成する必要があります。インタフェースには，処理の実体であるrunメソッドを持ったWorkインタフェースと，処理の受付，開始，終了などのタイミングで処理を実行するためのWorkListenerインタフェースがあります。このうち，Workは必ず実装してください。APIの詳細については，Timer and Work Manager for Application ServersのAPIの仕様を参照してください。

WorkListenerインタフェースのAPIが呼び出される流れとステータスの遷移を次に示します。

図20‒10　WorkListenerインタフェースのAPIが呼び出される流れとステータスの遷移

WorkListenerのメソッドおよびWork.runメソッドは，同一スレッド内で呼び出されます。そのため，それぞれのメソッドは，共通のJava EEコンテキストを使用できます。

デーモンWorkと非デーモンWorkに実装する処理の流れと実装例，およびWorkListenerの実装例を次に示します。

デーモンWorkに実装する処理の流れと実装例

デーモンWorkを使用するには，isDaemonメソッドがtrueを返すようにWorkを実装します。

WorkManagerが終了すると，コンテナはデーモンWorkを停止するために，releaseメソッドを実行します。そのため，releaseメソッドが実行されたらrunメソッドの処理が終了するように実装してください。releaseメソッドが適切に実装されていない場合，WorkManager停止時にデーモンWorkが停止しないで，無限待ちになることがあるので注意してください。

デーモンWorkの実装例を次に示します。

public class MyWork implements Work {
  private String name;
  private boolean isLoopContinue = true;
  public MyWork() {}

  public void release() {
    isLoopContinue = false;
  }

  public boolean isDaemon() {
    return true;
  }

  public void run() {
    while (isLoopContinue) {
      System.out.println("DaemonWork is executed");
   try {
     Thread.sleep(10000);
   } catch(InterruptedException e) {}
 }
  }
  public String toString() {
    return name;
  }
}

非デーモンWorkに実装する処理の流れと実装例

非デーモンWorkを使用するには，isDaemonメソッドがfalseを返すようにWorkを実装します。

非デーモンWorkの処理は，スケジューリングしたEJBやサーブレットの処理中に終了する必要があります。そのため，スケジュールしたWorkが終了するのを待って，EJBまたはサーブレットの処理を終了するように実装してください。スケジュールしたWorkの終了を待つには，waitForAllメソッドまたはwaitForAnyメソッドを使用します。スケジュールしたWorkが終了しないうちにEJBやサーブレットの処理を終了した場合，スケジュールしたEJBやサーブレットのライフサイクルを超えてWorkの処理が実行されてしまいます。非デーモンWorkがスケジュールしたリクエストのライフサイクルを超えて実行されないように，必ずwaitForAllメソッドなどを使用してユーザプログラム中で処理を終了してください。

非デーモンWorkの実装例を次に示します。

public class MyWork implements Work {
         private String name;
         private String data;
         public MyWork(String name) {
                  this.name = name;
}

         public void release() {}

         public boolean isDaemon() {
                  return false;
         }

         public void run() {
                  data = "Hello, World. name=" + name;
         }

         public String getData() {
                  return data;
         }

         public String toString() {
                  return name;
         }
}

WorkListenerの実装例

WorkListenerの実装例を次に示します。

public class ExampleListener implements WorkListener {
    public void workAccepted(WorkEvent we) {
        System.out.println("Work Accepted");
    }

    public void workRejected(WorkEvent we) {
        System.out.println("Work Rejected");
    }

    public void workStarted(WorkEvent we) {
        System.out.println("Work Started");
    }

    public void workCompleted(WorkEvent we) {
        System.out.println("Work Completed");
    }
}

(3)　スケジュール元となるEJBまたはサーブレットを作成する

WorkManagerを使用するには，スケジュール元となるEJBまたはサーブレットに，属性に定義したWorkManagerのJNDI名のルックアップ，およびWorkManagerの処理のスケジューリングを実装します。

属性に定義したWorkManagerのJNDI名

属性に定義したWorkManagerのJNDI名をルックアップしてWorkManagerを取得します。ルックアップにはjava:comp/envを使用します。WorkManagerを取得する例を次に示します。

   InitialContext ic = new InitialContext();
   WorkManager tm = (WorkManager)ic.lookup
                        ("java:comp/env/wm/MyWorkManager");

WorkManagerの処理のスケジューリング

WorkManagerの処理のスケジューリングは，WorkManagerのscheduleメソッドを呼び出して実行します。

複数の非デーモンWorkをスケジューリングしたあと，すべてのWorkの終了を待つプログラムの例を次に示します。

MyWork work1 = new MyWork();
MyWork work2 = new MyWork();
InitialContext ctx = new InitialContext();
WorkManager mgr = (WorkManager) ctx.lookup("java:comp/env/wm/MyWorkManager");
WorkItem wi1 = mgr.schedule(work1, new ExampleListener());
WorkItem wi2 = mgr.schedule(work2);
Collection coll = new ArrayList();
coll.add(wi1);
coll.add(wi2);
mgr.waitForAll(coll, WorkManager.INDEFINITE);

System.out.println("work1 data: " + work1.getData());
System.out.println("work2 data: " + work2.getData());

(4)　WorkManagerを使用するJ2EEアプリケーションをコンパイルする

WorkManagerを使用するJ2EEアプリケーションをコンパイルする場合は，次のJARファイルを含めてください。

＜Application Serverのインストールディレクトリ＞¥CC¥lib¥ejbserver.jar

20.4.5　実行環境の設定

非デーモンWorkで使用するスレッドプールの最大スレッド数をデフォルト値の「10」から変更したい場合，J2EEサーバの設定が必要です。

J2EEサーバの設定は，簡易構築定義ファイルで実施します。スレッドプールの最大スレッド数の定義は，簡易構築定義ファイルの論理J2EEサーバ（j2ee-server）の<configuration>タグ内に指定します。簡易構築定義ファイルでの設定を次の表に示します。

表20‒17　簡易構築定義ファイルでのスレッドプールの最大スレッド数を変更するための定義

指定するパラメタ

設定内容

ejbserver.commonj.WorkManager.non_daemon_work_threads

非デーモンWorkで使用するスレッドプールの最大スレッド数を設定します。1〜65535の範囲※で設定してください。

デフォルト値は10です。

注※　範囲以外の数値が指定された場合は，メッセージKDJE34510-Wが表示され，デフォルト値が適用されます。

簡易構築定義ファイルおよびパラメタについては，マニュアル「アプリケーションサーバ リファレンス 定義編(サーバ定義)」の「4.3　簡易構築定義ファイル」を参照してください。

付録

付録A　リダイレクタ機能のインストール

リダイレクタ機能をインストールする方法には，次の種類があります。

新規インストール

リダイレクタ機能がインストールされていない環境に，リダイレクタ機能をインストールすることです。新規インストールでは，リダイレクタのユーザ定義は，インストーラがデフォルトのユーザ定義を作成します。

更新インストール

リダイレクタ機能がインストール済みの環境に，リダイレクタ機能（同一製品）をインストールすることです。更新インストールでは，リダイレクタのユーザ定義は，引き継ぎます。

付録A.1　リダイレクタ機能をインストールする（Windowsの場合）

アプリケーションサーバに接続して，リダイレクタ機能をインストールします。インストールでは，製品の提供媒体であるインストーラを使用します。インストーラの使用方法については，製品の提供媒体のドキュメントを参照してください。

インストールの手順を次に示します。インストール作業にはAdministrator権限が必要です。インストールするときの注意事項については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「付録I.1　Application Serverをインストールおよびアンインストールするときの注意事項」を参照してください。

手順

製品の提供媒体をCD-ROMドライブにセットします。

［日立総合インストーラ］ダイアログに，「選択されたソフトウェアをインストールします。」と表示されます。

［日立総合インストーラ］ダイアログが表示されない場合，エクスプローラを使用して，CD-ROMディレクトリの「HCD_INST.EXE」をダブルクリックしてください。

注意事項

製品の提供媒体をハードディスクにコピーしてからインストールする場合は，コピー先のパス名に";"（セミコロン），"."（ピリオド），および全角文字を含まないようにしてください。

Application Serverを選択した状態で，［インストール実行］ボタンをクリックします。

［インストール処理開始の確認 − 日立総合インストーラ］ダイアログに，「インストールを開始します。よろしいですか？」と表示されます。

［OK］ボタンをクリックします。

［uCosminexus Application Serverセットアッププログラムへようこそ］ダイアログが表示されます。

［次へ］ボタンをクリックします。

［インストール先の選択］ダイアログが表示されます。

必要に応じて［インストール先のフォルダ］を選択して，［次へ］ボタンをクリックします。

［機能の選択］ダイアログが表示されます。

次に示すどちらかの左にあるボタンをクリックします。

新規インストールの場合：［Redirector - Redirectorをインストールするためのセットアップです。セットアップ可能なすべてのオプションをカスタマイズする事ができます。］

更新インストールの場合：［Redirector - Redirectorをインストールするためのセットアップです。再インストールするプログラム機能を選択できます。］

［プログラムの選択］ダイアログが表示されます。

インストールする構成ソフトウェア（プログラム）を選択して，［次へ］ボタンをクリックします。

次に示す構成ソフトウェアから選択します。

Component Container - Redirector（リダイレクタ機能）

HTTP Server（Webサーバ）

Performance Tracer（パフォーマンストレーサ）

［ユーザ情報］ダイアログが表示されます。

［ユーザ名］および［会社名］を入力して［次へ］ボタンをクリックします。

［プログラム フォルダの選択］ダイアログが表示されます。

必要に応じて［プログラムフォルダ］を変更して，［次へ］ボタンをクリックします。

［インストールの開始］ダイアログが表示されます。

設定した内容を確認して，問題がなければ［次へ］ボタンをクリックします。

インストールが開始されます。インストールが完了すると，［セットアップの完了］ダイアログが表示されます。

［完了］ボタンをクリックします。

OSを再起動するかどうかを確認する画面が表示されます。

［はい］ボタンをクリックします。

OSが再起動し，リダイレクタ機能のインストールが完了します。

付録A.2　リダイレクタ機能をインストールする（UNIXの場合）

アプリケーションサーバに接続して，リダイレクタ機能をインストールします。

インストールでは，製品の提供媒体であるPPインストーラを使用します。

インストールの手順を次に示します。インストール作業にはroot権限が必要です。インストールするときの注意事項については，マニュアル「アプリケーションサーバ システム構築・運用ガイド」の「付録I.1　Application Serverをインストールおよびアンインストールするときの注意事項」を参照してください。

手順

アプリケーションサーバにroot権限（スーパーユーザ）でログインします。

PPインストーラ実行時の言語種別と，実行するターミナルの言語が一致しているかどうかを確認し，一致していない場合は一致させます。

製品の提供媒体をCD-ROMドライブにセットします。

製品の提供媒体がCD-ROMの場合は，CD-ROMファイルシステムをマウントします。

コマンドの実行例を次に示します。下線部には，デバイススペシャルファイル名，およびCD-ROMファイルシステムのマウントディレクトリ名を指定します。なお，これらの名称は，OS，ハードウェア，および環境によって異なります。

（AIXの実行例）

mount -r -v cdrfs /dev/cd0 /cdrom

（Linuxの実行例）

mount -r -o mode=0544  /dev/cdrom  /mnt/cdrom

セットアッププログラムを起動します。

コマンドの実行例を次に示します。下線部には，CD-ROMファイルシステムのマウントディレクトリ名を指定します。

（AIXの実行例）

/cdrom/aix/setup /cdrom

（Linuxの実行例）

/mnt/cdrom/x64lin/setup /mnt/cdrom

CD-ROMセットアッププログラムによって，PPインストーラと常駐プロセス自動起動プログラムがハードディスク上にインストールされ，PPインストーラが自動的に起動されます。

注意事項

CD-ROMのディレクトリ名やファイル名は，マシン環境によって記述した内容と見え方が異なることがあります。lsコマンドで確認し，表示されたファイル名をそのまま入力してください。

PPインストーラのメインメニューで，［I］キーを押します。

PPインストール画面が表示されます。

プログラムにカーソルを移動させ，［スペース］キーを押します。

製品の共通モジュールと，次に示す構成ソフトウェアから必要なものを選択します。

Component Container - Redirector（リダイレクタ機能）

HTTP Server（Webサーバ）

Performance Tracer（パフォーマンストレーサ）

選択したプログラムの左側には<@>が表示されます。なお，プログラムを選択してインストールすることもできます。

注意事項

製品の共通モジュールは，製品によって表示されるプログラム名が異なります。

選択したプログラムの左側に<@>が表示されていることを確認して，［I］キーを押します。

画面の最下行に「Install PP? (y: install, n: cancel)==>」メッセージが表示されます。

［y］キーまたは［Y］キーを押します。

インストールが開始されます。

［n］キーまたは［N］キーを押すと，インストールが中止されてPPインストール画面に戻ります。

インストール終了を示すメッセージが出力されたら，［Q］キーを押します。

PPインストーラのメインメニューに戻ります。

必要に応じて，PPインストーラのメインメニューで［L］キーを押して，インストール済みのプログラムを確認します。

PP一覧表示画面が表示されます。［P］キーを押すと，インストール済みのプログラム一覧が「/tmp/hitachi_PPLIST」に出力されます。［Q］キーを押すと，PPインストーラのメインメニューに戻ります。

PPインストーラのメインメニューで，［Q］キーを押します。

リダイレクタ機能のインストールが完了します。

注意事項

リダイレクタ機能を使用するためHTTP Serverを起動する際は，次の環境変数を設定する必要があります。

LD_LIBRARY_PATH=/opt/Cosminexus/common/lib

付録B　推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタ

ここでは，推奨手順以外の方法でパフォーマンスチューニングをする場合のチューニングパラメタについて説明します。

付録B.1　タイムアウトを設定するチューニングパラメタ（推奨手順以外の方法）

ここでは，タイムアウトの設定で使用するチューニングパラメタの設定個所についてまとめて示します。

(1)　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウト

Webサーバ連携の場合は，Webサーバ単位に設定します。インプロセスHTTPサーバの場合は，J2EEサーバ単位に設定します。

表B‒1　Webサーバ側で設定するクライアントからのリクエスト受信，およびクライアントへのデータ送信のタイムアウトのチューニングパラメタ（推奨手順以外の方法）

使用するWebサーバ

設定方法

設定個所

Webサーバ連携

運用管理ポータル（HTTP Serverの場合）

［Webサーバの設定］画面の「項目ごとに設定します。」の「追加ディレクティブ」のTimeoutディレクティブ

［Webサーバの設定］画面の「設定ファイルの内容を直接設定します。」の「設定ファイルの内容」のTimeoutディレクティブ

ファイル編集※

HTTP Serverの場合

httpsd.confのTimeoutディレクティブ

Microsoft IISの場合

isapi_redirect.confのreceive_client_timeoutキー

インプロセスHTTPサーバ

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の「通信タイムアウト」の「リクエスト受信」

［通信・スレッド制御に関する設定］画面の「Webクライアントとの接続設定」の［通信タイムアウト］の［リクエスト送信］

ファイル編集

usrconf.propertiesのwebserver.connector.inprocess_http.receive_timeoutキー

usrconf.propertiesのwebserver.connector.inprocess_http.send_timeoutキー

注※　HTTP Serverの定義ファイルであるhttpd.confを編集して設定します。

(2)　リダイレクタ側で設定するWebコンテナへのデータ送信のタイムアウト

リダイレクタ側で設定するタイムアウトのチューニングパラメタについて，次の表に示します。なお，これらのチューニングパラメタは，Webサーバ連携の場合だけ指定できます。

表B‒2　リダイレクタ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

Webサーバの種類

設定方法

設定個所

HTTP Server

運用管理ポータル

［リダイレクタの設定］画面の「オプション」の「リクエスト送信コネクション確立タイムアウト時間」

ファイル編集

mod_jk.confのJkConnectTimeoutパラメタ

Microsoft IIS

ファイル編集

isapi_redirect.confのconnect_timeoutキー

HTTP Server

運用管理ポータル

［リダイレクタの設定］画面の「オプション」の「リクエスト送信タイムアウト時間」

ファイル編集

mod_jk.confのJkSendTimeoutパラメタ

Microsoft IIS

ファイル編集

isapi_redirect.confのsend_timeoutキー

(3)　リダイレクタ側で設定するWebコンテナからのデータ受信のタイムアウト

リダイレクタのワーカ定義単位で設定します。リダイレクタ側で設定するタイムアウトのチューニングパラメタの設定方法と設定個所を次の表に示します。

表B‒3　リダイレクタ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法

設定個所

運用管理ポータル

［ワーカの設定］画面の「リダイレクタで再利用するワーカとのコネクション数の定義」の「通信タイムアウト」

ファイル編集

workers.propertiesのworker.<ワーカ名>.receive_timeoutキー

Webサーバ連携の場合だけ指定できます。

(4)　Webコンテナ側で設定するリダイレクタからのデータ受信のタイムアウト

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタを次の表に示します。

表B‒4　Webコンテナ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法

設定個所

運用管理ポータル

［Webコンテナの設定］画面の「Webサーバとの接続」の「タイムアウト時間」

ファイル編集

usrconf.propertiesのwebserver.connector.ajp13.receive_timeoutキー

Webサーバ連携の場合だけ指定できます。

(5)　Webコンテナ側で設定するリダイレクタへのデータ受信のタイムアウト

J2EEサーバ単位で設定します。Webコンテナ側で設定するタイムアウトのチューニングパラメタを次の表に示します。

表B‒5　Webコンテナ側で設定するタイムアウトのチューニングパラメタ（推奨手順以外の方法）

設定方法

設定個所

運用管理ポータル

［Webコンテナの設定］画面の「Webサーバとの接続」の「レスポンス送信タイムアウト時間」

ファイル編集

usrconf.propertiesのwebserver.connector.ajp13.send_timeoutキー

Webサーバ連携の場合だけ指定できます。

(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト

J2EEサーバ単位，EJBクライアントアプリケーション単位またはAPIによる呼び出し単位に設定します。

EJBクライアント側で設定するタイムアウトのチューニングパラメタ（RMI-IIOP通信によるリモート呼び出し）を次の表に示します。

表B‒6　EJBクライアント側で設定するタイムアウトのチューニングパラメタ（RMI-IIOP通信によるリモート呼び出し）（推奨手順以外の方法）

単位

設定方法

設定個所

J2EEサーバ単位

運用管理ポータル

［EJBコンテナの設定］画面の「サーバとの接続」の「タイムアウト時間」

ファイル編集

usrconf.propertiesのejbserver.rmi.request.timeoutキー

EJBクライアントアプリケーション単位の設定，およびAPI単位の設定については，推奨手順の場合と違いがありません。

EJBクライアント側で設定するタイムアウトのチューニングパラメタ（ネーミングサービス呼び出し）を次の表に示します。

表B‒7　EJBクライアント側で設定するタイムアウトのチューニングパラメタ（ネーミングサービス呼び出し）（推奨手順以外の方法）

単位

設定方法

設定個所

J2EEサーバ単位

運用管理ポータル

［ネーミングの設定］画面の「利用するネーミングサービスの設定」の「タイムアウト時間」

ファイル編集

usrconf.propertiesのejbserver.jndi.request.timeoutキー

EJBクライアントアプリケーション単位の設定については，推奨手順の場合と違いがありません。

(7)　EJBクライアント側で設定するCTMからEnterprise Bean呼び出しのタイムアウト

J2EEサーバ単位，EJBクライアントアプリケーション単位またはAPIによる呼び出し単位に設定します。

なお，このタイムアウトの設定値には，「付録B.1(6)　EJBクライアント側で設定するEnterprise Beanのリモート呼び出し（RMI-IIOP通信）とJNDIによるネーミングサービス呼び出しのタイムアウト」で指定した設定値と同じ値が引き継がれます。

(8)　EJBコンテナ側で設定するデータベースのトランザクションタイムアウト（DB Connectorを使用した場合）

J2EEサーバ単位，Enterprise Bean，インタフェース，メソッド単位（CMTの場合），またはAPIによる呼び出し単位（BMTの場合）に設定します。

トランザクションタイムアウトのチューニングパラメタを次の表に示します。

表B‒8　トランザクションタイムアウトのチューニングパラメタ（推奨手順以外の方法）

単位

設定方法

設定個所

J2EEサーバ単位

運用管理ポータル

［トランザクションの設定］画面の「トランザクションに関する設定 」の「タイムアウト時間」

ファイル編集

usrconf.propertiesのejbserver.jta.TransactionManager.defaultTimeOutキー

Enterprise Bean，インタフェース，メソッド単位（CMTの場合）およびAPI単位（BMTの場合）のチューニングパラメタについては，推奨手順の場合と違いがありません。

(9)　データベースのタイムアウト

データベースのタイムアウトを設定するチューニングパラメタについては，推奨手順の場合と違いがありません。

付録B.2　Webアプリケーションの動作を最適化するためのチューニングパラメタ（推奨手順以外の場合）

ここでは，Webアプリケーションの動作を最適化するために使用するチューニングパラメタの設定個所についてまとめて示します。

(1)　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ

静的コンテンツとWebアプリケーションの配置の切り分けは，Webサーバの動作を定義するファイルのパラメタとして指定します。設定個所，ファイルおよびパラメタは，使用するWebサーバの種類によって異なります。

Webサーバの種類ごとの設定方法および設定個所を次に示します。

表B‒9　静的コンテンツとWebアプリケーションの配置を切り分けるためのチューニングパラメタ（推奨手順以外の場合）

使用するWebサーバ

Webサーバの種類

設定方法

設定個所

Webサーバ連携

（リダイレクタモジュールを使用した切り分け）

HTTP Server

運用管理ポータル

［論理Webサーバの定義］画面の「マッピング定義」

ファイル編集

mod_jk.confのマッピング定義（JkMountパラメタ）

Microsoft IIS

ファイル編集

uriworkermap.properties

インプロセスHTTPサーバ

（リバースプロキシモジュールを使用した切り分け）

HTTP Server

運用管理ポータル

［Webサーバの設定］画面の「項目ごとに設定します。」の「追加ディレクティブ」のProxyPassディレクティブ

［Webサーバの設定］画面の「設定ファイルの内容を直接設定します。」の「設定ファイルの内容」のProxyPassディレクティブ

ファイル編集

httpsd.confのProxyPassディレクティブ※

注※　httpsd.confの詳細については，マニュアル「HTTP Server」を参照してください。

(2)　静的コンテンツをキャッシュするためのチューニングパラメタ

静的コンテンツをキャッシュするためのチューニングパラメタについて説明します。これらのチューニングパラメタは，Webコンテナ単位またはWebアプリケーション単位に設定します。

Webコンテナ単位に設定するチューニングパラメタの設定方法および設定個所について，次の表に示します。

表B‒10　静的コンテンツをキャッシュするためのチューニングパラメタ（Webコンテナ単位で設定する項目）（推奨手順以外の場合）

設定項目

設定方法

設定個所

静的コンテンツのキャッシュを使用するかどうかの選択

運用管理ポータル

［Webコンテナの設定］画面の「Webコンテナの設定」の「静的コンテンツキャッシュ機能」

ファイル編集

usrconf.propertiesのwebserver.static_content.cache.enabledキー

Webアプリケーション単位のメモリサイズの上限値の設定

運用管理ポータル

［Webコンテナの設定］画面の「Webコンテナの設定」の「キャッシュサイズ」

ファイル編集

usrconf.propertiesのwebserver.static_content.cache.sizeキー

キャッシュする静的コンテンツのファイルサイズの上限値の設定

運用管理ポータル

［Webコンテナの設定］画面の「Webコンテナの設定」の「ファイルサイズ」

ファイル編集

usrconf.propertiesのwebserver.static_content.cache.filesize.thresholdキー

Webアプリケーション単位に設定するチューニングパラメタについては，推奨手順の場合と違いがありません。

(3)　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ

リダイレクタによってリクエストを振り分けるためのチューニングパラメタは，Webサーバの動作を定義するファイルのパラメタとして指定します。設定個所，ファイルおよびパラメタは，使用するWebサーバごとに異なります。

なお，この定義は，Webサーバ連携の場合だけできます。インプロセスHTTPサーバを使用している場合は定義できません。

Webサーバごとの設定方法および設定個所を次に示します。

表B‒11　リダイレクタによってリクエストを振り分けるためのチューニングパラメタ（推奨手順以外の場合）

Webサーバの種類

設定方法

設定個所

HTTP Server

運用管理ポータル

［論理Webサーバの定義］画面の「マッピング定義」

ファイル編集

mod_jk.confのマッピング定義（JkMountパラメタ）

Microsoft IIS

ファイル編集

uriworkermap.properties

付録B.3　Persistent Connectionについてのチューニングパラメタ（推奨手順以外の方法）

Persistent Connectionについてのチューニングパラメタについて説明します。

この項目は，Webフロントシステムの場合で，インプロセスHTTPサーバを使用するときにチューニングを検討してください。

表B‒12　Persistent Connectionについて設定するチューニングパラメタ（推奨手順以外の方法）

設定項目

設定方法

設定個所

Persistent Connection数の上限値

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「Persistentコネクション」の「上限値」

usrconf.properties

webserver.connector.inprocess_http.persistent_connection.max_connectionsキー

リクエスト処理回数の上限値

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「Persistentコネクション」の「リクエスト処理回数の上限値」

usrconf.properties

webserver.connector.inprocess_http.persistent_connection.max_requestsキー

タイムアウト

運用管理ポータル

［通信・スレッド制御に関する設定］画面の「Persistentコネクション」の「タイムアウト」

usrconf.properties

webserver.connector.inprocess_http.persistent_connection.timeoutキー

付録C　エラーステータスコード

ここでは，Webコンテナ，リダイレクタ，およびインプロセスHTTPサーバが返すエラーステータスコードについて示します。

使用するWebサーバによって，エラーが発生する個所が異なります。エラーが発生する個所に応じたエラーステータスコードを参照してください。使用するWebサーバとエラーが発生する個所の対応について次の表に示します。

表C‒1　使用するWebサーバとエラーが発生する個所の対応

使用するWebサーバ

エラーが発生する個所

Webコンテナ

リダイレクタ

インプロセスHTTPサーバ

HTTP ServerまたはMicrosoft IIS

○

○

−

インプロセスHTTPサーバ

○

−

○

（凡例）○：エラーが発生する。　−：エラーは発生しない。

付録C.1　Webコンテナが返すエラーステータスコード

クライアントから，存在しないリソースや例外が発生したサーブレットなどにアクセスがあると，Webコンテナはエラーステータスコードを返します。Webコンテナが返すエラーステータスコードと，エラーステータスコードを返す条件を次の表に示します。

表C‒2　Webコンテナが返すエラーステータスコードと条件

エラーステータスコード

エラーステータスコードを返す条件

400　Bad Request

次のどれかに該当する場合，エラーステータスコード400が返ります。

FORM認証で使用するログインページとして指定されたリソースに対して，クライアントから直接リクエストを送信し，その結果表示されたログインページからユーザ認証に成功した場合

次の三つの条件をすべて満たしているアクセスの場合

HTTPのバージョンが"HTTP/1.0"のとき

アクセス対象となるサーブレットがjavax.servlet.http.HttpServletを継承しているとき

アクセス時のHTTPメソッドが該当するサーブレットでオーバーライドされていないとき

Content-Lengthヘッダの値が2147483647より大きい，または0より小さいリクエストヘッダでアクセスされた場合

Content-Lengthヘッダの値が数値以外のリクエストヘッダでアクセスされた場合

Content-Lengthヘッダを複数含むリクエストヘッダでアクセスされた場合

リクエストURIを正規化できなかった場合

401　Unauthorized

BASIC認証を必要とするリソースに対して，次のようなアクセスがあった場合，エラーステータスコード401が返ります。

不正なユーザ名，またはパスワードでアクセスされた場合

認証情報を含まないでアクセスされた場合（Authorizationヘッダがないアクセス）。

403　Forbidden

次のどれかに該当する場合，エラーステータスコード403が返ります。

BASIC認証，またはFORM認証を必要とするリソースに対して，認可できないユーザ名でアクセスされた場合

web.xmlで，auth-constraint要素にrole-name要素を指定しないで，すべてのアクセスを許可しないとするリソースにアクセスされた場合※1

静的コンテンツに対して，PUTまたはDELETEメソッドでアクセスされた場合

web.xmlの<transport-guarantee>要素で，INTEGRALまたはCONFIDENTIALが設定されているリソースにhttpでアクセスされた場合※2

404　Not Found

次のどちらかのアクセスがあった場合，エラーステータスコード404が返ります。

存在しないリソースにアクセスされた場合

javax.servlet.UnavailableExceptionが発生しているサーブレット，またはJSPファイルにアクセスされた場合※3

405　Method Not Allowed

次の三つの条件をすべて満たしているアクセスの場合，エラーステータスコード405が返ります。

HTTPのバージョンが"HTTP/1.1"の場合

アクセス対象となるサーブレットがjavax.servlet.http.HttpServletを継承している場合

アクセス時のHTTPメソッドが該当するサーブレットでオーバーライドされていない場合

412　Precondition Failed

If-Matchヘッダ，またはIf-Unmodified-Sinceヘッダで指定した条件に一致しない静的コンテンツへのアクセスの場合，エラーステータスコード412が返ります。

413　Request Entity Too Large

リクエストボディのサイズが上限値を超えた場合，エラーステータスコード413が返ります。

416　Requested Range Not Satisfiable

次のどれかに当てはまる不正なRangeヘッダの値を使用した静的コンテンツへのアクセスの場合，エラーステータスコード416が返ります。

Rangeヘッダの値が"byte"から始まっていない

範囲定義に数字や"-"を使用していない

指定範囲が妥当ではない

500　Internal Server Error

次のどれかに該当する場合，エラーステータスコード500が返ります。

例外が発生するサーブレットまたはJSPファイルにアクセスされた場合※4

コンパイルに失敗したJSPファイルにアクセスされた場合

削除された静的コンテンツにアクセスされた場合※5

静的コンテンツへのアクセスでI/Oエラーが発生した場合

web.xmlの定義が不正な状態で，<auth-constraint>要素で保護されたリソースにアクセスされた場合※6

501　Not Implemented

静的コンテンツまたはjavax.servlet.http.HttpServletを継承したサーブレットに対して，GET，HEAD，POST，PUT，DELETE，OPTIONS，TRACEメソッド以外のHTTPメソッドでアクセスされた場合，エラーステータスコード501が返ります。

503　Service Unavailable

次のどれかに該当する場合，エラーステータスコード503が返ります。

リクエストの実行待ちキューに空きがない場合※7

javax.servlet.UnavailableExceptionが発生しているサーブレットまたはJSPファイルにアクセスされた場合※8

終了処理中のWebコンテナに対してアクセスされた場合

予期しないエラーまたは例外によって，異常な状態になったWebアプリケーションにアクセスされた場合

注※1　Webアプリケーションのバージョンが2.4以降の場合に該当します。

注※2　usrconf.propertiesのwebserver.connector.redirect_https.portキーに転送先のhttpsのポート番号を設定していない場合が該当します。

注※3　Webアプリケーションのバージョンが2.4以降の場合で，永久的に利用できないことを示すjavax.servlet.UnavailableExceptionが発生し，サーブレットおよびJSPファイルで例外をcatchしていないときが該当します。

注※4　次のような場合が該当します。

Webアプリケーションのバージョンが2.4以降の場合

サーブレットまたはJSPで例外をcatchしていないとき

Webアプリケーションのバージョンが2.3の場合

web.xmlの<error-page>タグまたはJSPファイルのpageディレクティブでエラーページの指定がなく，サーブレットまたはJSPファイルで例外をcatchしていないとき

注※5　Webアプリケーションのリロード機能，JSPファイルの再コンパイル機能，またはJ2EEアプリケーションのリロード機能を使用しない場合が該当します。

注※6　web.xmlで<auth-constraint>要素に<role-name>要素が定義され，<login-config>要素が定義されていない場合に該当します。この状態でアプリケーションを開始すると，KDJE39150-Wの警告メッセージがコンソール画面，およびメッセージログに出力されます。

注※7　Webアプリケーション単位の同時実行スレッド数制御，またはURLグループ単位の同時実行スレッド数制御を設定している場合が該当します。

注※8　次のような場合が該当します。

Webアプリケーションのバージョンが2.4以降の場合

一時的に利用できないことを示す，javax.servlet.UnavailableExceptionが発生し，サーブレットまたはJSPで例外をcatchしていないとき

Webアプリケーションのバージョンが2.3の場合

web.xmlの<error-page>タグまたはJSPファイルのpageディレクティブでエラーページの指定がなく，サーブレットまたはJSPファイルで例外をcatchしていないとき

付録C.2　リダイレクタが返すエラーステータスコード

Webコンテナとのデータ送受信時にタイムアウトが発生したり，定義ファイルに記載誤りがあったりすると，リダイレクタはエラーステータスコードを返します。リダイレクタが返すエラーステータスコードと，エラーステータスコードを返す条件を，Webサーバの種類ごとに表に示します。

表C‒3　リダイレクタが返すエラーステータスコードと発生条件（HTTP Serverの場合）

エラーステータスコード

エラーステータスコードを返す条件

400　Bad Request

次のどれかに該当する場合，エラーステータスコード400が返ります。

リクエストのHostヘッダのポート番号が不正な場合

リクエストのメソッドがPOSTではない場合※1

リクエストにContent-Lengthヘッダがない（POSTリクエストである場合，ボディがチャンク形式である）場合※1

リクエストのContent-Lengthヘッダの値が，POSTリクエスト転送先ワーカに設定されたPOSTデータサイズの上限を超えた値である場合※1

500　Internal Server Error

次のどれかに該当する場合，エラーステータスコード500が返ります。

mod_jk.confの内容に記述誤りがある場合※2

workers.propertiesの読み込みに失敗した場合，または内容に記述誤りがある場合※1

リクエストヘッダが16KBを超えている場合※3

Webコンテナとのコネクション確立に失敗した場合

Webコンテナとのコネクション確立でタイムアウトが発生した場合

Webコンテナへのデータ送信時にエラーが発生した場合

Webコンテナへのデータ送信時にタイムアウトが発生した場合

Webコンテナからのデータ受信時にエラーが発生した場合

Webコンテナからのデータ受信時にタイムアウトが発生した場合

クライアントからのPOSTデータの読み込みでタイムアウトが発生した場合

リクエストにサポートしないHTTPメソッド※4が指定されている場合

注※1　POSTデータサイズによる振り分けで，デフォルトワーカを指定していない場合が該当します。

注※2　Windowsの場合だけ該当します。UNIXの場合は起動に失敗します。

注※3　HTTP Serverのリクエストヘッダの制限に関する設定で合計16KB以上のリクエストヘッダを受信可能にしている場合，該当するおそれがあります。

注※4　HTTPメソッドのサポート可否については，表C-5を参照してください。

表C‒4　リダイレクタが返すエラーステータスコードと発生条件（Microsoft IISの場合）

エラーステータスコード

エラーステータスコードを返す条件

400　Bad Request

次のどちらかの場合，エラーステータスコード400が返ります。

リクエストURLに"%"を含み，さらに"%"のあとに続く2文字が16進数を表さない文字（A〜F，a〜f，または0〜9以外の文字）の場合

リクエストのHostヘッダのポート番号が不正の場合

403　Forbidden

次のどちらかの場合，エラーステータスコード403が返ります。

リクエストURLが"hitachi_ccfj"から始まる場合※1

リクエストURLに"%2F"が含まれる場合※1

500　Internal Server Error

次のどれかに該当する場合，エラーステータスコード500が返ります。

isapi_redirect.confの内容に記述誤りがある場合

workers.propertiesの読み込みに失敗した場合，または内容に記述誤りがある場合

リクエストヘッダが16KBを超えている場合※2

Webコンテナとのコネクション確立に失敗した場合

Webコンテナとのコネクション確立でタイムアウトが発生した場合

Webコンテナへのデータ送信時にエラーが発生した場合

Webコンテナへのデータ送信時にタイムアウトが発生した場合

Webコンテナからのデータ受信時にエラーが発生した場合

Webコンテナからのデータ受信時にタイムアウトが発生した場合

クライアントからのPOSTデータの読み込みでタイムアウトが発生した場合

リクエストにサポートしないHTTPメソッド※3が指定されている場合

注※1　大文字・小文字の区別はありません。

注※2　Microsoft IISのリクエストヘッダの制限に関する設定で合計16KB以上のリクエストヘッダを受信可能にしている場合，該当するおそれがあります。

注※3　HTTPメソッドのサポート可否については，表C-5を参照してください。

リダイレクタでのリクエストのHTTPメソッドのサポート可否

リダイレクタでのリクエストのHTTPメソッドのサポート可否について，次の表に示します。

表C‒5　リダイレクタでのリクエストのHTTPメソッドのサポート可否

HTTPメソッド

サポート可否

OPTIONS

○

GET

○

HEAD

○

POST

○

PUT

○

DELETE

○

TRACE

○

CONNECT

×※

PROPFIND

○

PROPPATCH

○

MKCOL

○

COPY

○

MOVE

○

LOCK

○

UNLOCK

○

ACL

○

REPORT

○

VERSION-CONTROL

○

CHECKIN

○

CHECKOUT

○

UNCHECKOUT

○

SEARCH

○

上記以外のHTTP1.1で使用できるメソッド

×※

（凡例）○：サポートする　×：サポートしない

注※

サポートしないHTTPメソッドが指定されているリクエストには，リダイレクタがステータス500エラーを返します。また，メッセージKDJE41001-Eが出力されます。

付録C.3　インプロセスHTTPサーバが返すエラーステータスコード

クライアントからのリクエストのサイズが上限値を超えたり，値が不正だったりした場合，インプロセスHTTPサーバはエラーステータスコードを返します。インプロセスHTTPサーバが返すエラーステータスコードとエラーステータスコードを返す条件を次の表に示します。

表C‒6　インプロセスHTTPサーバが返すエラーステータスコードと条件

エラーステータスコード

エラーステータスコードを返す条件

400　Bad Request

リクエストの状態が次のどれかの場合，エラーステータスコード400が返ります。

リクエストのHTTPのバージョンが1.1で，Hostヘッダがない場合

リクエストのHostヘッダのポート番号が不正な場合

リクエストヘッダのサイズが上限値を超えた場合

リクエストヘッダの数が上限値を超えた場合

リクエストURIが不正な場合

リクエストURIのデコードに失敗した場合

リクエストURIを正規化できなかった場合

リクエストのContent-Lengthヘッダの値が2147483647より大きい，または0より小さい場合

リクエストのContent-Lengthヘッダの値が数値以外の場合

リクエストのContent-Lengthヘッダが複数指定されている場合

リクエストラインのHTTPのバージョンがサポートされていない場合

403　Forbidden

web.xmlの<transport-guarantee>要素で，INTEGRALまたはCONFIDENTIALが設定されているリソースにhttpでアクセスされた場合，エラーステータスコード403が返ります。

405　Method Not Allowed

許可しないHTTPメソッドからアクセスがあった場合，エラーステータスコード405が返ります。

413　Request entity too large

リクエストボディのサイズが上限値を超えた場合，エラーステータスコード413が返ります。

414　Request-URI too large

リクエストラインの長さが上限値を超えた場合，エラーステータスコード414が返ります。

500　Internal Server Error

リダイレクト機能によってステータスコード200でファイルを返す際にファイルの読み込みに失敗した場合，エラーステータスコード500が返ります。

501　Not implemented

リクエストのtransfer-encodingヘッダの値が，サポートされていない場合に，エラーステータスコード501が返ります。

503　Service Unavailable

流量制御の上限を超えてリクエスト処理を実行しようとした場合，エラーステータスコード503が返ります。

付録D　HTTP Serverの設定に関する注意事項

ここでは，HTTP Serverの設定に関する注意事項について説明します。

付録D.1　HTTP Serverの再起動時の注意事項

HTTP Serverの再起動に失敗した原因が，簡易構築定義ファイル（Smart Composer機能を使用しない場合はリダイレクタ定義ファイル（mod_jk.conf），またはワーカ定義ファイル（workers.properties））にある場合，次のどちらかにメッセージが出力されます。

HTTP Serverの起動コマンド実行画面またはイベントログ

HTTP Serverをコマンドプロンプトから起動，停止，または再起動するときは，起動コマンド実行画面に出力されます。

HTTP Serverをサービスから起動，停止，または再起動するときは，イベントログに出力されます。Windowsの場合だけが該当します。

HTTP Serverのエラーログファイル

エラーログファイルは，デフォルトでは次の場所に出力されます。

Windowsの場合

<HTTP Serverのインストールディレクトリ>¥logs¥error.log

UNIXの場合

/opt/hitachi/httpsd/logs/error.log

それぞれに出力されるメッセージを表に示します。

表D‒1　HTTP Serverの起動コマンド実行画面またはイベントログに出力されるメッセージ

メッセージ

原因・対策方法

JkWorkersFile file_name invalid※

JkWorkersFileキーに指定されたファイル名が無効です。JkWorkersFileキーに指定している値を修正したあと，Webサーバを再起動してください。

Can't find the workers file specified※

指定されたワーカ定義ファイルが見つかりません。JkWorkersFileキーに指定されているファイルの有無を確認したあと，Webサーバを再起動してください。

Content should start with /※

URLパターンの先頭文字が「/」（スラッシュ）以外です。JkMountキーに指定されているURLパターンの先頭文字を「/」（スラッシュ）に修正したあと，Webサーバを再起動してください。

JkOptions: Illegal option 'a...a'

JkOptionキーに指定された値（a...a）は不正です。

JkOptionキーに指定している値を修正したあと，Webサーバを再起動してください。

a...a takes b...b arguments,

a...aに示すキーに指定できる値の数はb...bです。

a...aに示すキーに指定している値の数を修正したあと，Webサーバを再起動してください。

a...a must be On or Off

a...aに示すキーに指定できる値はOnまたはOffです。

a...aに示すキーに指定している値をOnまたはOffにしたあと，Webサーバを再起動してください。

JkModulePriority: Invalid value specified.a...a

JkModulePriorityキーに設定された値a...aが不正です。JkModulePriorityキーに正しい値を設定して，Webサーバを再起動してください。

注※　UNIXの場合だけ出力されるメッセージです。

表D‒2　HTTP Serverのエラーログファイル

メッセージ

説明・対策方法

[時刻] [emerg] Memory error

メモリが不足しています。

システムが利用できるメモリ使用量を確保したあと，Webサーバを再起動してください。

[時刻] [emerg] Error while opening the workers※

次のどちらかの問題が発生しています。

ワーカ定義ファイルのオープンに失敗しました。

JkWorkersFileキーに指定されているファイルのアクセス権に読み取り権限があることを確認したあと，Webサーバを再起動してください。

ワーカ定義ファイルの内容が不正です。

ワーカ定義ファイルの内容を正しく修正したあと，Webサーバを再起動してください。

[時刻] [emerg] Error while checking the mod_jk.conf※

リダイレクタ定義ファイルに不適切な記述がありました。リダイレクタに出力されているメッセージを確認したあと，Webサーバを再起動してください。

注※　UNIXの場合だけ出力されるメッセージです。

付録D.2　リダイレクタのログに関する注意事項

ログ出力先ディレクトリにHTTP Serverの実行アカウントの書き込み権限がない場合，リクエストは正常に処理されますが，ログは出力されません。

Windowsの場合，デフォルトの状態ではリダイレクタのログ出力先ディレクトリ（<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥logs）がありません。このため，HTTP Serverは，起動時に一つ上のディレクトリ（redirectorディレクトリ）のアクセス権を引き継いで，logsディレクトリを生成してログを出力しようとします。このとき，HTTP Serverの実行アカウントの書き込み権限がないとログは出力されません。この場合は，logsディレクトリを生成してアクセス権を設定するか，または一つ上のディレクトリ（redirectorディレクトリ）にアクセス権を設定してください。

また，リダイレクタのログ出力先ディレクトリを変更している場合に，指定しているパスが途中までしかないときは，存在する最下層のディレクトリに対してアクセス権を設定するか，または指定したパスに対応するディレクトリをすべて作成して，最下層のディレクトリにアクセス権を設定してください。

付録D.3　HTTP Serverのアップグレード時の注意事項

HTTP Serverをアップグレードした場合，HTTP Server用のリダイレクタの変更内容を反映するためには，HTTP Serverを再起動する必要があります。HTTP Serverの再起動の方法については，マニュアル「HTTP Server」を参照してください。

付録E　Microsoft IISの設定

ここでは，Microsoft IISを使用してWebサーバと連携する場合の設定方法について説明します。

付録E.1　Microsoft IIS 10.0の設定

ここでは，Microsoft IISを使用してWebサーバと連携する場合のMicrosoft IIS 10.0の設定方法について説明します。

J2EEサーバとMicrosoft IISとの連携は，次に示す手順で設定します。

Microsoft IISおよび役割サービスのインストール

ISAPIおよびCGIの制限の追加

ISAPIフィルタの追加

ハンドラマッピングの設定

仮想ディレクトリの追加

Webサーバの認証機能の解除

［サーバー］ノードでのアプリケーションプールの設定

［サイト］ノードでのアプリケーションプールの設定

リダイレクタログ出力先ディレクトリへのアクセス権の設定

Webサイトの開始

参考

Microsoft IISの設定で使用する，［インターネット インフォメーション サービス（IIS）マネージャー］の画面構成を次に示します。なお，以降で示す手順に従って，［接続］ウィンドウ，［機能ビュー］，［操作］ウィンドウなどで設定を実施してください。

(1)　Microsoft IISおよび役割サービスのインストール

Microsoft IISを使用する場合，Microsoft IISおよび用途に応じた役割サービスをインストールする必要があります。IISおよび役割サービスをインストールする手順を次に示します。

Microsoft IISがインストール済みの場合，不足している役割サービスがあれば追加インストールしてください（必要な役割サービスについては後述）。

［サーバーマネージャー］を起動します。

（自動起動していない場合，スタート画面から起動できます）

［サーバーマネージャー］の［役割と機能の追加］をクリックします。

ウィザードが起動するので［次へ］をクリックします。

［役割ベースまたは機能ベースのインストール］を選択し，［次へ］をクリックします。

対象のサーバを選択し，［次へ］をクリックします。

［サーバーの役割］では，［Webサーバー（IIS）］を選択し，［次へ］をクリックします。

［Webサーバー（IIS）に必要な機能を追加しますか？］のポップアップが出た場合，［管理ツールを含める（存在する場合）］にチェックを入れて［機能の追加］をクリックします。

［機能の選択］では［次へ］をクリックします。

［Webサーバーの役割（IIS）］では［次へ］をクリックし，［役割サービスの選択］では最低限次の役割サービスを選択し，［次へ］をクリックします。

HTTPエラー

ディレクトリの参照

既定のドキュメント

静的なコンテンツ

ISAPI拡張

ISAPIフィルター

IIS管理コンソール

指定した役割サービス以外も必要に応じて追加してください。特に［HTTPログ］や［トレース］は障害発生時のトラブルシュートに有益です。

［インストール］をクリックします。

［閉じる］をクリックします。

インストールが完了します。

(2)　ISAPIおよびCGIの制限の追加

ISAPIおよびCGIの制限を追加する手順を次に示します。

［インターネット インフォメーション サービス（IIS）マネージャー］を起動します。

［サーバマネージャー］の［ツール］から起動できます。

［機能ビュー］のサーバの［ホーム］ページで，［ISAPIおよびCGI制限］をダブルクリックします。

［ISAPIおよびCGI制限］ページの［操作］ウィンドウで［追加］をクリックします。

［ISAPIまたはCGIの制限の追加］ダイアログで次の操作をします。

［ISAPIまたはCGIパス］にリダイレクタのDLL（<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll）を指定します。

［説明］に「ISAPI」と入力します。

［拡張パスの実行を許可する］をチェックします。

［OK］ボタンをクリックします。

［ISAPIまたはCGIの制限の追加］ダイアログが閉じて，設定が反映されます。

(3)　ISAPIフィルタの追加

ISAPIフィルタを追加する手順を次に示します。

［機能ビュー］のサイトの［ホーム］ページで［ISAPIフィルター］をダブルクリックします。

［ISAPIフィルター］ページの［操作］ウィンドウで［追加］をクリックします。

［ISAPIフィルターの追加］ダイアログで次の操作をします。

［フィルター名］に「hitachi_ccfj」と入力します。

［実行可能ファイル］にリダイレクタのDLL（<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll）を指定します。

［OK］ボタンをクリックします。

［ISAPIフィルターの追加］ダイアログが閉じて，設定が反映されます。

(4)　ハンドラマッピングの設定

ハンドラマッピングを設定する手順を次に示します。

［機能ビュー］のサイトの［ホーム］ページで［ハンドラー マッピング］をダブルクリックします。

［ハンドラー マッピング］ページで「ISAPI-dll」を選択し，［操作］ウィンドウで［編集...］をクリックします。

［モジュール マップの編集］ダイアログで次の操作をします。

［要求パス］に「*.dll」と入力します。

［実行可能ファイル］にリダイレクタのDLL（<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll）を指定します。

すでにハンドラマッピングが設定されている場合，［スクリプトマップの編集］ダイアログが起動しますが，操作内容は同じです。

［OK］ボタンをクリックします。

モジュールマップの編集を有効にするかどうかを確認するメッセージダイアログで，ISAPI拡張機能を有効にするために，［はい］ボタンをクリックします。

［ハンドラー マッピング］ページで「ISAPI-dll」を選択し，［操作］ウィンドウで［機能のアクセス許可の編集...］をクリックします。

［機能のアクセス許可の編集］ダイアログで「読み取り」，「スクリプト」および「実行」のすべてのアクセス許可をチェックします。

［OK］ボタンをクリックします。

［機能のアクセス許可の編集］ダイアログが閉じて，設定が反映されます。

(5)　仮想ディレクトリの追加

「hitachi_ccfj」という名称の仮想ディレクトリを追加します。仮想ディレクトリを追加する手順を次に示します。

［接続］ウィンドウで［サイト］ノードを展開し，仮想ディレクトリを追加するサイトをクリックします。

［操作］ウィンドウで，［仮想ディレクトリの表示］をクリックします。

［仮想ディレクトリ］ページが表示されます。

［仮想ディレクトリ］ページの［操作］ウィンドウで，［仮想ディレクトリの追加...］をクリックします。

［仮想ディレクトリの追加］ダイアログで次の操作をします。

［エイリアス］に「hitachi_ccfj」と入力します。

［物理パス］にリダイレクタのDLL（<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥isapi_redirect.dll）が格納されているディレクトリを指定します。

［OK］ボタンをクリックします。

［仮想ディレクトリの追加］ダイアログが閉じて，設定が反映されます。

(6)　Webサーバの認証機能の解除

Webコンテナの認証機能を使用する場合，次に示すWebサーバの認証機能の解除が必要になります。

Active Directory クライアント証明書の認証

Webコンテナが管理するリソースへアクセスする場合は解除してください。

ダイジェスト認証

Webコンテナの認証機能の使用の有無に関係なく，必ず解除してください。

Windows認証

Webコンテナの認証機能（Basic認証）を使用する場合は解除してください。

APS.NET偽装

Webコンテナが管理するリソースへアクセスする場合は解除してください。

Active Directory クライアント証明書の認証，ダイジェスト認証，Windows認証，フォーム認証およびAPS.NET偽装を解除する手順を次に示します。

［接続］ウィンドウでサーバの［ホーム］ページを選択し，［認証］をダブルクリックします。

［認証］画面で，［Active Directory クライアント証明書の認証］を選択し，［操作］ウィンドウで［無効にする］をクリックします（任意）。

［接続］ウィンドウで［サイト］ノードを展開し，「hitachi_ccfj」をクリックします。

［ホーム］ページで［認証］をダブルクリックします。

［認証］画面で，［フォーム認証］を選択し，［操作］ウィンドウで［無効にする］をクリックします（任意）。

Webコンテナが管理するリソースへアクセスする場合は解除してください。

［認証］画面で，［ダイジェスト認証］を選択し，［操作］ウィンドウで［無効にする］をクリックします（必須）。

Webコンテナの認証機能の使用の有無に関係なく，ダイジェスト認証は必ず無効にしてください。

［認証］画面で，［Windows認証］を選択し，［操作］ウィンドウで［無効にする］をクリックします（任意）。

WebコンテナのBasic認証を設定している場合は，必ず解除してください。

［認証］画面で，［APS.NET偽装］を選択し，［操作］ウィンドウで［無効にする］をクリックします（任意）。

Webコンテナが管理するリソースへアクセスする場合は解除してください。

［OK］ボタンをクリックして各ウィンドウを閉じます。

(7)　［サーバー］ノードでのアプリケーションプールの設定

［サーバー］ノードでのアプリケーションプールの設定手順を次に示します。

［接続］ウィンドウでサーバノードを展開し，［アプリケーション プール］をクリックします。

［アプリケーション プール］ページで，使用するアプリケーションプールを選択し，［操作］ウィンドウの［詳細設定］をクリックします。

［詳細設定］ダイアログで次の操作をします。

［ワーカー プロセスの最大数］※に，Microsoft IIS内でリクエストを処理するプロセスの最大数を指定します。

注※

このマニュアルでは，Webコンテナの実行プロセスのことも「ワーカプロセス」と表記していますが，ここで設定する「ワーカー プロセス」とはMicrosoft IIS内でリクエストを処理するプロセスを指します。

［OK］ボタンをクリックします。

［詳細設定］ダイアログが閉じて，設定が反映されます。

(8)　［サイト］ノードでのアプリケーションプールの設定

サイトノードでのアプリケーションプールの設定手順を次に示します。

［接続］ウィンドウで［サイト］ノードを展開し，アプリケーションプールを指定するサイトをクリックします。

［操作］ウィンドウで，［詳細設定］をクリックします。

［詳細設定］ダイアログで，［アプリケーションプール］を入力します。

［アプリケーションプール］に，「(7) ［サーバー］ノードでのアプリケーションプールの設定」で設定したアプリケーションプールの名称を指定します。

［OK］ボタンをクリックします。

［詳細設定］ダイアログが閉じて，設定が反映されます。

(9)　リダイレクタログ出力先ディレクトリへのアクセス権の設定

リダイレクタのログ出力先ディレクトリには，Microsoft IISのアプリケーションプールの実行アカウントに対する書き込み権限を付加しておく必要があります。エクスプローラから，リダイレクタのログ出力ディレクトリにアクセス権を設定してください。

アプリケーションプールの実行アカウントは，アプリケーションプールの［詳細設定］ダイアログの［ID］で指定します。デフォルトのIDを指定している場合は，「IIS_IUSRS」グループに対して書き込み権限を付加してください。

デフォルトのIDは次のとおりです。

Microsoft IIS 10.0：「ApplicationPoolIdentity」

なお，新規インストール時には，デフォルトの状態ではリダイレクタのログ出力先ディレクトリ（<Application Serverのインストールディレクトリ>¥CC¥web¥redirector¥logs）がありません。このため，logsディレクトリを作成してアクセス権を設定するか，または一つ上のディレクトリ（redirectorディレクトリ）にアクセス権を設定してください。

また，リダイレクタのログ出力先ディレクトリを変更している場合に，指定しているパスが途中までしかないときは，存在する最下層のディレクトリに対してアクセス権を設定するか，または指定したパスに対応するディレクトリをすべて作成して，最下層のディレクトリにアクセス権を設定してください。

(10)　Webサイトの開始

Microsoft IISのWebサイトの開始の手順を次に示します。

［接続］ウィンドウで［サイト］ノードを展開し，開始するサイトをクリックします。

［操作］ウィンドウで，［開始］をクリックします。開始済みの場合は，［再起動］をクリックします。

Webサイトが開始，または再起動します。

(11)　注意事項

ここでは，Microsoft IISの設定時の注意事項について説明します。

(a)　構成設定の複数環境へのレプリケーションについての注意事項

Microsoft IISでは，構成設定をweb.configファイルに保存できます。また，保存したweb.configファイルを基に，xcopyを使用して複数環境に構成環境をレプリケーションできます。

ただし，リダイレクタを使用する構成環境の場合，xcopyでの複数環境へのレプリケーションでリダイレクタの設定はできません。xcopyで複数環境を同一の構成設定にする場合も，リダイレクタの設定は環境ごとに手動で同期してください。

(b)　エラーページのカスタマイズについての注意事項

Microsoft IISでエラーページにカスタムエラーページを返す設定にしている場合，web.xmlの<error-page>タグによるエラーページのカスタマイズは無効となることがあります。web.xmlの<error-page>タグによるエラーページのカスタマイズを有効にしたい場合は，Microsoft IISのエラーページのカスタムエラーページの設定を無効にしてください。

(c)　ほかのフィルタと共存させる場合の注意事項

Microsoft IISが受信したリクエストが，Webコンテナに転送するリクエストの場合，Microsoft IIS用リダイレクタはISAPIフィルタ内で使用するリクエストURL情報を変更します。そのため，Microsoft IIS用リダイレクタよりあとに実行されるISAPIフィルタでは，Microsoft IISが受信したリクエストURLを取得できません。Microsoft IISが受信したリクエストURLをフィルタで取得する場合は，Microsoft IIS用リダイレクタよりも順番が先になるように設定してください。順番を調整するために，Microsoft IIS用リダイレクタの優先順位を「中」または「低」に変更する必要がある場合は，isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）のfilter_priorityキーで指定します。isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）のfilter_priorityキーの詳細については，「13.2.1　isapi_redirect.conf（Microsoft IIS用リダイレクタ動作定義ファイル）」を参照してください。

付録F　JPAプロバイダとEJBコンテナ間の規約

ここでは，JPAプロバイダとEJBコンテナ間の規約について説明します。

付録F.1　ランタイムに関する規約

ランタイムに関する規約には，コンテナ側の責任とJPAプロバイダ側の責任があります。

(1)　コンテナ側の責任

トランザクションスコープの永続化コンテキストに関する規約

トランザクションスコープの永続化コンテキストが使用されている場合に，JTAトランザクションにエンティティマネージャが関連づいていないときには，コンテナは次の処理を実行します。

コンテナは次の場合に，EntityManagerFactory.createEntityManagerを呼び出して新しいエンティティマネージャを作成します。

JTAトランザクションのスコープ内のビジネスメソッドで，トランザクションスコープの永続化コンテキストを使用するエンティティマネージャのメソッドが初めて呼び出された場合

JTAトランザクションが決着（コミットまたはロールバック）したあとに，コンテナはEntityManager.closeを呼び出して，エンティティマネージャをクローズします。

また，コンテナは次の条件をすべて満たすと，TransactionRequiredExceptionをスローします。

トランザクションスコープの永続化コンテキストが使用されている場合

トランザクションがアクティブでない場合

アプリケーションからEntityManagerのpersist，remove，merge，refreshメソッドが呼び出された場合

拡張永続化コンテキストに関する規約

拡張永続化コンテキストが使用されている場合は，コンテナは次の処理を行います。

コンテナは次の場合に，EntityManagerFactory.createEntityManagerを呼び出して新しいエンティティマネージャを作成します。

Stateful Session Beanのインスタンスが作成された際に，拡張永続化コンテキストを使用するエンティティマネージャへの参照が定義されている場合

コンテナは次のタイミングで，EntityManager.closeを呼び出してエンティティマネージャをクローズします。

エンティティマネージャを作成したStateful Session Bean，および同じ永続化コンテキストを引き継いだStateful Session Beanが削除されたとき

コンテナ管理のトランザクションを使用するStateful Session Beanのビジネスメソッドの呼び出し時に，エンティティマネージャがJTAトランザクションと関連づけられていない場合には，コンテナはエンティティマネージャをJTAトランザクションに関連づけ，EntityManager.joinTransactionを呼び出します。JTAトランザクションにすでに別のエンティティマネージャが関連づけられている場合には，コンテナはEJBExceptionをスローします。

ビーン管理のトランザクションを使用するStateful Session Beanのビジネスメソッド内でUserTransaction.beginが呼び出された場合には，コンテナはエンティティマネージャをJTAトランザクションと関連づけ，EntityManager.joinTransactionを呼び出します。なお，ビーン管理のトランザクションについては，マニュアル「アプリケーションサーバ機能解説 基本・開発編(EJBコンテナ)」の「2.7.2　BMT」を参照してください。

コンテナ管理のエンティティマネージャに関する規約

コンテナ管理のエンティティマネージャを使用している場合に，アプリケーションがEntityManager.closeを呼び出すと，コンテナはIllegalStateExceptionをスローします。

@PersistenceCotnextまたはDDの<persistence-context-ref>タグで，プロパティが指定された場合には，コンテナはEntityManagerFactory.createEntityManager(Map map)メソッドを使用してエンティティマネージャを作成し，指定されたプロパティをmap引数に含めてJPAプロバイダに渡します。

コネクションの自動クローズ機能について

アプリケーションサーバの場合，Session BeanやWebコンポーネントの延長でJPAプロバイダが取得したコネクションは，コンテナの自動クローズ機能によって自動的にクローズされることがあります。コネクションの自動クローズ機能とは，コネクションのリークを防止するための機能です。

コネクションは，次の条件を満たすと自動クローズの対象となります。

Stateless Session Beanで取得したコネクションは，ビジネスメソッドからリターンするときに，自動クローズの対象となります。

Stateful Session Beanで取得したコネクションは，Stateful Session Beanが破棄されるときに，自動クローズの対象となります。

Webコンポーネントで取得したコネクションは，サービスメソッドからリターンするときに，自動クローズの対象となります。

ただし，これらの条件に当てはまる場合でも，コネクションがJTAトランザクションに参加しているときには，JTAトランザクションがコミットするまで自動クローズが保留されます。

(2)　JPAプロバイダ側の責任

アプリケーションで使用するエンティティマネージャが，トランザクションスコープの永続化コンテキストを使用するように定義されているか，拡張永続化コンテキストを使用するように定義されているかは，JPAプロバイダには伝わりません。JPAプロバイダでの責任は，コンテナが要求したときにエンティティマネージャを作成し，トランザクションからトランザクションの決着の通知を受け取るためのSynchronizationをトランザクションに登録することです。

コンテナがEntityManagerFactory.createEntityManagerを呼び出したときには，JPAプロバイダは新しいエンティティマネージャを作成し，それをコンテナに返す必要があります。JTAトランザクションがアクティブである場合は，JPAプロバイダはSynchronizationをJTAトランザクションに登録する必要があります。

コンテナがEntityManager.joinTransactionを呼び出したときには，JPAプロバイダはSynchronizationをJTAトランザクションに登録する必要があります。ただし，以前にjoinTransactionが呼び出されていて，JTAトランザクションにSynchronizationを登録済みの場合には，何もする必要はありません。

JTAトランザクションがコミットされるときには，JPAプロバイダはすべての変更されたエンティティの状態を，データベースにフラッシュする必要があります。

JTAトランザクションがロールバックされるときには，JPAプロバイダは，すべてのmanaged状態のエンティティをデタッチする必要があります。

JPAプロバイダがトランザクションのロールバックの原因になる例外をスローする場合には，JPAプロバイダがトランザクションをロールバックにマークする必要があります。

コンテナがEntityManager.closeを呼び出した場合，そのエンティティマネージャが関係したすべての未解決トランザクションが決着されたあとに，JPAプロバイダはすべての確保したリソースを解放する必要があります。エンティティマネージャがすでにクローズされている場合には，JPAプロバイダはIllegalStateExceptionをスローする必要があります。

コンテナがEntityManager.clearを呼び出した場合，JPAプロバイダはすべてのmanaged状態のエンティティをデタッチする必要があります。

(3)　javax.transaction.TransactionSynchronizationRegistryインタフェース

JPAプロバイダは，トランザクションにSynchronizationを登録したり，トランザクションをロールバックにマークしたりするために，TransactionSynchronizationRegistryインタフェースを使用できます。TransactionSynchronizationRegistryのインスタンスは，JNDIを使用して「java:comp/TransactionSynchronizationRegistry」という名前でルックアップできます。

インタフェース定義を次に示します。

package javax.transaction;

/**
 * このインタフェースは，JPAプロバイダやリソースアダプタなど，
 * アプリケーションサーバのシステムレベルのコンポーネントから使用する
 * ためのものです。
 * このインタフェースを使って，
 * 特別な順序で呼ばれるシンクロナイゼーションの登録，
 * 現在のトランザクションへのリソースオブジェクトの登録，
 * 現在のトランザクションのコンテキストの取得，
 * 現在のトランザクションのステータスの取得，
 * 現在のトランザクションをロールバックにマークできます。
 *
 * このインタフェースはステートレスなサービスオブジェクトとして，
 * アプリケーションサーバによって実装されます。
 * 同じオブジェクトを複数のコンポーネントからマルチスレッドセーフに
 * 使用できます。
 *
 * 標準的なアプリケーションサーバでは，このインタフェースを実装した
 * インスタンスは，JNDIを使用して標準的な名前でルックアップできます。
 * 標準的な名前は
 * 「java:comp/TransactionSynchronizationRegistry」です。
 */
public interface TransactionSynchronizationRegistry {

    /**
     * このメソッドを呼び出した時に現在のスレッドに関連づいている
     * トランザクションを表現する一意のオブジェクトを返します。
     * このオブジェクトのhashCodeとequalsメソッドは
     * オーバーライドされており，
     * ハッシュマップのキーとして使用できます。
     * トランザクションが存在しない場合には，nullを返します。
     *
     * 同じアプリケーションサーバの同じトランザクションコンテキスト内で
     * このメソッドが呼ばれて返されたオブジェクトは，すべて同じhashCodeを
     * 持ち，equalメソッドでの比較結果はtrueとなります。
     *
     * toStringメソッドは，トランザクションコンテキストの情報を人が
     * 読みやすい形の文字列として返します。
     * ただし，toStringで返される文字列のフォーマットは規定されていません。
     * また，toStringの結果に関して，バージョン間での互換性は
     * 保障されていません。
     *
     * 取得したオブジェクトがシリアライズできる保障はなく，
     * JavaVMの外に出したときの動作は規定されていません。
     *
     * @return このメソッドが呼ばれたときにスレッドに関連づいている
     * トランザクションを一意に表現するオブジェクト
     */
    Object getTransactionKey();

    /**
     * このメソッドを呼び出した時のスレッドに関連づいているトランザクション
     * のリソースマップに，オブジェクトを追加またはリプレースします。
     * マップのキーは，コンフリクトが発生しないように，
     * このメソッドを呼び出す側で定義されたクラスである必要があります。
     * キーとして使用するクラスは，マップのキーとして適切なhashCodeとequals
     * メソッドを持っている必要があります。
     * マップのキーや値が，このクラスによって評価されたり，使用されたりする
     * ことはありません。
     * このメソッドの一般的な規約は，Mapのputメソッドと同じで，
     * キーはnull以外にする必要がありますが，値はnullにすることもできます。
     * すでにキーに関連づいた値が存在する場合，その値は置き換えられます。
     *
     * @param key マップのエントリのキー
     * @param value マップのエントリの値
     * @exception IllegalStateException アクティブなトランザクションが
     * 存在しない場合
     * @exception NullPointerException 引数のキーがnullである場合
     */
    void putResource(Object key, Object value);

    /**
     * このメソッドを呼び出した時のスレッドに関連づいているトランザクション
     * のリソースマップから，オブジェクトを取り出します。
     * キーは，同じトランザクション内で，事前にputResourceメソッドに
     * 指定したオブジェクトと同じである必要があります。
     * 指定されたキーが現在のリソースマップに存在しない場合は，
     * nullを返します。
     * このメソッドの一般的な規約は，Mapのputメソッドと同じで，
     * キーはnull以外にする必要がありますが，値はnullにすることもできます。
     * マップにキーが格納されていない場合や，キーに対してnullが格納
     * されている場合には，返り値はnullになります。
     * @param key マップのエントリのキー
     * @return キーに関連づけられた値
     * @exception IllegalStateException アクティブなトランザクションが
     * 存在しない場合
     * @exception NullPointerException 引数のキーがnullである場合
     */
    Object getResource(Object key);

    /**
     * 特別な順序で呼ばれるシンクロナイゼーションのインスタンスを登録します。
     * このメソッドで登録したSynchronizationのbeforeCompletionは，
     * すべてのSessionSynchronization.beforeCompletionや，
     * トランザクションに直接登録された
     * Synchronization.beforeCompletionが呼ばれたあとで，
     * 2フェーズコミット処理が開始される前に呼び出されます。
     * 同じように，このメソッドで登録した
     * SynchronizationのafterCompletionは，
     * 2フェーズコミット処理が完了したあとで，
     * すべてのSessionSynchronization.afterCompletionや，
     * トランザクションに直接登録されたSynchronization.afterCompletionが
     * 呼ばれる前に呼び出されます。
     *
     * beforeCompletionは，このメソッドを呼び出した時にスレッドに
     * 関連づいていたトランザクションのコンテキストで呼び出されます。
     * beforeCompletionでは，コネクタなどのリソースへのアクセスは
     * 許可されていますが，タイマーサービスやビーンのメソッドなどの
     * ユーザコンポーネントへのアクセスは許可されていません。
     * これは，呼び出し側によって管理されているデータや，
     * registerInterposedSynchronizationで登録された
     * ほかのSynchronizationによって
     * すでにフラッシュされたデータを変更してしまうおそれがあるためです。
     * 一般的なコンテキストは，registerInterposedSynchronizationを
     * 呼び出したコンポーネントのコンテキストになります。
     *
     * afterCompletionが呼び出される時のコンテキストは定義されていません。
     * なお，ユーザコンポーネントへのアクセスは許可されていません。
     * また，リソースをクローズすることはできますが，
     * リソースに対するトランザクショナルな操作はできません。
     *
     *トランザクションがアクティブでない場合にこのメソッドが呼び出されたとき，
     * IllegalStateExceptionがスローされます。
     *
     * このメソッドが2フェーズコミット処理の開始後に呼び出された場合は，
     * IllegalStateExceptionがスローされます。
     *
     * @param sync 登録するSynchronizationのインスタンス
     * @exception IllegalStateException アクティブなトランザクションが
     * 存在しない場合
     */
    void registerInterposedSynchronization(Synchronization sync);

    /**
     * このメソッドを呼んだ時にスレッドに関連づいているトランザクション
     * のステータスを返します。
     * このメソッドの返り値は，
     * TransactionManager.getStatus()の結果と同じです。
     *
     * @return このメソッドを呼んだときにスレッドに関連づいている
     * トランザクションのステータス
     */
    int getTransactionStatus();

    /**
     * このメソッドを呼んだ時にスレッドに関連づいているトランザクション
     * がロールバックされるようにマークします。
     *
     * @exception IllegalStateException アクティブなトランザクションが
     * 存在しない場合
     */
    void setRollbackOnly();

    /**
     * このメソッドを呼んだ時にスレッドに関連づいているトランザクション
     * がロールバックするようにマークされているかどうかを返します。
     *
     * @return ロールバックするようにマークされている場合はtrue
     * @exception IllegalStateException アクティブなトランザクションが
     * 存在しない場合
     */
    boolean getRollbackOnly();
}

付録F.2　デプロイメントに関する規約

デプロイメントに関する規約には，コンテナ側の責任とJPAプロバイダ側の責任があります。

(1)　コンテナ側の責任

デプロイメント時に，コンテナはアプリケーション内の決められた場所にパッケージングされたpersistence.xmlを検索します。アプリケーション内にpersistence.xmlが存在する場合には，コンテナはpersistence.xmlに定義された永続化ユニットの定義を処理します。なお，コンテナが検索する場所については，マニュアル「アプリケーションサーバ機能解説 基本・開発編(コンテナ共通機能)」の「5.8　persistence.xmlでの定義」を参照してください。

コンテナはpersistence.xmlファイルをpersistence_1_0.xsdで検証します。検証の結果，エラーが発生した場合にはユーザに通知します。persistence.xmlにプロバイダやデータソースの情報が指定されていない場合には，デフォルト値が使用されます。使用されるデフォルト値は次のとおりです。

<provider>タグ

簡易構築定義ファイルで指定したデフォルトのJPAプロバイダが使用されます。また，このタグを省略した場合で，簡易構築定義ファイルでデフォルトのJPAプロバイダが指定されていないときには，JPAプロバイダとしてCJPAプロバイダが使用されます。

ポイント

簡易構築定義ファイルでデフォルトのJPAプロバイダを指定するには，論理J2EEサーバの<param-name>タグにejbserver.jpa.defaultProviderClassNameを指定して，<param-value>タグにデフォルトのJPAプロバイダクラス名を指定します。

なお，簡易構築定義ファイルで，論理J2EEサーバの<param-name>タグにejbserver.jpa.overrideProviderパラメタが指定されているときは，ejbserver.jpa.overrideProviderパラメタの<param-value>タグに指定されているJPAプロバイダクラス名が，<provider>タグやejbserver.jpa.defaultProviderClassNameパラメタに指定した値よりも優先して使用されます。

簡易構築定義ファイルに指定するパラメタについては，「11.2.1　J2EEサーバ用ユーザプロパティを設定するパラメタ」を参照してください。

永続化ユニットで使用されるJPAプロバイダを決定する優先順位を次の表に示します。

表F‒1　永続化ユニットで使用されるJPAプロバイダを決定する優先順位

優先度

使用するJPAプロバイダ

1

簡易構築定義ファイルのejbserver.jpa.overrideProviderプロパティに指定された値

2

persistence.xmlの<provider>タグに指定された値

3

CJPAプロバイダ

（簡易構築定義ファイルのejbserver.jpa.defaultProviderClassNameパラメタを使用して変更することもできる）

<jta-data-source>タグ，<non-jta-data-source>タグ

簡易構築定義ファイルのejbserver.jpa.defaultJtaDsNameパラメタまたはejbserver.jpa.defaultNonJtaDsNameパラメタに指定した値が使用されます。ただし，これらのプロパティにはデフォルト値がありません。

ejbserver.jpa.overrideJtaDsNameパラメタまたはejbserver.jpa.overrideNonJtaDsNameパラメタに値が指定されている場合は，<jta-data-source>タグ，<non-jta-data-source>タグに指定された値や，ejbserver.jpa.defaultJtaDsNameパラメタ，ejbserver.jpa.defaultNonJtaDsNameパラメタに指定された値よりも優先して使用されます。

永続化ユニットで使用されるJTAデータソースおよび非JTAデータソースを決定するときの優先順位を次の表に示します。

表F‒2　永続化ユニットで使用されるJTA データソースおよび非JTAデータソースを決定する優先順位

優先度

使用するJPAプロバイダ

1

簡易構築定義ファイルのejbserver.jpa.overrideJtaDsNameプロパティまたはejbserver.jpa.overrideNonJtaDsNameプロパティに指定された値

2

persistence.xml の<jta-data-source>または<non-jta-data-source>エレメントに指定された値

3

簡易構築定義ファイルのejbserver.jpa.defaultJtaDsNameプロパティまたはejbserver.jpa.defaultNonJtaDsNameプロパティに指定した値

コンテナが永続化ユニットのエンティティマネージャファクトリを作成するときには，JPAプロバイダにプロパティを渡すことがあります。

コンテナは，persistence.xmlで永続化ユニットごとに定義されたjavax.persistence.spi.PersistenceProviderの実装クラスのインスタンスを作成し，createContainerEntityManagerFactoryメソッドを呼び出して，コンテナ管理のエンティティマネージャを作成するためのEntityManagerFactoryを取得します。永続化ユニットのメタデータは，PersistenceUnitInfoオブジェクトとして，createContainerEntityManagerFactoryメソッドの引数でJPAプロバイダに渡されます。コンテナは一つの永続化ユニット定義に対して，一つだけEntityManagerFactoryを作成し，そのEntityManagerFactoryから複数のEntityManagerを作成します。

永続化ユニットが再デプロイされる場合には，コンテナはすでに取得したEntityManagerFactoryのcloseメソッドを呼び出したあと，createContainerEntityManagerFactoryを新しいPersistenceUnitInfoとともに呼び出します。

(2)　JPAプロバイダ側の責任

JPAプロバイダはPersistenceProvider SPIを実装し，PersistenceProviderのcreateContainerEntityManagerFactoryメソッドが呼ばれたときに，引数で渡される永続化ユニットのメタデータ（PersistenceUnitInfo）を使用して，EntityManagerFactoryを作成し，コンテナに返す必要があります。

JPAプロバイダは，永続化ユニットに含まれるマネージドクラス（エンティティクラスなど）のメタデータアノテーションを処理します。また，永続化ユニットでO/Rマッピングファイルが使用されている場合には，JPAプロバイダが解釈する必要があります。このとき，O/Rマッピングファイルをorm_1_0.xsdを使用して検証し，エラーが発生した場合はユーザに通知する必要があります。

(3)　javax.persistence.spi.PersistenceProviderインタフェース

JPAプロバイダは，javax.persistence.spi.PersistenceProviderインタフェースを実装する必要があります。このインタフェースはコンテナによって呼び出されるものであり，アプリケーションから呼び出すものではありません。PersistenceProviderの実装クラスは，publicで引数のないコンストラクタを持っている必要があります。

javax.persistence.spi.PersistenceProviderインタフェースを次に示します。

package javax.persistence.spi;

/**
* JPAプロバイダによって実装されるインタフェースです。
* このインタフェースはEntityManagerFactoryを作成するために使用されます。
* Java EE環境ではコンテナによって呼び出され，
* JavaSE環境ではPersistenceクラスによって呼び出されます。
*/
public interface PersistenceProvider {

  /**
  * PersistenceクラスがEntityManagerFactoryを作成する時に呼び出されます。
  *
  * @param emName 永続化ユニットの名前
  * @param map JPAプロバイダによって使用されるプロパティのMap。
  * ここに指定されたプロパティは，persistence.xmlファイルの対応する
  * プロパティを上書きするため，またはpersistence.xmlファイルに
  * 指定されていないプロパティを指定するために使用されます。
  *（プロパティを指定する必要がない場合はnullが渡されます）
  * @return 永続化ユニットのEntityManagerFactory
  * JPAプロバイダが正しくない場合は，nullを返します。
  */
  public EntityManagerFactory createEntityManagerFactory(String
  emName, Map map);

  /**
  * コンテナがEntityManagerFactoryを作成する時に呼びだされます。
  *
  * @param info JPAプロバイダが使用するためのメタデータ
  * @param map JPAプロバイダが使用するためのインテグレーションレベルの
  * プロパティ（指定しない場合はnullが渡されます）
  * @return メタデータで指定された永続化ユニットのEntityManagerFactory
  */
  public EntityManagerFactory createContainerEntityManagerFactory(
  PersistenceUnitInfo info, Map map);
}

(4)　javax.persistence.spi.PersistenceUnitInfoインタフェース

javax.persistence.spi.PersistenceUnitInfoインタフェースの定義を次に示します。

import javax.sql.DataSource;
/**
* このインタフェースはコンテナによって実装され，
* EntityManagerFactoryを作成する時にJPAプロバイダに渡されて使用される。
*/
public interface PersistenceUnitInfo {

  /**
  * @return persistence.xmlで定義された永続化ユニット名
  */
  public String getPersistenceUnitName();

  /**
  * @return persistence.xmlの<provider>エレメントに定義された，
  * JPAプロバイダ実装クラスの完全修飾クラス名
  */
  public String getPersistenceProviderClassName();

  /**
  * @return EntityManagerFactoryによって作成されるEntityManagerの
  * トランザクションのタイプを返す。
  * persistence.xmlのtransaction-type属性に指定されたタイプである。
  */
  public PersistenceUnitTransactionType getTransactionType();

  /**
  * @return JPAプロバイダが使用するためのJTAが有効な
  * データソースを返す。
  * persistence.xmlの<jta-data-source>エレメントで指定されたデータソースか，
  * デプロイメント時にコンテナによって決定されたデータソースである。
  */
  public DataSource getJtaDataSource();

  /**
  * @return JPAプロバイダがJTAトランザクションの外で
  * データにアクセスするための，JTAが無効なデータソースを返す。
  * persistence.xmlの<non-jta-data-source>エレメントで指定された
  * データソースか，デプロイメント時にコンテナによって決定された
  * データソースである。
  */
  public DataSource getNonJtaDataSource();

  /**
  * @return JPAプロバイダがエンティティクラスのマッピングを
  * 決定するためにロードする必要のある，マッピングファイル名のリスト
  * マッピングファイルは，標準的なXML形式のマッピングフォーマット
  * でなければならない。
  * 一意の名前を持ち，アプリケーションのクラスパスからリソースとして
  * ロードできるものでなければならない。
  * それぞれのマッピングファイル名は，persistence.xmlの<mapping-file>タグ
  * に指定されたものである。
  */
  public List<String> getMappingFileNames();

  /**
  * JPAプロバイダが，永続化ユニットのマネージドクラスを検索する必要のある，
  * JARファイルまたはJARファイルを展開したディレクトリのURLのリストを返す。
  * それぞれのURLはpersistence.xmlファイルの<jar-file>タグに指定された
  * ものである。
  * URLはJARファイルまたはJARファイルを展開したディレクトリを指す
  * ファイルURLか，またはJARのフォーマットのInputStreamを取得できる
  * そのほかのURL形式である。
  *
  * @return JARファイルまたはディレクトリを指すURLオブジェクトのリスト
  */
  public List<URL> getJarFileUrls();

  /**
  * 永続化ユニットルートであるJARファイルまたはディレクトリのURLを返す。
  * （永続化ユニットルートがWEB-INF/classesディレクトリである場合，
  * WEB-INF/classesディレクトリのURLを返す）
  * URLはJARファイルまたはJARファイルを展開したディレクトリを指す
  * ファイルURLか，またはJARのフォーマットのInputStreamを取得できる
  * そのほかのURL形式である。
  *
  * @return JARファイルまたはディレクトリを指すURLオブジェクト
  */
  public URL getPersistenceUnitRootUrl();

  /**
  * @return JPAプロバイダがマネージドクラスとして扱わなくてはならない
  * クラス名のリスト。
  * それぞれのクラス名はpersistence.xmlファイルの<class>タグに指定された
  * ものである。
  */
  public List<String> getManagedClassNames();

  /**
  * @return 永続化ユニットルートに配置されていて，
  * 明示的にマネージドクラスであると指定されていないクラスを，
  * マネージドクラスとして扱うかどうかを返す。
  * この値は，persistence.xmlファイルの<exclude-unlisted-classes>タグに
  * 指定されたものである。
  */
  public boolean excludeUnlistedClasses();

  /**
  * @return Propertiesオブジェクト。
  * それぞれのプロパティはpersistence.xmlファイルの<property>タグに
  * 指定されたものである。
  */
  public Properties getProperties();

  /**
  * @return JPAプロバイダがクラスやリソースをロードしたり，
  * URLをオープンしたりするために使用できるClassLoader。
  */
  public ClassLoader getClassLoader();

  /**
  * PersistenceUnitInfo.getClassLoaderメソッドによって返されるクラスローダで，
  * 新しいクラスの定義や，クラスの再定義のたびに呼ばれる，
  * JPAプロバイダのトランスフォーマーを登録する。
  * このトランスフォーマーは，PersistenceUnitInfo.getNewTempClassLoaderメソッドで返される
  * クラスローダでロードされるクラスには影響を与えない。
  * クラスローディングのスコープ内で永続化ユニットが幾つ定義されていても，
  * 同じクラスローディングのスコープ内でクラスが変換されるのは一度だけである。
  *
  * @param transformer コンテナがクラスの定義（再定義）時に呼び出す，
  * JPAプロバイダのトランスフォーマー
  */
  public void addTransformer(ClassTransformer transformer);

  /**
  * JPAプロバイダが一時的にクラスやリソースをロードしたり，
  * URLをオープンしたりするために使用できるクラスローダの
  * 新しいインスタンスを返す。
  * このクラスローダのスコープやクラスパスは，
  * PersistenceUnitInfo.getClassLoaderで返される
  * クラスローダと完全に同じである。
  * このクラスローダでロードしたクラスが，
  * アプリケーションのコンポーネントから参照できるようになることはない。
  * JPAプロバイダは，createContainerEntityManagerFactoryの
  * 呼び出しの延長でだけ，このクラスローダを使用できる。
  *
  * @return 現在のクラスローダと同じスコープ・クラスパスを持つ一時的な
  * クラスローダ
  */
  public ClassLoader getNewTempClassLoader();

}

参考

アプリケーションサーバでは，永続化ユニットでJTAデータソース，非JTAデータソースが定義されていない場合には，getJtaDataSource()またはgetNonJtaDataSource()はnullを返します。永続化ユニットでJTAデータソース，非JTAデータソースが定義されていない場合とは，次の状態を指します。

persistence.xmlで<jta-data-source>，<non-jta-data-source>が省略されていて，かつデフォルト値がシステムプロパティejbserver.jpa.defaultJtaDsName，ejbserver.jpa.defaultNonJtaDsNameで定義されていない場合

システムプロパティejbserver.jpa.overrideJtaDsName，ejbserver.jpa.overrideNonJtaDsNameも定義されていない場合

付録G　JPQLのBNF

ここでは，JPA1.0仕様で規定されているJPQLのBNFについて示します。

表G‒1　BNF表記の規則

表記

内容

{　}

グループを表します。

[　]

オプションの構文を表します。

*

0以上を表します。

A|B

AまたはBを表します。

なお，背景色付きの太字部分はキーワードを表します。

次に，BNFを示します。

QL_statement ::= select_statement | update_statement | delete_statement
select_statement ::= select_clause from_clause [where_clause] [groupby_clause]
[having_clause] [orderby_clause]
update_statement ::= update_clause [where_clause]
delete_statement ::= delete_clause [where_clause]
from_clause ::=
FROM identification_variable_declaration
{, {identification_variable_declaration | collection_member_declaration}}*
identification_variable_declaration ::= range_variable_declaration { join | fetch_join }*
range_variable_declaration ::= abstract_schema_name [AS] identification_variable
join ::= join_spec join_association_path_expression [AS] identification_variable
fetch_join ::= join_spec FETCH join_association_path_expression
association_path_expression ::=
collection_valued_path_expression | single_valued_association_path_expression
join_spec::= [ LEFT [OUTER] | INNER ] JOIN
join_association_path_expression ::= join_collection_valued_path_expression |
join_single_valued_association_path_expression
join_collection_valued_path_expression::=
identification_variable.collection_valued_association_field
join_single_valued_association_path_expression::=
identification_variable.single_valued_association_field
collection_member_declaration ::=
IN (collection_valued_path_expression) [AS] identification_variable
single_valued_path_expression ::=
state_field_path_expression | single_valued_association_path_expression
state_field_path_expression ::=
{identification_variable | single_valued_association_path_expression}.state_field
single_valued_association_path_expression ::=
identification_variable.{single_valued_association_field.}* single_valued_association_field
collection_valued_path_expression ::=
identification_variable.{single_valued_association_field.}*collection_valued_association_field
state_field ::= {embedded_class_state_field.}*simple_state_field
update_clause ::= UPDATE abstract_schema_name [[AS] identification_variable]
SET update_item {, update_item}*
update_item ::= [identification_variable.]{state_field | single_valued_association_field} =
new_value
new_value ::=
simple_arithmetic_expression |
string_primary |
datetime_primary |
boolean_primary |
enum_primary
simple_entity_expression |
NULL
delete_clause ::= DELETE FROM abstract_schema_name [[AS] identification_variable]
select_clause ::= SELECT [DISTINCT] select_expression {, select_expression}*
select_expression ::=
single_valued_path_expression |
aggregate_expression |
identification_variable |
OBJECT(identification_variable) |
constructor_expression
constructor_expression ::=
NEW constructor_name ( constructor_item {, constructor_item}* )
constructor_item ::= single_valued_path_expression | aggregate_expression
aggregate_expression ::=
{ AVG | MAX | MIN | SUM } ([DISTINCT] state_field_path_expression) |
COUNT ([DISTINCT] identification_variable | state_field_path_expression |
single_valued_association_path_expression)
where_clause ::= WHERE conditional_expression
groupby_clause ::= GROUP BY groupby_item {, groupby_item}*
groupby_item ::= single_valued_path_expression | identification_variable
having_clause ::= HAVING conditional_expression
orderby_clause ::= ORDER BY orderby_item {, orderby_item}*
orderby_item ::= state_field_path_expression [ ASC | DESC ]
subquery ::= simple_select_clause subquery_from_clause [where_clause]
[groupby_clause] [having_clause]
subquery_from_clause ::=
FROM subselect_identification_variable_declaration
{, subselect_identification_variable_declaration}*
subselect_identification_variable_declaration ::=
identification_variable_declaration |
association_path_expression [AS] identification_variable |
collection_member_declaration
simple_select_clause ::= SELECT [DISTINCT] simple_select_expression
simple_select_expression::=
single_valued_path_expression |
aggregate_expression |
identification_variable
conditional_expression ::= conditional_term | conditional_expression OR conditional_term
conditional_term ::= conditional_factor | conditional_term AND conditional_factor
conditional_factor ::= [ NOT ] conditional_primary
conditional_primary ::= simple_cond_expression | (conditional_expression)
simple_cond_expression ::=
comparison_expression |
between_expression |
like_expression |
in_expression |
null_comparison_expression |
empty_collection_comparison_expression |
collection_member_expression |
exists_expression
between_expression ::=
arithmetic_expression [NOT] BETWEEN
arithmetic_expression AND arithmetic_expression |
string_expression [NOT] BETWEEN string_expression AND string_expression |
datetime_expression [NOT] BETWEEN
datetime_expression AND datetime_expression
in_expression ::=
state_field_path_expression [NOT] IN ( in_item {, in_item}* | subquery)
in_item ::= literal | input_parameter
like_expression ::=
string_expression [NOT] LIKE pattern_value [ESCAPE escape_character]
null_comparison_expression ::=
{single_valued_path_expression | input_parameter} IS [NOT] NULL
empty_collection_comparison_expression ::=
collection_valued_path_expression IS [NOT] EMPTY
collection_member_expression ::= entity_expression
[NOT] MEMBER [OF] collection_valued_path_expression
exists_expression::= [NOT] EXISTS (subquery)
all_or_any_expression ::= { ALL | ANY | SOME} (subquery)
comparison_expression ::=
string_expression comparison_operator {string_expression | all_or_any_expression} |
boolean_expression { =|<>} {boolean_expression | all_or_any_expression} |
enum_expression { =|<>} {enum_expression | all_or_any_expression} |
datetime_expression comparison_operator
{datetime_expression | all_or_any_expression} |
entity_expression { = | <> } {entity_expression | all_or_any_expression} |
arithmetic_expression comparison_operator
{arithmetic_expression | all_or_any_expression}
comparison_operator ::= = | > | >= | < | <= | <>
arithmetic_expression ::= simple_arithmetic_expression | (subquery)
simple_arithmetic_expression ::=
arithmetic_term | simple_arithmetic_expression { + | - } arithmetic_term
arithmetic_term ::= arithmetic_factor | arithmetic_term { * | / } arithmetic_factor
arithmetic_factor ::= [{ + | - }] arithmetic_primary
arithmetic_primary ::=
state_field_path_expression |
numeric_literal |
(simple_arithmetic_expression) |
input_parameter |
functions_returning_numerics |
aggregate_expression
string_expression ::= string_primary | (subquery)
string_primary ::=
state_field_path_expression |
string_literal |
input_parameter |
functions_returning_strings |
aggregate_expression
datetime_expression ::= datetime_primary | (subquery)
datetime_primary ::=
state_field_path_expression |
input_parameter |
functions_returning_datetime |
aggregate_expression
boolean_expression ::= boolean_primary | (subquery)
boolean_primary ::=
state_field_path_expression |
boolean_literal |
input_parameter |
enum_expression ::= enum_primary | (subquery)
enum_primary ::=
state_field_path_expression |
enum_literal |
input_parameter |
entity_expression ::=
single_valued_association_path_expression | simple_entity_expression
simple_entity_expression ::=
identification_variable |
input_parameter
functions_returning_numerics::=
LENGTH(string_primary) |
LOCATE(string_primary, string_primary[, simple_arithmetic_expression]) |
ABS(simple_arithmetic_expression) |
SQRT(simple_arithmetic_expression) |
MOD(simple_arithmetic_expression, simple_arithmetic_expression) |
SIZE(collection_valued_path_expression)
functions_returning_datetime ::=
CURRENT_DATE|
CURRENT_TIME |
CURRENT_TIMESTAMP
functions_returning_strings ::=
CONCAT(string_primary, string_primary) |
SUBSTRING(string_primary,
simple_arithmetic_expression, simple_arithmetic_expression)|
TRIM([[trim_specification] [trim_character] FROM] string_primary) |
LOWER(string_primary) |
UPPER(string_primary)
trim_specification ::= LEADING | TRAILING | BOTH

付録H　各バージョンでの主な機能変更

ここでは，11-40よりも前のアプリケーションサーバの各バージョンでの主な機能の変更について，変更目的ごとに説明します。11-40での主な機能変更については，「1.3　アプリケーションサーバ 11-40での主な機能変更」を参照してください。

説明内容は次のとおりです。

アプリケーションサーバの各バージョンで変更になった主な機能と，その概要を説明しています。機能の詳細については「参照先マニュアル」の「参照個所」の記述を確認してください。「参照先マニュアル」および「参照個所」には，その機能についての11-40のマニュアルでの主な記載個所を記載しています。

「参照先マニュアル」に示したマニュアル名の「アプリケーションサーバ」は省略しています。

付録H.1　11-30での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒1　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JDBC4.3への対応

JDBC4.3に対応しました。

アプリケーションサーバ & BPM/ESB基盤 概説

4.6.2

接続できるデータベースにMySQL，PostgreSQLを追加

DB Connectorを使用して接続できるデータベースに，MySQL，PostgreSQLを追加しました。

機能解説 基本・開発編(コンテナ共通機能)

3.6

パッケージ名変換機能の追加

jakartaパッケージ名を前提とするアプリケーションをアプリケーションサーバで動作させる機能を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

20章

付録H.2　11-20での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒2　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JSF 2.3への対応

JSF 2.3に対応しました。

機能解説 基本・開発編(Web コンテナ)

3章

JAX-RS 2.1への対応

JAX-RS 2.1に対応しました。

機能解説 基本・開発編(Web コンテナ)

4章

WebSocket 1.1への対応

WebSocket 1.1に対応しました。

機能解説 基本・開発編(Web コンテナ)

5章

Servlet 4.0への対応

Servlet 4.0に対応しました。これに伴い，NIO HTTPサーバでHTTP/2に対応しました。

機能解説 基本・開発編(Web コンテナ)

8章

CDI Managed BeanでのJPA利用

CDI Managed BeanでのJPA利用に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

5章

JPA 2.2への対応

JPA 2.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

6章

CDI 2.0への対応

CDI 2.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

WEB-INF/lib内のCDIへの対応

WARファイルのWEB-INF/lib以下のJARファイルからCDIを利用できるようにしました。

機能解説 基本・開発編(コンテナ共通機能)

9章

BV 2.0への対応

BV 2.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

10章

JSON-P 1.1への対応

JSON-P 1.1に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

12章

JSON-B 1.0への対応

JSON-B 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

13章

付録H.3　11-10での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表H‒3　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ライブラリ競合回避機能の追加

クラス・リソースをロードするときの検索順序を変更し，ユーザアプリケーションに含まれるライブラリを優先して参照できるようにする機能を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

付録B.4

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒4　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JSP2.3への対応

JSP2.3に対応しました。

機能解説 基本・開発編(Web コンテナ)

8章

コンテナ管理のEntityManagerへの対応

JPA 2.1に対応したコンテナ管理のEntityManagerに対応しました。

機能解説 基本・開発編(コンテナ共通機能)

5章

Interceptors 1.2への対応

Interceptors 1.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

15章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表H‒5　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッションマネージャの指定機能の追加

クラウド環境利用時にHTTPセッションのセッションフェイルオーバを利用できるようにする機能を追加しました。

機能解説 基本・開発編(Web コンテナ)

2.22

付録H.4　11-00での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表H‒6　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

開発環境のWindows Server対応

クラウド環境上にアプリケーション開発環境を構築できるよう，uCosminexus DeveloperのサポートOSにWindows Server OSを追加しました。

−

−

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒7　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0/3.1への対応

Servlet 3.0の非同期サーブレット，およびServlet 3.1の非同期I/O系APIに対応しました。

機能解説 基本・開発編(Webコンテナ)

8.1

EL 3.0への対応

EL 3.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.3.3

JSF 2.2への対応

JSF 2.2に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

JAX-RS 2.0への対応

JAX-RS 2.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

4章

WebSocket 1.0への対応

WebSocket 1.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

5章

NIO HTTPサーバ機能の追加

従来のリダイレクタ機能やインプロセスHTTPサーバ機能に代わり，非同期サーブレットやWebSocketなどのノンブロッキングI/O処理に対応したインプロセスのHTTPサーバとして，NIO HTTPサーバ機能を追加しました。

機能解説 基本・開発編(Web コンテナ)

7章

JPA 2.1への対応

JPA 2.1に対応し，JPA 2.1対応のJPAプロバイダを利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

6章

CDI 1.2への対応

CDI 1.2に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

BV 1.1への対応

Bean Validation 1.1に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

10章

Java Batch 1.0への対応

Batch Applications for the Java Platform （Java Batch） 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

11章

JSON-P 1.0への対応

Java API for JSON Processing（JSON-P） 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

12章

Concurrency Utilities 1.0への対応

Concurrency Utilities for Java EE 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

14章

WebSocket通信への対応

HTTP ServerからJ2EEサーバにWebSocket通信を中継する機能を追加しました。

HTTP Server

4.15

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表H‒8　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

暗号化通信モジュールの変更

HTTP Serverの暗号化通信モジュールとしてmod_sslを採用しました。

HTTP Server

5章，付録D

(4)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表H‒9　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

V9互換モードの追加

Version 9以前のJ2EEサーバから移行するユーザ向けに，Version 9との互換性を維持するためのV9互換モードを追加しました。

機能解説 保守／移行編

10.3.4

付録H.5　09-87での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒10　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Java SE 11への対応

Java SE 11の機能が使用できるようになりました。

機能解説 保守／移行編

9章

付録H.6　09-80での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒11　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JAX-RS機能でのラムダ式の使用

web.xmlのサーブレット初期化パラメタに指定したパッケージとそのサブパッケージに含まれるクラスで，ラムダ式が使用できるようになりました。

Webサービス開発ガイド

11.2

Java SE 9への対応

Java SE 9の機能が使用できるようになりました。

機能解説 保守／移行編

9章

(2)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表H‒12　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

WebサーバのApache2.4のサポート

WebサーバのベースバージョンとしてApache2.4をサポートしました。

HTTP Server

6章，付録C

SSL通信での楕円曲線暗号の利用

楕円曲線暗号を利用したSSL通信ができるようになりました。

HTTP Server

5章，付録C

SSLライブラリの変更

SSL機能を提供するSSLライブラリをOpenSSLに変更しました。

HTTP Server

5章，付録C

付録H.7　09-70での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒13　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのJSPコンパイルバージョンの追加

J2EEサーバでのJSPから生成されたサーブレットのコンパイル方法に「JDK1.7の仕様に従ったコンパイル」と「JDK7の仕様に従ったコンパイル」を追加する。

運用管理ポータル操作ガイド

10.8.4

リファレンス 定義編(サーバ定義)

4.11.2

JDK8でのメタスペース対応

JavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する。

システム構築・運用ガイド

付録A.2

運用管理ポータル操作ガイド

10.8.7

リファレンス 定義編(サーバ定義)

5.2.1，5.2.2，8.2.3

統合ユーザ管理でのユーザ認証のSHA-2対応

統合ユーザ管理でのユーザ認証のハッシュアルゴリズムとしてSHA-224，SHA-256，SHA-384，SHA-512を追加する。

機能解説 セキュリティ管理機能編

5.3.1，5.3.9，5.10.7，11.4.3，12.4.3，12.5.3，13.2，14.2.2

Red Hat Enterprise Linux Server 7での自動起動と自動再起動および自動停止の追加

Red Hat Enterprise Linux Server 7でのManagement Serverと運用管理エージェントの自動起動と自動再起動および自動停止方法を追加する。

機能解説 運用／監視／連携編

2.6.3，2.6.4，2.6.5

リファレンス コマンド編

7.2

(2)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表H‒14　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

V9.7へのバージョンアップ対応

バージョンアップ時のJavaVMの起動で使用しているPermanent領域用のオプションをMetaspace領域用のオプションに変更する手順を追加する。

機能解説 保守／移行編

10.3.1，10.3.2，10.3.5

(3)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表H‒15　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

snapshotログの収集対象

snapshotログの収集対象としてJavaVMイベントログとManagement Serverのスレッドダンプを追加する。

機能解説 保守／移行編

付録A.2

付録H.8　09-60での主な機能変更

(1)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒16　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

G1GCへの対応

G1GCを選択できるようになりました。

システム設計ガイド

7.15

リファレンス 定義編(サーバ定義)

14.5

圧縮オブジェクトポインタ機能への対応

圧縮オブジェクトポインタ機能を使用できるようになりました。

機能解説 保守／移行編

9.16

(2)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表H‒17　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ファイナライズ滞留解消機能の追加

ファイナライズ処理の滞留を解消でき，OS資源の解放遅れなどの発生を抑止できるようになりました。

機能解説 保守／移行編

9.17

(3)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表H‒18　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログファイルの非同期出力機能の追加

ログのファイル出力を非同期でできるようになりました。

リファレンス 定義編(サーバ定義)

14.2

付録H.9　09-50での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更した項目を次の表に示します。

表H‒19　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Eclipseセットアップの簡略化

GUIを利用してEclipse環境をセットアップできるようになりました。

アプリケーション開発ガイド

1.1.5，2.4

ユーザ拡張性能解析トレースを使ったデバッグ支援

ユーザ拡張性能解析トレース設定ファイルを開発環境で作成できるようになりました。

アプリケーション開発ガイド

1.1.3，6.4

(2)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表H‒20　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのシステム構成パターンの拡充

仮想化環境で使用できるティアの種類（http-tier，j2ee-tierおよびctm-tier）が増えました。これによって，次のシステム構成パターンが構築できるようになりました。

WebサーバとJ2EEサーバを別のホストに配置するパターン

フロントエンド（サーブレット，JSP）とバックエンド（EJB）を分けて配置するパターン

CTMを使用するパターン

仮想化システム構築・運用ガイド

1.1.2

(3)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒21　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JDBC 4.0仕様への対応

DB ConnectorでJDBC 4.0仕様のHiRDB Type4 JDBC Driver，およびSQL ServerのJDBCドライバに対応しました。

機能解説 基本・開発編(コンテナ共通機能)

3.6.3

Portable Global JNDI名での命名規則の緩和

Portable Global JNDI名に使用できる文字を追加しました。

機能解説 基本・開発編(コンテナ共通機能)

2.4.3

Servlet 3.0仕様への対応

Servlet 3.0のHTTP Cookieの名称，およびURLのパスパラメタ名の変更が，Servlet 2.5以前のバージョンでも使用できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.7

Bean Validationと連携できるアプリケーションの適用拡大

CDIやUAPでもBean Validationを使って検証できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

10章

JavaMailへの対応

JavaMail 1.4に準拠したAPIを使用したメール送受信機能を利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

8章

javacoreコマンドが使用できるOSの適用拡大

javacoreコマンドを使って，Windowsのスレッドダンプを取得できるようになりました。

リファレンス コマンド編

javacore（スレッドダンプの取得／Windowsの場合）

(4)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表H‒22　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

コードキャッシュ領域の枯渇回避

システムで使用しているコードキャッシュ領域のサイズを確認して，領域が枯渇する前にしきい値を変更して領域枯渇するのを回避できるようになりました。

システム設計ガイド

7.2.6

機能解説 保守／移行編

5.7.2，5.7.3

リファレンス 定義編(サーバ定義)

14.1，14.2，14.4

明示管理ヒープ機能の効率的な適用への対応

自動解放処理時間を短縮し，明示管理ヒープ機能を効率的に適用するための機能として，Explicitヒープに移動するオブジェクトを制御できる機能を追加しました。

Explicitメモリブロックへのオブジェクト移動制御機能

明示管理ヒープ機能適用除外クラス指定機能

Explicitヒープ情報へのオブジェクト解放率情報の出力

システム設計ガイド

7.14.6

機能解説 拡張編

7.2.2，7.6.5，7.10，7.13.1，7.13.3

機能解説 保守／移行編

5.5

クラス別統計情報の出力範囲拡大

クラス別統計情報を含んだ拡張スレッドダンプに，staticフィールドを基点とした参照関係を出力できるようになりました。

機能解説 保守／移行編

9.6

(5)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表H‒23　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

EADsセッションフェイルオーバ機能のサポート

EADsと連携してセッションフェイルオーバ機能を実現するEADsセッションフェイルオーバ機能をサポートしました。

機能解説 拡張編

5章

WARによる運用

WARファイルだけで構成されたWARアプリケーションをJ2EEサーバにデプロイできるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.2.1

機能解説 基本・開発編(コンテナ共通機能)

18.9

リファレンス コマンド編

cjimportwar（WARアプリケーションのインポート）

運用管理機能の同期実行による起動と停止

運用管理機能（Management Serverおよび運用管理エージェント）の起動および停止を，同期実行するオプションを追加しました。

機能解説 運用／監視／連携編

2.6.1，2.6.2，2.6.3，2.6.4

リファレンス コマンド編

adminagentctl（運用管理エージェントの起動と停止），mngautorun（自動起動および自動再起動の設定／設定解除），mngsvrctl（Management Serverの起動／停止／セットアップ）

明示管理ヒープ機能でのExplicitメモリブロックの強制解放

javagcコマンドで，Explicitメモリブロックの解放処理を任意のタイミングで実行できるようになりました。

機能解説 拡張編

7.6.1，7.9

リファレンス コマンド編

javagc（GCの強制発生）

(6)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表H‒24　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

定義情報の取得

snapshotlog（snapshotログの収集）コマンドで定義ファイルだけを収集できるようになりました。

機能解説 保守／移行編

2.3

リファレンス コマンド編

snapshotlog（snapshotログの収集）

cjenvsetupコマンドのログ出力

Component Container管理者のセットアップ（cjenvsetupコマンド）の実行情報がメッセージログに出力されるようになりました。

システム構築・運用ガイド

4.1.4

機能解説 保守／移行編

4.20

リファレンス コマンド編

cjenvsetup（Component Container管理者のセットアップ）

BIG-IP v11のサポート

使用できる負荷分散機の種類にBIG-IP v11が追加になりました。

システム構築・運用ガイド

4.7.2

仮想化システム構築・運用ガイド

2.1

明示管理ヒープ機能のイベントログへのCPU時間の出力

Explicitメモリブロック解放処理に掛かったCPU時間が，明示管理ヒープ機能のイベントログに出力されるようになりました。

機能解説 保守／移行編

5.11.3

ユーザ拡張性能解析トレースの機能拡張

ユーザ拡張性能解析トレースで，次の機能を追加しました。

トレース対象の指定方法を通常のメソッド単位の指定方法に加えて，パッケージ単位またはクラス単位で指定できるようになりました。

使用できるイベントIDの範囲を拡張しました。

ユーザ拡張性能解析トレース設定ファイルに指定できる行数の制限を緩和しました。

ユーザ拡張性能解析トレース設定ファイルでトレース取得レベルを指定できるようになりました。

機能解説 保守／移行編

7.5.2，7.5.3，8.25.1

Session Beanの非同期呼び出し使用時の情報解析向上

PRFトレースのルートアプリケーション情報を使用して，呼び出し元と呼び出し先のリクエストを突き合わせることができるようになりました。

機能解説 基本・開発編（EJBコンテナ）

2.17.3

付録H.10　09-00での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表H‒25　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境での構築・運用の操作対象単位の変更

仮想化環境の構築・運用時の操作対象単位が仮想サーバから仮想サーバグループへ変更になりました。仮想サーバグループの情報を定義したファイルを使用して，複数の仮想サーバを管理ユニットへ一括で登録できるようになりました。

仮想化システム構築・運用ガイド

1.1.2

セットアップウィザードによる構築環境の制限解除

セットアップウィザードを使用して構築できる環境の制限が解除されました。ほかの機能で構築した環境があってもアンセットアップされて，セットアップウィザードで構築できるようになりました。

システム構築・運用ガイド

2.2.7

構築環境の削除手順の簡略化

Management Serverを使用して構築したシステム環境を削除する機能（mngunsetupコマンド）の追加によって，削除手順を簡略化しました。

システム構築・運用ガイド

4.1.37

運用管理ポータル操作ガイド

3.6，5.4

リファレンス コマンド編

mngunsetup（Management Serverの構築環境の削除）

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒26　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 3.0への対応

Servlet 3.0に対応しました。

機能解説 基本・開発編(Webコンテナ)

8章

EJB 3.1への対応

EJB 3.1に対応しました。

機能解説 基本・開発編(EJBコンテナ)

2章

JSF 2.1への対応

JSF 2.1に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

JSTL 1.2への対応

JSTL 1.2に対応しました。

機能解説 基本・開発編(Webコンテナ)

3章

CDI 1.0への対応

CDI 1.0に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

9章

Portable Global JNDI名の利用

Portable Global JNDI名を利用したオブジェクトのルックアップができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

2.4

JAX-WS 2.2への対応

JAX-WS 2.2に対応しました。

Webサービス開発ガイド

1.1，16.1.5，16.1.7，16.2.1，16.2.6，16.2.10，16.2.12，16.2.13，16.2.14，16.2.16，16.2.17，16.2.18，16.2.20，16.2.22，19.1，19.2.3，37.2，37.6.1，37.6.2，37.6.3

JAX-RS 1.1への対応

JAX-RS 1.1に対応しました。

Webサービス開発ガイド

1.1，1.2.2，1.3.2，1.4.2，1.5.1，1.6，2.3，11章，12章，13章，17章，24章，39章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表H‒27　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

SSL/TLS通信でのTLSv1.2の使用

RSA BSAFE SSL-Jを使用して，TLSv1.2を含むセキュリティ・プロトコルでSSL/TLS通信ができるようになりました。

−

−

（凡例）−：09-70で削除された機能です。

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表H‒28　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Webコンテナ全体の実行待ちキューの総和の監視

Webコンテナ全体の実行待ちキューの総和を稼働情報に出力して監視できるようになりました。

機能解説 運用／監視／連携編

3章

アプリケーションの性能解析トレース（ユーザ拡張トレース）の出力

ユーザが開発したアプリケーションの処理性能を解析するための性能解析トレースを，アプリケーションの変更をしないで出力できるようになりました。

機能解説 保守／移行編

7章

仮想化環境でのユーザスクリプトを使用した運用

任意のタイミングでユーザ作成のスクリプト（ユーザスクリプト）を仮想サーバ上で実行できるようになりました。

仮想化システム構築・運用ガイド

7.8

運用管理ポータル改善

運用管理ポータルの次の画面で，手順を示すメッセージを画面に表示するように変更しました。

［設定情報の配布］画面

Webサーバ，J2EEサーバおよびSFOサーバの起動画面

WebサーバクラスタとJ2EEサーバクラスタの一括起動，一括再起動および起動画面

運用管理ポータル操作ガイド

10.10.1，11.9.2，11.10.2，11.10.4，11.10.6，11.11.2，11.12.2，11.12.4，11.12.6

運用管理機能の再起動機能の追加

運用管理機能（Management Serverおよび運用管理エージェント）で自動再起動が設定できるようになり，運用管理機能で障害が発生した場合でも運用が継続できるようになりました。また，自動起動の設定方法も変更になりました。

機能解説 運用／監視／連携編

2.4.1，2.4.2，2.6.3，2.6.4

リファレンス コマンド編

mngautorun（自動起動および自動再起動の設定／設定解除）

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表H‒29　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

ログ出力時のファイル切り替え単位の変更

ログ出力時に，日付ごとに出力先のファイルを切り替えられるようになりました。

機能解説 保守／移行編

3.2.1

Webサーバの名称の変更

アプリケーションサーバに含まれるWebサーバの名称をHTTP Serverに変更しました。

HTTP Server

−

BIG-IPのAPI（SOAPアーキテクチャ）を使用した直接接続への対応

BIG-IP（負荷分散機）でAPI（SOAPアーキテクチャ）を使用した直接接続に対応しました。

また，APIを使用した直接接続を使用する場合に，負荷分散機の接続環境を設定する方法が変更になりました。

システム構築・運用ガイド

4.7.3，付録J

仮想化システム構築・運用ガイド

2.1，付録C

機能解説 セキュリティ管理機能編

8.2，8.4，8.5，8.6，18.2.1，18.2.2，18.2.3

（凡例）−：マニュアル全体を参照する

付録H.11　08-70での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更した項目を次の表に示します。

表H‒30　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータル改善

運用管理ポータルの画面で，リソースアダプタの属性を定義するプロパティ（Connector属性ファイルの設定内容）の設定，および接続テストができるようになりました。また，運用管理ポータルの画面で，J2EEアプリケーション（earファイルおよびzipファイル）をManagement Serverにアップロードできるようになりました。

ファーストステップガイド

3.5

運用管理ポータル操作ガイド

−

page/tagディレクティブのimport属性暗黙インポート機能の追加

page/tagディレクティブのimport属性暗黙インポート機能を使用できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3.7

仮想化環境でのJP1製品に対する環境設定の自動化対応

仮想サーバへのアプリケーションサーバ構築時に，仮想サーバに対するJP1製品の環境設定を，フックスクリプトで自動的に設定できるようになりました。

仮想化システム構築・運用ガイド

7.7.2

統合ユーザ管理機能の改善

ユーザ情報リポジトリでデータベースを使用する場合に，データベース製品のJDBCドライバを使用して，データベースに接続できるようになりました。DABroker LibraryのJDBCドライバによるデータベース接続はサポート外になりました。

簡易構築定義ファイルおよび運用管理ポータルの画面で，統合ユーザ管理機能に関する設定ができるようになりました。

また，Active Directoryの場合，DNで日本語などの2バイト文字に対応しました。

機能解説 セキュリティ管理機能編

5章，14.2.2

運用管理ポータル操作ガイド

3.5，10.8.1

HTTP Server設定項目の拡充

簡易構築定義ファイルおよび運用管理ポータルの画面で，HTTP Serverの動作環境を定義するディレクティブ（httpsd.confの設定内容）を直接設定できるようになりました。

システム構築・運用ガイド

4.1.21

運用管理ポータル操作ガイド

10.9.1

リファレンス 定義編(サーバ定義)

4.10

（凡例）−：マニュアル全体を参照する

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更した項目を次の表に示します。

表H‒31　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ejb-jar.xmlの指定項目の追加

ejb-jar.xmlに，クラスレベルインターセプタおよびメソッドレベルインターセプタを指定できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

2.15

パラレルコピーガーベージコレクションへの対応

パラレルコピーガーベージコレクションを選択できるようになりました。

リファレンス 定義編(サーバ定義)

14.5

Connector 1.5仕様に準拠したInboundリソースアダプタのグローバルトランザクションへの対応

Connector 1.5仕様に準拠したリソースアダプタでTransacted Deliveryを使用できるようにしました。これによって，Message-driven Beanを呼び出すEISがグローバルトランザクションに参加できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

3.16.3

TP1インバウンドアダプタのMHPへの対応

TP1インバウンドアダプタを使用してアプリケーションサーバを呼び出すOpenTP1のクライアントとして，MHPを使用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

4章

cjrarupdateコマンドのFTPインバウンドアダプタへの対応

cjrarupdateコマンドでバージョンアップできるリソースアダプタにFTPインバウンドアダプタを追加しました。

リファレンス コマンド編

2.2

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更した項目を次の表に示します。

表H‒32　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

データベースセッションフェイルオーバ機能の改善

性能を重視するシステムで，グローバルセッション情報を格納したデータベースのロックを取得しないモードを選択できるようになりました。また，データベースを更新しない，参照専用のリクエストを定義できるようになりました。

機能解説 拡張編

6章

OutOfMemoryハンドリング機能の対象となる処理の拡大

OutOfMemoryハンドリング機能の対象となる処理を追加しました。

機能解説 保守／移行編

2.5.4

リファレンス 定義編(サーバ定義)

14.2

HTTPセッションで利用するExplicitヒープの省メモリ化機能の追加

HTTPセッションで利用するExplicitヒープのメモリ使用量を抑止する機能を追加しました。

機能解説 拡張編

7.11

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更した項目を次の表に示します。

表H‒33　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

仮想化環境でのJP1製品を使用したユーザ認証への対応（クラウド運用対応）

JP1連携時に，JP1製品の認証サーバを利用して，仮想サーバマネージャを使用するユーザを管理・認証できるようになりました。

仮想化システム構築・運用ガイド

1.2.2，3章，4章，5章，6章，7.9

(5)　そのほかの目的

そのほかの目的で変更した項目を次の表に示します。

表H‒34　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

負荷分散機へのAPI（RESTアーキテクチャ）を使用した直接接続の対応

負荷分散機への接続方法として，API（RESTアーキテクチャ）を使用した直接接続に対応しました。

また，使用できる負荷分散機の種類にACOS（AX2500）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3

仮想化システム構築・運用ガイド

2.1

リファレンス 定義編(サーバ定義)

4.2.4

snapshotログ収集時のタイムアウトへの対応と収集対象の改善

snapshotログの収集が指定した時間で終了（タイムアウト）できるようになりました。一次送付資料として収集される内容が変更になりました。

機能解説 保守／移行編

付録A

付録H.12　08-53での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更された項目を次の表に示します。

表H‒35　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

さまざまなハイパーバイザに対応した仮想化環境の構築

さまざまなハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築できるようになりました。

また，複数のハイパーバイザが混在する環境にも対応しました。

仮想化システム構築・運用ガイド

2章，3章，5章

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更された項目を次の表に示します。

表H‒36　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

トランザクション連携に対応したOpenTP1からの呼び出し

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出すときに，トランザクション連携ができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

4章

JavaMail

POP3に準拠したメールサーバと連携して，JavaMail 1.3に準拠したAPIを使用したメール受信機能を利用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

8章

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更された項目を次の表に示します。

表H‒37　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JavaVMのトラブルシュート機能強化

JavaVMのトラブルシュート機能として，次の機能が使用できるようになりました。

OutOfMemoryError発生時の動作を変更できるようになりました。

JITコンパイル時に，Cヒープ確保量の上限値を設定できるようになりました。

スレッド数の上限値を設定できるようになりました。

拡張verbosegc情報の出力項目を拡張しました。

機能解説 保守／移行編

4章，5章，9章

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更された項目を次の表に示します。

表H‒38　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

JP1/ITRMへの対応

ITリソースを一元管理する製品であるJP1/ITRMに対応しました。

仮想化システム構築・運用ガイド

1.3，2.1

(5)　そのほかの目的

そのほかの目的で変更された項目を次の表に示します。

表H‒39　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

Microsoft IIS 7.0およびMicrosoft IIS 7.5への対応

WebサーバとしてMicrosoft IIS 7.0およびMicrosoft IIS 7.5に対応しました。

−

−

HiRDB Version 9およびSQL Server 2008への対応

データベースとして次の製品に対応しました。

HiRDB Server Version 9

HiRDB/Developer's Kit Version 9

HiRDB/Run Time Version 9

SQL Server 2008

また，SQL Server 2008に対応するJDBCドライバとして，SQL Server JDBC Driverに対応しました。

機能解説 基本・開発編(コンテナ共通機能)

3章

（凡例）−：該当なし。

付録H.13　08-50での主な機能変更

(1)　導入・構築の容易性強化

導入・構築の容易性強化を目的として変更された項目を次の表に示します。

表H‒40　導入・構築の容易性強化を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Webサービスプロバイダ側でのweb.xmlの指定必須タグの変更

Webサービスプロバイダ側でのweb.xmlで，listenerタグ，servletタグ，およびservlet-mappingタグの指定を必須から任意に変更しました。

リファレンス 定義編(サーバ定義)

2.2.3

論理サーバのネットワークリソース使用

J2EEアプリケーションからほかのホスト上にあるネットワークリソースやネットワークドライブにアクセスするための機能を追加しました。

機能解説 運用／監視／連携編

1.2.3，5.2，5.7

サンプルプログラムの実行手順の簡略化

一部のサンプルプログラムをEAR形式で提供することによって，サンプルプログラムの実行手順を簡略化しました。

ファーストステップガイド

3.5

システム構築・運用ガイド

付録L

運用管理ポータルの画面の動作の改善

画面の更新間隔のデフォルトを「更新しない」から「3秒」に変更しました。

運用管理ポータル操作ガイド

7.4.1

セットアップウィザードの完了画面の改善

セットアップウィザード完了時の画面に，セットアップで使用した簡易構築定義ファイルおよびConnector属性ファイルが表示されるようになりました。

システム構築・運用ガイド

2.2.6

仮想化環境の構築

ハイパーバイザを使用して実現する仮想サーバ上に，アプリケーションサーバを構築する手順を追加しました。

仮想化システム構築・運用ガイド

3章，5章

(2)　標準機能・既存機能への対応

標準機能・既存機能への対応を目的として変更された項目を次の表に示します。

表H‒41　標準機能・既存機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

OpenTP1からの呼び出しへの対応

OpenTP1からアプリケーションサーバ上で動作するMessage-driven Beanを呼び出せるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

4章

JMSへの対応

JMS 1.1仕様に対応したCJMSプロバイダ機能を使用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

7章

Java SE 6への対応

Java SE 6の機能が使用できるようになりました。

機能解説 保守／移行編

5.5，5.8.1

ジェネリクスの使用への対応

EJBでジェネリクスを使用できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

4.2.18

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更された項目を次の表に示します。

表H‒42　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

明示管理ヒープ機能の使用性向上

自動配置設定ファイルを使用して，明示管理ヒープ機能を容易に使用できるようになりました。

システム設計ガイド

7.2，7.7.3，7.11.4，7.12.1

機能解説 拡張編

7章

データベースセッションフェイルオーバ機能のURI単位での抑止

データベースセッションフェイルオーバ機能を使用する場合に，機能の対象外にするリクエストをURI単位で指定できるようになりました。

機能解説 拡張編

5.6.1

仮想化環境での障害監視

仮想化システムで，仮想サーバを監視し，障害の発生を検知できるようになりました。

仮想化システム構築・運用ガイド

−

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更された項目を次の表に示します。

表H‒43　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

管理ユーザアカウントの省略

運用管理ポータル，Management Serverのコマンド，またはSmart Composer機能のコマンドで，ユーザのログインIDおよびパスワードの入力を省略できるようになりました。

システム構築・運用ガイド

4.1.15

運用管理ポータル操作ガイド

2.2，7.1.1，7.1.2，7.1.3，8.1，8.2.1，付録E.2

リファレンス コマンド編

1.4，mngsvrctl（Management Serverの起動／停止／セットアップ），mngsvrutil（Management Serverの運用管理コマンド），8.3，cmx_admin_passwd（Management Serverの管理ユーザアカウントの設定）

仮想化環境の運用

仮想化システムで，複数の仮想サーバを対象にした一括起動・一括停止，スケールイン・スケールアウトなどを実行する手順を追加しました。

仮想化システム構築・運用ガイド

4章，6章

(5)　そのほかの目的

そのほかの目的で変更された項目を次の表に示します。

表H‒44　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

Tenured領域内不要オブジェクト統計機能

Tenured領域内で不要となったオブジェクトだけを特定できるようになりました。

機能解説 保守／移行編

9.8

Tenured増加要因の基点オブジェクトリスト出力機能

Tenured領域内不要オブジェクト統計機能を使って特定した，不要オブジェクトの基点となるオブジェクトの情報を出力できるようになりました。

9.9

クラス別統計情報解析機能

クラス別統計情報をCSV形式で出力できるようになりました。

9.10

論理サーバの自動再起動回数オーバー検知によるクラスタ系切り替え

Management Serverを系切り替えの監視対象としているクラスタ構成の場合，論理サーバが異常停止状態(自動再起動回数をオーバーした状態，または自動再起動回数の設定が0のときに障害を検知した状態)になったタイミングでの系切り替えができるようになりました。

機能解説 運用／監視／連携編

18.4.3，18.5.3，

16.2.2，

16.3.3，16.3.4

ホスト単位管理モデルを対象とした系切り替えシステム

クラスタソフトウェアと連携したシステム運用で，ホスト単位管理モデルを対象にした系切り替えができるようになりました。

16章

ACOS（AX2000，BS320）のサポート

使用できる負荷分散機の種類にACOS（AX2000，BS320）が追加になりました。

システム構築・運用ガイド

4.7.2，4.7.3，4.7.5，4.7.6，付録J，付録J.2

リファレンス 定義編(サーバ定義)

4.2.4，4.3.2，4.3.4，4.3.5，4.3.6，4.7.1

CMTでトランザクション管理をする場合にStateful Session Bean（SessionSynchronization）に指定できるトランザクション属性の追加

CMTでトランザクション管理をする場合に，Stateful Session Bean（SessionSynchronization）にトランザクション属性としてSupports，NotSupportedおよびNeverを指定できるようになりました。

機能解説 基本・開発編(EJBコンテナ)

2.7.3

OutOfMemoryError発生時の運用管理エージェントの強制終了

JavaVMでOutOfMemoryErrorが発生したときに，運用管理エージェントが強制終了するようになりました。

機能解説 保守／移行編

2.5.5

スレッドの非同期並行処理

TimerManagerおよびWorkManagerを使用して，非同期タイマ処理および非同期スレッド処理を実現できるようになりました。

機能解説 拡張編

−

付録H.14　08-00での主な機能変更

(1)　開発生産性の向上

開発生産性の向上を目的として変更された項目を次の表に示します。

表H‒45　開発生産性の向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

ほかのアプリケーションサーバ製品からの移行容易化

ほかのアプリケーションサーバ製品からの移行を円滑に実施するため，次の機能を使用できるようになりました。

HTTPセッションの上限が例外で判定できるようになりました。

JavaBeansのIDが重複している場合や，カスタムタグの属性名とTLDの定義で大文字・小文字が異なる場合に，トランスレーションエラーが発生することを抑止できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3，2.7.5

cosminexus.xmlの提供

アプリケーションサーバ独自の属性をcosminexus.xmlに記載することによって，J2EEアプリケーションをJ2EEサーバにインポート後，プロパティの設定をしないで開始できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.3

(2)　標準機能への対応

標準機能への対応を目的として変更された項目を次の表に示します。

表H‒46　標準機能への対応を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

Servlet 2.5への対応

Servlet 2.5に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.2，2.5.4，2.6，8章

JSP 2.1への対応

JSP 2.1に対応しました。

機能解説 基本・開発編(Webコンテナ)

2.3.1，2.3.3，2.5，2.6，8章

JSPデバッグ

MyEclipseを使用した開発環境でJSPデバッグができるようになりました。※

機能解説 基本・開発編(Webコンテナ)

2.4

タグライブラリのライブラリJARへの格納とTLDのマッピング

タグライブラリをライブラリJARに格納した場合に，Webアプリケーション開始時にWebコンテナによってライブラリJAR内のTLDファイルを検索し，自動的にマッピングできるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.3.4

application.xmlの省略

J2EEアプリケーションでapplication.xmlが省略できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.4

アノテーションとDDの併用

アノテーションとDDを併用できるようになり，アノテーションで指定した内容をDDで更新できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

17.5

アノテーションのJava EE 5標準準拠（デフォルトインターセプタ）

デフォルトインターセプタをライブラリJARに格納できるようになりました。また，デフォルトインターセプタからDIできるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

16.4

@Resourceの参照解決

@Resourceでリソースの参照解決ができるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

17.4

JPAへの対応

JPA仕様に対応しました。

機能解説 基本・開発編(コンテナ共通機能)

6章

注※　09-00以降では，WTPを使用した開発環境でJSPデバッグ機能を使用できます。

(3)　信頼性の維持・向上

信頼性の維持・向上を目的として変更された項目を次の表に示します。

表H‒47　信頼性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

セッション情報の永続化

HTTPセッションのセッション情報をデータベースに保存して引き継げるようになりました。

機能解説 拡張編

5章，6章

FullGCの抑止

FullGCの要因となるオブジェクトをJavaヒープ外に配置することで，フFullGC発生を抑止できるようになりました。

機能解説 拡張編

7章

クライアント性能モニタ

クライアント処理に掛かった時間を調査・分析できるようになりました。

−

−

（凡例）−：09-00で削除された機能です。

(4)　運用性の維持・向上

運用性の維持・向上を目的として変更された項目を次の表に示します。

表H‒48　運用性の維持・向上を目的とした変更

項目

変更の概要

参照先マニュアル

参照個所

運用管理ポータルでのアプリケーション操作性向上

アプリケーションおよびリソースの操作について，サーバ管理コマンドと運用管理ポータルの相互運用ができるようになりました。

運用管理ポータル操作ガイド

1.1.3

(5)　そのほかの目的

そのほかの目的で変更された項目を次の表に示します。

表H‒49　そのほかの目的による変更

項目

変更の概要

参照先マニュアル

参照個所

無効なHTTP Cookieの削除

無効なHTTP Cookieを削除できるようになりました。

機能解説 基本・開発編(Webコンテナ)

2.7.4

ネーミングサービスの障害検知

ネーミングサービスの障害が発生した場合に，EJBクライアントが，より早くエラーを検知できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

2.9

コネクション障害検知タイムアウト

コネクション障害検知タイムアウトのタイムアウト時間を指定できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

3.15.1

Oracle11gへの対応

データベースとしてOracle11gが使用できるようになりました。

機能解説 基本・開発編(コンテナ共通機能)

3章

バッチ処理のスケジューリング

バッチアプリケーションの実行をCTMによってスケジューリングできるようになりました。

機能解説 拡張編

4章

バッチ処理のログ

バッチ実行コマンドのログファイルのサイズ，面数，ログの排他処理失敗時のリトライ回数とリトライ間隔を指定できるようになりました。

リファレンス 定義編(サーバ定義)

3.2.5

snapshotログ

snapshotログの収集内容が変更されました。

機能解説 保守／移行編

付録A.1，付録A.2

メソッドキャンセルの保護区公開

メソッドキャンセルの対象外となる保護区リストの内容を公開しました。

機能解説 運用／監視／連携編

付録C

統計前のガーベージコレクション選択機能

クラス別統計情報を出力する前に，ガーベージコレクションを実行するかどうかを選択できるようになりました。

機能解説 保守／移行編

9.7

Survivor領域の年齢分布情報出力機能

Survivor領域のJavaオブジェクトの年齢分布情報をJavaVMログファイルに出力できるようになりました。

機能解説 保守／移行編

9.11

ファイナライズ滞留解消機能

JavaVMのファイナライズ処理の状態を監視して，処理の滞留を解消できるようになりました。

−

−

サーバ管理コマンドの最大ヒープサイズの変更

サーバ管理コマンドが使用する最大ヒープサイズが変更されました。

リファレンス 定義編(サーバ定義)

5.2.1，5.2.2

推奨しない表示名を指定された場合の対応

J2EEアプリケーションで推奨しない表示名を指定された場合にメッセージが出力されるようになりました。

メッセージ(構築／運用／開発用)

KDJE42374-W

（凡例）−：09-00で削除された機能です。

付録I　用語解説

マニュアルで使用する用語について

マニュアル「アプリケーションサーバ & BPM/ESB基盤 用語解説」を参照してください。

索引

記号

@AssociationOverride[1]

@AssociationOverrides[1]

@AttributeOverride[1]

@AttributeOverrides[1]

@Basic[1]

@Column[1]

@ColumnResult[1]

@DiscriminatorColumn[1]

@DiscriminatorValue[1]

@Embeddable[1]

@Embedded[1]

@EmbeddedId[1]

@Entity[1]

@EntityListeners[1]

@EntityResult[1]

@Enumerated[1]

@ExcludeDefaultListeners[1]

@ExcludeSuperclassListeners[1]

@FieldResult[1]

@GeneratedValue[1]

@Id[1]

@IdClass[1]

@IdClassを利用する方法[1]

@Inheritance[1]

@JoinColumn[1]

@JoinColumns[1]

@JoinTable[1]

@Lob[1]

@ManyToMany[1]

@ManyToOne[1]

@MapKey[1]

@MappedSuperclass[1]

@NamedNativeQueries[1]

@NamedNativeQuery[1]

@NamedQueries[1]

@NamedQuery[1]

@OneToMany[1]

@OneToOne[1]

@OneToOneおよび@ManyToOneでのLAZYフェッチ[1]

@OrderBy[1]

@PostLoad[1]

@PostPersist[1]

@PostRemove[1]

@PostUpdate[1]

@PrePersist[1]

@PreRemove[1]

@PreUpdate[1]

@PrimaryKeyJoinColumn[1]

@PrimaryKeyJoinColumns[1]

@QueryHint[1]

@SecondaryTable[1]

@SecondaryTables[1]

@SequenceGenerator[1]

@SqlResultSetMapping[1]

@SqlResultSetMappings[1]

@Table[1]

@TableGenerator[1]

@Temporal[1]

@Transient[1]

@Version[1]

数字

11-10での主な機能変更[1]

11-20での主な機能変更[1]

11-30での主な機能変更[1]

B

built-inフィルタ[1]、[2]

C

CDIのトレース取得ポイント[1]

cjjspc[1]

CJPAプロバイダ[1]

CJPAプロバイダが提供する機能[1]

CJPAプロバイダでの処理[1]

CJPAプロバイダ独自のプロパティ[1]

CJPAプロバイダとは[1]

CJPAプロバイダの稼働ログ[1]

CJPAプロバイダのトレース取得ポイント[1]

CJPAプロバイダを使用するための前提条件[1]

cjresumepool[1]

cjsuspendpool[1]

cjtracesync[1]

connect_timeout〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

connection_sharing〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

Connector属性ファイル[1]

Cookie利用時の注意[1]

cosminexus.jpa.cache.size.<ENTITY>[1]

cosminexus.jpa.cache.size.default[1]

cosminexus.jpa.cache.type.<ENTITY>[1]

cosminexus.jpa.cache.type.default[1]

cosminexus.jpa.exception.logging.sql〔J2EEサーバのカスタマイズ用キー〕[1]

cosminexus.jpa.logging.level.operation.<category>〔J2EEサーバのカスタマイズ用キー〕[1]

cosminexus.jpa.pessimistic-lock[1]

cosminexus.jpa.target-database[1]

D

DBConnector_CP_ClusterPool_Root.rarを使用する場合に指定できるプロパティ[1]

DBConnector_Oracle_CP_ClusterPool_Member.rarを使用する場合に指定できるプロパティ[1]

DB Connectorのコネクション数の見積もり[1]

DB Connectorのコネクション操作のトレース取得ポイントと取得できるトレース情報[1]

detached[1]

detached状態のエンティティへのアクセス[1]

E

ejbserver.deploy.applications.metadata_complete〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.jpa.defaultJtaDsName〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.jpa.defaultNonJtaDsName〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.jpa.defaultProviderClassName〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.jpa.disable〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.jpa.emfprop.<property key>〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.jpa.overrideJtaDsName〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.jpa.overrideNonJtaDsName〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.jpa.overrideProvider〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.logger.channels.define.<チャネル名>.filenum〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.logger.channels.define.<チャネル名>.filesize〔J2EEサーバのカスタマイズ用キー〕[1]

ejbserver.server.eheap.ajp13.enabled〔J2EEサーバのカスタマイズ用キー〕[1]

Enterprise Beanの呼び出し方法の最適化[1]

EntityManagerFactoryの取得／解放処理のトレース取得ポイントと取得できるトレース情報[1]

EntityManagerおよびEntityManagerFactoryの設定方法[1]

EntityManagerでのエンティティのライフサイクル管理[1]

EntityManager内のクエリ関連インタフェースのAPIで発生する例外[1]

EntityManagerによるエンティティの操作[1]

EntityManagerのAPIに関する注意事項[1]

EntityManagerの解放処理のトレース取得ポイントと取得できるトレース情報[1]

EntityManagerの取得処理のトレース取得ポイントと取得できるトレース情報[1]

EntityManagerの操作のトレース取得ポイントと取得できるトレース情報[1]

EntityTransactionの操作のトレース取得ポイントと取得できるトレース情報[1]

Explicitヒープのチューニング[1]

F

FetchType.EAGER[1]

FetchType.LAZY[1]

filter_priority〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

flush操作またはトランザクションの決着時のバージョンチェック[1]

FROM節[1]

Full[1]

G

gateway_host〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

gateway_https_scheme〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

gateway_port〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

GROUP BY節[1]

H

HardWeak[1]

HAVING節[1]

HiRDBでJPQLを使用する場合の注意事項[1]

httpsd.conf[1]

HTTP Serverのアップグレード時の注意事項[1]

HTTP Serverの再起動時の注意事項[1]

HTTP Serverの設定に関する注意事項[1]

HTTP Server用リダイレクタ動作定義ファイル[1]

HTTP Server用リダイレクタ動作定義を設定するパラメタ[1]

HTTPセッションを作成するリクエスト処理のトレース取得ポイントと取得できるトレース情報（データベースセッションフェイルオーバ機能のトレース）[1]

HTTPレスポンス圧縮機能[1]

HTTPレスポンス圧縮機能を有効にする場合の条件[1]

HTTPレスポンス圧縮フィルタ[1]

HTTPレスポンス圧縮フィルタに対する制約[1]

HTTPレスポンス圧縮フィルタの概要[1]

HTTPレスポンス圧縮フィルタを使用するアプリケーションの実装[1]

HTTPレスポンス圧縮フィルタを使用するための条件[1]

HTTPレスポンスヘッダのカスタマイズ[1]

HTTPレスポンスを使用したWebクライアントへのレスポンスのカスタマイズ[1]

I

IPアドレス指定（Webサーバ連携）[1]

IPアドレス指定（インプロセスHTTPサーバ）[1]

isapi_redirect.conf[1]、[2]

J

J2EEサーバで使用するファイル[1]

J2EEサーバ用ユーザプロパティファイル[1]

J2EEサーバ用ユーザプロパティを設定するパラメタ[1]

javax.annotationパッケージに含まれるアノテーションのサポート範囲[1]

javax.ejbパッケージに含まれるアノテーションのサポート範囲[1]

javax.persistenceパッケージに含まれるアノテーションのサポート範囲[1]

javax.servlet.error.XXXXXによるエラー情報参照時の注意[1]

javax.servlet.http.HttpServletRequestインタフェースのgetRequestURIメソッドおよびgetRequestURLメソッドの戻り値について[1]

JkConnectTimeout〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkGatewayHost〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkGatewayHttpsScheme〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkGatewayPort〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkLogFileDir〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkLogFileNum〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkLogFilePrefix〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]

JkLogFileSize〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkLogLevel〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkModulePriority〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkMount〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]

JkOptions〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]

JkPrfId〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkRequestRetryCount〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkSendTimeout〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]

JkSendTimeout〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]

JkTraceLogFileDir〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkTraceLogFileNum〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkTraceLogFilePrefix〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]

JkTraceLogFileSize〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkTraceLog〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkTranslateBackcompat〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]、[2]

JkWorkersFile〔HTTP Server用リダイレクタ動作定義ファイルのキー〕[1]

JOINED戦略[1]

Joins式[1]

JPAアプリケーションでトラブルが発生した場合[1]

JPAで使用するファイル[1]

JPAでのトレース取得ポイント[1]

JPAプロバイダとEJBコンテナ間の規約[1]

JPQL使用時の注意事項[1]

JPQLでのデータベースの参照および更新方法[1]

JPQLでの悲観的ロック[1]

JPQLとキャッシュの関係[1]

JPQLのBNF[1]

JPQLの記述方法[1]

JPQLの構文[1]

JSPの事前コンパイル[1]

L

log_file_dir〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

log_file_num〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

log_file_prefix〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

log_file_size〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

log_level〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

M

managed[1]

managed状態のエンティティ[1]

Microsoft IISの設定[1]

Microsoft IIS用マッピング定義ファイル[1]

Microsoft IIS用リダイレクタ動作定義ファイル[1]

mod_jk.conf[1]、[2]

N

new[1]

NONE[1]

O

O/Rマッピングファイルでのコールバックリスナの指定[1]

Oracle RACを使用したOracleへの接続[1]

ORDER BY節[1]

P

Path式の注意事項[1]

persistence.xmlの定義[1]

Persistent Connection[1]

Persistent ConnectionによるWebクライアントとの通信制御[1]

Persistent Connectionによる通信制御[1]

POSTデータサイズでのリクエストの振り分け[1]

POSTデータサイズでのリクエストの振り分けの概要[1]

POSTデータサイズによるリクエストの振り分けの例[1]

POSTリクエスト転送先ワーカ[1]

POSTリクエスト振り分けワーカ[1]

prf_id[1]

PRFトレース取得レベル[1]、[2]

PRFトレース取得レベル〔Webコンテナ〕[1]、[2]

PRFトレース取得レベル〔インプロセスHTTPサーバ〕[1]

PRFトレース取得レベル〔フィルタのトレース（正常に処理が終了した場合）〕[1]

PRFトレース取得レベル〔フィルタのトレース（例外が発生した場合）〕[1]

PrintWriter，JSPWriterクラス利用時の性能向上について[1]

Q

QueryインタフェースのAPIで発生する例外[1]

Queryオブジェクトの取得方法[1]、[2]

Queryの操作のトレース取得ポイントと取得できるトレース情報[1]

R

receive_client_timeout〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

removed[1]

request_retry_count〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

S

SELECT節[1]

SELECT節の実行結果[1]

SELECT文[1]

send_timeout〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

setFirstResultメソッド[1]

setMaxResultsメソッド[1]

SINGLE TABLE戦略[1]

SOAPアプリケーション運用時の注意事項[1]

SoftWeak[1]

T

Timer and Work Manager for Application Serversとの対応[1]

TimerManager[1]

TimerManagerのステータス遷移[1]

TimerManagerの多重スケジュール数[1]

TimerManagerのライフサイクル[1]

TimerManagerを使用したスレッドのスケジューリング方式[1]

TimerManagerを使用した非同期タイマ処理[1]

trace_log_file_dir〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

trace_log_file_num〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

trace_log_file_prefix〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

trace_log_file_size〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

trace_log〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

U

uriworkermap.properties[1]、[2]

URIのデコード機能[1]

URLConnectionクラス使用時の注意[1]

URLパターンでのリクエストの振り分け[1]

URLパターンでのリクエストの振り分けの概要[1]

URLパターンによるリクエストの振り分け[1]

URLパターンの種類と適用されるパターンの優先順位[1]

usrconf.properties[1]、[2]

V

V9互換モード[1]

V9互換モードで事前コンパイルをする場合の注意事項[1]

W

Weak[1]

webserver.connector.ajp13.backlog〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.ajp13.bind_host〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.ajp13.max_threads[1]

webserver.connector.ajp13.max_threads〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.ajp13.port〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.ajp13.receive_timeout〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.ajp13.send_timeout〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.backlog〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.bind_host〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.enabled_methods〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.enabled〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.file.content_type〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.file〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.redirect_url〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.request_url〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.error_custom.<エラーページカスタマイズ定義名>.status〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.error_custom.list〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.gateway.host〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.gateway.https_scheme〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.gateway.port〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.hostname_lookups〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.init_threads〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.keep_start_threads〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.limit.max_headers〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.limit.max_request_body〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.limit.max_request_header〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.limit.max_request_line〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.max_connections〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.max_execute_threads[1]

webserver.connector.inprocess_http.max_execute_threads〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.max_spare_threads〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.min_spare_threads〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.permitted.hosts〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.persistent_connection.max_connections〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.persistent_connection.max_requests〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.persistent_connection.timeout〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.port〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.receive_timeout〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.file.content_type〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.file〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.redirect_url〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.request_url〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.redirect.<リダイレクト定義名>.status〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.redirect.list〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.rejection_threads〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.response.header.server〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.inprocess_http.send_timeout〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.connector.limit.max_fileupload_count〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.container.ac.logEnabled〔J2EEサーバのカスタマイズ用キー〕[1]

webserver.logger.access_log.<フォーマット名>[1]、[2]

webserver.logger.access_log.format_list[1]、[2]

webserver.logger.access_log.inprocess_http.enabled[1]、[2]

webserver.logger.access_log.inprocess_http.filename[1]、[2]

webserver.logger.access_log.inprocess_http.filenum[1]、[2]

webserver.logger.access_log.inprocess_http.filesize[1]、[2]

webserver.logger.access_log.inprocess_http.usage_format[1]、[2]

webserver.logger.communication_trace.inprocess_http.filenum[1]、[2]

webserver.logger.thread_trace.inprocess_http.filenum[1]、[2]

Webアプリケーションで使用するコマンド[1]

Webアプリケーションで使用するコマンドの詳細[1]

Webクライアントからの接続数の制御[1]

Webクライアントからの接続数の制御の概要[1]

Webクライアントからの同時接続数の制御[1]

Webクライアントからの同時接続数の制御によるリクエストの流量制御[1]

Webコンテナ[1]

Webコンテナが返すエラーステータスコード[1]

Webコンテナ単位での同時実行スレッド数の制御[1]

Webコンテナでのリクエスト受信時[1]

Webコンテナでのレスポンス送信時[1]

Webコンテナのトレース取得ポイント（セッショントレース）[1]

Webコンテナのトレース取得ポイント（データベースセッションフェイルオーバ機能のトレース）[1]

Webコンテナのトレース取得ポイント（フィルタのトレース）[1]

Webコンテナのトレース取得ポイント（リクエスト処理のトレース）[1]

Webコンテナへのゲートウェイ情報の通知[1]、[2]

Webサーバ（リダイレクタ）によるリクエストの振り分け[1]

Webサーバでのリクエスト受信時[1]

Webサーバでのレスポンス送信時[1]

Webサーバのレスポンスタイムの解析[1]

Webサーバ連携時の注意事項[1]

Webサーバ連携で使用するファイル[1]

Webサーバ連携で使用するファイルの一覧[1]

WHERE節[1]

WHERE節で使用できる条件式[1]

worker_file〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

worker_mount_file〔Microsoft IIS用リダイレクタ動作定義ファイルのキー〕[1]

worker.<ワーカ名>.<パラメタ>〔ワーカ定義ファイルのキー〕[1]、[2]

worker.<ワーカ名>.balanced_workers〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.cachesize〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.default_worker〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.delegate_error_code〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.host〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.lbfactor〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.port〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.post_data〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.post_size_workers〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.receive_timeout〔ワーカごとの定義パラメタ〕[1]、[2]

worker.<ワーカ名>.typeごとの定義パラメタ[1]

worker.<ワーカ名>.type〔ワーカごとの定義パラメタ〕[1]、[2]

worker.list〔ワーカ定義ファイルのキー〕[1]、[2]

workers.properties[1]、[2]

WorkManager[1]

WorkManagerのライフサイクル[1]

WorkManagerを使用したアプリケーションの開発[1]

WorkManagerを使用した非同期スレッド処理[1]

あ

アクセサメソッドの作成[1]

アクセサメソッドのメソッドシグネチャ規則[1]

アクセサメソッドへのビジネスロジックの追加[1]

アクセスを許可するホストの制限[1]

アクセスを許可するホストの制限によるアクセス制御[1]

アノテーション参照抑止機能の設定変更[1]

アノテーションでのコールバックメソッドの指定[1]

アプリケーション管理の永続化コンテキストを利用した場合のトレース取得ポイントと取得できるトレース情報[1]

アプリケーションサーバ 11-40での主な機能変更[1]

アプリケーションサーバが使用するTCP/UDPのポート番号[1]

アプリケーションサーバが提供するサーブレットフィルタ[1]

アプリケーションサーバの機能[1]

アプリケーションサーバの性能解析トレースの概要[1]

アプリケーションの実行基盤としての機能[1]

アプリケーションの実行基盤を運用・保守するための機能[1]

アプリケーションの種類ごとにチューニングできる項目[1]

い

インプロセスHTTPサーバ[1]、[2]、[3]

インプロセスHTTPサーバが返すエラーステータスコード[1]

インプロセスHTTPサーバが出力するログ・トレース[1]

インプロセスHTTPサーバで使用できる機能[1]

インプロセスHTTPサーバのアクセスログのカスタマイズ[1]

インプロセスHTTPサーバの概要[1]

インプロセスHTTPサーバの使用[1]

インプロセスHTTPサーバのログ取得の設定[1]、[2]

インプロセスHTTPサーバ用トレースファイルの同期[1]

う

埋め込み型クラス[1]

埋め込み型クラスを利用する方法[1]

え

永続化コンテキストからのエンティティの切り離しとmerge操作[1]

永続化フィールド[1]

永続化フィールドおよび永続化プロパティのデフォルトマッピング規則[1]

永続化フィールドおよびリレーションシップのバージョンチェック[1]

永続化プロパティ[1]

エラーページのカスタマイズ（Webサーバ連携）[1]

エラーページのカスタマイズ（インプロセスHTTPサーバ）[1]

エラーページのカスタマイズの概要[1]

エラーページのカスタマイズの仕組み[1]

エラーページのカスタマイズの注意事項[1]

演算子の優先順位[1]

エンティティオブジェクトのキャッシュ機能[1]

エンティティクラスとデータベースの対応の定義[1]

エンティティクラスの継承方法[1]

エンティティクラスの作成[1]

エンティティクラスの作成要件[1]

エンティティクラスのバイナリ変換のトレース取得ポイントと取得できるトレース情報[1]

エンティティクラスのフィールドに対するアクセス方法の指定[1]

エンティティ継承階層構造の非エンティティのクラス[1]

エンティティでのプライマリキーの指定[1]

エンティティに対するpersist操作[1]

エンティティに対するremove操作[1]

エンティティに対する操作[1]

エンティティに対する操作と状態遷移[1]

エンティティに対する操作の伝播[1]

エンティティのmerge処理[1]

エンティティの永続化フィールドおよび永続プロパティの型[1]

エンティティの状態の種類[1]

エンティティのリレーションシップ[1]

エンティティを使用したデータベースの更新[1]

か

カスタマイズできるエラーページ[1]

関数式[1]

き

機能とマニュアルの対応[1]

機能の分類[1]

機能レイヤ[1]

キャッシュ機能の処理[1]

キャッシュ機能の処理の流れ[1]

キャッシュ機能の有効範囲[1]

キャッシュ機能を使用するときの注意事項[1]

キャッシュの更新処理の流れ[1]

キャッシュの参照形態とキャッシュタイプ[1]

キャッシュの登録および更新のタイミング[1]

キャッシュを使用する永続化コンテキストが複数ある場合の注意[1]

強参照[1]

く

クエリ結果件数の範囲指定[1]

クエリ結果の取得および実行[1]

クエリ言語によるデータベース操作[1]

クエリ言語を利用したデータベースの参照および更新方法[1]

クエリ使用時に発生する例外[1]

クエリでデータを更新または削除した場合の注意[1]

クエリの実行時の注意事項[1]

クエリのドメイン[1]

クエリヒントの指定[1]

クラスタコネクションプール機能[1]

クラスタコネクションプールの概要[1]

クラスタコネクションプールの設定[1]

クラスタコネクションプールの動作[1]

クラスローダの取得に関する注意[1]

け

継承階層内での呼び出し順序[1]

継承クラスの種類[1]

継承マッピング戦略[1]

ゲートウェイ指定機能[1]、[2]、[3]、[4]、[5]

ゲートウェイ指定機能を使用する場合の注意[1]

結果セットマッピング[1]

こ

コールバックメソッド使用時の注意事項[1]

コールバックメソッドに適用されるルール[1]

コールバックメソッドの実装[1]

コールバックメソッドの指定個所[1]

コールバックメソッドの指定方法[1]

コールバックメソッドの除外について[1]

コールバックメソッドの呼び出し順序[1]

コネクションプールの一時停止[1]、[2]

コネクションプールの再開[1]、[2]

コネクションプールの状態によるコマンド実行の可否[1]

コネクションプールの状態の確認[1]、[2]

コネクションプールをクラスタ化するために必要な設定[1]

このマニュアルに記載している機能の説明[1]

コミット後のエラーページの表示に関する注意[1]

コレクションメンバの宣言[1]

コンストラクタ式[1]

コンテキスト[1]

コンテキストルート[1]

コンテナ管理の永続化コンテキストを利用した場合のトレース取得ポイントと取得できるトレース情報[1]

さ

サーブレットおよびJSP実装時共通の注意事項[1]

サーブレットおよびJSPの実装時の注意事項[1]

し

弱参照[1]

集合関数[1]

出力されるログ情報とログ取得の設定[1]

手動によるコネクションプールの停止・開始の流れ[1]

取得できるトレース情報〔Webコンテナ〕[1]、[2]

取得できるトレース情報〔インプロセスHTTPサーバ〕[1]

取得できるトレース情報〔データベースセッションフェイルオーバ機能〕[1]、[2]、[3]、[4]

取得できるトレース情報〔フィルタのトレース（正常に処理が終了した場合）〕[1]

取得できるトレース情報〔フィルタのトレース（例外が発生した場合）〕[1]

詳細レベル[1]

使用するサーバと指定するパラメタの参照先の対応[1]

使用するリソースアダプタ[1]

す

推奨モード[1]

スレッドの非同期並行処理で使用できるJava EEの機能[1]

スレッドの非同期並行処理の概要[1]

スレッドの非同期並行処理の流れ[1]

せ

性能解析トレースファイルの出力情報（性能解析トレースの場合）[1]

性能解析トレースファイルをフィルタリングした例[1]

接続できるデータベース[1]

そ

双方向のManyToManyリレーションシップ[1]

双方向のManyToOne/OneToManyリレーションシップ[1]

双方向のOneToOneリレーションシップ[1]

ソフト参照[1]

た

タイムアウトが発生したリクエストの特定[1]

タイムアウトしたリクエストを確認するために使用できる性能解析トレース[1]

短寿命Work[1]

単方向のManyToManyリレーションシップ[1]

単方向のManyToOneリレーションシップ[1]

単方向のMulti-Valuedリレーションシップ[1]

単方向のOneToManyリレーションシップ[1]

単方向のOneToOneリレーションシップ[1]

単方向のSingle-Valuedリレーションシップ[1]

ち

抽象エンティティクラス[1]

抽象スキーマ型[1]

抽象スキーマ名[1]

チューニングの方法[1]

長寿命Work[1]

つ

通信タイムアウト（インプロセスHTTPサーバ）[1]

通信タイムアウトの概要[1]

通信タイムアウトの設定[1]

て

データ更新の有無のチェック方法[1]

データソースの指定の注意[1]

データベースアクセス方法の最適化[1]

データベースからのエンティティ情報の読み込み[1]

データベースからのエンティティ情報を読み込むタイミング[1]

データベースからのエンティティの取得[1]

データベースと接続するための設定（クラスタコネクションプールの場合）[1]、[2]

データベースとの同期[1]

データベースへのエンティティ情報の書き込み[1]

デーモンWork[1]

デーモンWorkと非デーモンWork[1]

デーモンWorkのライフサイクル[1]

デフォルトマッピング（双方向のリレーションシップ）[1]

デフォルトマッピング（単方向のリレーションシップ）[1]

デフォルトワーカ[1]

デプロイメントに関する規約[1]

と

同時実行数の最適化[1]

同時実行スレッド数の制御によるリクエストの流量制御[1]

特別な意味を持つ入力値の表示に関する注意[1]

ドメイン名指定でのトップページの表示[1]

ドメイン名指定でのトップページの表示について[1]

トランザクションとJDBCコネクション利用時の注意[1]

トランザクションマネージャとのトランザクション連携処理のトレース取得ポイントと取得できるトレース情報[1]

トレース取得ポイント[1]、[2]

トレース取得ポイントとPRFトレース取得レベル〔データベースセッションフェイルオーバ機能〕[1]、[2]、[3]、[4]

トレース取得ポイント〔Webコンテナ〕[1]、[2]

トレース取得ポイント〔インプロセスHTTPサーバ〕[1]

トレース取得ポイント〔フィルタのトレース（正常に処理が終了した場合）〕[1]

トレース取得ポイント〔フィルタのトレース（例外が発生した場合）〕[1]

ね

ネイティブクエリ結果の取得および実行[1]

ネイティブクエリでのデータベースの参照および更新方法[1]

ネイティブライブラリのロードに関する注意[1]

は

バインド先アドレス設定機能[1]、[2]、[3]、[4]

パス式[1]

パッケージ名の指定に関する注意[1]

パフォーマンスチューニング[1]

バルクDELETE文[1]

バルクUPDATE文[1]

範囲変数宣言と識別変数[1]

ひ

非デーモンWork[1]

非デーモンWorkで使用するスレッドプールとキューについて[1]

非デーモンWorkのライフサイクル[1]

非同期スレッド処理[1]

非同期タイマ処理[1]

標準レベル[1]

ふ

ファイルアクセス時の注意[1]

フィルタリングに使用するイベントIDが示すトレース取得ポイント[1]

フィルタ連鎖の推奨例[1]

複合型のプライマリキー[1]

プライマリキー値の自動採番[1]

プライマリキーの型[1]

フラッシュモードの指定[1]

ほ

保守レベル[1]

ま

マッピング定義[1]

マップドスーパークラス[1]

め

メンバコネクションプール[1]

メンバコネクションプールの一時停止[1]

メンバコネクションプールの再開始[1]

メンバコネクションプールの状態[1]

メンバコネクションプールの状態遷移（自動で一時停止が実行される場合）[1]

メンバコネクションプールの状態遷移（手動で一時停止を実行する場合）[1]

メンバコネクションプールの情報の参照[1]

メンバリソースアダプタ用DB Connectorの一般情報[1]

メンバリソースアダプタ用DB Connectorの設定[1]

メンバリソースアダプタ用コンフィグレーションプロパティ[1]

メンバリソースアダプタ用のDB Connectorのインポート[1]

メンバリソースアダプタ用のDB Connectorの開始[1]

メンバリソースアダプタ用のDB Connectorの接続テスト[1]

メンバリソースアダプタ用のDB Connectorの停止[1]

メンバリソースアダプタ用のDB Connectorのデプロイ[1]

メンバリソースアダプタ用のDB Connectorのプロパティ定義[1]

も

モジュール定義[1]

ゆ

有効なHTTPメソッドの制限によるアクセス制御[1]

ユーザスレッドの使用方法[1]

ユーザへのコールバックメソッドのトレース取得ポイントと取得できるトレース情報[1]

よ

抑止レベル[1]

ら

ラウンドロビン方式によるリクエストの振り分け[1]

ラウンドロビン方式によるリクエストの振り分けの概要[1]

ラウンドロビン方式によるリクエストの振り分けの例[1]

楽観的ロック[1]

楽観的ロックに失敗した場合の例外処理[1]

楽観的ロックの処理[1]

楽観的ロックを使用する際の注意事項[1]

ランタイムに関する規約[1]

り

リクエストURIの正規化[1]

リクエストおよびレスポンスのフィルタリング機能[1]

リクエスト受信時の通信タイムアウト[1]

リクエスト処理スレッド数の制御[1]

リクエスト処理スレッド数の制御の概要[1]

リクエスト送受信時の通信タイムアウト[1]

リクエスト送信処理のリトライ[1]

リクエストデータのサイズの制限[1]

リクエストデータのサイズの制限によるアクセス制御[1]

リクエストの転送パターン[1]

リクエストの振り分け条件[1]

リクエストの振り分け方法[1]

リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用しない場合）[1]

リクエストの振り分け方法を設定するユーザ定義ファイル（Smart Composer機能を使用する場合）[1]

リソースアダプタの設定の流れ（クラスタコネクションプールを使用する場合）[1]

リダイレクタ[1]

リダイレクタが返すエラーステータスコード[1]

リダイレクタ定義[1]

リダイレクタでのリクエスト送信時[1]

リダイレクタでのリクエストのHTTPメソッドのサポート可否[1]

リダイレクタでのレスポンス受信時[1]

リダイレクタとの通信用オブジェクト[1]

リダイレクタのトレース取得ポイント[1]

リダイレクタのログに関する注意事項[1]

リダイレクタを使用したリクエスト振り分けの仕組み[1]

リダイレクトによるリクエストの振り分け[1]

リテラルの注意事項[1]

リレーションシップのアノテーション[1]

リレーションシップの種類[1]

リレーションシップの方向[1]

る

ルートアプリケーション情報を利用したログ調査[1]

ルートリソースアダプタ用DB Connectorの設定[1]

ルートリソースアダプタ用のDB Connectorのインポート[1]

ルートリソースアダプタ用のDB Connectorの開始[1]

ルートリソースアダプタ用のDB Connectorの接続テスト[1]

ルートリソースアダプタ用のDB Connectorの停止[1]

ルートリソースアダプタ用のDB Connectorのデプロイ[1]

ルートリソースアダプタ用のDB Connectorのプロパティ定義[1]

れ

例外発生時のエラーページの設定について[1]

レスポンス送受信時の通信タイムアウト[1]

レスポンス送信時の通信タイムアウト[1]

レスポンスのカスタマイズ[1]

ろ

ロード対象のクラスとロード時に必要なクラスパス[1]

ロードバランサ[1]

ログ・トレースの出力[1]

論理J2EEサーバで指定できるパラメタ[1]

論理Webサーバで指定できるパラメタ[1]

わ

ワーカごとの定義パラメタ[1]、[2]

ワーカ定義ファイル[1]、[2]

ワーカ定義ファイルに指定できるキー[1]、[2]

ワーカ定義を設定するパラメタ[1]

ワーカプロセス[1]