Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング

12c リリース1(12.1.1)

B65951-02(原本部品番号:E24973-02)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- EJB開発者向けのサンプルとチュートリアル

- Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

- WebLogic Server配布キットのEJBサンプル

- このリリースでの新機能と変更点

2 Enterprise JavaBeansについて

- アプリケーションによるEJBの使い方

- セッションEJBによるビジネス・ロジックの実装

- ステートレス・セッションBean

- ステートフル・セッションBean

- エンティティEJBによる永続データの保持

- メッセージドリブンBeanによる疎結合ビジネス・ロジックの実装

- EJBの構造と環境

- EJBの構成要素

- EJBコンテナ

- EJBデプロイメント記述子

- 主要なデプロイメント要素のマッピング

- Beanとリソースのリファレンス

- セキュリティ・ロール

- EJB、クライアント、およびアプリケーション・オブジェクト

- EJBの通信

- EJBとメッセージ宛先の参照

- WebLogic ServerのEJBの付加価値機能

- WebLogic Server EJBのパフォーマンス拡張機能

- プールはEJBの応答時間を短縮する

- キャッシングはEJBのパフォーマンスを向上させる

- CMPエンティティ用の追加的なキャッシング機能

- 効率的な問合せのためのフィールド・グループ(CMPエンティティ)

- 構成可能な書込み動作

- 処理の順序付けとバッチ処理(CMPエンティティ)

- データベースの更新の最適化(CMPエンティティ)

- 読取り専用パターンと読取り専用の無効化(CMPエンティティ)

- CMP Beanは開発者の生産性を向上させる

- 自動主キー生成(CMPエンティティ)

- 自動表作成(CMPエンティティ)

- 動的問合せ(CMPエンティティ)

- 信頼性と可用性の機能

- クラスタ化されたEJBのロード・バランシングはスケーラビリティを向上させる

- クラスタ化されたEJBのフェイルオーバーは信頼性を向上させる

- EJBのセキュリティ

3 Enterprise JavaBeansの設計

- 適切なBeanタイプの選択

- セッションBeanの機能

- ステートフル・セッションBean

- ステートレス・セッションBean

- ステートレスBeanはパフォーマンスとスケーラビリティを向上させる

- ステートレス・セッションBeanをWebサービスとしてエクスポーズする

- エンティティBeanの機能

- エンティティBeanの主な特長

- 読み書き対応エンティティBeanと読取り専用エンティティBean

- エンティティBeanのパフォーマンスとデータ一貫性の特徴

- メッセージドリブンBean

- 永続性管理の選択肢

- 生産性と移植性が必要な場合はコンテナ管理による永続性(CMP)を使用する

- Bean管理による永続性(BMP)は必要なときだけ使用する

- トランザクションの設計と管理のオプション

- トランザクションの境界設定方式とパフォーマンスについて

- サーバー・レベルでのトランザクションの境界設定が最も効率的

- コンテナ管理によるトランザクションは開発が簡単でパフォーマンスに優れている

- ロールバック

- トランザクション境界

- 複数のBeanでのトランザクションの分散

- コストのかかるオプション: 複数のデータベースでのトランザクションの分散

- Beanレベルのトランザクション管理

- Bean管理によるトランザクションを使用する場合

- Bean管理によるトランザクションを短くする

- クライアント・レベルのトランザクション管理はコストがかかる

- トランザクションのアイソレーション: パフォーマンスとデータ一貫性の選択

- WebLogic Server EJBでアプリケーションの要件を満たす

4 Enterprise JavaBeansの実装

- EJB開発プロセスの概要

- ソース・ディレクトリを作成する

- EJBのクラスとインタフェースを作成する

- WebLogic Serverの汎用的なBeanテンプレートの使い方

- クライアントによるEJBへのアクセスのプログラミング

- クライアントによる初期コンテキストの取得のプログラミング

- クライアントによるホーム・インタフェースのルックアップのプログラミング

- EJBリンクの使用

- URLに要求を送信するようにEJBを構成する

- URLによるHTTPリソースの指定

- JNDI名によるHTTPリソースの指定

- BeanコードからのHTTPリソースへのアクセス

- EJBのネットワーク通信の構成

- トランザクションのプログラミングと構成

- コンテナ管理によるトランザクションのプログラミング

- コンテナ管理トランザクションの自動的な再試行の構成

- Bean管理のトランザクションのプログラミング

- 複数のEJBで分散されるトランザクションのプログラミング

- クライアントのトランザクション・コンテキストから複数のEJBを呼び出す

- EJB「ラッパー」を使用してEJB間トランザクションをカプセル化する

- EJBタイマー・サービスのプログラミング

- クラスタ化されたEJBタイマー・サービスとローカルEJBタイマー・サービス

- クラスタ化されたEJBタイマー・サービス

- ローカルEJBタイマー・サービス

- Javaプログラミング・インタフェースを使用してタイマー・オブジェクトをプログラミングする

- EJB 2.1タイマー関連プログラミング・インタフェース

- WebLogic Server固有のタイマー関連インタフェース

- タイマー・デプロイメント記述子

- クラスタ化されたEJBタイマーの構成

- Webサービスの参照の宣言

- Javaソースをコンパイルする

- デプロイメント記述子を生成する

- デプロイメント記述子を編集する

- セキュリティ要素

- リソース・マッピング要素

- 永続性要素

- クラスタ化要素

- データの一貫性要素

- コンテナ管理によるトランザクション要素

- パフォーマンス要素

- ネットワーク通信要素

- EJBラッパー・クラスとスタブおよびスケルトン・ファイルを生成する

- appcと生成されたクラス名の衝突

- パッケージ化する

- クライアントが他のアプリケーションにあるEJBのパッケージ化の考慮事項

- デプロイする

- 開発時に問題を解決する

- 行番号をクラス・ファイルに追加する

- データをモニターする

- デバッグ・メッセージを作成する

- EJBを開発するためのWebLogic Serverツール

- Oracle JDeveloper

- Oracle Enterprise Pack for Eclipse

- 管理コンソール

- javac

- EJBGen

- DDInit

- WebLogic Server Antユーティリティ

- weblogic.Deployer

- appc

- DDConverter

- EJBツールの機能の比較

5 セッションEJB

- ステートレス・セッションBeanとステートフル・セッションBeanの比較

- ステートレス・セッションEJBのプール

- ステートフル・セッションEJBのキャッシュとパッシブ化

- ステートフル・セッションEJBの作成

- ステートフル・セッションEJBのパッシブ化

- パッシブ化の制御

- 積極的なパッシブ化(LRU)

- 遅延パッシブ化(NRU)

- パッシブ化されたBeanの永続ストア・ディレクトリの指定

- ステートフル・セッションBeanへの同時アクセスの構成

- セッションBeanの設計上の決定

- ステートレスBeanとステートフルBeanの選択

- ステートレス・セッションBeanの最適なフリー・プール設定の選択

- セッションBeanの実装

- WebLogicに固有のセッションBeanの構成可能な動作

6 エンティティEJB

- エンティティBeanのプールとキャッシュの管理

- エンティティのプールについて

- エンティティのキャッシングについて

- エンティティBeanのパッシブ化について

- ejbLoad()とejbStore()の動作について

- ejbLoad()およびejbStore()の動作の制御

- キャッシュのフラッシュの無効化

- アプリケーション・レベルのキャッシングの構成

- 主キーの使用

- 主キーと主キー・クラスの指定

- 主キーのガイドライン

- 主キーの自動生成

- Oracleデータベース用自動キー生成の指定

- Microsoft SQL Server用自動キー生成の指定

- 命名済シーケンス表を使用した主キーの生成

- 主キー・フィールドの型の宣言

- OracleデータベースのSEQUENCEのサポート

- 文字列値CMPフィールドの削除

- 文字列の削除の利点

- 文字列の削除を無効にする

- データベース操作に向けたエンティティEJBの構成

- 表マッピングの構成

- 自動表作成(開発のみ)

- データベース挿入の遅延

- データベースの挿入を遅延させる理由

- データベースの挿入遅延の構成

- cache-between-transactionsによるデータベース読込みの制限

- トランザクション終了前のデータベースの更新

- 動的問合せ

- 動的問合せの有効化

- 動的問合せの実行

- OracleまたはDB2データベースのBLOBおよびCLOB列のサポートの有効化

- デプロイメント記述子によるBLOB列の指定

- Oracle Blobにマップされたbyte[]型のcmp-fieldsのシリアライゼーション

- デプロイメント記述子によるCLOB列の指定

- Oracle 10gにおけるCLOB列の挿入の最適化

- フィールド・グループの指定

- 処理の順序付けとバッチ処理

- 処理の順序付け

- バッチ処理に関するガイドラインおよび制限

- 問合せキャッシングの使用(読取り専用エンティティBean)

- エンティティBeanでのSQLの使用

- コンテナ管理による関係(CMR)の使用

- CMRの要件と制限

- CMRのカーディナリティ

- CMRの方向

- CMRの削除

- コンテナ管理による関係(CMR)の定義

- ejb-jar.xmlでの関係の指定

- 関係のカーディナリティの指定

- 関係の方向の指定

- weblogic-cmp-jar.xmlでの関係の指定

- 1対1の関係と1対多の関係

- 多対多の関係

- 複数の表にマップされるEJBのCMRの指定

- CMRフィールドとCMRフィールド・アクセサ・メソッドについて

- CMRのエンティティのカスケード削除の使用

- リレーションシップ・キャッシング

- リレーションシップ・キャッシングの有効化

- 同時実行性ストラテジの選択

- 排他的同時実行性

- データベース同時実行性

- オプティミスティック同時実行性

- オプティミスティックなBeanデータが古くなるのを防ぐ

- オプティミスティックなBeanを明示的に無効化する

- クラスタ内のオプティミスティック同時実行性の無効化オプション

- オプティミスティック同時実行性でのデータ有効性のチェック

- オプティミスティック同時実行性とOracleデータベース

- 読取り専用同時実行性

- 同時実行性ストラテジのトレードオフ

- 同時実行性ストラテジの構成

- 排他的同時実行性とカスケード削除を使用するデッドロックの防止

- read-mostlyパターンの使い方

- エンティティBeanのread-mostlyパターンの構成

- 読取り専用エンティティEJBの暗黙的な無効化

- エンティティEJBの明示的な無効化

- 機能別のCMPエンティティBeanの記述子

- コンテナ管理による関係の要素

- 主キーの要素

7 メッセージドリブンEJB

8 Enterprise JavaBeansのデプロイメント・ガイドライン

- EJBをデプロイする前に

- デプロイメント・タスクの概要と実行

- EJBデプロイメントのガイドライン

- エンタープライズ・アプリケーションの一部としてのEJBのデプロイメント

- お互いに呼出しあう複数のEJBの同じアプリケーションでのデプロイメント

- 依存関係インジェクションを使用するEJBのデプロイメント

- クラスタへの均一なデプロイメント

- 固定EJBのクラスタへのデプロイメント

- EJBの再デプロイメント

- FastSwapデプロイメントによるデプロイメントの最小化

- 警告メッセージについて

- EJBデプロイメントの警告メッセージの無効化

A デプロイメント記述子スキーマおよび文書型定義リファレンス

- XMLスキーマ定義とネームスペース宣言

- weblogic-ejb-jar.xmlのネーム・スペース宣言とスキーマの場所

- weblogic-cmp-jar.xmlのネーム・スペース宣言とスキーマの場所

- ejb-jar.xmlのネームスペース宣言とスキーマの場所

- 文書型定義およびDOCTYPEヘッダー情報

B weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス

- 2.1のweblogic-ejb-jar.xmlファイルの構造

- 2.1のweblogic-ejb-jar.xmlの要素

- allow-concurrent-calls

- 機能

- 例

- allow-remove-during-transaction

- 機能

- 例

- cache-between-transactions

- 機能

- 例

- cache-type

- 機能

- 例

- client-authentication

- 機能

- 例

- client-cert-authentication

- 機能

- 例

- clients-on-same-server

- 機能

- 例

- component-factory-class-name

- 機能

- concurrency-strategy

- 機能

- 例

- confidentiality

- 機能

- 例

- connection-factory-jndi-name

- 機能

- 例

- connection-factory-resource-link

- 機能

- create-as-principal-name

- 機能

- delay-updates-until-end-of-tx

- 機能

- 例

- description

- 機能

- 例

- destination-jndi-name

- 機能

- 例

- destination-resource-link

- 機能

- disable-warning

- 機能

- 例

- dispatch-policy

- 機能

- 例

- distributed-destination-connection

- 機能

- 例

- durable-subscription-deletion

- 機能

- 例

- ejb-name

- 機能

- 例

- ejb-reference-description

- 機能

- 例

- ejb-ref-name

- 機能

- 例

- enable-bean-class-redeploy

- 機能

- 例

- enable-call-by-reference

- 機能

- 例

- enable-dynamic-queries

- 機能

- 例

- entity-always-uses-transaction

- 機能

- entity-cache

- 機能

- 例

- entity-cache-name

- 機能

- 例

- entity-cache-ref

- 機能

- 例

- entity-clustering

- 機能

- 例

- entity-descriptor

- 機能

- 例

- estimated-bean-size

- 機能

- 例

- externally-defined

- 機能

- finders-load-bean

- 機能

- 例

- generate-unique-jms-client-id

- 機能

- global-role

- home-call-router-class-name

- 機能

- 例

- home-is-clusterable

- 機能

- 例

- home-load-algorithm

- 機能

- 例

- idempotent-methods

- 機能

- 例

- identity-assertion

- 機能

- 例

- idle-timeout-seconds

- 機能

- 例

- iiop-security-descriptor

- 機能

- 例

- init-suspend-seconds

- 機能

- initial-beans-in-free-pool

- 機能

- 例

- initial-context-factory

- 機能

- 例

- integrity

- 機能

- 例

- invalidation-target

- 機能

- 例

- is-modified-method-name

- 機能

- 例

- isolation-level

- 機能

- Oracleデータベースのみのアイソレーション・レベル

- 例

- jms-client-id

- 機能

- 例

- jms-polling-interval-seconds

- 機能

- 例

- jndi-binding

- 機能

- 例

- jndi-name

- 機能

- 例

- local-jndi-name

- 機能

- 例

- max-beans-in-cache

- 機能

- 例

- max-beans-in-free-pool

- 機能

- 例

- max-messages-in-transaction

- 機能

- max-queries-in-cache

- 機能

- max-suspend-seconds

- 機能

- message-destination-descriptor

- 機能

- 例

- message-destination-name

- 機能

- 例

- message-driven-descriptor

- 機能

- 例

- method

- 機能

- 例

- method-intf

- 機能

- 例

- method-name

- 機能

- 例

- method-param

- 機能

- 例

- method-params

- 機能

- 例

- network-access-point

- 機能

- 例

- passivate-as-principal-name

- 機能

- persistence

- 機能

- 例

- persistence-use

- 機能

- 例

- persistent-store-dir

- 機能

- 例

- persistent-store-logical-name

- 機能

- pool

- 機能

- 例

- principal-name

- 機能

- 例

- provider-url

- 機能

- 例

- read-timeout-seconds

- 機能

- 例

- remote-client-timeout

- 機能

- 例

- remove-as-principal-name

- 機能

- replication-type

- 機能

- 例

- resource-env-ref-name

- 機能

- 例

- res-ref-name

- 機能

- 例

- resource-adapter-jndi-name

- 機能

- resource-description

- 機能

- 例

- resource-env-description

- 機能

- 例

- resource-link

- 機能

- 例

- retry-count

- 機能

- retry-methods-on-rollback

- 機能

- role-name

- 機能

- 例

- run-as-identity-principal

- 機能

- 例

- run-as-principal-name

- 機能

- 例

- run-as-role-assignment

- 機能

- 例

- A_EJB_with_runAs_role_X

- B_EJB_with_runAs_role_X

- C_EJB_with_runAs_role_Y

- security-permission

- 機能

- 例

- security-permission-spec

- 機能

- 例

- security-role-assignment

- 機能

- 例

- service-reference-description

- 機能

- 例

- session-timeout-seconds

- 機能

- 例

- stateful-session-cache

- 機能

- 例

- stateful-session-clustering

- 機能

- 例

- stateful-session-descriptor

- 機能

- 例

- stateless-bean-call-router-class-name

- 機能

- 例

- stateless-bean-is-clusterable

- 機能

- 例

- stateless-bean-load-algorithm

- 機能

- 例

- stateless-clustering

- 機能

- 例

- stateless-session-descriptor

- 機能

- 例

- stick-to-first-server

- 機能

- 例

- timer-descriptor

- 機能

- timer-implementation

- 機能

- 例

- transaction-descriptor

- 機能

- 例

- transaction-isolation

- 機能

- 例

- transport-requirements

- 機能

- 例

- trans-timeout-seconds

- 機能

- 例

- type-identifier

- 機能

- 例

- type-storage

- 機能

- 例

- type-version

- 機能

- 例

- use-serverside-stubs

- 機能

- 例

- use81-style-polling

- 機能

- 例

- weblogic-compatibility

- 機能

- weblogic-ejb-jar

- 機能

- weblogic-enterprise-bean

- 機能

- work-manager

- 機能

C weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス

- 2.1のweblogic-cmp-jar.xmlデプロイメント記述子ファイルの構造

- 2.1のweblogic-cmp-jar.xmlデプロイメント記述子の要素

- allow-readonly-create-and-remove

- 機能

- 例

- automatic-key-generation

- 機能

- 例

- caching-element

- 機能

- 例

- caching-name

- 機能

- 例

- check-exists-on-method

- 機能

- 例

- cluster-invalidation-disabled

- 機能

- 例

- cmp-field

- 機能

- 例

- cmr-field

- 機能

- 例

- column-map

- 機能

- 例

- compatibility

- 機能

- 例

- create-default-dbms-table

- 機能

- 自動表作成

- OracleデータベースのSEQUENCEの自動生成

- 例

- database-specific-sql

- 機能

- 例

- database-type

- 機能

- 例

- data-source-jndi-name

- 機能

- 例

- db-cascade-delete

- 機能

- Oracleデータベースでのカスケード削除の設定

- 例

- dbms-column

- 機能

- 例

- dbms-column-type

- 機能

- 例

- dbms-default-value

- 機能

- 例

- default-dbms-tables-ddl

- 機能

- delay-database-insert-until

- 機能

- 例

- description

- 機能

- 例

- disable-string-trimming

- 機能

- 例

- ejb-name

- 機能

- 例

- ejb-ql-query

- 機能

- 例

- enable-batch-operations

- 機能

- 例

- enable-query-caching

- 機能

- 例

- field-group

- 機能

- 例

- field-map

- 機能

- 例

- finders-return-nulls

- 機能

- 例

- foreign-key-column

- 機能

- 例

- foreign-key-table

- 機能

- 例

- generator-name

- 機能

- 例

- generator-type

- 機能

- 例

- group-name

- 機能

- 例

- include-updates

- 機能

- 例

- instance-lock-order

- 機能

- 例

- key-cache-size

- 機能

- 例

- key-column

- 機能

- 例

- lock-order

- 機能

- 例

- max-elements

- 機能

- 例

- method-name

- 機能

- 例

- method-param

- 機能

- 例

- method-params

- 機能

- 例

- optimistic-column

- 機能

- 例

- order-database-operations

- 機能

- 例

- pass-through-columns

- 機能

- 例

- primary-key-table

- 機能

- 例

- query-method

- 機能

- 例

- relation-name

- 機能

- 例

- relationship-caching

- 機能

- 例

- relationship-role-map

- 機能

- 例

- 関係の外部キー側のBeanの複数表へのマッピング

- 関係の主キー側のBeanの複数表へのマッピング

- relationship-role-name

- 機能

- 例

- serialize-byte-array-to-oracle-blob

- 機能

- 例

- serialize-char-array-to-bytes

- 機能

- 例

- sql

- 機能

- 例

- sql-query

- 機能

- 例

- sql-select-distinct

- 機能

- 例

- sql-shape

- 機能

- 例

- sql-shape-name

- 機能

- 例

- table-map

- 機能

- 例

- table-name

- 機能

- 例

- trigger-updates-optimistic-column

- 機能

- 例

- unknown-primary-key-field

- 機能

- 例

- use-select-for-update

- 機能

- 例

- validate-db-schema-with

- 機能

- 例

- verify-columns

- 機能

- 例

- verify-rows

- 機能

- 例

- version-column-initial-value

- 機能

- 例

- weblogic-ql

- 機能

- 例

- weblogic-query

- 機能

- 例

- weblogic-rdbms-bean

- 機能

- 例

- weblogic-rdbms-jar

- 機能

- 例

- weblogic-rdbms-relation

- 機能

- 例

- 1対1の関係の定義

- 1対多の関係の定義

- 多対多の関係の定義

- weblogic-relationship-role

- 機能

- 例

D appcリファレンス

- appc

- appcの利点

- appcの構文

- 代替デプロイメント記述子の指定

- appcのオプション

- appcおよびEJB

E EJBGenリファレンス

- EJBGenの実行

- EJBGenの配布と例

- EJBGenの起動

- EJBGenのコマンド・オプション

- 主要なEJBGenの機能の使い方

- EJBGenが生成するファイルの管理

- EJBGenでのプロパティ・ファイルの使用

- ユーザー変数の使い方

- 定義済み変数の使い方

- スペースを含む属性は二重引用符で囲む

- EJBGenによるタグ継承のサポート

- EJBGenタグの使用例

- EJBGenによる複数表へのエンティティBeanのマッピング

- EJBGenタグによるリレーションシップ・キャッシングの指定

- EJBGenタグによる関係の指定

- ローカル・インタフェースを使用するように関係を更新する

- Enum属性定数値

- Constants.Bool

- Constants.TransactionAttribute

- Constants.IsolationLevel

- Constants.RefType

- Constants.HomeLoadAlgorithm

- Constants.Interface

- Constants.ConcurrencyStrategy

- EJBGenアノテーション・リファレンス

- EJBコンテナ・アノテーション

- weblogic.ejbgen.ActivationConfigProperties

- weblogic.ejbgen.ActivationConfigProperty

- 属性

- weblogic.ejbgen.AutomaticKeyGeneration

- 属性

- weblogic.ejbgen.CmpField

- 属性

- weblogic.ejbgen.CmrField

- 属性

- weblogic.ejbgen.Compatibility

- 属性

- weblogic.ejbgen.CreateDefaultDbmsTables

- weblogic.ejbgen.CreateDefaultRdbmsTables

- weblogic.ejbgen.DBSpecificSQL

- 属性

- weblogic.ejbgen.EjbClientJar

- weblogic.ejbgen.EjbInterface (非推奨)

- 属性

- weblogic.ejbgen.EjbLocalRef

- 属性

- weblogic.ejbgen.EjbLocalRefs

- weblogic.ejbgen.EjbRef

- 属性

- weblogic.ejbgen.EjbRefs

- weblogic.ejbgen.Entity

- 属性

- weblogic.ejbgen.EntityCacheRef

- 属性

- weblogic.ejbgen.EnvEntries

- weblogic.ejbgen.EnvEntry

- 属性

- weblogic.ejbgen.FileGeneration

- 属性

- weblogic.ejbgen.Finder

- 属性

- weblogic.ejbgen.Finders

- weblogic.ejbgen.ForeignJmsProvider

- 属性

- weblogic.ejbgen.JarSettings

- 属性

- weblogic.ejbgen.JndiName

- 属性

- weblogic.ejbgen.LocalHomeMethod

- 属性

- weblogic.ejbgen.LocalMethod

- 属性

- weblogic.ejbgen.MessageDestination

- 属性

- weblogic.ejbgen.MessageDestinationRef

- 属性

- weblogic.ejbgen.MessageDestinationRefs

- weblogic.ejbgen.MessageDestinations

- weblogic.ejbgen.MessageDriven

- 属性

- weblogic.ejbgen.MethodIsolationLevelPattern

- 属性

- weblogic.ejbgen.MethodIsolationLevelPatterns

- weblogic.ejbgen.MethodPermissionPattern

- 属性

- weblogic.ejbgen.MethodPermissionPatterns

- weblogic.ejbgen.PrimKeyField

- weblogic.ejbgen.Relation

- 属性

- weblogic.ejbgen.Relations

- weblogic.ejbgen.RelationshipCachingElement

- 属性

- weblogic.ejbgen.RelationshipCachingElements

- weblogic.ejbgen.RemoteHomeMethod

- 属性

- weblogic.ejbgen.RemoteMethod

- 属性

- weblogic.ejbgen.ResourceEnvRef

- 属性

- weblogic.ejbgen.ResourceEnvRefs

- weblogic.ejbgen.ResourceRef

- 属性

- weblogic.ejbgen.ResourceRefs

- weblogic.ejbgen.RoleMapping

- 属性

- weblogic.ejbgen.RoleMappings

- weblogic.ejbgen.SecurityRoleRef

- 属性

- weblogic.ejbgen.SecurityRoleRefs

- weblogic.ejbgen.Select

- 属性

- weblogic.ejbgen.ServiceEndpointMethod

- 属性

- weblogic.ejbgen.ServiceRef

- 属性

- weblogic.ejbgen.ServiceRefs

- weblogic.ejbgen.Session

- 属性

- weblogic.ejbgen.SqlFinder

- 属性

- weblogic.ejbgen.SqlFinders

- weblogic.ejbgen.SqlShape

- 属性

- weblogic.ejbgen.SqlShapeTable

- 属性

- weblogic.ejbgen.SqlShapes

- weblogic.ejbgen.ValueObject

- 属性

- weblogic.ejbgen.ValueObjectField

- 属性

F EJB 1.1ユーザーへの重要な情報

- EJB 1.1 CMPのRDBMS永続性用の記述

- ファインダ署名

- finder-list要素

- finder-query要素

- EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)の使用

- WLQL構文

- WLQL演算子

- WLQLオペランド

- WLQL式の例

- CMP 1.1ファインダ問合せとしてのSQLの使用

- WebLogic ServerでのEJB 1.1 CMPの調整更新

- is-modified-method-nameを使用したejbStore()の呼出しの制限

- 5.1のweblogic-ejb-jar.xmlデプロイメント記述子ファイルの構造

- 5.1のweblogic-ejb-jar.xmlデプロイメント記述子要素

- caching-descriptor

- max-beans-in-free-pool

- initial-beans-in-free-pool

- max-beans-in-cache

- idle-timeout-seconds

- cache-strategy

- read-timeout-seconds

- persistence-descriptor

- is-modified-method-name

- delay-updates-until-end-of-tx

- persistence-type

- db-is-shared

- stateful-session-persistent-store-dir

- persistence-use

- clustering-descriptor

- home-is-clusterable

- home-load-algorithm

- home-call-router-class-name

- stateless-bean-is-clusterable

- stateless-bean-load-algorithm

- stateless-bean-call-router-class-name

- stateless-bean-methods-are-idempotent

- transaction-descriptor

- trans-timeout-seconds

- reference-descriptor

- resource-description

- ejb-reference-description

- enable-call-by-reference

- jndi-name

- transaction-isolation

- isolation-level

- Oracleのみのアイソレーション・レベル

- method

- security-role-assignment

- 1.1のweblogic-cmp-jar.xmlデプロイメント記述子ファイルの構造

- 1.1のweblogic-cmp-jar.xmlデプロイメント記述子要素

- RDBMS定義要素

- enable-tuned-updates

- pool-name

- schema-name

- table-name

- EJBフィールド・マッピング要素

- attribute-map

- object-link

- bean-field

- dbms-column

- ファインダ要素

- finder-list

- finder

- method-name

- method-params

- method-param

- finder-query

- finder-expression

G EJB問合せ言語(EJB-QL)とWebLogic Server

- EJB 2.x BeanについてのEJB QLの要件

- EJB QLのEJB 2.x WebLogic QL拡張機能の使い方

- upperおよびlower関数

- upper

- lower

- ORDER BYの使用

- サブ問合せの使用

- 副問合せの戻り値の型

- 比較オペランドとしてのサブ問合せ

- 相関サブ問合せと非相関サブ問合せ

- サブ問合せでのDISTINCT句

- 算術関数の使用

- 集約関数の使用

- ResultSetを返す問合せの使用

- OracleのSELECT HINTの使用

- getおよびsetメソッドの制約

- Queryインタフェースのプロパティ・ベースのメソッド

- WLQLからEJB QLへの移行

- 暗黙的クロス積に関して確認済みの問題

- EJB QLエラー報告機能

- 問合せ内エラーのビジュアルなインジケータ

- 1回のコンパイル後に複数のエラー報告

Oracle® Fusion Middleware

Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング

12c リリース1(12.1.1)

B65951-02(原本部品番号:E24973-02)

2012年1月

このドキュメントは、Java Platform, Enterprise Edition 6以前を使用して、WebLogic Server Enterprise JavaBeans (EJB)バージョン2.1以前を利用したアプリケーションを開発するソフトウェア開発者を対象としています。

Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング, 12c リリース1(12.1.1)

B65951-02

Copyright © 2007, 2012, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りがないことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、このガイド『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この項では、このガイド『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』の内容と構成について説明します。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- EJB開発者向けのサンプルとチュートリアル

- このリリースでの新機能と変更点

ドキュメントのスコープと対象読者

このドキュメントは、WebLogic Server Enterprise JavaBeans (EJB)バージョン2.1を利用したアプリケーションを開発するソフトウェア開発者を対象としています。また、WebLogic Serverを評価するビジネス・アナリストや特定の用途にWebLogic Server EJBの使用を考えているシステム設計者にとって便利な情報も掲載されています。

このマニュアルのトピックでは、ソフトウェア・プロジェクトの設計および開発段階に関連する情報を提供します。また、プロジェクトのテストおよびプロダクション前の段階で見つかるアプリケーションの問題を解決するうえで便利なトピックもあります。

このドキュメントでは、プロダクション段階における管理、モニター、またはパフォーマンス・チューニングについては取扱いません。これらのトピックに関するWebLogic Serverのドキュメントとリソースへのリンクについては、「関連ドキュメント」を参照してください。

このドキュメントは、Java EEおよびEJB 2.1の概念に精通している読者を対象としています。このドキュメントでは、WebLogic Server EJBが提供する付加価値機能と、EJBアプリケーションを実行するWebLogic Server機能の使い方に関する主要な情報が重点的に扱われています。

EJB 3.1のプログラミングとパッケージ化の詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』を参照してください。

このドキュメントの手引き

- この章「概要とロードマップ」では、このマニュアルの構成を紹介します。

- 第2章「Enterprise JavaBeansについて」では、さまざまなタイプのBean、それらのBeanの機能、およびそれらのBeanが他のアプリケーション・オブジェクトやWebLogic Serverとどのように機能するのかについて説明します。

- 第3章「Enterprise JavaBeansの設計」では、WebLogic Server Enterprise JavaBeans (EJB)の設計オプション、設計の過程で検討する要素、およびお薦めの設計パターンについて説明します。

- 第4章「Enterprise JavaBeansの実装」では、EJBの実装プロセスを説明し、EJBをWebLogic Serverで実行する方法について説明します。

- 第5章「セッションEJB」では、セッションBeanがEJBコンテナの中でどのように機能するのかを説明し、セッションBeanに固有の設計および開発ガイドラインも提供します。

- 第6章「エンティティEJB」では、エンティティBeanがEJBコンテナの中でどのように機能するのかを説明し、エンティティBeanに固有の設計および開発ガイドラインも提供します。

- 第6章「メッセージドリブンEJB」では、メッセージドリブンBeanがEJBコンテナの中でどのように機能するのかを説明し、メッセージドリブンBeanに固有の設計および開発ガイドラインも提供します。

- 第8章「Enterprise JavaBeansのデプロイメント・ガイドライン」では、EJB固有のデプロイメントの問題と手順を説明します。

- 付録A「デプロイメント記述子スキーマおよび文書型定義リファレンス」では、EJB XMLスキーマ定義(XSD)と、デプロイメント記述子ファイルに定義する必要があるネームスペース宣言について説明します。

- 付録B「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」では、weblogic-ejb-jar.xmlファイル(WebLogic Server固有のデプロイメント記述子)のEJB 2.xデプロイメント記述子要素について説明します。

- 付録C「weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス」では、weblogic-cmp-jar.xmlファイル(コンテナ管理による永続性のためのWebLogic Server固有のデプロイメント記述子)のEJB 2.xデプロイメント記述子要素について説明します。

- 付録D「appcリファレンス」は、EJBコードのコンパイル、検証、生成に使用するWebLogic Server appcツールの詳細なリファレンスです。

- 付録E「EJBGenリファレンス」は、WebLogic Server EJBGen EJB 2.xコード・ジェネレータのリファレンスです。

- 付録F「EJB 1.1ユーザーへの重要な情報」では、EJB 1.1に固有の重要な設計および実装の情報を提供します。

- 付録G「EJB問合せ言語(EJB-QL)とWebLogic Server 」では、WebLogic ServerでEJB QLを使用することに関連する問題を説明します。

関連ドキュメント

このドキュメントには、EJB固有の設計および開発上の情報が含まれています。

WebLogic Serverアプリケーションを開発、デプロイ、およびモニターするための包括的なガイドラインについては、以下のドキュメントを参照してください。

- 『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』は、メッセージドリブンBean(MDB)を使用するアプリケーションを開発するためのリソースです。

- 『Oracle WebLogic Serverアプリケーションの開発』は、WebLogic Serverアプリケーションの開発ガイドです。

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』は、開発および本番環境でのWebLogic Serverアプリケーションのデプロイメントについての主要な情報源です。

- 『Oracle WebLogic Serverパフォーマンスおよびチューニング』は、WebLogic Serverでのパフォーマンスの監視方法やコンポーネントのチューニング方法に関する情報を提供します。

EJB開発者向けのサンプルとチュートリアル

このドキュメントの他にも、さまざまなサンプル・コードやチュートリアルがEJB開発者向けに用意されています。それらのサンプルとチュートリアルはWebLogic Server EJBの動作を例示し、主要なEJB開発タスクを実行する実際的な手順を示します。

独自のEJBを開発する前に、まずEJBサンプルの一部またはすべてを実行することをお薦めします。

Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

MedRecはWebLogic Serverに付属したエンド・ツー・エンドのサンプルJava EEアプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者に対して、さまざまなクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRecはWebLogic ServerとJava EEの機能を例示し、Oracle推奨のベスト・プラクティスを重要点として示します。MedRecはWebLogic Server配布キットに含まれており、Windowsマシンの「スタート」メニューからアクセスできます。Linuxなどのプラットフォームでは、WL_HOME\samples\domains\medrecディレクトリからMedRecを起動できます。WL_HOMEは、WebLogic Platformの最上位のインストール・ディレクトリです。

MedRecには、Webアプリケーション、Webサービス、ワークフロー・アプリケーション、および将来のクライアント・アプリケーションからの要求を共同で処理する複数のEJBで主に構成されるサービス層があります。このアプリケーションには、メッセージドリブンEJB、ステートレス・セッションEJB、ステートフル・セッションEJB、およびエンティティEJBが含まれます。

MedRecアプリケーションの手引きとして、主要な開発タスク(EJB固有のタスクを含む)の手順をステップ・バイ・ステップで説明する以下のようなチュートリアルが用意されています。

- EJBGenを使用したEJBデプロイメント記述子の生成

- Webサービスとしてのステートレス・セッションEJBのエクスポーズ

- 管理コンソールを使用したEJBリソースの保護

WebLogic Server配布キットのEJBサンプル

WebLogic Serverでは、任意でAPIサンプル・コードをWL_HOME\samples\server\examples\src\examples\ejbにインストールできます。WL_HOMEは、WebLogic Serverの最上位インストール・ディレクトリです。WebLogic Serverのスタート・メニューからサンプル・サーバーを起動して、サンプルとその実行手順に関する情報を確認できます。

このリリースでの新機能と変更点

WebLogic Serverのこのリリースに追加された新機能の一覧については、『Oracle WebLogic Serverの新機能』のWebLogic Serverの新機能に関する項を参照してください。

2 Enterprise JavaBeansについて

この章では、Enterprise JavaBean (EJB)の様々なタイプと、それらがアプリケーションで果たす機能を概説し、それらが他のアプリケーション・オブジェクトおよびWebLogic Serverとどのように機能するかについて説明します。

この章は、JavaのプログラミングおよびEJB 2.xの概念と機能に精通している読者を対象としています。

- アプリケーションによるEJBの使い方

- EJBの構造と環境

- EJB、クライアント、およびアプリケーション・オブジェクト

- EJBとメッセージ宛先の参照

- WebLogic ServerのEJBの付加価値機能

- EJBのセキュリティ

アプリケーションによるEJBの使い方

次の項では、各Beanタイプの目的と機能について説明します。

- セッションEJBによるビジネス・ロジックの実装

- エンティティEJBによる永続データの保持

- メッセージドリブンBeanによる疎結合ビジネス・ロジックの実装

セッションEJBによるビジネス・ロジックの実装

セッションBeanは、ビジネス・ロジックを実装します。セッションBeanインスタンスは、一度に1つのクライアントにサービスを提供します。セッションBeanには、2つのタイプ(ステートフルとステートレス)があります。

ステートレス・セッションBean

ステートレス・セッションBeanは、呼出し間でセッションやクライアントの状態の情報を格納しません。唯一格納されることのある状態はクライアントに固有のものではなく、キャッシュされたデータベース接続や別のEJBの参照などです。ステートレス・セッションBeanが状態を格納できるのは、長くてメソッド呼出しの期間だけです。メソッドが完了すると、状態情報は維持されません。ステートレス・セッションBeanのインスタンスはすべて、どのクライアントにもサービスを提供できます(どのインスタンスも機能は同じ)。ステートレス・セッションBeanは、ステートフル・セッションBeanよりもパフォーマンスが優れています。その理由は、各ステートレス・セッションBeanが複数のクライアントをサポートできるからです(ただし一度に1つ)。

例:訪問者が「お問い合わせ」リンクをクリックして電子メール送信できるインターネット・アプリケーションでは、ステートレス・セッションBeanを使用して、JSPによってユーザーから収集された送信先と送信元の情報に基づいて電子メールを生成できます。

ステートフル・セッションBean

ステートフル・セッションBeanは、特定のクライアントとの対話を反映する状態情報をメソッドやトランザクションをまたがって維持します。ステートフル・セッションBeanは、クライアントと他のエンタープライズBeanの対話を管理するか、ワークフローを管理できます。

例:社員が個人のプロファイル情報を表示して更新できる、ある会社のWebサイトでは、ステートフル・セッションBeanを使用してさまざまな他のBeanを呼び出し、ユーザーがページ上で「データの表示」をクリックした後に以下のようなユーザーが必要とするサービスを提供できます。

- JSPからログイン・データを受け付け、そのログイン・データを検証する別のEJBを呼び出す

- 認可の確認をJSPに送信する

- 認可されたユーザーのプロファイル情報にアクセスするBeanを呼び出す

エンティティEJBによる永続データの保持

エンティティBeanは、永続データの集合(通常はデータベースの行)を表し、そのデータを管理したり読み込んだりするためのメソッドを提供します。エンティティBeanは主キーによってユニークに識別され、複数のクライアントに同時にサービスを提供できます。エンティティBeanは、他のエンティティBeanとの関係に参加することができます。エンティティBean間の関係は、エンティティBeanがモデル化する実世界のエンティティによって決まります。エンティティBeanのフィールドと他のエンティティBeanとの関係は、そのBeanのejb-jar.xmlデプロイメント記述子で指定されたオブジェクト・スキーマで定義します。

エンティティBeanは、他のBeanタイプ(メッセージドリブンBeanやセッションBeanなど)をクライアントとするか、Webコンポーネントから直にアクセスすることができます。クライアントは、エンティティBeanを使用して永続ストアのデータにアクセスします。エンティティBeanはデータベース・アクセスの仕組みをカプセル化し、その複雑さをクライアントから分離し、物理データベースの細部をビジネス・ロジックから切り離します。

例:会社のイントラネット上の個人プロファイル情報にアクセスする社員のサービスを調整する、上の例のステートフル・セッションBeanでは、社員のプロファイルを取得および更新するためにエンティティBeanを使用できます。

メッセージドリブンBeanによる疎結合ビジネス・ロジックの実装

メッセージドリブンBeanは、要求に対する応答が即時である必要のない疎結合(非同期)のビジネス・ロジックを実装します。メッセージドリブンBeanは、JMSキューまたトピックからメッセージを受信し、そのメッセージの内容に基づいてビジネス・ロジックを実行します。それは、EJBとJMSの間の非同期インタフェースです。

MDBインスタンスはそのライフサイクルを通じて、同時にではありませんが複数のクライアントからのメッセージを処理できます。特定のクライアントの状態は維持されません。メッセージドリブンBeanのインスタンスはすべて同じ機能であり、EJBコンテナはどのMDBインスタンスにもメッセージを割り当てることができます。コンテナは、それらのインスタンスをプールしてメッセージのストリームの並行処理を可能にします。

EJBコンテナは、必要に応じてBeanのインスタンスを作成し、JMSメッセージをインスタンスに渡すことによってメッセージドリブンBeanと直接対話します。コンテナは、デプロイメント時にBeanのインスタンスを作成し、メッセージのトラフィックに基づいて作動時にインスタンスを追加および削除します。

詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』を参照してください。

例:顧客から注文を受けるプロセスがサプライヤへの発注プロセスを引き起こすオンライン・ショッピング・アプリケーションでは、サプライヤへの発注プロセスをメッセージドリブンBeanで実装できます。顧客の注文が必ずサプライヤへの発注につながる一方で、そのステップは疎結合になります。その理由は、顧客の注文を確定する前にサプライヤへの発注を生成する必要はないからです。関連するサプライヤへの注文が発行される前に顧客の注文が「蓄積」されるのは問題なく、有益なことです。

EJBの構造と環境

以下の節では、各Beanタイプで必須のクラス、EJB実行時環境、およびBeanの実行時の動作を管理するデプロイメント記述子ファイルについて簡単に説明します。

- EJBの構成要素

- EJBコンテナ

- EJBデプロイメント記述子

EJBの構成要素

Beanの構造はBeanタイプによって異なります。表2-1に、各タイプのEJBを構成するクラスと、そのクラス・タイプの用途を示します。

表2-1 EJBの構成要素

EJBコンポーネント

説明

ステートレス・セッション

ステートフル・セッション

エンティティ

MDB

リモート・インタフェース

リモート・インタフェースはビジネス・ロジックをリモート・クライアント(EJBとは別のアプリケーションで動作するクライアント)にエクスポーズします。リモート・クライアントから呼び出せるビジネス・メソッドを定義します。

はい

はい

はい

いいえ

ローカル・インタフェース

ローカル・インタフェースは、ビジネス・ロジックをローカル・クライアント(EJBと同じアプリケーションで動作しているクライアント)にエクスポーズします。ローカル・クライアントから呼び出せるビジネス・メソッドを定義します。

注意 : 1.1 EJBでは利用できません。

はい

はい

はい

いいえ

ローカル・ホーム・インタフェース

ローカル・ホーム・インタフェース(EJBファクトリまたはライフサイクル・インタフェースとも呼ばれる)は、ローカル・クライアント(EJBと同じアプリケーションで動作するクライアント)から使用して、Beanのインスタンスを作成、削除、および(エンティティBeanの場合は)検索することができるメソッドを提供します。

ローカル・ホーム・インタフェースには、特定のBeanインスタンスに固有ではないビジネス・ロジックである「ホーム・メソッド」もあります。

はい

はい

はい

いいえ

リモート・ホーム・インタフェース

リモート・ホーム・インタフェース(EJBファクトリまたはライフサイクル・インタフェースとも呼ばれる)は、リモート・クライアント(EJBとは別のアプリケーションで動作するクライアント)から使用して、Beanのインスタンスを作成、削除、および検索することができるメソッドを提供します。

はい

はい

はい

いいえ

Beanクラス

Beanクラスはビジネス・ロジックを実装します。

はい

はい

はい

はい

主キー・クラス

エンティティBeanだけが主キー・クラスを持ちます。主キー・クラスは、データベースの1つまたは複数のフィールドにマッピングされ、エンティティBeanが対応している永続データを識別します。

いいえ

いいえ

はい

いいえ

EJBコンテナ

EJBコンテナとは、アプリケーション・サーバーにデプロイされたBeanの実行時コンテナです。このコンテナはアプリケーション・サーバーの起動時に自動的に作成され、Beanと以下のような実行時サービスの間のインタフェースとして機能します。

- ライフサイクル管理

- コード生成

- 永続性管理

- セキュリティ

- トランザクションの管理

- ロックと同時実行性の制御

EJBデプロイメント記述子

Beanの構造とその実行時の動作は、1つまたは複数のXMLデプロイメント記述子ファイルで定義します。プログラマはデプロイメント記述子をEJBのパッケージ化プロセスで作成し、その記述子はBeanのコンパイル時にEJBデプロイメントの一部になります。

WebLogic ServerのEJBには、以下の3つのデプロイメント記述子があります。

- ejb-jar.xml - 標準Java EEデプロイメント記述子。Beanはすべてejb-jar.xmlで指定する必要があります。ejb-jar.xmlでは、一緒にデプロイされる複数のBeanを指定できます。

- weblogic-ejb-jar.xml - クラスタ化、キャッシング、トランザクションといったWebLogic Serverの機能と関連する要素を格納するWebLogic Server固有のデプロイメント記述子。このファイルは、BeanがWebLogic Server固有の機能を利用する場合は必須です。ejb-jar.xmlと同じように、weblogic-ejb-jar.xmlでは一緒にデプロイされる複数のBeanを指定できます。『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスに関する項を参照してください。

- weblogic-cmp-jar.xml - エンティティBeanのコンテナ管理による永続性に関連する要素を格納するWebLogic Server固有のデプロイメント記述子。コンテナ管理による永続性を使用するエンティティBeanは、weblogic-cmp-jar.xmlファイルに指定する必要があります。『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のweblogic-cmp-jar.xmlデプロイメント記述子のリファレンスに関する項を参照してください。

主要なデプロイメント要素のマッピング

「EJBデプロイメント記述子」で説明されているように、WebLogic Server EJBの実行時の動作は、3つの異なるデプロイメント記述子ファイルejb-jar.xml、weblogic-ejb-jar.xml、およびweblogic-cmp-jar.xmlの要素で制御できます。

表2-2に、各記述子ファイルで値が一致しなければならない要素のリストを示します。表中の要素は、「Beanとリソースのリファレンス」と「セキュリティ・ロール」で定義されています。

表2-2 記述子ファイル間の要素のマッピング

この要素のマッピング

ejb-jar.xmlのこの要素から

weblogic-ejb-jar.xmlのこの要素の同じ要素へ

および、weblogic-cmp-jar.xmlのこの要素へ

role-name

security-role

security-role-assignment

なし

ejb-name

message-driven、entity、またはsession

weblogic-enterprise-bean

weblogic-rdbms-bean

ejb-ref-name

assembly-descriptor

ejb-reference-description (参照されるBeanが現在のBeanとは異なるコンテナで動作する場合)

なし

res-ref-name

resource-ref

resource-description

なし

Beanとリソースのリファレンス

各記述子ファイルは、BeanとそのBeanが使用する実行時ファクトリ・リソースを識別する要素を格納します。

- ejb-name - 各デプロイメント記述子ファイルでBeanを識別するために使用する名前。Beanの参照にアプリケーション・コードで使用する名前とは関係ありません。

- ejb-ref-name - 別の.jarにあるBeanが参照元Beanのコードで表される名前。

- res-ref-name - リソース・ファクトリが参照元Beanのコードで表される名前。

特定のBeanまたはリソース・ファクトリは、それを格納する各記述子ファイルで同じ値で識別されます。表2-1に、Beanとリソースの参照要素およびそれらの各記述子ファイルでの位置を示します。

たとえば、LineItemという名前のコンテナ管理による永続性エンティティBeanの場合、次の行、

<ejb-name>LineItem</ejb-name>

は以下の位置にあります。

- ejb-jar.xmlのassembly-descriptor要素

- weblogic-ejb-jar.xmlのenterprise-bean要素

- weblogic-cmp-jar.xmlのweblogic-rdbms-bean要素

セキュリティ・ロール

セキュリティ・ロールは、ejb-jar.xmlおよびweblogic-ejb-jar.xmlのrole-name要素で定義します。

詳細情報:

- EJBのセキュリティ機能のプログラミングについては、『Oracle WebLogic Serverセキュリティのプログラミング』のEnterprise JavaBeans (EJB)のセキュリティ対策に関する項を参照

- デプロイメント記述子ファイルの作成または生成については、「デプロイメント記述子を生成する」を参照

- デプロイメント記述子ファイルの編集については、「デプロイメント記述子を編集する」を参照

- ejb-jar.xmlの要素については、http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsdを参照

- weblogic-ejb-jar.xmlの要素については、「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」を参照

- weblogic-cmp-jar.xmlの要素については、「weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス」を参照

EJB、クライアント、およびアプリケーション・オブジェクト

図2-1に、EJBとWebLogic Serverアプリケーションの他のコンポーネント、およびEJBとクライアントとの一般的な関係を示します。

図2-1 EJBと他のアプリケーション・コンポーネント

「図2-1 EJBと他のアプリケーション・コンポーネント」の説明

EJBは、サーブレット、Javaクライアント・アプリケーション、他のEJB、アプレット、非Javaクライアントなどのサーバー・サイドまたはクライアント・サイド・オブジェクトからアクセスできます。

EJBのクライアントは、アプリケーションが同じか別かに関係なく同じ方法でEJBにアクセスします。WebLogic Serverは、Beanにローカル・インタフェースしかない場合を除いて、リモートで機能できるEJBのホーム・インタフェースおよびビジネス・インタフェースの実装を自動的に作成します。

EJBでは、Java Naming and Directory Interface (JNDI)を使用して環境プロパティを指定する必要があります。さまざまなマシン、アプリケーション・サーバー、コンテナなど、ネットワーク上のあらゆる場所にあるEJBのホーム・インタフェースが含まれるようにEJBクライアントのJNDIネームスペースを構成できます。

ほとんどのBeanでは、グローバルJNDI名(weblogic-ejb-jar.xmlのjndi-name要素およびlocal-jndi-name要素で指定)は必要ありません。ほとんどのBeanは、「EJBリンクの使用」で説明されているようにejb-linkを使用してお互いを参照します。

ネットワークのオーバーヘッドのため、Beanにはリモート・クライアントからアクセスするよりも同じマシン上のクライアントからアクセスする方が効率的であり、クライアントが同じアプリケーションにあればさらに効率的です。

EJBへのクライアント・アクセスのプログラミングについては、「クライアントによるEJBへのアクセスのプログラミング」を参照してください。

EJBの通信

WebLogic Server EJBは、以下のプロトコルを使用します。

- T3 - リモート・オブジェクトとの通信に使用します。T3は、Remote Method Invocation (RMI)プロトコルを実装するWebLogic独自のリモート・ネットワーク・プロトコルです。

- RMI - リモート・オブジェクトとの通信に使用します。RMIを使用すると、アプリケーションはネットワークの他のどこかにあるオブジェクトの参照を取得し、同じJVMでクライアントと共存しているかのようにそのオブジェクトのメソッドをクライアントの仮想マシンからローカルで呼び出すことができます。
リモート・インタフェースのあるEJBはRMIオブジェクトです。EJBのリモート・インタフェースは、java.rmi.remoteを拡張します。WebLogic RMIの詳細は、『Oracle WebLogic Server RMIのプログラミング』を参照してください。

- HTTP - EJBは、java.net.URLリソース接続ファクトリを使用してWebLogic Server環境外のWebサーバーとのHTTP接続を取得できます。詳細については、「URLに要求を送信するようにEJBを構成する」を参照してください。

EJBが使用するネットワーク接続の属性は、EJBをWebLogic Serverカスタム・ネットワーク・チャネルにバインドすることによって指定できます。詳細については、「EJBのネットワーク通信の構成」を参照してください。

EJBとメッセージ宛先の参照

このリリースのWebLogic Serverでは、論理メッセージ宛先を使用して、ejb-jar.xmlに定義された論理メッセージ宛先をweblogic-ejb-jar.xmlに定義された実際のメッセージ宛先にマップできます。『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』の論理メッセージ宛先を使用するEJBの構成に関する項を参照してください。

メッセージ宛先の参照をデプロイメント中に解決できない場合、警告が発行されますが、デプロイメント自体は正常に完了します。使用できないメッセージ宛先にリンクされているMDBは、そのメッセージ宛先に定期的に接続しようとします。そのメッセージ宛先が使用可能にならない限り、ejb-jar.xmlに宣言されているmessage-destination-referencesのルックアップは失敗し、javax.naming.NamingExceptionが発生します。メッセージ宛先が使用可能になると、MDBはそのメッセージ宛先に接続し、そのメッセージを処理します。

WebLogic ServerのEJBの付加価値機能

この節では、EJBの開発プロセスを容易にしたり、EJBアプリケーションのパフォーマンス、信頼性、および可用性を拡張する主要なWebLogic Serverの機能について説明します。

WebLogic Server EJBのパフォーマンス拡張機能

WebLogic Serverは、EJBの応答時間とパフォーマンスを向上させるプールやキャッシングなどの機能をサポートしています。プロダクション環境では、それらの機能により、クライアントがEJBインスタンスを取得したり、永続データにアクセスしてそれを保持したりするのに要する時間を短縮できます。

プールはEJBの応答時間を短縮する

Weblogic Serverは、ステートレス・セッションBean、メッセージドリブンBean、およびエンティティBeanのすぐに使えるよう準備されたEJBインスタンスのフリー・プールを保持します。そのEJBコンテナは構成された数のBeanインスタンスを起動時に作成するので、要求ごとに新しいインスタンスを作成する必要はありません。クライアントでEJBインスタンスが不要になると、コンテナはそれを再利用できるようにプールに返します。詳細については、以下を参照してください。

- エンティティのプールについて

- 『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のメッセージドリブンEJBのライフサイクルと空きプールに関する項

- ステートレス・セッションEJBのプール

このリリースのWebLogic Serverでは、管理者は管理コンソールを使用してEJBプールを必要に応じて初期化できます。初期化されたEJBプールは、EJBがデプロイされた直後の状態にリセットされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBのアイドル状態Beanのキャッシュとプールの初期化に関する項を参照してください。

キャッシングはEJBのパフォーマンスを向上させる

WebLogic Serverは、ステートフル・セッションBeanとエンティティBeanのキャッシングをサポートしています。

キャッシュされている非アクティブなBeanインスタンスはパッシブ化でき(キャッシュから削除されてディスクに書き込まれる)、必要に応じて後でメモリーに復元できます。Beanインスタンスをパッシブ化すると、システム・リソースの使用が最適化されます。

キャッシュのサイズ、およびキャッシュからBeanを削除するルールなどの関連動作を構成することができます。コンテナ管理の永続性とBean管理の永続性のどちらを使用するかに関係なく、エンティティEJBではキャッシングがサポートされています。

また、このリリースのWebLogic Serverでは、管理者は管理コンソールを使用してEJBキャッシュを必要に応じて初期化できます。初期化されたEJBキャッシュは、EJBがデプロイされた直後の状態にリセットされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBのアイドル状態Beanのキャッシュとプールの初期化に関する項を参照してください。

詳細は、次を参照してください:

- エンティティのキャッシングについて

- ステートフル・セッションEJBのキャッシュとパッシブ化

コンテナ管理の永続性を使用するEJB用の、追加的なキャッシング機能も用意されています。詳細については、次の節を参照してください。

CMPエンティティ用の追加的なキャッシング機能

WebLogic Serverは、コンテナ管理による永続性を使用するエンティティBean向けに以下のキャッシング機能を提供します。

- リレーションシップ・キャッシング - リレーションシップ・キャッシングでは、関係する複数Beanをキャッシュにロードし、それらに結合問合せを発行して問合せの発行回数を削減することによって、エンティティBeanのパフォーマンスが高められます。詳細については、「リレーションシップ・キャッシング」を参照してください。

- アプリケーション・レベルのキャッシング - アプリケーション・レベルのキャッシング(「組合せキャッシング」とも呼ばれます)では、同じJava EEアプリケーションに属する複数のエンティティBeanが1つの実行時キャッシュを共有できます。詳細については、「アプリケーション・レベルのキャッシングの構成」を参照してください。

- トランザクション間のキャッシング: トランザクション間のキャッシング、または、長期キャッシングを使用すると、EJBコンテナはエンティティBeanの永続データをトランザクション間でキャッシュできるようになります。詳細は、「cache-between-transactionsによるデータベース読込みの制限」を参照してください。

効率的な問合せのためのフィールド・グループ(CMPエンティティ)

グループは、エンティティBeanの一連の永続属性を指定します。field-groupは、Beanのコンテナ管理による永続性(CMP)フィールドとコンテナ管理による関係(CMR)フィールドのサブセットを表します。Bean内の関連フィールドを、フォルトのあったグループにまとめて1つのユニットとしてメモリー内に入れることができます。グループを問合せまたは関係に関連付けることができます。それによって、問合せを実行するか、または関係に従った結果としてBeanがロードされたときに、グループ内の指定フィールドのみがロードされます。詳細については、「フィールド・グループの指定」を参照してください。

構成可能な書込み動作

ejbLoad()メソッドとejbStore()メソッドは、ejbStore()の不要な呼出しを防止してパフォーマンスを上げるように構成できます。必要に応じて、ejbStore()がトランザクションの終わりにではなく各メソッド呼出しの後にWebLogic Serverから呼び出されるようにすることができます。詳細については、「ejbLoad()とejbStore()の動作について」を参照してください。

処理の順序付けとバッチ処理(CMPエンティティ)

WebLogic Serverでは、1回のデータベース・アクセスで完了できるように複数のデータベース処理をバッチ処理および順序付けできます。この機能を利用すると、複数のエンティティ・インスタンスが1つのトランザクションから影響を受ける場合に起こる可能性のあるボトルネックを避けることができます。詳細については、「処理の順序付けとバッチ処理」を参照してください。

データベースの更新の最適化(CMPエンティティ)

このリリースのWebLogic ServerのCMP 2.0エンティティBeanでは、setXXX()メソッドを呼び出しても、変更されていないプリミティブ・フィールドおよび不変フィールドの値はデータベースに書き込まれません。この最適化により、特にデータベースの更新が多いアプリケーションでパフォーマンスが向上します。

読取り専用パターンと読取り専用の無効化(CMPエンティティ)

頻繁には更新されないEJBデータの場合、read-only EJBとread-write EJBを組み合わせることによって「read-mostlyパターン」を作成できます。read-mostlyパターンを使用すると、マルチキャストの無効化を利用してデータの一貫性を維持できます(更新後にキャッシュされている読取り専用データを無効化する効率的なメカニズム)。トランザクションの更新が完了した後にinvalidate()メソッドを使用すると、ローカル・キャッシュが無効化されるとともに、マルチキャスト・メッセージがクラスタ内の他のサーバーに送信されてそれらのキャッシュされているコピーが無効化されます。詳細については、「read-mostlyパターンの使い方」を参照してください。

CMP Beanは開発者の生産性を向上させる

WebLogic Serverは、コンテナ管理による永続性を使用するエンティティBeanのさまざまな付加価値データベース・アクセス機能を提供します。

自動主キー生成(CMPエンティティ)

WebLogic Serverは、CMPエンティティEJBの単純主キーを自動的に生成する複数の手法をサポートしています(WebLogic Serverで自動的に生成できるOracle SEQUENCEの使用を含む)。詳細については、「主キーの自動生成」を参照してください。

自動表作成(CMPエンティティ)

エンティティBeanが変更されたときにEJBコンテナが自動的に基底の表スキーマを変更するように構成できます。そのように構成すると、表はオブジェクトの関係の最新のマッピングを常に反映するようになります。詳細については、「自動表作成(開発のみ)」を参照してください。

動的問合せ(CMPエンティティ)

WebLogic Serverを使用すると、各自のアプリケーション・コードでプログラム的に問合せを作成したり実行できるようになります。このため、EJBを更新してデプロイせずに、新しい問合せを作成して実行することができます。また、EJBデプロイメント記述子のサイズが小さくなったり、複雑さが緩和されたりもします。詳細については、「同時実行性ストラテジの選択」を参照してください。

信頼性と可用性の機能

WebLogic Server EJBはクラスタにデプロイすることができ、EJBのリモート・クライアントのためにロード・バランシングとフェイルオーバーがサポートされます。EJBは、クラスタ化されているすべてのサーバーにデプロイする必要があります。

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クラスタはクライアントからは単一のWebLogic Serverインスタンスのように見えます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに分散配置することもできます。

EJBのフェイルオーバーとロード・バランシングは、レプリカ対応スタブによって処理されます。このスタブは、クラスタ全体の中からオブジェクトのインスタンスを見つけ出すためのメカニズムです。レプリカ対応スタブは、オブジェクトのコンパイル処理の結果としてEJBに対して作成されます。EJBは、2つの異なるレプリカ対応スタブを持つことができます。1つはEJBHomeインタフェース用、もう1つはEJBObjectインタフェース用です。このため、クライアントがEJBHomeスタブを使用してEJBオブジェクトをルックアップするときにはホーム・レベルで、クライアントがEJBObjectスタブを使用してEJBに対するメソッド呼出しを行うときにはメソッド・レベルで、一部のBeanタイプはロード・バランシングとフェイルオーバーの機能を利用することができます。表2-1は、各EJBタイプのロード・バランシングとフェイルオーバーのサポートをまとめたものです(メソッド・レベルとホーム・レベル)。

クラスタ化されたEJBのロード・バランシングはスケーラビリティを向上させる

Beanスタブは、オブジェクトに対するメソッド呼出しを負荷分散するためのロード・バランシング・アルゴリズム(呼出しルーティング・クラス)を備えています。呼出しが行われるたびに、スタブではそのロード・アルゴリズムを利用して呼び出すレプリカを選択できます。

WebLogic Serverクラスタは、クラスタ化EJBのロード・バランシングを行う複数のアルゴリズムをサポートしています。デフォルトはラウンドロビン方式です。詳細は、『Oracle WebLogic Serverクラスタの使用』のクラスタでのロード・バランシングに関する項を参照してください。

すべてのBeanタイプが、ホーム・レベルのロード・バランシングをサポートしています。メソッド・レベルのロード・バランシングは、読み書き対応エンティティBeanを除くすべてのBeanタイプでサポートされています。

注意:

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。ほとんどの場合は、リモート・サーバーにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。

クラスタ化されたEJBのフェイルオーバーは信頼性を向上させる

EJBのフェイルオーバーは、EJBHomeスタブまたはサポートされている場合はEJBObjectスタブを使用して実現します。クライアントがスタブを通じて障害が発生したサービスに対して呼出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼出しを再試行します。

EJBのフェイルオーバーでは、Beanのメソッドが多重呼出し不変で、weblogic-ejb-jar.xmlでそのように構成されている必要があります。詳細は、『Oracle WebLogic Serverクラスタの使用』のEJBおよびRMIオブジェクトのレプリケーションとフェイルオーバーに関する項を参照してください。

表2-3に、クラスタ化されたEJBのフェイルオーバーおよびロード・バランシング機能をまとめます。

表2-3 クラスタ化されたEJBのフェイルオーバーとロード・バランシング

EJBタイプ

ホーム・レベルのフェイルオーバー

メソッド・レベルのフェイルオーバー

注意

ステートレス・セッション

サポート

サポート

ステートレス・セッションEJBのクラスタ化動作は、weblogic-ejb-jar.xmlで構成します。「WebLogicに固有のセッションBeanの構成可能な動作」を参照してください。

ステートフル・セッション

サポート

サポート

EJBObjectスタブは、EJBのプライマリ・ステートとセカンダリ・ステートの位置を保持します。セカンダリ・サーバー・インスタンスは、『Oracle WebLogic Serverクラスタの使用』のレプリケーション・グループの使用に関する項で定義されているルールと同じルールを使用して選択します。

ステートフル・セッションEJBのクラスタ化動作は、weblogic-ejb-jar.xmlで構成します。「WebLogicに固有のセッションBeanの構成可能な動作」を参照してください。

読み書き対応エンティティ

サポート

サポートされていない

EJBHomeスタブは、回復可能な呼出しエラーが発生したときにフェイルオーバーは行われません。

フェイルオーバーはメソッドの実行中にはサポートされず、メソッドの完了後またはメソッドがサーバー・インスタンスへの接続に失敗したときにのみサポートされます。

読み書き対応BeanのホームはBeanのローカル・インスタンスを取得し、ローカル・サーバー・インスタンスに固定されたスタブを返します。

エンティティのクラスタ化動作は、weblogic-ejb-jar.xmlで構成します。「クラスタ化要素」を参照してください。

読取り専用エンティティ

サポート

サポート

EJBHomeスタブは、回復可能な呼出しエラーが発生したときにフェイルオーバーは行われません。

エンティティのクラスタ化動作は、weblogic-ejb-jar.xmlで構成します。「クラスタ化要素」を参照してください。

メッセージドリブン

なし

なし

WebLogic Java Messaging Service (JMS)は、JMSサーバーのクラスタリングをサポートしています。詳細は、『Oracle WebLogic Serverクラスタの使用』のJMSとクラスタリングに関する項を参照してください。

詳細は、『Oracle WebLogic Serverクラスタの使用』のEJBおよびRMIのレプリケーションとフェイルオーバーに関する項およびEJBとRMIオブジェクトのロード・バランシングに関する項を参照してください。

EJBのセキュリティ

WebLogic Serverのセキュリティ機能を使用すると、EJBへのアクセス(認可)と他のアプリケーション・コンポーネントや他のEJBと対話するときのEJBのIDの検証(認証)の両方を管理できます。

WebLogic Serverを使用すると、アプリケーション開発者はJava EEおよびWebLogic Serverデプロイメント記述子を使用してセキュリティをEJBアプリケーションに組み込むことができ、システム管理者はWebLogic Server管理コンソールからEJBアプリケーションのセキュリティを管理できます。後者に関しては、開発者はセキュリティをコード化する手間を省くことができ、管理者には、エンタープライズ・アプリケーション(EAR)全体、複数のEJBの含まれるEJB JAR、そのJAR内の特定のEJB、またはそのEJB内の1つのメソッドに対するセキュリティ・ポリシーを定義する一元的なツールが提供されます。

セキュリティとEJBの詳細については、以下を参照してください。

- 認証、認可など、セキュリティ関連の基礎的な情報については、『Oracle WebLogic Serverセキュリティの理解』のセキュリティの基礎に関する項を参照してください。

- EJBの認証と認可を構成する手順については、『Oracle WebLogic Serverセキュリティのプログラミング』のEnterprise JavaBeans (EJB)のセキュリティ対策に関する項を参照してください。

- 管理コンソールを使用してEJBの認証と認可を構成する手順については、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

3 Enterprise JavaBeansの設計

この章では、WebLogic Server Enterprise JavaBeans (EJB)の設計オプション、設計の過程で考慮すべきBeanの動作、および推奨の設計パターンについて説明します。

- 適切なBeanタイプの選択

- 永続性管理の選択肢

- トランザクションの設計と管理のオプション

- WebLogic Server EJBでアプリケーションの要件を満たす

この章は、Javaのプログラミング、EJB 2.x、および「WebLogic ServerのEJBの付加価値機能」で説明されている機能に精通している読者を対象としています。

Beanの設計を終えたら、第4章「Enterprise JavaBeansの実装」のプログラミングや他の実装に関するトピックを参照してください。

適切なBeanタイプの選択

処理タスクのBeanタイプを選択するときには、さまざまなBeanの異なる性質や機能を考慮してください。

Beanのタイプは、クライアントとのBeanの関係によって異なります。一部のBeanタイプは一連のプロセスを通じてクライアントに固定され、ある種の総合請負業者のように機能し、クライアントに対するサービスを取得して調整します。下請け業者のように機能するBeanタイプもあり、それらのBeanは複数のクライアント指向の総合請負業者Beanに同じ1つの機能を提供します。クライアント指向のbeanは、クライアント・セッションを通じてクライアントの対話やクライアント・プロセスと関連する他の情報を追跡します(「状態の保持」と呼ばれる機能)。複数のクライアント指向Beanにコモディティ・サービスを提供するBeanは、状態を保持しません。

以降の節では、各Beanタイプのクライアントとの対話や状態管理の特性を説明します。

注意:

各Beanタイプが適しているビジネス・プロセスの例を含む、各Beanタイプの基本的な概要については、「アプリケーションによるEJBの使い方」を参照してください。

セッションBeanの機能

セッションBeanは、サーバー内の1つのクライアントを表します。サーバーにデプロイされたアプリケーションにアクセスするために、クライアントはセッションBeanのメソッドを呼び出します。セッションBeanはクライアントの代わりに作業を実行し、サーバー内のタスクを実行してクライアントから複雑さを隠蔽します。

セッションBeanインスタンスにはクライアントが1つあります。セッションBeanは永続的ではありません。クライアントが終了すると、そのセッションBeanは終了したようになり、クライアントとの関連はなくなります。

セッションbeanはWebアプリケーションとエンティティbeanの間でfacadeとして使用して、複雑な対話を格納し、RMI呼出しを削減できます。クライアント・アプリケーションが直接リモートのエンティティBeanにアクセスする場合、各ゲッター・メソッドはリモート呼出しです。セッションFacade BeanはエンティティBeanにローカルでアクセスし、データを構造体に収集して、それを値で返すことができます。以降の節では、2種類のセッションBean、状態を保持するセッションBeanと状態を保持しないセッションBeanが説明されています。

ステートフル・セッションBean

ステートフル・セッションBeanは、密結合クライアントとの会話サービスをサポートしています。ステートフル・セッションBeanは、特定のクライアントのタスクを実行します。それは、クライアント・セッションの間状態を保持します。セッションが完了した後は、状態は維持されません。

ステートフル・セッションBeanはクライアント単位でインスタンス化され、急激に増加してリソースを消費する可能性があります。

ステートレス・セッションBean

ステートフル・セッションBeanと同じように、ステートレス・セッションBeanは特定のクライアントのタスクを実行します。ステートフル・セッションBeanとは違って、ステートレス・セッションBeanはクライアントの状態を保持しません。ステートレス・セッションBeanは、メソッド呼出しの間だけ状態を保持できます。メソッドが終了すると、状態は維持されなくなります。

メソッド呼出しの間を除いて、ステートレスBeanのインスタンスはすべて同じ機能であり、EJBコンテナはインスタンスをどのクライアント要求にでも割り当てることができます。ホーム・インタフェースでステートレスBeanが作成されると、Beanがデプロイされたどのサーバーにでも呼出しを転送できるレプリカ対応スタブが返されます。ステートレスBeanでは状態が保持されないので、スタブではBeanのホストであるどのサーバーにでも呼出しを転送できます。

ステートレスBeanはパフォーマンスとスケーラビリティを向上させる

ステートレス・セッションBeanは2次ストレージに書き込まれないので、ステートフル・セッションBeanよりもパフォーマンスが良くなります。

多数のクライアントが必要なアプリケーションの場合、ステートレス・セッションBeanはステートフル・セッションBeanよりも優れたスケーラビリティを実現します。

インスタンスを作成するシステムのオーバーヘッドは、ステートフル・セッションBeanよりもステートレス・セッションBeanの方が小さくなります。

- ステートレス・セッションBeanのインスタンスは、フリー・プールから取得することができます。

- ステートフル・セッションBeanのインスタンスはクライアントの要求でインスタンス化され、セッション・コンテキストを設定する必要があり、セッションの最後にガベージ・コレクションされる必要があります。

ステートフル・セッションBeanよりもステートレス・セッションBeanの方が、通常はより多くのクライアントをサポートできます。ステートレス・セッションBeanのインスタンスは1つのクライアント要求の間だけ確保されますが、ステートフル・セッションBeanはセッションが終わるまで確保されます。

必要なステートレス・セッションBeanインスタンスの数は通常はサーバーの実行キューのスレッド数とだいたい同じですが(数百)、必要なステートフル・セッションBeanインスタンスの数はアプリケーションのクライアント数により密接に対応します(一部のアプリケーションでは数十万になります)。

ステートレス・セッションBeanをWebサービスとしてエクスポーズする

このリリースのWebLogic Serverでは、Webサービス・エンドポイント・インタフェースを使用してステートレス・セッションBeanをWebサービスとして公開できます。詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』を参照してください。

エンティティBeanの機能

エンティティBeanは、永続ストレージ・メカニズム内のビジネス・オブジェクトを表します。ビジネス・オブジェクトの例としては、顧客、注文、製品などがあります。Java EE SDKでは、永続ストレージ・メカニズムはリレーショナル・データベースです。通常、各エンティティBeanはリレーショナル・データベースに基底の表を持ち、Beanの各インスタンスはその表の行に対応します。

エンティティBeanの主な特長

エンティティBeanの主な特長は以下のとおりです。

- 永続性 - エンティティBeanの永続性は、EJBコンテナまたはそのBean自体で管理できます。Beanでコンテナ管理による永続性が使用される場合、EJBコンテナは自動的に必要なデータベース・アクセス呼出しを生成します。エンティティBeanに記述したコードには、それらの呼出しは含まれません。Bean管理による永続性の場合は、データベース・アクセス・コードを記述してそれをBeanに含める必要があります。

- 共有アクセス: そのライフサイクルを通じて、エンティティBeanのインスタンスでは複数のクライアントをサポートできます(ただし同時ではありません)。複数のクライアントが同じデータを変更する場合があるので、エンティティBeanがトランザクション内で機能することが重要です。通常、EJBコンテナはトランザクション管理を提供します。この場合は、トランザクションの管理方法を決めるトランザクション属性をBeanのejb-jar.xmlファイルで指定します。Beanでトランザクションの境界をコード化する必要はありません。コンテナが境界を設定します。トランザクション管理については、「トランザクションの設計と管理のオプション」を参照してください。

- 主キー - 各エンティティBeanには、ユニークなオブジェクト識別子があります。たとえば顧客エンティティBeanは、顧客番号で識別される場合があります。ユニークな識別子(主キー)により、クライアントは特定のエンティティBeanを見つけることができます。詳細については、「コンテナ管理による関係(CMR)の使用」を参照してください。

- 関係 - リレーショナル・データベースの表のように、エンティティBeanは他のエンティティBeanと関連することがあります。Bean管理による永続性を使用するエンティティBeanとコンテナ管理による永続性を使用するエンティティBeanでは、関係の実装方法が異なります。Bean管理による永続性の場合は、記述するコードで関係を実装します。コンテナ管理による永続性の場合は、EJBコンテナが関係を処理します。このため、コンテナ管理による永続性を使用するエンティティBeanの関係はコンテナ管理による関係と呼ばれることもあります。詳細については、「CMRのエンティティのカスケード削除の使用」を参照してください。

読み書き対応エンティティBeanと読取り専用エンティティBean

WebLogic Serverは、読み書き対応と読取り専用の2種類のエンティティBeanをサポートしています。

読取り専用Beanは、データベースからデータが読み込まれる回数が減るので読み書き対応Beanよりもパフォーマンスが優れています。

一部のアプリケーションでは、読み書き対応エンティティBeanの使用が必須です。どちらを使用するかは、更新の頻度とデータ一貫性の要件によって決まります。表3-1に、主なガイドラインを示します。

表3-1 読み書き対応エンティティBeanと読取り専用エンティティBeanの比較

アプリケーション要件

読み書き対応エンティティBeanを選択する場合

読取り専用エンティティBeanを選択する場合

更新の頻度

アプリケーション・データが頻繁に更新されます。

例: リアルタイムの株価情報の提供

アプリケーション・データは頻繁には更新されないか、まったく更新されません。

例: 水着のカタログ

データの一貫性

アプリケーションで、データの更新時にトランザクション上一貫性のあるデータのスナップショットが必要となります。

例: 銀行口座の残高を更新するアプリケーション

データがある程度古くても許容できます(データが完全に最新である必要がありません)。

例: ニュースの提供。ユーザーはデータベースに入れられたらすぐにその記事を読みますが、その記事はトランザクションで更新されることはありません。

エンティティBeanのパフォーマンスとデータ一貫性の特徴

これらの項では、パフォーマンスとデータ一貫性の要件に基づいてエンティティBeanの実装を選択する手法について説明します。

古いデータで問題ない場合は読取り専用Beanでパフォーマンスを向上させる

古いデータが許容可能な場合は常に読取り専用エンティティBeanをお薦めします - それらは製品カタログや多くのアプリケーションの多くのコンテンツに適しています。主キーに基づく読込みは、タイマーに基づいて無効化されるローカル・エンティティ・キャッシュに対して実行されます。他の問合せは、データベースに対して行われます。読取り専用エンティティBeanは、トランザクショナル・エンティティより3 - 4倍高速です。

注意:

クライアントは読取り専用エンティティBeanでセッター・メソッドを正常に呼び出すことができますが、データが永続ストアに移動することはあり得ません。

高度なデータ一貫性には読み書き対応Beanを使用する

読み書き対応Beanは、顧客口座の保守など、高度なデータ一貫性が要求されるアプリケーションに適しています。読み書きはすべてデータベースで実行されます。

注意:

Bean管理による永続性を使用するエンティティBean、またはコンテナ管理による永続性を使用するEJB 1.1エンティティBeanの場合は、weblogic-ejb-jar.xmlでisModifiedメソッドを指定することでデータベースへの書込み回数を減らすことができます。

読取り専用Beanと読み書き対応Beanを組み合わせるとパフォーマンスが最適化される

read-mostlyアプリケーション(頻繁に読込みが行われ、更新はまれであるカタログなど)では、読取り専用Beanと読取り専用Beanを拡張する読み書き対応Beanの組み合わせが適しています。読取り専用Beanでは高速で一貫性の乏しい読込みが行われ、読み書き対応Beanでは一貫性の優れた書込みが行われます。

セッションFacadeを使用するとリモート・エンティティBeanのパフォーマンスが最適化される

リモート呼出しによるオーバーヘッドを回避するには、クライアントまたはサーブレットのコードからリモートEJBエンティティBeanにアクセスしないようにします。そのかわりに、セッションBean (Facadeと呼ばれる)を使用して複雑な対話を内包し、WebアプリケーションからRMIオブジェクトへの呼出しを削減します。クライアント・アプリケーションが直接リモートのエンティティBeanにアクセスする場合、各ゲッター・メソッドはリモート呼出しです。セッションFacade BeanはエンティティBeanにローカルでアクセスし、データを構造体に収集して、それを値で返すことができます。

Web層から直接ローカルのエンティティBeanインスタンスにアクセスすることに不都合な点はありません。むしろそうする方が、Facadeを使用するよりも適切です。

転送オブジェクトは使用しない

転送オブジェクト(値オプションやヘルパー・オブジェクトとも呼ばれる)は使用しないでください。転送オブジェクトは関連する属性をグループ化するEJB内のシリアライズ可能クラスで、リモート・ビジネス・メソッドの戻り値の型として使用される複合値を形成します。

パフォーマンスを最適化するためには、転送オブジェクトを使用するよりもローカル・エンティティ・インスタンスにアクセスする方が常に適切です。

メッセージドリブンBean

メッセージドリブンBean(MDB)とは、Java EEアプリケーションが非同期でメッセージを処理できるようにするエンタープライズBeanのことです。MDBは、JMSまたはJCAメッセージ・リスナー(イベントの代わりにメッセージを受信することを除いてイベント・リスナーと同様)として機能します。メッセージは、任意のJava EEコンポーネント(アプリケーション・クライアント、別のエンタープライズBeanまたはWebコンポーネント)、あるいはJava EE以外のアプリケーションから送信されます。

『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』を参照してください。

永続性管理の選択肢

永続性管理の方式は、エンティティBeanのデータベース・アクセスがどのように実行されるのかを決めます。

エンティティBeanの永続性管理方式(コンテナ管理またはBean管理)はejb-jar.xmlのpersistence-type要素で構成します。

注意:

weblogic-ejb-jar.xmlのpersistence-use要素では、コンテナ管理による永続性を使用するエンティティBeanのサード・パーティ永続性サービスの使用を指定できます。

生産性と移植性が必要な場合はコンテナ管理による永続性(CMP)を使用する

CMP Beanは、すべてのデータベース対話についてEJBコンテナに依存します。Beanは、データベースにアクセスするコードを持ちません。その代わりに、EJBコンテナが、weblogic-cmp-jar.xmlにあるエンティティBeanの永続フィールドと関係についての情報に基づいてデータベース・アクセス・メソッドを生成します。詳細については、「weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス」を参照してください。

CMP Beanは、データベース・アクセスにEJB QLを使用します。「EJB問合せ言語(EJB-QL)とWebLogic Server」を参照してください。

コンテナ管理による永続性のメリットは以下のとおりです。

- プログラミングの労力の削減 - CMP Beanのためにデータベース・アクセスを実行するメソッドを記述する必要がありません。EJBコンテナが自動的にそのためのメソッドを生成します。

- 移植性の向上 - CMPは、以下の点でBeanの移植性を向上させます。

- 物理データベースの細部をビジネス・ロジックから切り離すことで、Beanが論理的に関連データベースから独立します。修正したデータベース設計を実装するか、別のデータベース・サーバーに変更する場合でも、Beanコードを修正する必要がありません。

- Beanのコードを修正したり再コンパイルすることなく、Beanを別のJava EEアプリケーション・サーバーに再デプロイできます。

注意:

ターゲット・アプリケーション・サーバーでサポートされていない機能を使用するBeanを再デプロイする場合は、Beanのコードを修正することが必要な場合もあります。

CMPエンティティでサポートされる機能の詳細については、「エンティティEJB」を参照してください。

Bean管理による永続性(BMP)は必要なときだけ使用する

それ自身の永続性を管理するBeanには、データ・アクセスを実行するメソッドが必要です。

BMPは推奨されていません。CMPは、「生産性と移植性が必要な場合はコンテナ管理による永続性(CMP)を使用する」で説明されているようにBean管理による永続性より多くのメリットを提供します。

ただし、一部のアプリケーションの要件はCMP Beanでは満たすことができません。たとえば、以下の場合はBMPを使用する必要があります。

- アプリケーションでSQLストアド・プロシージャの既存のライブラリを使用する必要があります。

- ターゲット・データベースでJDBCがサポートされていません。

- Beanとデータベース表の間のマッピングが複雑です。たとえば、Beanは主キーを共有しない複数の表にマッピングされます。

トランザクションの設計と管理のオプション

トランザクションとは、ディスク上、メモリー内、またはデータベース内にあるアプリケーションの状態を変更する作業の1単位であり、一度開始されると最後まで完了するか、あるいは一切何も行われません。

トランザクションの境界設定方式とパフォーマンスについて

トランザクションは、EJBコンテナ、Beanコード、またはクライアント・コードによって境界設定(開始およびコミットまたはロールバックでの終了)することができます。

サーバー・レベルでのトランザクションの境界設定が最も効率的

トランザクションは、コストのかかるアプリケーション・リソースです(特にデータベース・トランザクション)。その理由は、トランザクションが終わるまでネットワーク接続が確保されるからです。データベース層、アプリケーション・サーバー層、およびWeb層のある多層アーキテクチャでは、ネットワーク・トラフィックの「往復」を減らしてパフォーマンスを最適化します。最適なアプローチは、EJBコンテナでアプリケーション・サーバー・レベルでトランザクションを開始および停止することです。

コンテナ管理によるトランザクションは開発が簡単でパフォーマンスに優れている

コンテナ管理によるトランザクション(CMT)は、セッション、エンティティ、およびメッセージドリブンのすべてのBeanタイプでサポートされています。ンテナ管理によるトランザクションは優れたパフォーマンスを実現し、開発を容易にします。その理由は、エンタープライズBeanのコードにトランザクションを開始および終了する文が含まれないからです。

CMT Beanの各メソッドは、1つのトランザクションと関連付けることができますが、必ずしもその必要はありません。コンテナ管理によるトランザクションでは、EJBコンテナが開始、停止、コミット、およびロールバックを含めてトランザクションを管理します。通常、コンテナはBeanのメソッドが開始される直前にトランザクションを開始し、メソッドが終了する直前にトランザクションをコミットします。

ejb-jar.xmlおよびweblogic-ejb-jar.xmlのトランザクション管理に関連する要素については、「コンテナ管理によるトランザクション要素」を参照してください。

ロールバック

トランザクションの途中で例外がスローされた場合、コンテナは自動的にトランザクションをロールバックします。トランザクションがシステム例外に基づくエラーの結果ロールバックされた場合を除いて、ロールバックされたコンテナ管理のトランザクションを自動的に再試行するように、EJBコンテナを構成できます。ロールバックは、Beanで明示的にプログラミングすることもできます。詳細は、第4章「Enterprise JavaBeansの実装」を参照してください。

トランザクション境界

メソッド呼出しを別の呼出しシナリオのエンタープライズBeanのビジネス・メソッドに委託したときにトランザクションの境界をEJBコンテナがどのように管理するかは、ejb-jar.xmlのtrans-attribute要素で管理します。

たとえば、トランザクションを呼び出すクライアントがそれ自体トランザクション内で動作している場合は、呼び出されたトランザクションのtrans-attribute要素によって、それが新しいトランザクションで動作するのか、呼出し側トランザクション内で動作するのかが決まります。

複数のBeanでのトランザクションの分散

1つのデータベース・トランザクションは、複数のサーバー・インスタンス上にある複数のBeanにまたがることができます。複数のBeanが関わるトランザクションの実装については、「複数のEJBで分散されるトランザクションのプログラミング」を参照してください。

コストのかかるオプション: 複数のデータベースでのトランザクションの分散

複数のデータ・ストアを更新するトランザクションは、論理単位としてコミットまたはロールバックする必要があります。2フェーズ・コミット・プロトコルを使用すると、複数のリソース・マネージャにまたがる1つのトランザクションを調整して、すべての参加データベースで更新がコミットされるか、すべてのデータベースで完全にロールバックされるようにすることができます。

2フェーズ・コミットはリソースを大量に消費します。トランザクションは複数のデータベースに分散しないようにしてください。

Beanレベルのトランザクション管理

Bean管理によるトランザクションでは、EJBのコードが開始、停止、コミット、およびロールバックを含めてトランザクションを管理します。Bean管理によるトランザクションは、すべてのセッションBeanおよびメッセージドリブンBeanでサポートされています。エンティティBeanでは、Bean管理によるトランザクションは使用できません。

注意:

Bean管理によるトランザクションでは、コンテナ提供のトランザクション管理機能は使用できません。Bean管理によるトランザクションとコンテナ管理によるトランザクションを同じBeanで組み合わせないでください。

Bean管理によるトランザクションを使用する場合

Bean管理によるトランザクションを使用せざるを得ない要件の例を以下に示します。

- 1つのメソッド呼出しで複数のトランザクションを定義する必要があります。コンテナ管理によるトランザクションの場合、メソッドは1つのトランザクションとしか関連付けることができません。Bean管理によるトランザクションを使用すると、1つのメソッドで複数のトランザクションを定義できます。ただし、そのメソッドを複数のメソッドに分割し、それぞれが専用のコンテナ管理によるトランザクションを使用するようにして、Bean管理によるトランザクションが必要にならないようにしてください。

- 複数のEJBメソッド呼出しにまたがる1つのトランザクションを定義する必要があります。たとえば、あるメソッドを使用してトランザクションを開始し、別のメソッドでトランザクションをコミットまたはロールバックするステートフル・セッションEJBの場合です。
EJBオブジェクトの機能についての詳しい情報が必要になるため、このような動作は避けてください。ただし、どうしても必要な場合は、Bean管理によるトランザクションの調整を利用し、個々のメソッドに対するクライアントの呼出しを調整する必要があります。

Bean管理によるトランザクションを短くする

開発を簡略化し、信頼性を向上させるために、Bean管理によるトランザクションは適度に短くしてください。

Bean管理によるトランザクションの実装については、「Bean管理のトランザクションのプログラミング」を参照してください。

クライアント・レベルのトランザクション管理はコストがかかる

クライアント・アプリケーションでは、中断や予期せぬ終了が起こることがあります。クライアント・レベルでトランザクションを開始および停止する場合は、以下のリスクがあります。

- ユーザーのアクションを待つ間、中断の間、クライアント・アクティビティが再開されるまで、またはタイムアウトになるまでのネットワーク・リソースの消費

- トランザクションのタイムアウトまたは終了後にトランザクションをロールバックするための処理リソースとネットワーク・リソースの消費

決定的な理由がない限りは、クライアント・アプリケーションでトランザクションを管理しないでください。

トランザクションのアイソレーション: パフォーマンスとデータ一貫性の選択

トランザクションのアイソレーション・レベルとは、更新されたがコミットはされていないデータを他のトランザクションにエクスポーズする度合いのことです。コミットされていないデータへのアクセスを許可すると、パフォーマンスは向上しますが、不適切なデータが他のトランザクションに提供されるリスクが増します。

Bean管理によるトランザクションのアイソレーション・レベルは、BeanのJavaコードで設定します。手順については、「Bean管理のトランザクションのプログラミング」を参照してください。

コンテナ管理によるトランザクションのアイソレーション・レベルは、weblogic-ejb-jar.xmlのtransaction-isolation要素のisolation-level下位要素で設定します。WebLogic Serverは、この値を基底のデータベースに渡します。トランザクションの動作は、EJBのアイソレーション・レベル設定と、基底となる永続ストレージの同時実行性制御に依存します。

コンテナ管理トランザクションの分離レベルの設定については、『Oracle WebLogic Server JTAのプログラミング』を参照してください。

WebLogic Server EJBでアプリケーションの要件を満たす

WebLogic Serverは、アプリケーションの要件を満たすために構成できる、エンタープライズBeanのさまざまな付加価値機能を提供します。それらの機能の詳細については、「WebLogic ServerのEJBの付加価値機能」を参照してください。

表3-2に、アプリケーションの要件と、それらを満たすために使用できる設計方式およびWebLogic Serverの機能を示します。

表3-2 機能と設計パターン

設計の目的

検討する設計パターンとWebLogic Serverの機能

可用性と信頼性

- クラスタ化されたEJBのフェイルオーバーは信頼性を向上させる

- クラスタ化されたEJBのロード・バランシングはスケーラビリティを向上させる

スケーラビリティ

- ステートレスBeanはパフォーマンスとスケーラビリティを向上させる

データの一貫性

- 生産性と移植性が必要な場合はコンテナ管理による永続性(CMP)を使用する

- 高度なデータ一貫性には読み書き対応Beanを使用する

- トランザクションのアイソレーション: パフォーマンスとデータ一貫性の選択

- Bean管理によるトランザクションを短くする

開発者と管理者の生産性

- 生産性と移植性が必要な場合はコンテナ管理による永続性(CMP)を使用する

- コンテナ管理によるトランザクションは開発が簡単でパフォーマンスに優れている

パフォーマンス

Beanタイプと設計パターンの選択

- 読取り専用Beanと読み書き対応Beanを組み合わせるとパフォーマンスが最適化される

- 古いデータで問題ない場合は読取り専用Beanでパフォーマンスを向上させる

- セッションFacadeを使用するとリモート・エンティティBeanのパフォーマンスが最適化される

- 転送オブジェクトは使用しない

- ステートレスBeanはパフォーマンスとスケーラビリティを向上させる

クラスタ化機能

- クラスタ化されたEJBのロード・バランシングはスケーラビリティを向上させる

プールとキャッシング

- WebLogic Server EJBのパフォーマンス拡張機能

トランザクション管理

- コンテナ管理によるトランザクションは開発が簡単でパフォーマンスに優れている

- サーバー・レベルでのトランザクションの境界設定が最も効率的

- トランザクションのアイソレーション: パフォーマンスとデータ一貫性の選択

- コストのかかるオプション: 複数のデータベースでのトランザクションの分散

- Bean管理によるトランザクションを短くする

4 Enterprise JavaBeansの実装

この章では、EJBの実装プロセスを説明し、EJBをWebLogic Serverで実行する方法について説明します。

この章は、WebLogic ServerのEJBの付加価値機能を理解し、アプリケーションの設計パターンをすでに選択しており、主要な設計上の決定をすでに行っている読者を対象としています。

WebLogic Server EJBの機能の概要については、「WebLogic ServerのEJBの付加価値機能」を参照してください。

EJBの設計オプション、設計の過程で考慮する要素、およびお薦めの設計パターンについては、「Enterprise JavaBeansの設計」を参照してください。

- EJB開発プロセスの概要

- ソース・ディレクトリを作成する

- EJBのクラスとインタフェースを作成する

- EJBタイマー・サービスのプログラミング

- Webサービスの参照の宣言

- Javaソースをコンパイルする

- デプロイメント記述子を生成する

- デプロイメント記述子を編集する

- EJBラッパー・クラスとスタブおよびスケルトン・ファイルを生成する

- パッケージ化する

- デプロイする

- 開発時に問題を解決する

- EJBを開発するためのWebLogic Serverツール

EJB開発プロセスの概要

この節では、EJB開発プロセスを簡単に説明します。主な実装タスクと関連する結果について説明します。

図4-1に、EJBの開発プロセスを示します。プロセスの手順、および各手順の結果については、表4-1を参照してください。以下の節では、各手順について詳しく説明します。

図4-1 EJB開発プロセスの概要

「図4-1 EJB開発プロセスの概要」の説明

表4-1 EJB開発タスクと結果

ステップ

説明

結果

ソース・ディレクトリを作成する

ソース・ファイル、デプロイメント記述子、および実装の過程で生成されるファイルのディレクトリ構造を作成します。

ローカル・ドライブ上のディレクトリ構造

EJBのクラスとインタフェースを作成する

Beanを構成するクラスを作成します。適切なタグをソース・コードに挿入して、これ以降の実装プロセスでのデプロイメント記述子要素の自動生成を有効にします。

各クラスの.javaファイル

Javaソースをコンパイルする

ソース・コードをコンパイルします。

各クラスの.classファイル

デプロイメント記述子を生成する

Beanの実行時の動作と環境を構成するデプロイメント記述子を記述または生成します。

ejb-jar.xmlとオプションとして以下のもの

- weblogic-ejb-jar.xml (WebLogic Server固有の機能を制御する要素が格納されます)

- weblogic-cmp-jar.xml (Beanがコンテナ管理による永続性エンティティBeanである場合)

デプロイメント記述子を編集する

Beanの目的の実行時動作がすべて正しく反映されるように、デプロイメント記述子の編集が必要な場合もあります。

Beanが使用するオプションの機能を指定するマークアップがソース全体に記述され、EJBGenを使用してデプロイメント記述子を自動的に生成する場合、デプロイメント記述子の編集は最小限にする必要があります。

- ejb-jar.xml

- weblogic-ejb-jar.xml (WebLogic Server固有の機能を制御する要素が格納されます)

- weblogic-cmp-jar.xml (Beanがコンテナ管理による永続性エンティティBeanである場合)

EJBラッパー・クラスとスタブおよびスケルトン・ファイルを生成する

ホーム・インタフェースやリモート・インタフェースのクラスを含む、デプロイメント・ユニットにアクセスするためのコンテナ・クラスを生成します。

生成されたクラスはアーカイブまたはディレクトリに追加されます。

パッケージ化する

コンパイル済みファイル、生成ファイル、およびデプロイメント記述子をデプロイメント用にパッケージ化します。

状況によっては、ファイルをアーカイブせずにディレクトリ形式で展開しておくことも可能です。

アーカイブ(JARまたはEAR)

デプロイする

選択したステージング・モードに従って、アーカイブまたはアプリケーション・ディレクトリのターゲットとして目的の管理対象サーバーまたはWebLogic Serverクラスタを設定します。

Beanのデプロイメント設定は、config.xmlのEJBComponent要素に書き込まれます。

ソース・ディレクトリを作成する

EJBをアセンブルするソース・ディレクトリを作成します。

ソース・ファイルと出力ファイルを並列ディレクトリ構造に分離する分割開発ディレクトリ構造をお薦めします。分割ディレクトリ構造を準備し、EJBをエンタープライズ・アプリケーション・アーカイブ(EAR)としてパッケージ化する方法については、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリ構造の概要に関する項を参照してください。

EJBをJARファイルにパッケージ化してデプロイする場合は、クラス・ファイルのディレクトリと、デプロイメント記述子ファイル用のMETA-INFというサブディレクトリを作成します。

例4-1 JARをパッケージ化するためのディレクトリ構造

myEJB/
META-INF/
ejb-jar.xml
weblogic-ejb-jar.xml
weblogic-cmp-jar.xml
foo.class
fooHome.class
fooBean.class

EJBのクラスとインタフェースを作成する

必要なクラスは、開発するEJBのタイプによって異なります(「EJBの構成要素」を参照)。

クラス・ファイルおよびインタフェース・ファイルを開発するための生産性の高いツールが用意されています。EJBGenコマンド・ライン・ユーティリティはクラス・ファイルとインタフェース・ファイルの作成プロセスを自動化するとともに、EJBのデプロイメント記述子ファイルも生成します。これらのツールの詳細と使い方については、「EJBGenリファレンス」を参照してください。

以降の節では、WebLogic Server固有のEJB機能を使用する上でのヒントとガイドラインを示します。

WebLogic Serverの汎用的なBeanテンプレートの使い方

WebLogic Serverでは、各EJBタイプについて、ほとんどのEJBで必要なJavaコールバック(リスナー)が含まれる汎用クラスが提供されます。それらの汎用クラスは、weblogic.ejb パッケージにあります。

- GenericEnterpriseBean

- GenericEntityBean

- GenericMessageDrivenBean

- GenericSessionBean

汎用Beanテンプレートは、その汎用クラスを作成中のクラスにインポートすることで独自のクラスで実装できます。次の例では、GenericSessionBeanクラスがHelloWorldEJBにインポートされます。

import weblogic.ejb.GenericSessionBean;
...
public class HelloWorldEJB extends GenericSessionBean {

クライアントによるEJBへのアクセスのプログラミング

以降の節では、EJBに対するクライアント・アクセスをプログラミングするためのガイドラインを示します。

クライアントによる初期コンテキストの取得のプログラミング

ローカル・クライアントは、次の抜粋のようなgetInitialContextメソッドを使用して初期コンテキストを取得します。

例4-2 ルックアップを実行するローカル・クライアント

...
Context ctx = getInitialContexLt("t3://localhost:7001", "user1", "user1Password");
...
static Context getInitialContext(String url, String user, String password) {
Properties h = new Properties();
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, url);
h.put(Context.SECURITY_PRINCIPAL, user);
h.put(Context.SECURITY_CREDENTIALS, password);

return new InitialContext(h);
}

リモート・クライアントは、WebLogic Server InitialContextファクトリからInitialContextを取得します。

クライアントによるホーム・インタフェースのルックアップのプログラミング

クライアントは、次の2つの方法のいずれかでエンティティBeanのホーム・インタフェースをルックアップできます。

- EJB参照に従います。Java Naming and Directory Interfaceから直接ホーム・インタフェースをルックアップする方法であり、もう1つの方法よりパフォーマンスがよく、Oracleのベスト・プラクティスです。EJB参照の使い方については、次節「EJBリンクの使用」を参照してください。

- Java Naming and Directory Interface (JNDI)から直接。コンテナが、グローバルなサーバー側のJNDIネームスペースでエンティティBeanのホーム・インタフェースをバインドします。手順については、『Oracle WebLogic Server JNDIのプログラミング』を参照してください。

EJBリンクの使用

EJBリンクの使用はOracleのベスト・プラクティスであり、WebLogic ServerはEJB 2.1仕様で定義されているEJBリンクを完全にサポートしています。アプリケーション・コンポーネント内でEJB参照を宣言し、これを同じJava EEアプリケーション内で宣言されたエンタープライズBeanにリンクさせることができます。

ejb-jar.xmlファイルで、参照元アプリケーション・コンポーネントのejb-ref要素のejb-link要素を使用してEJBへのリンクを指定します。ejb-linkの値は、参照先EJBのejb-jar.xmlとweblogic-ejb-jar.xml両方のejb-nameの値と同じでなければなりません。参照先のEJBは、参照元アプリケーション・コンポーネントと同じJava EEアプリケーションのEJB JARファイルのどれかに含まれていると考えられます。

ejb-nameはEJB JARファイル間で必ずしもユニークでなくてもよいため、そのリンクの絶対パスを与える必要があるかもしれません。次の構文を使って、同じJava EEアプリケーション内のEJBへのパス名を与えます。

<ejb-link>../products/product.jar#ProductEJB</ejb-link>

この参照では参照先のEJBが含まれるEJB JARファイルのパス名を与え、「#」でパス名と区別して参照先Beanのejb-nameを追加します。このパス名は、参照元のアプリケーション・コンポーネントJARファイルからの相対パスです。

URLに要求を送信するようにEJBを構成する

EJBがjava.net.URLリソース・マネージャ接続ファクトリ・タイプを使用して外部HTTPサーバーとのHttpURLConnectionを開くようにするには、URLまたはURLに対応するJNDIツリーでバインドされたオブジェクトをejb-jar.xmlのresource-ref要素およびweblogic-ejb-jar.xmlのres-ref-name要素を使用して指定します。

URLによるHTTPリソースの指定

EJBが要求を送信するURLを指定するには、次の手順に従います。

1. ejb-jar.xmlのresource-ref要素の<jndi-name>要素でURLを指定します。

2. weblogic-ejb-jar.xmlのresource-description要素の<jndi-name>要素でURLを指定します。

<resource-description>
<res-ref-name>url/MyURL</res-ref-name>
<jndi-name>http://www.rediff.com/</jndi-name>
</resource-description>

WebLogic Serverは指定されたjndi-nameでURLオブジェクトを作成し、そのオブジェクトをjava:comp/envにバインドします。

JNDI名によるHTTPリソースの指定

URLを指定する代わりに、JNDIでバインドされ、URLに対応するオブジェクトを指定するには、次のようにします。

1. ejb-jar.xmlのresource-ref要素の<jndi-name>要素で、URLがJNDIでバインドされている名前を指定します。

2. 次のように、weblogic-ejb-jar.xmlのresource-description要素の<jndi-name>要素で、URLがJNDIでバインドされている名前を指定します。

<resource-description>
<res-ref-name>url/MyURL1</res-ref-name>
<jndi-name>firstName</jndi-name>
</resource-description>

firstNameは、URLに対応するJNDIツリーにバインドされたオブジェクトです。このバインディングは、起動クラスで行うこともできます。jndi-nameが有効なURLでない場合、WebLogic ServerはそれをURLに対応し、すでにJNDIツリーにバインドされているオブジェクトとして取り扱い、LinkRefとそのjndi-nameをバインドします。

BeanコードからのHTTPリソースへのアクセス

HTTPリソースの指定方法(URLかURLに対応するJNDI名か)に関係なく、次のようにしてEJBのコードからそのHTTPリソースにアクセスできます。

URL url = (URL) context.lookup("java:comp/env/url/MyURL");
connection = (HttpURLConnection)url.openConnection();

EJBのネットワーク通信の構成

EJBが通信に使用するネットワーク接続の属性は、カスタム・ネットワーク・チャネルを構成してEJBに割り当てることによって設定できます。WebLogic Serverのネットワーク・チャネルとそれに関連する構成手順については、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください。カスタム・チャネルを構成したら、weblogic-ejb-jar.xmlのnetwork-access-point要素を使用してEJBに割り当てます。

トランザクションのプログラミングと構成

トランザクションの設計上の決定事項については、「トランザクションの設計と管理のオプション」に説明されています。以降の節では、トランザクションをプログラミングするためのガイドラインを示します。

トランザクションをエンティティBeanと使用することについては、「ejbLoad()とejbStore()の動作について」を参照してください。

コンテナ管理によるトランザクションのプログラミング

コンテナ管理によるトランザクションは、Bean管理によるトランザクションよりもプログラミングが簡単です。その理由は、境界設定(トランザクションの開始と停止)がEJBコンテナで行われるからです。

トランザクション動作は、ejb-jar.xmlおよびweblogic-ejb-jar.xmlで構成します。関連情報については、「コンテナ管理によるトランザクション要素」を参照してください。

コンテナ管理によるトランザクションの主なプログラミング・ガイドラインは以下のとおりです。

- トランザクション境界の保持 - コンテナが設定したトランザクションの境界に干渉するメソッドは呼び出さないでください。以下のメソッドは使用しないでください。

- java.sql.Connectionのcommit、setAutoCommit、およびrollbackメソッド

- javax.ejb.EJBContextのgetUserTransactionメソッド

- javax.transaction.UserTransactionのすべてのメソッド

- トランザクションの明示的なロールバック - 明示的にコンテナがコンテナ管理によるトランザクションをロールバックするようにするには、EJBContextインタフェースのsetRollbackOnlyメソッドを呼び出します。Beanからアプリケーション例外が送出される場合(通常はEJBException)、ロールバックは自動的に行われます。

- シリアライゼーション問題の回避 - 多くのデータ・ストアでは、シリアライゼーションに関する問題の検出は、単一ユーザー接続の場合でさえ制限されています。そのような場合は、weblogic-ejb-jar.xmlのtransaction-isolationがTransactionSerializableに設定されていても、同じ行でクライアント間に競合が発生した場合はEJBクライアントで例外またはロールバックが発生する場合があります。そのような例外を回避するために、以下のことができます。

- SQL例外を捕捉して(たとえばトランザクションをやり直すなどして)適切に解決するコードをクライアント・アプリケーションに含める

- Oracleデータベースの場合は、「isolation-level」で説明されているトランザクションのアイソレーション設定を使用する

コンテナ管理トランザクションの自動的な再試行の構成

このリリースのWebLogic Serverでは、トランザクションを開始したビジネス・メソッドが、システム例外に関連のないトランザクション・ロールバックが原因で失敗した場合、EJBコンテナが新しいトランザクションを開始し、失敗したメソッドを指定された回数まで再試行するように指定できます。メソッドの失敗が指定された再試行回数に達した場合、EJBコンテナは例外を送出します。

注意:

EJBコンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。

コンテナ管理によるトランザクションの自動的な再試行を構成するには、次の手順に従います。

1. 使用するBeanがコンテナ管理によるセッションBeanまたはエンティティBeanであることを確認します。
コンテナ管理によるセッションBeanおよびエンティティBeanの場合にのみ、コンテナ管理によるトランザクションの自動再試行を構成できます。メッセージドリブンBeanの場合は、コンテナ管理によるトランザクションの自動再試行を構成できません。MDBは、メッセージの受信を含むトランザクションがロールバックされたときに、そのメッセージの受信の確認応答を行わないため、メッセージは確認応答が行われるまで自動的に再試行されます。また、タイマーBeanの場合も、コンテナ管理によるトランザクションの自動再試行は構成できません。タイマーBeanのejbTimeoutメソッドが開始されてロールバックされると、タイムアウトが常に再試行されるからです。

2. トランザクションの自動再試行を構成する場合、対象となるビジネス・メソッドは、Beanのリモートまたはローカル・インタフェースの内部か、またはホーム・インタフェースのホーム・メソッド(特定のBeanインスタンスに固有ではないローカル・ホーム・ビジネス・ロジック)として定義されている必要があります。メソッドには、以下のコンテナ管理トランザクション属性の1つが設定されていなければなりません。

- RequiresNew。メソッドのトランザクション属性(ejb-jar.xmlのtrans-attribute要素)がRequiresNewの場合、メソッドの呼出し前に常に新しいトランザクションが開始され、構成されている場合、そのトランザクションが失敗すると自動再試行が行われます。

- Required。メソッドのトランザクション属性(ejb-jar.xmlのtrans-attribute要素)がRequiredの場合、メソッドが新しいトランザクションで再試行されるのは、失敗したトランザクションがそのメソッドのために開始された場合のみです。

詳細については、以下を参照してください。

- プログラミング・インタフェースについては、「EJBのクラスとインタフェースを作成する」を参照してください。

- ejb-jar.xmlのtrans-attribute要素については、「コンテナ管理によるトランザクション要素」のtrans-attributeを参照してください。

3. トランザクションの自動再試行を有効にする場合、対象となるメソッドは再呼出しできなければなりません。失敗したメソッドの再試行によって得られる結果は、直前の再試行が成功した場合に得られる結果と同じでなければなりません。特に、以下の場合です。

- メソッドの呼出しによって呼出しチェーンが開始された場合、そのメソッドを再試行するときは呼出しチェーン全体を再呼び出しするのが安全です。

- メソッドのすべてのパラメータを再利用できなければなりません。メソッドが再試行される場合、そのメソッドは失敗したメソッドを呼び出すために使用されたパラメータで再試行されます。一般に、再利用できるパラメータは、プリミティブ、不変オブジェクト、または読取り専用オブジェクトの参照です。パラメータがメソッドによって変更されるオブジェクトの参照である場合、メソッドの再呼出しによってメソッド呼出しの結果に悪影響が生じてはなりません。

- 再試行されるメソッドを保持するBeanがステートフル・セッションBeanである場合、そのBeanの対話状態は再呼出し時に失われてはなりません。ステートフル・セッションBeanの状態はトランザクション対応ではなく、トランザクションのロールバック中に復元できないので、トランザクションの自動再試行の機能を使用する場合、Beanの状態がロールバック後も有効であることを確認しておく必要があります。

4. EJBコンテナがどのメソッドのトランザクションを自動的に再試行するか、およびその回数は、weblogic-ejb-jar.xmlのretry-methods-on-rollback要素で指定します。
retry-methods-on-rollbackのretry-count下位要素は、管理コンソールからも変更できます。

Bean管理のトランザクションのプログラミング

この節では、Bean管理によるトランザクションのプログラミング上の考慮事項を示します。Beanレベルのトランザクションの特徴的な機能の概要や関連する設計上の考慮事項の説明については、「Beanレベルのトランザクション管理」を参照してください。

- トランザクションの境界設定 - EJBまたはクライアント・コードにトランザクション境界を定義するには、Java Transaction Service (JTS)またはJDBCデータベース接続を取得する前に、UserTransactionオブジェクトを取得してトランザクションを開始しなければなりません。UserTransactionオブジェクトを取得するには、次のコマンドを使用します。

ctx.lookup("javax.transaction.UserTransaction");

UserTransactionオブジェクトを取得した後は、tx.begin()、tx.commit()、tx.rollback()でトランザクションの境界を指定します。

データベース接続を取得してからトランザクションを開始した場合、その接続は新しいトランザクションと何の関連性も持たず、以後のトランザクション・コンテキストにその接続を「入れる」ためのセマンティクスも存在しません。JTS接続がトランザクション・コンテキストに関連付けられていない場合、JTS接続はautocommitをtrueに設定した標準のJDBC接続と同じように動作し、更新はデータ・ストアに自動的にコミットされます。

いったんトランザクション・コンテキスト内にデータベース接続が作成されると、その接続はトランザクションがコミットまたはロールバックされるまで確保されます。パフォーマンスとスループットを最適化するには、トランザクションを迅速に完了させることによって、データベース接続を解放し、他のクライアント要求が使用できるようにする必要があります。

注意:

アクティブなトランザクション・コンテキストには単一のデータベース接続しか関連付けることができません。

- トランザクション・アイソレーション・レベルの設定 - Bean管理によるトランザクションでは、アイソレーション・レベルはBeanコードで定義します。有効なアイソレーション・レベルは、java.sql.Connectionインタフェースで定義されます。各アイソレーション・レベルの詳細については、「isolation-level」を参照してください。
サンプル・コードについては、例4-3を参照してください。

例4-3 BMTでのトランザクション・アイソレーション・レベルの設定

import javax.transaction.Transaction;
import java.sql.Connection
import weblogic.transaction.TxHelper:
import weblogic.transaction.Transaction;
import weblogic.transaction.TxConstants;
User Transaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
//Begin user transaction
tx.begin();
//Set transaction isolation level to TransactionReadCommitted
Transaction tx = TxHelper.getTransaction();
tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
(Connection.TransactionReadCommitted));
//perform transaction work
tx.commit();

- 制限されたメソッドの回避 - Bean管理によるトランザクションでは、EJBContextインタフェースのgetRollbackOnlyメソッドとsetRollbackOnlyメソッドは呼び出さないでください。これらのメソッドは、コンテナ管理によるトランザクションのみで使用します。Bean管理によるトランザクションでは、UserTransactionインタフェースのgetStatusメソッドとrollbackメソッドを呼び出します。

- アクティブなトランザクション・コンテキストにつき1つの接続の使用 - アクティブなトランザクション・コンテキストに関連付けることができるのは、1つのデータベース接続だけです。

複数のEJBで分散されるトランザクションのプログラミング

この節では、複数のBean (複数のサーバー・インスタンスに存在する場合もある)にトランザクションを分散させる2つのアプローチを説明します。

クライアントのトランザクション・コンテキストから複数のEJBを呼び出す

次の断片的なコードは、UserTransactionオブジェクトを取得し、それを使用してトランザクションを開始およびコミットするクライアント・アプリケーションから引用したものです。クライアントは、トランザクションのコンテキストの中で2つのEJBを呼び出します。

import javax.transaction.*;
...
u = (UserTransaction) jndiContext.lookup("javax.transaction.UserTransaction");
u.begin();
account1.withdraw(100);
account2.deposit(100);
u.commit();
...

account1とaccount2のBeanで実行される更新は、1つのUserTransactionのコンテキスト内で行われます。同じサーバー・インスタンス上にあるか、異なるサーバー・インスタンスにあるか、またはWebLogic Serverクラスタにあるのかに関係なく、EJBは1つの論理単位として一緒にコミットまたはロールバックされます。

1つのトランザクション・コンテキストから呼び出されるEJBはすべて、クライアント・トランザクションをサポートしている必要があります。つまり、ejb-jar.xmlの各Beanのtrans-attribute要素が、Required、Supports、またはMandatoryに設定されている必要があります。

EJB「ラッパー」を使用してEJB間トランザクションをカプセル化する

トランザクションをカプセル化する「ラッパー」EJBを使用できます。クライアントはラッパーEJBを呼び出して銀行振替などのアクションを実行し、ラッパーは新しいトランザクションを開始して、トランザクションの処理を実行する1つまたは複数のEJBを呼び出します。

ラッパーEJBは、他のEJBを呼び出す前にトランザクション・コンテキストを明示的に取得できます。あるいは、ejb-jar.xmlでラッパーのtrans-attribute要素がRequiredまたはRequiresNewに設定されている場合、WebLogic Serverは新しいトランザクション・コンテキストを自動的に作成できます。

ラッパーEJBによって呼び出されるすべてのEJBは、そのラッパーEJBのトランザクション・コンテキストをサポートしている必要があります。つまり、そのtrans-attribute要素がRequired、Supports、またはMandatoryに設定されていなければなりません。

EJBタイマー・サービスのプログラミング

WebLogic Serverは、EJB 2.1仕様とEJB 3.0仕様で定義されているEJBタイマー・サービスをサポートしています。EJBタイマー・サービスはEJBコンテナによって提供されるサービスです。このサービスを使用すると、タイマー・オブジェクトが期限切れになったときに発生するコールバックをスケジューリングするタイマーを作成できます。タイマー・オブジェクトは、エンティティBean、メッセージドリブンBean、およびステートレス・セッションBean用に作成できます。タイマー・オブジェクトは、指定した時間、指定した期間の経過後、または指定した間隔で期限切れになります。たとえば、タイマー・サービスを使用して、EJBが一定期間にわたって特定の状態のままであるときに通知を送信できます。

WebLogic EJBタイマー・サービスは、大まかなタイマー・サービスとして使用するように設計されています。大量のタイマー・オブジェクトを使用してデータ・セットに対して同じタスクを実行するより、少数のタイマーを使用して大量のタスクを実行することをお薦めします。たとえば、従業員の経費レポートを表すEJBがあるとします。各経費レポートは、マネージャの承認を受けてから処理されなければなりません。この場合、1つのEJBタイマーを使用してすべての未決の経費レポートを定期的に検査し、担当のマネージャに対して、承認待ちのレポートを決裁するように促す電子メールを送信できます。

クラスタ化されたEJBタイマー・サービスとローカルEJBタイマー・サービス

EJBタイマー・サービスは、2つのタイプ(クラスタまたはローカル)を構成することができます。

クラスタ化されたEJBタイマー・サービス

クラスタ化されたEJBタイマー・サービスには、次の利点があります。

- 可視性に優れています。
クラスタ内のすべてのノードからタイマーにアクセスできます。たとえば、javax.ejb.TimerService.getTimers()メソッドを使用すると、EJBに対して作成されたクラスタに含まれるすべてのステートレス・セッションBeanタイマーまたはメッセージドリブンBeanタイマーの完全なリストが返されます。エンティティBeanの主キーをgetTimers()メソッドに渡すと、そのエンティティBeanのタイマーのリストが返されます。

- 自動ロード・バランシングおよびフェイルオーバー
クラスタ化されたEJBタイマー・サービスは、ジョブ・スケジューラのロード・バランシング機能とフェイルオーバー機能を利用できます。

クラスタ化されたEJBタイマー・サービスの構成については、「クラスタ化されたEJBタイマーの構成」を参照してください。

ローカルEJBタイマー・サービス

ローカルEJBタイマー・サービスは、ローカルEJBタイマー・サービスが作成されたサーバー上でのみ実行され、そのサーバー上のBeanにしか認識されません。ローカルEJBタイマー・サービスを使用する場合、クラスタ化されたEJBタイマー・サービスとは異なり、クラスタ、データベース、JDBCデータ・ソース、またはリース・サービスを構成する必要はありません。

ローカルEJBタイマー・オブジェクトは、別のサーバーに移行できません。タイマー・オブジェクトは、サーバー全体の一部としてのみ移行できます。EJBタイマーが存在するサーバーが何らかの理由でダウンした場合、サーバーを再起動するか、またはサーバー全体を移行しなければタイマーを実行できません。

Javaプログラミング・インタフェースを使用してタイマー・オブジェクトをプログラミングする

この節では、EJB 2.1仕様に定義されている、タイマーのプログラミングに使用できるJavaプログラミング・インタフェースについて説明します。これらのインタフェースの詳細については、EJB 2.1仕様を参照してください。また、この節では、WebLogic Server固有のタイマー関連インタフェースについて詳しく説明します。

EJB 2.1タイマー関連プログラミング・インタフェース

次の表に、タイマーのプログラミングに使用できるEJB 2.1インタフェースを示します。

表4-2 EJB 2.1タイマー関連プログラミング・インタフェース

プログラミング・インタフェース

説明

javax.ejb.TimedObject

タイマー・コールバックのためにタイマー・サービスに登録されるBeanのエンタープライズBeanクラスによって実装されます。このインタフェースは、単一のメソッド、ejbTimeoutを備えています。

EJBContext

getTimerServiceメソッドを使用してタイマー・サービスにアクセスします。

javax.ejb.TimerService

EJBの新しいEJBタイマーを作成するか、既存のEJBタイマーにアクセスします。

javax.ejb.Timer

特定のEJBタイマーに関する情報にアクセスします。

javax.ejb.TimerHandle

永続化できるシリアライズ可能なタイマー・ハンドルを定義します。タイマーはローカル・オブジェクトなので、TimerHandleはBeanのリモート・インタフェースまたはWebサービス・インタフェースを介して渡してはなりません。

EJB 2.1のタイマー関連プログラミング・インタフェースの詳細については、EJB 2.1仕様を参照してください。

WebLogic Server固有のタイマー関連インタフェース

タイマーのプログラミングに使用できるWebLogic Server固有のインタフェースは以下のとおりです。

- weblogic.management.runtime.EJBTimerRuntimeMBean。特定のEJBHomeのタイマーの実行時情報と管理機能を提供します。例4-4にweblogic.management.runtime.EJBTimerRuntimeMBeanインタフェースを示します。

例4-4 weblogic.management.runtime.EJBTimerRuntimeMBeanインタフェース

public interface weblogic.management.runtime.EJBTimerRuntimeMBean {
public int getTimeoutCount(); // get the number of successful timeout notifications that have been made
public int getActiveTimerCount(); // get the number of active timers for this EJBHome
public int getCancelledTimerCount(); // get the number of timers that have been cancelled for this EJBHome
public int getDisabledTimerCount(); // get the number of timers temporarily disabled for this EJBHome
public void activateDisabledTimers(); // activate any temporarily disabled timers
}

- weblogic.ejb.WLTimerServiceインタフェース。javax.ejb.TimerServiceインタフェースの拡張です。このインタフェースを使用すると、タイマーに関するWebLogic Server固有の構成情報を指定できます。例4-5にweblogic.ejb.WLTimerServiceインタフェースを示します。javax.ejb.TimerServiceの詳細は、EJB 2.1仕様を参照してください。

注意:

weblogic.ejb.WLTimerServiceインタフェースは、クラスタ化されたEJBタイマー・サービスではサポートされません(「クラスタ化されたEJBタイマーの構成」を参照)。

例4-5 weblogic.ejb.WLTimerServiceインタフェース

public interface WLTimerService extends TimerService {
public Timer createTimer(Date initial, long duration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(Date expiration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(long initial, long duration, Serializable info
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(long duration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
}

- weblogic.ejb.WLTimerInfoインタフェース。weblogic.ejb.WLTimerServiceインタフェースで使用され、タイマーに関するWebLogic Server固有の構成情報を渡します。例4-6にweblogic.ejb.WLTimerInfoインタフェースを示します。

注意:

weblogic.ejb.WLTimerServiceインタフェースは、クラスタ化されたEJBタイマー・サービスではサポートされません(「クラスタ化されたEJBタイマーの構成」を参照)。

例4-6 weblogic.ejb.WLTimerInfoインタフェース

public final interface WLTimerInfo {
public static int REMOVE_TIMER_ACTION  = 1;
public static int DISABLE_TIMER_ACTION = 2;
public static int SKIP_TIMEOUT_ACTION  = 3;
/**
* Sets the maximum number of retry attempts that will be
* performed for this timer.  If all retry attempts
* are unsuccesful, the timeout failure action will
* be executed.
*/
public void setMaxRetryAttempts(int retries);
public int getMaxRetryAttempts();
/**
* Sets the number of milliseconds that should elapse
* before any retry attempts are made.
*/
public void setRetryDelay(long millis);
public long getRetryDelay();
/**
* Sets the maximum number of timeouts that can occur
* for this timer.  After the specified number of
* timeouts have occurred successfully, the timer
* will be removed.
*/
public void setMaxTimeouts(int max);
public int getMaxTimeouts();
/**
* Sets the action the container will take when ejbTimeout
* and all retry attempts fail.  The REMOVE_TIMER_ACTION,
* DISABLE_TIMER_ACTION, and SKIP_TIMEOUT_ACTION fields
* of this interface define the possible values.
*/
public void setTimeoutFailureAction(int action);
public int getTimeoutFailureAction();
}

- weblogic.ejb.WLTimerインタフェース。javax.ejb.Timerインタフェースの拡張であり、タイマーの現在の状態に関する追加情報を提供します。例4-7にweblogic.ejb.WLTimerインタフェースを示します。

注意:

weblogic.ejb.WLTimerServiceインタフェースは、クラスタ化されたEJBタイマー・サービスではサポートされません(「クラスタ化されたEJBタイマーの構成」を参照)。

例4-7 weblogic.ejb.WLTimerインタフェース

public interface WLTimer extends Timer {
public int getRetryAttemptCount();
public int getMaximumRetryAttempts();
public int getCompletedTimeoutCount();
}

タイマー・デプロイメント記述子

タイマーに関連するデプロイメント記述子の要素は以下のとおりです。

表4-3 タイマー・デプロイメント記述子

要素

説明

timer-descriptor

EJBタイマー・オブジェクト。

timer-implementation

EJBタイマー・サービスのクラスタ化の有無。クラスタ化されたEJBタイマー・サービスについては、「クラスタ化されたEJBタイマーの構成」を参照してください。

persistent-store-logical-name

WebLogic Serverがタイマー・オブジェクトを格納する、サーバーのファイル・システム上の永続ストアの名前。

これらの要素の詳細については、「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」を参照してください。

クラスタ化されたEJBタイマーの構成

注意:

クラスタ化されたEJBタイマーの利点については、「クラスタ化されたEJBタイマー・サービスとローカルEJBタイマー・サービス」を参照してください。

EJBタイマーのクラスタ化を構成するには、次の手順に従います。

1. 以下について構成したかどうかを確認します。

- クラスタ化ドメイン。詳細は、『Oracle WebLogic Serverクラスタの使用』のWebLogicクラスタの設定に関する項を参照してください。

- ジョブ・スケジューラの以下の機能。

- HAデータベース(Oracle、DB2、Informix、MySQL、Sybase、MSSQLなど)。

- config.xmlファイルの<data-source-for-job-scheduler>要素を使用してHAデータベースにマップされているJDBCデータ・ソース。

- リース・サービス。デフォルトでは、データベース・リースが使用され、config.xmlファイルの<data-source-for-job-scheduler>要素によって定義されたJDBCデータ・ソースが使用されます。

ジョブ・スケジューラの構成については、『Oracle WebLogic Server Timer and Work Manager API (CommonJ)プログラマーズ・ガイド』を参照してください。

2. クラスタ化EJBタイマー・サービスを有効にするために、weblogic-ejb-jar.xmlデプロイメント記述子のtimer-implementation要素をClusteredに設定します。

<timer-implementation>Clustered</timer-implementation>

詳細は、「timer-implementation」を参照してください。

クラスタ化されたEJBタイマー・サービスでは、以下のように動作が変更されることに注意してください。

- weblogic.ejb.WLTimer*インタフェースは、クラスタ化されたEJBタイマー・サービスではサポートされません。

- createTimer()メソッドを使用してクラスタ化されたEJBタイマーを新しく作成する場合、タイマーの初期セット・アップ時にタイムアウトの実行が遅延する場合があります。

- ジョブ・スケジューラでは、「少なくとも1回」の実行が保証されます。クラスタ化されたEJBタイマーが期限切れになった場合、データベースはリスナー・コールバック・メソッドが完了するまで更新されません。データベースが更新される前にサーバーがクラッシュした場合、タイマーはもう一度実行されます。

- クラスタ化されたEJBタイマー・サービスでは、障害が発生した場合に実行するアクションに関するタイマーの構成オプションは使用できません。これらの構成オプションには、再試行の遅延、再試行の最大数、タイムアウトの最大数、およびタイムアウト・エラー・アクションがあります。

- ジョブ・スケジューラは、期限切れになるタイマーを識別するために30秒ごとにデータベースに対して問合せを実行します。30秒未満の間隔でタイマーの実行が遅延する場合があります。

- 障害が発生した場合、トランザクション対応のタイマーのみ再試行されます。

- タイマー実行の固定間隔スケジューリングはサポートされません。

Webサービスの参照の宣言

このリリースのWebLogic Serverは、外部のWebサービスの宣言およびアクセスに関するEJB 2.1の要件を満たしています。Webサービスの参照をEJBのデプロイメント記述子で宣言することによって、Webサービスの論理名が実際のWebサービス・インタフェースにマップされます。これにより、論理名を使用してWebサービスを参照できるようになります。さらに、BeanコードはWebサービスの参照名を使用してJNDIルックアップを実行します。

詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』を参照してください。

Javaソースをコンパイルする

コンパイル・プロセスをサポートしているツールを確認するには、表4-1を参照してください。

コンパイル・プロセスについては、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。

デプロイメント記述子を生成する

Beanのクラス・ファイルにJDK 1.5のアノテーションを追加すると、EJBGenを使用してEJBアプリケーションのリモート・クラス、ホーム・クラス、およびデプロイメント記述子ファイルを生成できます。

デプロイメント記述子の生成には、EJBGenを使用することをお薦めします。詳細については、「EJBGenリファレンス」を参照してください。

デプロイメント記述子を編集する

ejb-jar.xml、weblogic-ejb-jar.xml、およびweblogic-cmp-jar.xml (コンテナ管理による永続性エンティティBeanの場合)の要素は、アプリケーションの実行時の特性を制御します。

記述子要素を修正する必要がある場合は、任意のテキスト・エディタを使用して記述子ファイルを編集できます。ただし、エラーを防止するために、XML編集用に設計されたツールを使用してください。WebLogic Server管理コンソールで編集できる記述子要素については、表4-1を参照してください。

以下の節では、WebLogic Server固有のデプロイメント要素を簡単に参照できます。各節では、特定のタイプの機能または動作に関連する要素が取り上げられています。各節の表では、制御する動作、関連するBeanタイプ(Beanタイプ固有の場合)、その要素が含まれるweblogic-ejb-jar.xmlの親要素、およびweblogic-ejb-jar.xmlで明示的に指定しない場合に予想される動作に基づいて関連要素が定義されています。

- セキュリティ要素

- リソース・マッピング要素

- 永続性要素

- クラスタ化要素

- データの一貫性要素

- コンテナ管理によるトランザクション要素

- パフォーマンス要素

- ネットワーク通信要素

各記述子ファイルの要素、定義、および使用例の包括的なドキュメントについては、以下を参照してください。

- weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス

- weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス

- ejb-jar.xmlの要素に関するSunのドキュメント

注意:

以降の節では、「要素」列の要素名をクリックすると、その要素の詳しい説明が表示されます。

セキュリティ要素

この表は、セキュリティに関連するweblogic-ejb-jar.xmlの要素を示しています。

表4-4 weblogic-ejb-jar.xmlのセキュリティ要素

要素

説明

デフォルト値

security-role-assignment

ejb-jar.xmlファイルのセキュリティ・ロールをWebLogic Serverのセキュリティ・プリンシパルの名前にマッピングします。

ejb-jar.xmlがアプリケーション・ロールを定義する場合に必須。

なし

security-permission

このEJBに付与される追加のJavaセキュリティ権限。

なし

run-as-principal-name

ejb-jar.xmlでsecurity-identity run-as-role-nameを指定したBeanのrun-asプリンシパルとして使用されるセキュリティ・プリンシパル名。

なし

iiop-security-descriptor

RMI-IIOPプロトコルを使用するBeanのセキュリティ・オプション。

なし

リソース・マッピング要素

この表は、ソース・コードで使用されるBeanまたはリソースの名前をデプロイメント環境のJNDI名にマッピングするweblogic-ejb-jar.xmlの要素を示しています。

表4-5 weblogic-ejb-jar.xmlのリソース・マッピング要素

要素

Beanタイプ

説明

デフォルト値

jndi-name

すべて

WebLogic Serverのリソースまたは参照のJNDI名。

注意 : JNDI名をBeanに割り当てるのは推奨されません。グローバルJNDI名は、クラスタ化サーバーの起動時に大量のマルチキャスト・トラフィックを引き起こします。より適切なプラクティスについては、「EJBリンクの使用」を参照してください。

なし

local-jndi-name

すべて

Beanのローカル・ホームのJNDI名。Beanがリモート・ホームとローカル・ホームを持つ場合は、それぞれのホームに1つずつのJNDI名を指定する必要があります。

なし

concurrency-strategy

MDB

キューおよびトピックの作成にBeanが使用するJMS接続ファクトリのJNDI名。

weblogic.jms.Message.DrivenBeanConnectionFactory

destination-jndi-name

MDB

JNDIツリーでメッセージドリブンBeanとキューまたはトピックを関連付けるJNDI名。

なし

initial-context-factory

MDB

接続ファクトリの作成にEJBコンテナが使用する初期コンテキスト・ファクトリ。

weblogic.jndi.WLInitial.Context.Factory

jms-client-id

MDB

恒久サブスクライバ・トピックと関連付けられたメッセージドリブンBeanのクライアントID。

ejb-nameの値

message-destination-descriptor

MDB

ejb-jar.xmlファイル内のメッセージ宛先の参照を、WebLogic Serverの実際のメッセージ宛先(JMSキュー、トピックなど)にマップします。

なし

provider-url

MDB

InitialContextで使用されるURLプロバイダを指定します。

t3://localhost:7001

永続性要素

この表は、Beanの状態がどのように保持されるのかを指定するweblogic-ejb-jar.xmlの要素を示しています。

表4-6 weblogic-ejb-jar.xmlの永続性要素

要素

Beanタイプ

説明

デフォルト値

type-identifier

エンティティ

EJBの永続性タイプを指定します。WebLogic Server RDBMSベースの永続性では、WebLogic_CMP_RDBMSという識別子を使用します。

なし

type-storage

エンティティ

この永続性タイプのデータを格納するファイルのパスを、EJBのデプロイメントJARファイルまたはデプロイメント・ディレクトリの最上位を基準にして定義します。

WebLogic Server RDBMSベースの永続性では通常、Beanの永続性データを格納するのにweblogic-cmp-jar.xmlというXMLファイルを使用します。このファイルは、JARファイルのMETA-INFサブディレクトリにあります。

なし

type-version

エンティティ

type-identifierで指定された永続性タイプのバージョン。WebLogic 2.0 CMPの永続性の場合は、値2.0を使用します。

WebLogic 1.1 CMPの永続性の場合は、値1.1を使用します。

なし

delay-updates-until-end-of-tx

エンティティ

trueの場合、EJBコンテナはトランザクションが終わるまでBeanの状態の更新をデータベースに書き込むのを遅らせようとします。ただしコンテナは、問合せのinclude-updates要素(weblogic-cmp-jar.xmlのweblogic-query要素)がtrueの場合はEJBファインダまたはselect問合せを実行する前にデータベースに更新をフラッシュします。

コンテナ管理による永続性BeanとBean管理による永続性Beanの両方に適用可能。

True

finders-load-bean

エンティティ

finderまたはejbSelectメソッドで返されたBeanがメソッドの復帰前に直ちにキャッシュにロードされるようにします。

注意: コンテナ管理による永続性Beanでのみ適用可能。

True

persistent-store-dir

ステートフル・セッション

パッシブ化されたステートフル・セッションBeanのインスタンスの状態が格納されるディレクトリ。

pstore

is-modified-method-name

エンティティ

Beanが変更されていて、その変更をデータベースに書き込む必要があるかどうかを判断するためにコンテナから呼び出されるメソッド。

Bean管理による永続性BeanまたはEJB 1.1コンテナ管理による永続性Beanに適用されます。

指定しないと、Beanの状態は各メソッドの完了後に保持されることになります。

クラスタ化要素

この表は、クラスタ化に関連するweblogic-ejb-jar.xmlの要素を示しています。これらの要素は、WebLogic Serverクラスタのクラスタ化されたBeanのフェイルオーバーおよびロード・バランシング動作を制御します。

表4-7 weblogic-ejb-jar.xmlのクラスタ化要素

要素

Beanタイプ

説明

デフォルト値

home-call-router-class-name

ステートフル・セッション

ステートレス・セッション

エンティティ

ホーム・メソッド呼出しのルーティングに使用するカスタム・クラス。このクラスはweblogic.rmi.extensions.CallRouter()を実装する必要があります。

なし

home-is-clusterable

ステートフル・セッション

ステートレス・セッション

エンティティ

Beanのホームがクラスタ化できるかどうかを示します。

True

home-load-algorithm

ステートフル・セッション

ステートレス・セッション

エンティティ

Beanホームのレプリカ間でロード・バランシングを行うためのアルゴリズム。

weblogic.cluster.defaultLoadAlgorithmの値

idempotent-methods

ステートレス・セッション

エンティティ

クラスタ化されたEJBの多重呼出し不変メソッド。多重呼出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができます。

ステートレス・セッションBeanのホームおよび読取り専用エンティティBeanインスタンスのメソッドは、明示的に指定する必要はありません。それらのメソッドは自動的に多重呼出し不変として設定されます。

なし

replication-type

ステートフル・セッション

クラスタのステートフル・セッションBeanに使用するレプリケーションを示す(in-memoryまたはnone)。

none

stateless-bean-call-router-class-name

ステートレス・セッション

Beanメソッド呼出しのルーティングに使用するカスタム・クラス。

なし

stateless-bean-is-clusterable

ステートレス・セッション

Beanがクラスタ化できるかどうかを示します。

ejb-jar.xmlでsession-typeがStatelessになっているセッションBeanでのみ使用します。

True

stateless-bean-load-algorithm

ステートレス・セッション

Beanのレプリカ間でロード・バランシングを行うためのアルゴリズム。

weblogic.cluster.defaultLoadAlgorithmプロパティの値

use-serverside-stubs

ステートレス・セッション

Beanホームがサーバー・コンテキストでサーバー・サイド・スタブを使用するようにします。

False

データの一貫性要素

この表は、Beanインスタンスのデータとデータベースの一貫性に関連するweblogic-ejb-jar.xmlの要素を示しています。これらの要素は、Beanインスタンスの値を反映して、いつどのようにデータベースが更新されるのかなどの動作を制御します。

注意:

コンテナ管理による永続性に関連する要素については、「エンティティBeanのプールとキャッシュの管理」を参照してください。

表4-8 weblogic-ejb-jar.xmlのデータ一貫性要素

要素

Beanタイプ

説明

デフォルト値

concurrency-strategy

エンティティ

エンティティBeanへの同時アクセスがどのように管理されるのか。

データベース

invalidation-target

エンティティ

このコンテナ管理による永続性エンティティBeanが変更されたときに無効化する読取り専用エンティティBean。

注意 : EJB 2.x CMP Beanにのみ適用できます。

なし

delay-updates-until-end-of-tx

エンティティ

trueの場合、EJBコンテナはトランザクションが終わるまでBeanの状態の更新をデータベースに書き込むのを遅らせようとします。ただしコンテナは、問合せのinclude-updates要素(weblogic-cmp-jar.xmlのweblogic-query要素)がtrueの場合はEJBファインダまたはselect問合せを実行する前にデータベースに更新をフラッシュします。

コンテナ管理による永続性BeanとBean管理による永続性Beanの両方に適用可能。

True

コンテナ管理によるトランザクション要素

表4-9は、コンテナ管理によるトランザクションに関連するejb-jar.xmlの要素を示しています。

表4-9 ejb-jar.xmlのコンテナ管理によるトランザクション要素

要素

説明

デフォルト値

transaction-type

値はBeanまたはContainerのいずれか。

なし。EJB 2.xではこの属性の指定は必須となっています。

trans-attribute

メソッドの呼出しをエンタープライズBeanのビジネス・メソッドに委託するときにコンテナがトランザクションの境界をどのように管理するのかを指定します。有効な値は以下のとおりです:

- NotSupported
値がNotSupportedの場合、エンティティBeanが指定されていないトランザクションで実行されており、トランザクションが存在するとき、EJBコンテナはトランザクションを中断します。エンティティBeanが指定されていないトランザクションで実行され、トランザクションが存在しない場合、EJBコンテナはアクションを実行しません。

- Supports
値がSupportsの場合、エンティティBeanが指定されていないトランザクションで実行されており、トランザクションが存在するとき、EJBコンテナは現在のトランザクションを使用します。エンティティBeanが指定されていないトランザクションで実行され、トランザクションが存在しない場合、EJBコンテナはアクションを実行しません。

- Required

- RequiresNew

- Mandatory

- Never
値がNeverの場合、エンティティBeanが指定されていないトランザクションで実行されており、トランザクションが存在するとき、EJBコンテナは例外を送出します。エンティティBeanが指定されていないトランザクションで実行され、トランザクションが存在しない場合、EJBコンテナはアクションを実行しません。

注意 : 9.0より前のリリースのWebLogic Serverでは、EJBコンテナは、トランザクションが存在せず、trans-attributeの値がNotSupported、Supports、およびNeverの場合、新しいトランザクションを開始した。EJBコンテナを9.0より前のリリースのWebLogic Serverと同じように動作させて新しいトランザクションを作成する場合は、weblogic-ejb-jar.xmlのentity-always-uses-transactionをTrueに設定します。

クライアントはMDBの呼出しでトランザクション・コンテキストを提供しないので、コンテナ管理によるトランザクションを使用するMDBではtrans-attributeがRequiredでなければなりません。

指定しないと、EJBコンテナは警告を発し、MDBではNotSupported、それ以外のEJBではSupportsを使用します。

transaction-scope

この省略可能な要素は、エンタープライズBeanがそのメソッドで分散トランザクションを必須とするかどうか、またはローカル・トランザクションの最適化を使用できるかどうかを指定します。

値はLocalとDistributedのいずれか。

指定しない場合、コンテナは分散トランザクションが使用されなければならないものと想定します。

表4-10は、コンテナ管理によるトランザクションに関連するweblogic-ejb-jar.xmlの要素を示しています。

表4-10 weblogic-ejb-jar.xmlのコンテナ管理によるトランザクション要素

要素

説明

デフォルト値

retry-methods-on-rollback

ここで指定したメソッドに対して、EJBコンテナはロールバックされたコンテナ管理によるトランザクションを自動的に再試行します。

注意: この要素で指定されたメソッドに関わらず、EJBコンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。

なし

transaction-isolation

メソッドがトランザクションを開始するときに使用するトランザクション・アイソレーション・レベル。指定されたトランザクション・レベルは、メソッドが既存のトランザクションを継承する場合は使用されません。

基底のDBMSのデフォルト

trans-timeout-seconds

トランザクションの最長継続時間。

なし

パフォーマンス要素

この表は、パフォーマンスに関連するweblogic-ejb-jar.xmlの要素を示しています。

表4-11 weblogic-ejb-jar.xmlのパフォーマンス要素

要素

Beanタイプ

説明

デフォルト値

allow-concurrent-calls

ステートフル・セッション

Remote Exceptionが送出されることなく、複数のクライアントがBeanに同時にアクセスできるかどうか。

ステートフル・セッションBeanインスタンスによるメソッド呼出しの処理中に、同時に他のメソッド呼出しがサーバーに送信されたときに、サーバーはRemoteExceptionを送出します。

False

cache-between-transactions

エンティティ

コンテナがトランザクション間でエンティティBeanの永続データをキャッシュするようにします。

False

cache-type

ステートフル・セッション

ステートフル・セッションBeanがキャッシュから削除される順序。

NRU

(最近未使用)

clients-on-same-server

すべて

Beanのすべてのクライアントが同じサーバー・インスタンス上でそのBeanと連結されていることを示します。この要素は、EJBにグローバルJNDI名がある場合のみ使用します。trueに設定すると、JNDI名がレプリケートされません。

値をtrueにすると、大規模なクラスタで開始時間を短縮できます。

False

delay-updates-until-end-of-tx

エンティティ

trueの場合、EJBコンテナはトランザクションが終わるまでBeanの状態の更新をデータベースに書き込むのを遅らせようとします。

ただしコンテナは、問合せのinclude-updates要素(weblogic-cmp-jar.xmlのweblogic-query要素)がtrueの場合はEJBファインダまたはselect問合せを実行する前にデータベースに更新をフラッシュします。

コンテナ管理による永続性BeanとBean管理による永続性Beanの両方に適用可能。

True

dispatch-policy

すべて

Beanへの要求を処理するために使用するスレッド・プールを指定します。

なし

entity-cache-name

エンティティ

アプリケーション・レベルのエンティティ・キャッシュ。同じアプリケーションに属する複数のエンティティBeanのインスタンスをキャッシュできます。

注意: アプリケーション・レベルのキャッシュはweblogic-application.xmlで宣言します。

なし

estimated-bean-size

エンティティ

エンティティBeanのインスタンスの推定平均サイズ(バイト単位)。

なし

finders-load-bean

エンティティ

finderまたはejbSelectメソッドで返されたBeanがメソッドの復帰前に直ちにキャッシュにロードされるようにします。

注意: コンテナ管理による永続性Beanでのみ適用可能。

True

idle-timeout-seconds

エンティティ

Beanがパッシブ化されるまでの活動のない状態の秒数。

注意: この要素は現在は使われていません。

600

idle-timeout-seconds

ステートフル・セッション

Beanがパッシブ化されるまでの活動のない状態の秒数。

600

initial-beans-in-free-pool

エンティティ

メッセージドリブン

ステートレス・セッション

起動時にコンテナによってインスタンス化されるEJBのインスタンスの数。

0

is-modified-method-name

エンティティ

Beanの状態を変更するメソッド。このメソッドを指定すると、WebLogic serverはメソッドの完了時にBeanの状態を保持します。

注意 : Bean管理による永続性BeanまたはEJB 1.1コンテナ管理による永続性Beanに適用されます。

指定しないと、Beanの状態は各メソッドの完了後に保持されることになります。

jms-polling-interval-seconds

メッセージドリブン

アクセスできなくなっているJMS宛先にEJBコンテナが再接続しようとする試みの秒間隔。

10

max-beans-in-cache

エンティティ

ステートフル・セッション

キャッシュ内のインスタンスの最大数。

1000

max-beans-in-free-pool

エンティティ

ステートレス・セッション

メッセージドリブン

フリー・プールのインスタンスの最大数。

1000

read-timeout-seconds

エンティティ

読取り専用エンティティBeanでejbLoadを呼び出す間隔の秒数。read-timeout-seconds が0の場合、ejbLoadはBeanがキャッシュされた場合のみ呼び出されます。

600

ネットワーク通信要素

この表は、ネットワーク通信に関連するweblogic-ejb-jar.xmlの要素を示しています。

表4-12 weblogic-ejb-jar.xmlの通信要素

要素

Beanタイプ

説明

デフォルト値

network-access-point

すべて

EJBにカスタム・ネットワーク・チャネルを割り当てます。

なし

EJBラッパー・クラスとスタブおよびスケルトン・ファイルを生成する

コンテナ・クラスには、WebLogic Serverが使用するEJBの内部表現に加えて、クライアントが使用する外部インタフェース(ホーム、ローカル、またはリモート)の実装も格納されます。コンテナ・クラスを生成するには、Oracle Workshop for WebLogic Platformまたはappcを使用します。

コンテナ・クラスは、weblogic-ejb-jar.xmlの記述子要素に従って生成されます。たとえば、クラスタ化要素を指定すると、appcはデプロイメントで使用されるクラスタ対応クラスを作成します。appcは、必要なオプションと引数を指定することでコマンド・ラインから直接使用できます。詳細については、「appc」を参照してください。

次の図は、EARまたはJARファイルの作成時にデプロイメント・ユニットに追加されるコンテナ・クラスを示しています。

図4-2 EJBコンテナ・クラスの生成

「図4-2 EJBコンテナ・クラスの生成」の説明

appcと生成されたクラス名の衝突

まれなことではありますが、appcでクラス名を生成したとき、生成したクラス名の衝突に遭遇し、これがClassCastExceptionや他の例外を招くことがあります。これは、生成されるクラス名が、Beanクラス名、Beanクラス・パッケージ、そのBeanのejb-nameの3つのキーを基にしているためです。この問題が起こるのは、複数のJARファイルを含むEARファイルを使用し、その2つ以上のJARファイルのそれぞれにBeanクラス、パッケージ、または、クラス名を同じくするEJBが含まれ、双方のEJBがそれぞれのJARファイル内で同じejb-nameを持っている場合です。この問題が発生した場合は、いずれかのBeanのejb-nameをユニークなものに変更してください。

ejb-nameはファイル名の基となるキーの1つであり、ejb-nameはJARファイル内でユニークでなければならないので、同じJARファイルにある2つのEJB間ではこの問題は起きません。また、EARファイルではファイルごとに個別のクラスローダーになるため、別々のEARファイルに置かれた2つのEJB間でこの問題は起きません。

パッケージ化する

EJBをエンタープライズ・アプリケーションの一部としてパッケージ化することをお薦めします。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項を参照してください。

クライアントが他のアプリケーションにあるEJBのパッケージ化の考慮事項

WebLogic Serverでは、別のアプリケーションのプログラムに基づくクライアントがEJBへのアクセスに必要とするEJBクラスをパッケージ化するためのejb-client.jarファイルの使用がサポートされています。

Beanのejb-jar.xmlファイルのejb-client-jar要素でクライアントJARの名前を指定します。appcコンパイラを実行すると、EJBにアクセスするために必要なクラスを持つJARファイルが生成されます。

クライアントJARをリモート・クライアントからアクセスできるようにします。Webアプリケーションの場合は、ejb-client.jarを/libディレクトリに配置します。非Webクライアントの場合は、クライアントのクラスパスでejb-client.jarを指定します。

注意:

WebLogic Serverのクラスローディング動作は、クライアントがスタンドアロンかどうかによって異なります。ejb-client.jarにアクセスできるスタンドアロンのクライアントは、ネットワーク経由で必要なクラスをロードできます。ただし、セキュリティ上の理由から、サーバー・インスタンスで動作しているプログラムに基づくクライアントはネットワーク経由でクラスをロードすることはできません。

デプロイ

EJBをデプロイすると、WebLogic ServerはEJBのコンポーネントをクライアントに提供できるようになります。EJBは、ユーザーの環境とEJBが本番環境に置かれるかどうかに基づいて、複数の手順のうちの1つでデプロイできます。

WebLogic Serverアプリケーションおよびモジュール(EJBを含む)をデプロイする一般的な手順については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。EJB固有のデプロイメントの問題と手続きについては、このドキュメント『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』の第8章「Enterprise JavaBeansのデプロイメント・ガイドライン」を参照してください。

開発時に問題を解決する

以降の節では、デプロイしたEJBのチェックとデバッグに便利なWebLogic Serverの機能を説明します。

行番号をクラス・ファイルに追加する

appcでEJBをコンパイルする場合は、appc -lineNumbersコマンド・オプションを使用して、デバッグしやすいように生成したクラス・ファイルに行番号を追加できます。詳細については、「appcリファレンス」を参照してください。

データをモニターする

WebLogic Serverは、デプロイされたEJBの実行時の処理についてさまざまなデータを収集します。管理コンソールの「デプロイメント」ノードで表示できるこのデータは、EJBが目的の処理を完了しているかどうかを判断する上で便利です。EJBの実行時の統計を表示するには、管理コンソールで「デプロイメント」ノードを展開し、そのBeanが含まれているJAR EARを見つけて「モニター」タブを選択します。

参照できるデータについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のページを参照してください。

- 「デプロイメント:モニター: EJB :ステートフル」

- 「デプロイメント:モニター: EJB :ステートレス」

- 「デプロイメント:モニター: EJB :メッセージドリブン」

- 「デプロイメント:モニター: EJB :エンティティ」

デバッグ・メッセージを作成する

バグや問題のトラブルシューティングおよび解決に役立つメッセージをアプリケーションで作成する手順については、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。

EJBを開発するためのWebLogic Serverツール

この節では、EJB開発プロセスをサポートするOracleのツールについて説明します。各ツールの機能の比較については、表4-14を参照してください。

Oracle JDeveloper

Oracle JDeveloperは、EJBのエンドツーエンドの開発に使用できるフル機能のJava IDEです。詳細については、Oracle JDeveloperのオンライン・ヘルプを参照してください。JDeveloperのインストールについては、『Oracle Fusion Middleware Oracle JDeveloperインストレーション・ガイド』を参照してください。

Oracle Enterprise Pack for Eclipse

Oracle Enterprise Eclipse (OEPE) - WebLogic Webサービスの開発を容易にするEclipse IDEプラットフォームのプラグイン群を提供します。詳細については、Eclipse IDEプラットフォームのオンライン・ヘルプを参照してください。

管理コンソール

管理コンソールでは、多くのデプロイメント記述子要素について表示、修正、およびEJB内の記述子ファイルへの保持を行うことができます。記述子は、EJBの管理サーバー・コピー、ならびにEJBのすべてのデプロイされたコピー(デプロイ後)において、修正されます。記述子を修正した場合、変更はユーザーのEJBのオリジナル・コピー(デプロイ前)に対して行われます。

ただし、これらの記述子要素の更新は、EJBを再デプロイする必要なしに、実行時に動的に行われます。管理コンソールで変更できる記述子要素は、表4-13にまとめられているように、実行時に動的に変更できるものに限定されています。

表4-13 管理コンソールからアクセスできる記述子要素

EJBタイプ

編集可能な要素

エンティティ

- max-beans-in-cache

- max-beans-in-free-pool

- key-cache-size

- trans-timeout-seconds

- read-timeout-seconds (読取り専用エンティティBeanのみ)

メッセージドリブン

- max-beans-in-free-pool

- message-selector (http://www.java.sun.com/dtd/ejb-jar_2_0.dtdを参照)

- jms-polling-interval-seconds

- trans-timeout-seconds

ステートレス

- max-beans-in-free-pool

- trans-timeout-seconds

ステートフル

- max-beans-in-free-pool

- idle-timeout-seconds

- trans-timeout-seconds

javac

Java SE JDKに付属のjavacコンパイラは、javaコンパイル機能を提供します。javacの詳細は、http://www.oracle.com/technetwork/java/index-jsp-142903.html#documentationを参照してください。

EJBGen

EJBGenは、EJB 2.xのコード・ジェネレータです。Beanクラス・ファイルにjavadocタグでアノテーションを付けた後、EJBGenを使用してEJBアプリケーションのリモート・インタフェース・クラス、ホーム・インタフェース・クラス、および、デプロイメント記述子ファイルを生成することができるので、編集および管理すべきEJBファイルの数を1つに減らせます。

デプロイメント記述子の生成には、EJBGenの使用をお薦めします; これは、EJBの維持を容易化および簡略化できる、Oracleのベスト・プラクティスです。EJBGenを使用する場合、記述してアノテーションを付ける必要があるBeanクラスは1つだけです。そのため、記述、デバッグ、および維持が簡略化されます。開発環境としてOracle Workshop for WebLogic Platformを使用すると、EJBGenタグが自動挿入されます。

EJBGenの詳細については、「EJBGenリファレンス」を参照してください。

DDInit

DDInitは、WebLogic Serverアプリケーションのデプロイメント記述子を生成するためのユーティリティです。DDInitでは、クラス・ファイルからの情報に基づいてデプロイメント記述子ファイルを作成します。

『Oracle WebLogic Serverコマンド・リファレンス』のDDInitに関する項を参照してください。

WebLogic Server Antユーティリティ

WebLogic Serverには、スケルトン・デプロイメント記述子を作成するためのAntユーティリティが用意されています。

このAntタスクは、EJBを含むディレクトリを検証し、そのディレクトリの内容に基づいてデプロイメント記述子を作成します。Antユーティリティは、個別のEJBに必要な構成やマッピングに関する情報をすべて保持しているわけではないので、Antユーティリティによって作成されるスケルトン・デプロイメント記述子は不完全なものです。このユーティリティがスケルトン・デプロイメント記述子を作成した後で、テキスト・エディタやXMLエディタを使ってデプロイメント記述子を編集し、EJBの構成を完全なものにしてください。

詳細は、『Oracle WebLogic Serverアプリケーションの開発』のwldeployを使用したアプリケーションのデプロイに関する項を参照してください。

weblogic.Deployer

weblogic.Deployerコマンド・ライン・ツールは、WebLogic ServerデプロイメントAPIにコマンド・ライン・インタフェースを提供する、Javaベースの開発ツールです。このツールは、コマンド・ライン、シェル・スクリプト、またはJava以外の自動化された環境からデプロイメントを開始する必要がある管理者および開発者向けに開発されました。

『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerコマンドライン・リファレンスに関する項を参照してください。

appc

appcコンパイラは、EJBおよびJSPをWebLogic Serverにデプロイするのに必要なクラスを生成し、コンパイルします。それは、個別のモジュール・レベルとアプリケーション・レベルの両方で、現在の仕様に準拠しているかどうかデプロイメント記述子を検証します。アプリケーション・レベルのチェックでは、個別のモジュールに対するアプリケーション・レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。

注意:

appcは、非推奨のejbcユーティリティの後継ツールです。ejbcではなくappcを使用することをお薦めします。

「appcリファレンス」を参照してください。

DDConverter

DDConverterは、WebLogic Serverの旧リリースのデプロイメント記述子をアップグレードするコマンド・ライン・ツールです。最新のJava EE仕様とWebLogic Serverリリースの機能を活用するために、常にデプロイメント記述子をアップグレードすることをお薦めします。

weblogic.DDConverterを使用すると、デプロイメント記述子をアップグレードできます。weblogic.DDConverterの使い方については、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。

注意:

このリリースのWebLogic Serverでは、EJB固有のDDConverterであるweblogic.ejb20.utils.DDConverterは非推奨になっています。使用しているアプリケーションのデプロイメント記述子(EJB固有のデプロイメント記述子を含む)を変換するには、アプリケーション・レベルの新しいDDConverterであるweblogic.DDConverterを使用してください。

EJBツールの機能の比較

次の表はEJB開発のOracleツールと、各ツールの機能を示しています。可は、そのツールが対応する機能を備えていることを示します。

表4-14 EJBツールとその機能

EJBツール

インタフェースおよびホーム・インタフェースの生成

Javaコードのコンパイル

デプロイメント記述子を生成する

デプロイメント記述子の表示と編集

デプロイ

WebLogic Workshop

可

可

可

いいえ

可

appc

いいえ

可

いいえ

いいえ

いいえ

javac

いいえ

可

いいえ

いいえ

いいえ

EJBGen

可

いいえ

可

可

いいえ

DDInit

いいえ

いいえ

可

いいえ

いいえ

管理コンソール

いいえ

いいえ

いいえ

可

可

Deployer

いいえ

いいえ

いいえ

いいえ

可

DDConverter

いいえ

いいえ

可

いいえ

いいえ

5 セッションEJB

この章では、セッションBeanがEJBコンテナの中でどのように機能するのかを説明し、セッションBeanに固有の設計および開発ガイドラインも提供します。Bean開発の全体的なプロセスについては、「Enterprise JavaBeansの実装」を参照してください。

この章は、JavaのプログラミングおよびセッションBeanの機能に精通している読者を対象としています。セッションBeanの機能の概要およびセッションBeanのアプリケーションでの典型的な使用方法については、「セッションEJBによるビジネス・ロジックの実装」および「セッションBeanの機能」を参照してください。

以下の節では、セッションBeanのライフサイクル、設計上の考慮事項、および主要な実装タスクの手順について説明します。

- ステートレス・セッションBeanとステートフル・セッションBeanの比較

- ステートレス・セッションEJBのプール

- ステートフル・セッションEJBのキャッシュとパッシブ化

- セッションBeanの設計上の決定

- セッションBeanの実装

ステートレス・セッションBeanとステートフル・セッションBeanの比較

この節では、ステートレス・セッションBeanとステートフル・セッションBeanの主な違いについて説明します。

表5-1 ステートレス・セッションBeanとステートフル・セッションBeanの比較

ステートレス・セッションBean

ステートフル・セッションBean

必要になるたびにBeanを作成するオーバーヘッドを削減するためにメモリーにプールされます。WebLogic Serverは必要なときにBeanのインスタンスを使用し、処理が完了したらそれをプールに戻します。

ステートレス・セッションBeanは、ステートフルBeanよりも高速なパフォーマンスを提供します。

各クライアントはBeanの新しいインスタンスを作成し、最終的にそれを削除します。インスタンスは、キャッシュがいっぱいの場合はディスクにパッシブ化できます。

アプリケーションはejbRemove()を発行してBeanをキャッシュから削除します。

ステートフル・セッションBeanは、ステートレス・セッションBeanほどのパフォーマンスは発揮しません。

IDがなく、クライアントとの関連もありません。匿名です。

特定のクライアント・インスタンスにバインドされます。各Beanには暗黙のIDがあります。クライアントがセッション中にステートフル・セッションBeanと対話する場合、それは毎回同じオブジェクトに対して行われます。

持続しません。Beanに呼出し間の状態はありません。

持続します。ステートフル・セッションBeanの状態は、セッションが終わるまで保持されます。

どのタイプのセッションBeanをいつ使用するのかについては、「ステートレスBeanとステートフルBeanの選択」を参照してください。

ステートレス・セッションEJBのプール

デフォルトでは、WebLogic Serverには起動時にステートレス・セッションEJBインスタンスは存在しません。個々のBeanが呼び出されると、WebLogic ServerはEJBの新しいインスタンスを初期化します。

ただし、プロダクション環境では、WebLogic Serverは非バインド・ステートレス・セッションEJB (現在メソッド呼出しを処理していないインスタンス)のフリー・プールを使用することでステートレス・セッションEJBのパフォーマンスとスループットを向上させることができます。要求の処理に利用できる非バインド・インスタンスがある場合は、要求がインスタンスの作成を待つ必要がないので応答時間が向上します。フリー・プールは、できる限りオブジェクトの再利用やコンテナ・コールバックのスキップをすることでパフォーマンスを改善しています。

WebLogic Serverは起動時に、自動的にフリー・プールを作成し、weblogic-ejb-jar.xmlファイルのBeanのデプロイメント要素initial-beans-in-free-poolで指定された量のインスタンスをそのプールに配置します。デフォルトでは、initial-beans-in-free-poolは0に設定されています。

また、このリリースのWebLogic Serverでは、管理者は管理コンソールを使用してEJBプールを必要に応じて初期化できます。初期化されたEJBプールは、EJBがデプロイされた直後の状態にリセットされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBのアイドル状態Beanのキャッシュとプールの初期化に関する項を参照してください。

次の図に、WebLogic Serverのフリー・プールと、ステートレスEJBがフリー・プールに出入りするプロセスを示します。点線は、WebLogic Server側から見たEJBの「状態」を表しています。

図5-1 ステートレス・セッションEJBのライフサイクルを示すWebLogic Serverフリー・プール

「図5-1 ステートレス・セッションEJBのライフサイクルを示すWebLogic Serverフリー・プール」の説明

プールを構成した場合、WebLogic Serverはフリー・プールのEJBインスタンス(利用可能な場合)を利用してメソッド呼出しに対応します。EJBは、クライアントのメソッド呼出しの間アクティブ状態になります。メソッドが完了すると、EJBのインスタンスはフリー・プールに戻されます。WebLogic Serverは各メソッドの呼出し後にクライアントからステートレス・セッションBeanを非バインドするので、クライアントが使用する実際のBeanクラスは呼出しごとに異なります。

EJBクラスのすべてのインスタンスがアクティブで、max-beans-in-free-poolに達した場合、EJBクラスを要求する新しいクライアントは、アクティブEJBがメソッド呼出しを完了するまでブロックされます。トランザクションがタイムアウトになった場合(トランザクション非対応の呼出しでは、5分経過した場合)、WebLogic Serverは、リモート・クライアントに対してはRemoteExceptionを、ローカル・クライアントに対してはEJBExceptionを送出します。

注意:

フリー・プールの最大サイズは、max-beans-in-free-pool要素の値、使用可能メモリー、または実行スレッドの数によって制限されます。

WebLogic Serverを構成することによって、プール内のBeanインスタンスがpool要素のidle-timeout-seconds要素で指定した期間にわたって未使用であった場合にそのインスタンスを削除できます。idle-timeout-secondsで指定する期間にわたってプール内のBeanが未使用である場合、そのプール内のBeanはinitial-beans-in-free-poolで指定されている数まで削除されます。プール内のBeanの数は、initial-beans-in-free-poolで指定されている数より少なくなることはありません。

アプリケーションがフリー・プールのBeanインスタンスを要求した場合には、以下の3通りの結果が考えられます。

- インスタンスがプールにあります。WebLogic Serverはそのインスタンスを利用可能にし、アプリケーションは処理を進めます。

- 使用可能なインスタンスがプールにありませんが、使用中のインスタンス数はmax-beans-in-free-poolに達していません。WebLogic Serverは新しいBeanインスタンスを割り当てて、それを提供します。

- 使用可能なインスタンスがプールになく、使用中のインスタンス数がmax-beans-in-free-poolに達しています。トランザクションがタイムアウトになるか、プール内の既存のBeanインスタンスが使用可能になるまで待機する必要があります。

ステートフル・セッションEJBのキャッシュとパッシブ化

WebLogic Serverは、Beanインスタンスのキャッシュを使用してステートフル・セッションEJBのパフォーマンスを高めます。キャッシュはメモリー内にアクティブなEJBインスタンスを格納することで、それらをクライアント要求に即座に使用できるようにしています。キャッシュには、クライアントによって現在使用されているEJBと最近使われていたインスタンスが格納されます。キャッシュ内のステートフル・セッションBeanは、特定のクライアントと結び付いています。

次の図に、WebLogic Serverのキャッシュと、ステートフルEJBがキャッシュに出入りするプロセスを示します。

図5-2 ステートフル・セッションEJBのライフサイクル

「図5-2 ステートフル・セッションEJBのライフサイクル」の説明

ステートフル・セッションEJBの作成

WebLogic Serverには起動時にステートフル・セッションEJBインスタンスは存在しません。クライアントがステートフル・セッションBeanへのアクセスを開始する前に、Beanとのセッションで使用する新しいBeanインスタンスが作成されます。セッションが終了すると、インスタンスは破棄されます。セッションが進行中の間は、インスタンスはメモリーにキャッシュされます。

ステートフル・セッションEJBのパッシブ化

パッシブ化は、EJBの状態をディスク上で保持しつつキャッシュからそのEJBインスタンスを削除するためにWebLogic Serverが使用するプロセスです。パッシブ化されているEJBはメモリーには存在せず、キャッシュに格納されているときのようにクライアント要求に応じて即座に使用することはできません。

EJB開発者は、ejbPassivate()メソッドが呼び出されたときに、ステートフル・セッションBeanが、WebLogic Serverによってそのデータがシリアライズされてそのインスタンスのパッシブ化が行われるような状態に置かれるようにしなければなりません。パッシブ化の間、WebLogic Serverはtransientであると宣言されていないフィールドをシリアライズしようとします。つまり、すべての非transientフィールドがシリアライズ可能なオブジェクト(Beanのリモートまたはホーム・インタフェースなど)を表すようにしなければなりません。EJB 2.1では、許可されるフィールド・タイプが指定されています。

パッシブ化の制御

ステートフル・セッションBeanのパッシブ化を制御するルールは、Beanのcache-type要素の値によって決まります。この要素の値は以下のいずれかです。

- LRU - 最長時間未使用(積極的なパッシブ化)

- NRU - 最近未使用(怠惰なパッシブ化)

idle-timeout-seconds要素とmax-beans-in-cache要素も、cache-typeの値に基づいてパッシブ化と削除の動作に影響を与えます。

積極的なパッシブ化(LRU)

cache-typeをLRUに設定してステートフル・セッションBeanの積極的なパッシブ化を構成すると、コンテナは以下のようにしてインスタンスをディスクにパッシブ化します。

- max-beans-in-cacheの値に関係なく、インスタンスの非アクティブな状態がidle-timeout-secondsの期間を経過するとすぐ

- idle-timeout-secondsが経過していなくても、max-beans-in-cacheに達したとき

コンテナは、パッシブ化されたインスタンスを、そのパッシブ化後、idle-timeout-secondsの期間非アクティブな状態が続いた後にディスクから削除します。この動作は、怠惰な削除と呼ばれます。

注意:

idle-timeout-secondsに達すると削除されるBeanインスタンスでejbRemoveを呼び出すことはできません。

怠惰なパッシブ化(NRU)

cache-typeをNRUに設定して怠惰なパッシブ化を構成すると、関連するシステムのオーバーヘッドが原因でコンテナはBeanのパッシブ化を回避します(キャッシュに影響を与えるのは、Beanのパッシブ化または積極的な削除を引き起こすイベントのみとなります)。

キャッシュがいっぱいになり、Beanインスタンスをキャッシュから削除して別のインスタンス用のスペースを確保する場合、コンテナは次のようになります:

注意:

idle-timeout-secondsに達すると削除されるBeanインスタンスでejbRemoveを呼び出すことはできません。

- idle-timeout-secondsが経過したときにキャッシュからBeanのインスタンスを削除し、それをディスクにパッシブ化することはしません。この動作は、即時削除と呼ばれます。即時削除を行うと、アクティブでないインスタンスによってメモリーまたはディスクのリソースが消費されなくなります。

- idle-timeout-secondsの有効期限が切れない場合、Beanのインスタンスをディスクにパッシブ化します。

パッシブ化されたBeanの永続ストア・ディレクトリの指定

ステートフル・セッションBeanがパッシブ化されると、その状態がファイル・システムのディレクトリに格納されます。各サーバー・インスタンスには、パッシブ化されたステートフル・セッションbeanの状態を格納する専用のディレクトリ永続ストア・ディレクトリがあります。永続ストア・ディレクトリは、パッシブ化されたBeanごとに1つのサブディレクトリを格納します。

永続ストア・ディレクトリは、たとえば次のようにサーバー・インスタンスのディレクトリにデフォルトで作成されます。

D:\releases\<version>\bea\user_domains\mydomain\myserver\tmp\pstore\

永続ストアのパスは次のとおりです。

RootDirectory\ServerName\persistent-store-dir

各要素の説明は次のとおりです。

- RootDirectory - WebLogic Serverが動作するディレクトリ。
RootDirectoryは、-Dweblogic.RootDirectoryプロパティを使用してサーバーの起動時に指定できます。

- ServerName - サーバー・インスタンスの名前。

- persistent-store-dir - weblogic-ejb-jar.xmlの<stateful-session-descriptor>要素のpersistent-store-dir要素の値。<persistent-store-dir>の値が指定されていない場合、ディレクトリの名前はデフォルトでpstoreになります。

永続ストア・ディレクトリには、パッシブ化された各Bean用のサブディレクトリ(ハッシュ・コードで命名される)が格納されます。たとえば、上の例のパッシブ化されたBeanのサブディレクトリは次のようになります。

D:\releases\810\bea\user_domains\mydomain\myserver\pstore\14t89gex0m2fr

ステートフル・セッションBeanへの同時アクセスの構成

EJB 2.x仕様に従って、ステートフル・セッションEJBに同時アクセスするとRemoteExceptionが送出されます。ステートフル・セッションEJBに関するこのアクセス制限は、EJBクライアントがWebLogic Serverの内部にあるのかそれともリモートにあるのかに関係なく適用されます。この制限を無効にして、同時呼出しが可能なようにステートフル・セッションBeanを構成するには、allow-concurrent-callsデプロイメント要素を設定します。

複数のサーブレット・クラスがステートフル・セッションEJBにアクセスする場合は、サーブレット・クラスのインスタンスごとではなくサーブレット・スレッドごとに独自のセッションEJBインスタンスを使用する必要があります。同時アクセスを避けるために、JSPまたはサーブレットは要求スコープでステートフル・セッションBeanを使用できます。

セッションBeanの設計上の決定

この節では、セッションBeanに関連するいくつかの設計上の決定について説明します。

ステートレスBeanとステートフルBeanの選択

ステートレス・セッションBeanは、アプリケーションでビジネス・メソッドの呼出しの間に特定クライアントの状態を保持する必要がない場合は適切な選択肢です。WebLogic Serverはマルチスレッドで、複数のクライアントに同時にサービスを提供します。ステートレス・セッションBeanを使用した場合、EJBコンテナはセッションの間各クライアントのインスタンスを確保するのではなく、プールにある利用可能なBeanインスタンスを自由に利用してクライアント要求に応えることができます。その結果、リソースの使用率、スケーラビリティ、およびスループットが向上します。

ステートレス・セッションBeanのメリットは、その実装が軽量であることです。ステートレス・セッションBeanは、アプリケーションのBeanがBean同士の対話なしで独立した別個のタスクを実行する場合に優れた選択肢となります。

ステートフル・セッションBeanは、セッションが終わるまでBeanの状態を保持する必要がある場合に良い選択肢です。

ステートレス・セッションBeanとステートフル・セッションBeanのアプリケーションの例については、「ステートレス・セッションBean」および「ステートフル・セッションBean」を参照してください。

ステートレス・セッションBeanの最適なフリー・プール設定の選択

initial-beans-in-free-poolおよびmax-beans-in-free-poolの値を選択するときには、メモリー消費とアプリケーションの速度低下を天秤にかけて検討する必要があります。ステートレス・セッションBeanインスタンスの数が多すぎると、フリー・プールにメモリーを消費する非アクティブなインスタンスが格納されます。数が少なすぎると、クライアントは必要なときにインスタンスを取得できない場合があります。その場合は、インスタンスが解放されるまでクライアント・スレッドがブロックされて、アプリケーションの速度が低下します。

通常、max-beans-in-free-poolはサーバー・インスタンスのワーカー・スレッドと同数にします。そうすれば、スレッドが処理を試みるときに、インスタンスが利用可能な状態にあります。

セッションBeanの実装

第4章では、セッションBean実装の手順が説明されています。この節では、Bean固有のデプロイメント記述子要素を設定してWebLogic Server固有のセッションBeanの動作を構成する詳細について説明します。

WebLogicに固有のセッションBeanの構成可能な動作

表5-2では、ステートレス・セッションbeanの動作を構成するために設定するデプロイメント記述子要素について、および要素を構成しない場合のbeanの動作についてまとめられています。リストされている要素はすべて、weblogic-ejb-jar.xmlのstateless-session-descriptor要素のサブ要素です。

表5-3では、ステートフル・セッションbeanの動作を構成するために設定するデプロイメント記述子要素、および要素を構成しない場合のbeanの動作についてまとめられています。リストされている要素はすべて、weblogic-ejb-jar.xmlのstateful-session-descriptor要素のサブ要素です。

表5-2 ステートレス・セッションEJBのWebLogic固有の機能

制御の対象

設定するweblogic-ejb-jar.xmlの要素

デフォルト動作

起動時のWebLogic Serverに存在するステートレス・セッションBeanの非アクティブなインスタンスの数。

「ステートレス・セッションEJBのプール」を参照してください。

initial-beans-in-free-pool

フリー・プールでBeanは作成されません。

プール内のBeanがアイドル状態でいることができる秒数。WebLogic Serverはその秒数が経過するとBeanを削除できます。

注意: アイドル状態のBeanは、プール内のBean数がinitial-beans-in-free-poolに達するまで削除されます。

idle-timeout-seconds

WebLogic Serverは、フリー・プールのBeanが600秒アイドル状態である場合にそのBeanを削除します。

非アクティブなステートレス・セッションBeanのフリー・プールの最大サイズ。

max-beans-in-free-pool

フリー・プールのBeanの最大数は1000に制限されます。

クラスタでステートレス・セッションEJBのインスタンスがどのようにレプリケートされるのか。

「信頼性と可用性の機能」を参照してください。

- stateless-clustering

- home-is-clusterable

- home-load-algorithm

- home-call-router-class-name

- stateless-bean-is-clusterable

- stateless-bean-load-algorithm

- stateless-bean-call-router-class-name

EJBはクラスタ内の複数のサーバーにデプロイできます。

表5-3 ステートフル・セッションEJBのWebLogic固有の機能

動作

weblogic-ejb-jar.xmlの要素

デフォルト値

Remote Exceptionが送出されることなく、複数のクライアントがBeanに同時にアクセスできるかどうか。

「ステートフル・セッションBeanへの同時アクセスの構成」を参照してください。

allow-concurrent-calls

False - ステートフル・セッションBeanインスタンスによるメソッド呼出しの処理中に、同時に他のメソッド呼出しがサーバーに送信されたときに、サーバーはRemoteExceptionを送出します。

EJBコンテナがエラーを起こすことなくトランザクション・コンテキスト内でステートフル・セッションBeanを削除できるかどうか。

allow-remove-during-transaction

False - ステートフル・セッションBeanがトランザクション・コンテキスト内で削除されるとサーバーは例外を送出します。

キャッシュに存在できるステートフルBeanのインスタンスの数。

max-beans-in-cache

1000

ステートフル・セッションBeanのインスタンスがキャッシュに留まり(max-beans-in-cacheに達していないものと仮定)、パッシブ化の後、ディスクに留まるようになるまでの活動のない状態の期間。

idle-timeout-seconds

600秒

キャッシュからステートフル・セッションBeanのインスタンスを削除するルール。

cache-type

NRU (最近未使用) - この動作の説明については、「遅延パッシブ化(NRU)」を参照してください。

パッシブ化されたステートフル・セッションBeanのインスタンスの状態をWebLogic Serverが格納する場所。

persistent-store-dir

pstore

メソッドのフェイルオーバーをサポートするには、クラスタ化されたEJBの多重呼出し不変メソッドを指定します。多重呼出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができます。

idempotent-methods

なし

ホーム・メソッド呼出しのルーティングに使用するカスタム・クラス。

home-call-router-class-name

なし

Beanのホームがクラスタ化できるかどうかを示します。

home-is-clusterable

True

Beanホームのレプリカ間でロード・バランシングを行うためのアルゴリズム。

home-load-algorithm

プロパティweblogic.cluster.defaultLoadAlgorithmで指定されたアルゴリズム。

クラスタのステートフル・セッションBeanに使用するレプリケーションを示す(in-memoryまたはnone)。

replication-type

なし

6 エンティティEJB

この章では、アプリケーションでエンティティBeanをプログラミングおよび使用するためのWebLogic Serverの付加価値機能について説明し、関連する設計および開発上のガイドラインを示します。

この章は、JavaのプログラミングおよびエンティティBeanの機能に精通している読者を対象としています。エンティティBeanの概要およびエンティティBeanのアプリケーションでの典型的な使用方法については、「エンティティEJBによる永続データの保持」および「エンティティBeanの機能」を参照してください。

Bean開発の全体的なプロセスについては、「Enterprise JavaBeansの実装」を参照してください。

- エンティティBeanのプールとキャッシュの管理

- 主キーの使用

- データベース操作に向けたエンティティEJBの構成

- エンティティBeanでのSQLの使用

- コンテナ管理による関係(CMR)の使用

- 同時実行性ストラテジの選択

- 機能別のCMPエンティティBeanの記述子

エンティティBeanのプールとキャッシュの管理

WebLogic Serverには、エンティティEJBのパフォーマンスとスループットを向上させる以下の機能があります。

- フリー・プール - ファインダ、ホーム・メソッドの呼び出し、およびエンティティBeanの作成に使用する匿名エンティティBeanを格納します。

- キャッシュ - ID (主キー)を持つインスタンス、またはトランザクションに現在登録されているインスタンスを格納します(READYおよびACTIVEのエンティティEJBインスタンス)。

図6-1は、エンティティBeanインスタンスのライフサイクルを示しています。この節では、プール処理について、およびコンテナがフリー・プールとキャッシュにデータを格納して管理する仕組みについて説明します。

図6-1 エンティティBeanのライフサイクル

「図6-1 エンティティBeanのライフサイクル」の説明

エンティティのプールについて

weblogic-ejb-jar.xmlでinitial-beans-in-free-pool要素にゼロ以外の値を指定すると、WebLogic Serverは起動時に指定された量のBeanインスタンスをプールに格納します。

initial-beans-in-free-poolのデフォルト値はゼロです。起動時にBeanインスタンスをフリー・プールに格納しておくと、要求が来てから新しいインスタンスを生成せずにBeanに対する初期要求が可能になるため、EJBの初期応答時間が短縮されます。このリリースのWebLogic Serverでは、管理者は管理コンソールを使用してプールを必要に応じて初期化できます。初期化されたプールは、EJBがデプロイされた直後の状態にリセットされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBのアイドル状態のBeanのキャッシュおよびプールの初期化に関する項を参照してください。

フリー・プールからエンティティBeanのインスタンスを取得しようとすると、その試みはプールが空の場合でも必ず成功します。プールが空の場合は、新しいBeanインスタンスが作成されて返されます。

プールされたBeanは匿名インスタンスであり、ファインダおよびホーム・メソッドで使用されます。プールに格納できるインスタンスの最大数は、weblogic-ejb-jar.xmlのmax-beans-in-free-pool要素で指定します(デフォルト設定は1,000)。

WebLogic Serverを構成することによって、プール内のエンティティBeanがpool要素のidle-timeout-seconds要素で指定した期間にわたって未使用であった場合にそのBeanを削除できます。idle-timeout-secondsで指定する期間にわたってプール内のBeanが未使用である場合、そのプール内のBeanはinitial-beans-in-free-poolで指定されている数まで削除されます。プール内のBeanの数は、initial-beans-in-free-poolで指定されている数より少なくなることはありません。

エンティティのキャッシングについて

Beanでビジネス・メソッドが呼び出されると、コンテナはプールからインスタンスを取得し、ejbActivateを呼び出して、そのインスタンスがメソッド呼出しに対応します。

READYインスタンスはキャッシュにあり、ID (関連付けられた主キー)を持ちますが、現時点ではトランザクションに登録されていません。READYエンティティEJBのインスタンスは、最長時間未使用(LRU)の順で維持されます。

ACTIVEインスタンスは、現時点でトランザクションに登録されています。トランザクションの完了後、そのインスタンスはREADYになり、他のBean用にスペースが必要になるまでキャッシュにとどまります。

管理コンソールの「モニター」タブの「現在のキャッシュ済みBean数」フィールドには、READYおよびACTIVE Beanの数が表示されます。また、このリリースのWebLogic Serverでは、管理者は管理コンソールを使用してキャッシュを必要に応じて初期化できます。初期化されたキャッシュは、EJBがデプロイされた直後の状態にリセットされます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBのアイドル状態のBeanのキャッシュおよびプールの初期化に関する項を参照してください。

max-beans-in-cache要素の効果とキャッシュで許可される主キーが同じインスタンスの数は、同時実行性ストラテジによって異なります。表6-1は、同時実行性ストラテジごとに、weblogic-ejb-jar.xmlのmax-beans-in-cache要素の値がキャッシュ内のエンティティBeanインスタンスの数をどのように制限するのか、および同じ主キーでエンティティBeanインスタンスがいくつキャッシュ内で許可されるのかを示しています。

表6-1 同時実行性タイプ別のエンティティEJBのキャッシング動作

同時実行性オプション

キャッシュ内のBeanインスタンス数に対するmax-beans-in-cacheの影響

主キーの同じインスタンスが同時にいくつキャッシュに存在できるか

Exclusive

max-beans-in-cache = ACTIVE Beanの数+ READYインスタンスの数

1

Database

max-beans-in-cache数までのACTIVE Beanインスタンス、および、max-beans-in-cache数までのREADY Beanインスタンス

複数

ReadOnly

max-beans-in-cache = ACTIVE Beanの数+ READYインスタンスの数

1

READYのエンティティEJBインスタンスは、他のBeanでスペースが必要なときにキャッシュから削除されます。READYインスタンスがキャッシュから削除され、BeanでejbPassivateが呼び出されて、コンテナがそのインスタンスをフリー・プールに戻そうとします。

WebLogic Serverを構成することによって、キャッシュ内のエンティティ・インスタンスがidle-timeout-seconds要素で指定した期間にわたってアイドル状態である(トランザクションに参加していない)場合にそのインスタンスを定期的に削除できます。専用キャッシュの場合、クリーニング・タスクの固定期間はidle-timeout-secondsの値に等しくなります。アプリケーション・レベルのキャッシュの場合、複数のタイプのエンティティBeanがキャッシュを共有し、各Beanがそれぞれのidle-timeout-secondsの値を使用できるようになります。この場合、クリーニング・タスクの固定期間はMIN(キャッシュ内のすべてのBeanのidle-timeout-secondsのセット)に等しくなり、クリーニング・タスクは可変期間で実行される可能性があります。

コンテナがインスタンスをフリー・プールに戻そうとしたときに、プールがすでにmax-beans-in-free-pool数のインスタンスで満たされている場合、インスタンスは破棄されます。

ACTIVEのエンティティEJBインスタンスは、そのインスタンスが参加しているトランザクションがコミットまたはロールバックされるまでキャッシュから削除されません。トランザクションがコミットまたはロールバックされた時点で、インスタンスはREADYになり、キャッシュから削除できるようになります。

エンティティBeanのパッシブ化について

満杯であるキャッシュにエンティティBeanが追加されようとしたときに、トランザクションに参加しているエンティティBeanは、必要な場合、CacheFullExceptionを回避するためにパッシブ化することができます。パッシブ化はEJBコンテナによって自動処理されるため、この機能を使用するためにEJBのプログラミングを変更する必要はありません。しかし、必要な場合、EJBが現在のトランザクション内のすべての操作を実行したことをキャッシュに伝えるようにプログラミングできます。この場合、キャッシュはBeanのパッシブ化が可能かどうかを評価するときにこの情報を利用します。

EJBが現在のトランザクション内のすべての操作を実行したことをキャッシュに伝えるようにプログラミングするには、次のようにoperationsComplete Java APIを使用します。

weblogic.ejb.interfaces.EJBLocalObject
public.void.operationsComplete()
weblogic.ejb.EJBObject
public.void.operationsComplete()

ejbLoad()とejbStore()の動作について

この節では、CMP 2.1エンティティBeanの永続データがいつどのようにしてキャッシュにロードされ、永続ストレージに書き込まれるのかを説明します。

- findXXX() - デフォルトでは、CMP Beanでファインダ・メソッドを呼び出すと、Beanの永続データがすぐにキャッシュにロードされます。この動作は、weblogic-ejb-jar.xmlのpersistence要素のfinders-load-bean要素で制御します。

- ejbLoad() - CMP 2.1エンティティBeanの場合は、ejbLoad()を呼び出すと、Beanのデータに対して次にgetXXX()が呼び出されたときにBeanの永続データがエンティティ・キャッシュに「怠惰」にロードされます。したがって、CMP 2.0エンティティBeanのインスタンスでトランザクションが開始されるときは、Beanが最後にキャッシュにロードされてからejbLoad()が呼び出されていない限り、WebLogic Serverはデータベースからではなくエンティティ・キャッシュからBeanのデータを読み込みます。
デフォルトでは、WebLogic ServerはエンティティBeanで新しいトランザクションが開始されるたびにejbLoad()を呼び出します。

注意:

CMP 1.1のエンティティBeanおよびBean管理による永続性を使用するエンティティBeanで使用する場合、ejbLoad()は怠惰なロードを実行しません。それらのBeanタイプの場合、Beanの永続データはejbLoad()の間にキャッシュにロードされます。

- ejbStore() - WebLogic Serverは、ejbStore()の呼出しを使用してエンティティEJBの永続フィールドをデータベースに書き込みます。
デフォルトでは、WebLogic Serverはトランザクションのコミット時にejbStore()を呼び出します。

ejbLoad()およびejbStore()の動作の制御

複数のクライアントがBeanの基底データにアクセスして修正できるアプリケーションの場合、「ejbLoad()とejbStore()の動作について」で説明されているejbLoad()とejbStore()のデフォルトの動作では、以下のようにしてデータベースの整合性が確保されます。

- 新しいトランザクションがそれぞれEJBの永続データの最新バージョンを必ず使用するようにする

- トランザクションのコミット時にデータベースを更新する

ただし、要件によっては、ejbLoad()およびejbStore()の呼出し回数を増やすか減らす必要があるかもしれません。たとえば、パフォーマンス上の理由から、データベースにアクセスする呼出しを制限することが必要な場合もあります。アプリケーションが複数のトランザクションのEJBへの同時アクセスを許可しない場合(たとえばBeanがExclusive同時実行性を使用している場合)、各トランザクションの開始時にデータをロードする必要はありません。他のクライアントやシステムがEJBの基底データを更新しないとすると、キャッシュされたEJBのデータは常に最新の状態であり、ejbLoad()を呼び出すことは余計なオーバーヘッドにつながります。そのような場合は、ejbLoad()の呼出し回数を安全に減らすことができます(「cache-between-transactionsによるデータベース読込みの制限」を参照)。

あるいは、トランザクションの中間結果を利用するために、トランザクションのコミット前に呼び出してejbStore()の標準動作から逸脱することが必要な場合もあるかもしれません。手順については、「トランザクション終了前のデータベースの更新」を参照してください。

キャッシュのフラッシュの無効化

EJBの仕様によると、トランザクションによる更新内容は、トランザクションで発行された問合せファインダおよびejbSelectの結果に反映させる必要があります。この要件に従うとパフォーマンスが低下する場合があります。問合せの実行前にキャッシュをフラッシュしたくない場合は、weblogic-cmp-jar.xmlのinclude-updates要素の値をデフォルト値のTrueからFalseに変更できます。

キャッシュのフラッシュを無効にするかどうかは、データが最新であることよりもパフォーマンスを重視するかどうかで判断します。include-updatesをFalseに設定するとパフォーマンスは最高になりますが、現在のトランザクションの更新が問合せで反映されません。include-updatesがTrueの場合、コンテナはトランザクションの変更をすべてデータベースにフラッシュしてから新しい問合せを実行します。

トランザクションが修正されたデータの問合せを再実行しない場合は(一般的なシナリオ)キャッシュのフラッシュを安全にオフにして、最高のパフォーマンスを得ることができます。

アプリケーション・レベルのキャッシングの構成

アプリケーション・レベルのキャッシング(「組合せキャッシング」とも呼ばれます)では、同じJava EEアプリケーションに属する複数のエンティティBeanが1つの実行時キャッシュを共有できます。各キャッシュを何個のエンティティBeanが参照するかについて制限はありません。

アプリケーション・レベルのキャッシングには以下の利点があります。

- エンティティBeanキャッシュの数が減り、その結果としてキャッシュを構成する作業が軽減されます。

- フラグメンテーションが減るので、メモリーおよびヒープ・スペースの使用率が向上します。たとえば、特定のEJBホームでアクティビティが急増した場合に、結合したキャッシュで利用可能なすべてのメモリーを利用することができます(キャッシュを使用する他のEJBはページアウトされます)。2つのEJBが異なるキャッシュを使用する場合は、片方のBeanのキャッシュがいっぱいになったときに、コンテナは他のBeanのキャッシュでEJBをページアウトできず、その結果としてメモリーが浪費されます。

- 管理が簡素化されます。キャッシュの結合により、システム管理者は多くのキャッシュではなく1つのキャッシュのみの調整で済みます。

- スケーラビリティが向上します。

ただし、アプリケーション・レベルのキャッシングは、スループットの高いアプリケーションにとっては最適な選択肢ではありません。1つのキャッシュにつき一度に1つの制御スレッドしかないので、スループットが高い場合は、複数のタスクがスレッドの制御を奪い合ってそれがボトルネックになることがあります。

アプリケーション・レベルのキャッシュを構成するには、次の手順に従います。

1. weblogic-application.xmlファイルがEARファイルのMETA-INFディレクトリ内にあるか確めます。

2. weblogic-application.xmlのentity-cache要素でアプリケーション・レベルのキャッシュを定義します。この要素とその子要素の定義については、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項のentity-cacheに関する項を参照してください。

3. weblogic-ejb-jar.xmlのentity-descriptor要素のentity-cache-ref要素でアプリケーション・レベルのキャッシュを参照します。
以下の点に注意してください。

- entity-cache-nameはweblogic-application.xmlで指定されているアプリケーション・レベルのキャッシュの名前でなければなりません。

- Beanで指定するconcurrency-strategyはweblogic-application.xmlのcaching-strategyと一致している必要があります。読取り専用エンティティは、マルチバージョンのアプリケーションレベル・キャッシュのみを使用できます。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項のcaching-strategyに関する項を参照してください。

weblogic-application.xmlデプロイメント記述子については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

主キーの使用

すべてのエンティティEJBには、そのホームでエンティティBeanをユニークに識別する主キーが必要です。個々のエンティティBeanインスタンスは、その主キーに対して別のクラスを定義できます(複数のエンティティBeanが必要に応じて同じ主キー・クラスを使用できます)。

2つのエンティティBeanインスタンスのホームと主キーが共通する場合、両者は同一のものと見なされます。クライアントはエンティティBeanインスタンスのリモート・インタフェースへの参照に対してgetPrimaryKey()メソッドを呼び出して、そのホーム内でのインスタンスのIDを調べることができます。

参照と関連付けられたインスタンスIDは、参照が有効な間は変化しません。したがってgetPrimaryKey()メソッドは、同じエンティティ・オブジェクトの参照に対して呼び出されたときは常に同じ値を返します。エンティティ・オブジェクトの主キーを知っているクライアントは、Beanのホーム・インタフェースのfindByPrimaryKey(key)メソッドを呼び出すことによって、エンティティ・オブジェクトへの参照を取得することができます。

主キーと主キー・クラスの指定

主キーは、1つまたは複数のフィールドにマップできます。

- 主キーを1つのCMPフィールドにマップする
エンティティBeanクラスでは、主キーを1つのCMPフィールドにマップできます。CMPフィールドは、ejb-jar.xmlとweblogic-cmp-jar.xmlの両方で指定する必要があります。両方の記述子ファイルで、CMPフィールドはcmp-field要素で指定します。単純主キーの場合は、ejb-jar.xmlのprimkey-field要素でも主キーを指定します。さらに、ejb-jar.xmlのprim-key-class要素で主キー・フィールドのクラスを指定します。

- 1つまたは複数のCMPフィールドを主キー・クラスにラップする
1つまたは複数のフィールドに対応する独自の主キー・クラスを定義することができます。主キー・クラスはpublicでなければならず、パラメータを付けないpublicコンストラクタを持たなければなりません。ejb-jar.xmlのprim-key-class要素で主キー・クラスの名前を指定します。主キー・クラスのすべてのフィールドはpublicでなければならず、ejb-jar.xmlおよびweblogic-ejb-jar.xmlの対応するcmp-fieldと同じで名前を持つ必要があります。複数のCMPフィールドに対応する複合主キーの場合は、ejb-jar.xmlでprimkey-fieldを指定しません。

- 無名主キー・クラス
EJBが無名主キー・クラスを使用する場合、EJBをサブクラス化しjava.lang.Integer型のcmp-fieldをそのサブクラスに追加する必要があります。そのフィールドの自動主キー生成を有効にし、コンテナがフィールドの値を自動的に埋め、そのフィールドをweblogic-cmp-jar.xmlデプロイメント記述子のデータベース列にマップできるようにします。

最終的に、ejb-jar.xmlファイルを更新して元のEJBクラスではなくEJBサブクラスを指定するようにし、そのBeanをWebLogic Serverにデプロイします。

注意:

元のEJBを無名主キー・クラスとともに使用した場合、デプロイメント時にWebLogic Serverから次のエラー・メッセージが表示されます。

In EJB ejb_name, an 'Unknown Primary Key Class' ( <prim-key-class> == java.lang.Object ) MUST be specified at Deployment time (as something other than java.lang.Object).

主キーのガイドライン

WebLogic Serverで主キーを使用するときには以下の提言に従ってください。

- ejbCreateを使用して新しい主キー・クラスを作成しないでください。その代わりに、「主キーの自動生成」の説明に従ってコンテナ内部で主キー・クラスを作成できるようにしてください。

- それ独自の主キー値を管理するアプリケーションにおいて、StringまたはIntegerなどの原子的な値1つで構成された単純主キーの場合は、その主キー・クラスをコンテナ管理によるフィールドにします。ejbCreateメソッド内でsetXXXメソッドを使用して、主キーのcmp-fieldの値を設定します。

- BigDecimal型のcmp-fieldは、CMP Beanの主キー・フィールドとして使用しないでください。boolean BigDecimal.equals (object x)メソッドでは、値とスケールが同じ場合に限り2つのBigDecimalが等しいと判断されます。なぜなら、Java言語とさまざまなデータベースでは精度に違いがあるからです。たとえば、このメソッドでは7.1と7.10は等しいとは判断されません。したがって、このメソッドを使用すると、ほとんどの場合でFalseが返されるか、CMP Beanでエラーが発生します。
BigDecimalを主キーとして使用する必要がある場合は、次の操作を行ってください。

1. 主キー・クラスを実装します。

2. この主キー・クラスで、boolean equal (Object x)メソッドを実装します。

3. equalメソッドで、boolean BigDecimal.compareTo(BigDecimal val)を使用します。

- データベース列をcmp-fieldおよびcmr-fieldに同時にマップし、cmp-fieldが主キー・フィールドである場合は、ejbCreate()メソッドが呼び出されたときにcmp-fieldのsetXXXメソッドを使用して値を設定します。その場合、cmr-fieldは自動的に初期化され、cmr-fieldのsetXXXメソッドは使用できません。逆に、cmp-fieldが主キー・フィールドでない場合には、cmp-fieldが読取り専用です。列はcmr-fieldを使用して更新され、cmp-fieldは外部キーの読出し専用ビューを提供します。

主キーの自動生成

WebLogic Serverは、CMPエンティティBeanでの自動主キー生成機能をサポートしています。この機能は、単純(非複合)主キーでのみサポートされています。

WebLogic Serverは、自動主キー生成の2通りの手法をサポートしています。

- ネイティブのデータベース主キー生成 - データベースが主キーを生成します。この機能を有効にするには、weblogic-cmp-jar.xmlの<automatic-key-generation>要素でデータベースとジェネレータ名を指定します。コンテナは、構成された値に基づいてデータベースから主キーを取得するコードを生成します。この機能は、OracleおよびMicrosoft SQL Serverデータベースのみでサポートされています。「主キー・フィールドの型の宣言」の手順も参照してください。

- SEQUENCE表から生成される主キー

どちらの方法を使用する場合でも、「主キー・フィールドの型の宣言」の手順を参照してください。

Oracleデータベース用自動キー生成の指定

Oracleデータベース用の主キー生成サポートでは、OracleデータベースのSEQUENCEエンティティを使用してユニークな主キーを生成します。OracleデータベースのSEQUENCEは、新しい数値が必要な場合に呼び出されます。自動キー生成は、weblogic-cmp-jar.xmlのautomatic-key-generation要素で指定します。generator-nam要素で、OracleデータベースのSEQUENCEの名前を指定します。OracleデータベースのSEQUENCEがSEQUENCE INCREMENTで作成された場合は、key-cache-sizeを指定します。key-cache-sizeの値は、OracleデータベースのSEQUENCE INCREMENTの値と同じでなければなりません。2つの値が違う場合は、キーが重複することがあります。

主キーの生成でOracleデータベースのSEQUENCEオブジェクトを使用する場合は、以下の点に注意してください。

- Oracleでは、generator-typeをUSER_DESIGNATED_TABLEに設定しません。そのように設定するとTX ISOLATION LEVELがSERIALIZABLEに設定され、次の例外が生じる場合があります。

javax.ejb.EJBException: nested exception is: java.sql.SQLException: Automatic
Key Generation Error: attempted to UPDATE or QUERY NAMED SEQUENCE TABLE
NamedSequenceTable, but encountered SQLException java.sql.SQLException:
ORA-08177: can't serialize access for this transaction.

代わりに、OracleデータベースではAutoKeyオプションを使用します。

- このリリースのWebLogic Serverでは、SEQUENCEスキーマ・オブジェクトに対応するOracleデータベースの同様の機能をサポートしていません。SEQUENCEと同様の機能を使用するアプリケーションをWebLogic Server 8.1より前のリリースからこのリリースに移行すると、以下のエラーが生じます。

[EJB:011066]During EJB deployment, error(s) were encountered while setting up The ORACLE SEQUENCE named 'XXX' with INCREMENT value '1'
[EJB:011064]The ORACLE SEQUENCE named 'XXX' with INCREMENT '1' was not found in the database'

Microsoft SQL Server用自動キー生成の指定

Microsoft SQL Serverデータベース用の主キー生成サポートでは、SQL ServerのIDENTITY列が使用されます。Beanが作成され、新しい行がデータベース表に挿入されると、SQL Serverは、IDENTITY列として指定された列に、次の主キー値を自動的に挿入します。

注意:

IDENTITY列の含まれるSQL Server表作成の手順については、Microsoftのドキュメントを参照してください。

表でIDENTITY列が作成されたら、次のようにweblogic-cmp-jar.xmlで自動キー生成を指定してください。

<automatic-key-generation>
<generator-type>SQLServer</generator-type>
</automatic-key-generation>

命名済シーケンス表を使用した主キーの生成

シーケンス表は、データベースに依存しない主キーを生成する手段です。シーケンス表は、Beanインスタンスの作成時にその主キー値として使用される、一定の割合で増加する整数のシーケンス値を保持します。

現在の主キー値を保持するSEQUENCEという名前の表を作成します。この表は、次の文で定義するように、1行1列で構成されます。

CREATE table_name (SEQUENCE int)
INSERT into table_name VALUES (0)

この機能を使用するには、基底のデータベースがトランザクションのアイソレーション・レベルSerializableをサポートしていなければなりません。Serializable値は、このトランザクションを同時に複数回実行すると、トランザクションを順番に複数回実行するのと同じ結果になることを示します。これは、複数のサーバー・インスタンスがシーケンス表に同時にアクセスするWebLogic Serverクラスタで重要です。データベースがサポートするアイソレーション・レベルを確認するには、そのデータベースのドキュメントを参照してください。

自動キー生成は、weblogic-cmp-jar.xmlファイルで次のように指定します。「主キー・フィールドの型の宣言」の手順も参照してください。

<automatic-key-generation>
<generator-type>NamedSequenceTable</generator-type>
MY_SEQUENCE_TABLE_NAME</generator-name>
<key-cache-size>100</key-cache-size>
</automatic-key-generation>

generator-name要素で、シーケンス表の名前を指定します。

キー・キャッシュのサイズ(1回のDBMS呼出しでコンテナが取得するキーの数)は、key-cache-size要素で指定します。key-cache-sizeは、1より大きく設定することをお薦めします。この設定により、次のキー値を取得するためのデータベースの呼出し回数を減らすことができます。

NAMED SEQUENCE表はBeanのタイプごとに定義することをお薦めします。異なるタイプのBeanがNAMED SEQUENCE表を共有しないようにしてください。こうすることで、キー表の競合の発生を防ぎます。

主キー・フィールドの型の宣言

ネイティブのDBMS主キー生成と、命名済シーケンス表を使用したキー生成の両方について、関連付けられたエンティティBeanの抽象getメソッドおよびsetメソッドで、主キー・フィールドの型を以下のいずれかとして宣言します。

- java.lang.Integer

- java.lang.Long

weblogic-cmp-jar.xmlでは、シーケンスの主キー値がデータベースから一度にいくつ取得されるのかを指定するkey-cache-size要素を設定します。たとえばkey_cache_sizeを10に設定すると、Beanが10作成されるたびに一度データベース・アクセスが実行されてシーケンスが更新されます。key_cache_sizeのデフォルト値は1です。データベース・アクセスを最小限に抑えてパフォーマンスを向上させるために、key_cache_sizeには1より大きい値を設定することを推奨しています。

OracleデータベースのSEQUENCEのサポート

WebLogic Serverは、OracleデータベースのSEQUENCE (呼び出されるたびにユニークな整数を生成する番号ジェネレータ)を自動的に作成できます。

OracleデータベースのSEQUENCEは、指定された「インクリメント値」を使用できます。インクリメント値とは、生成ごとに整数が大きくなる増加量のことです。たとえば、SEQUENCEで整数24が生成され、インクリメント値が10の場合、SEQUENCE で生成される次の整数は34になります。

文字列値CMPフィールドの削除

このリリースのWebLogic Serverでは、デフォルトによって、EJBコンテナは文字列値CMPフィールドがデータベースから取得されたときにその末尾のスペースを削除します。すべての文字列値CMPフィールドのセット・メソッドでも、末尾のスペースが削除されます。

文字列の削除の利点

主キー・フィールド内のスペースを削除しない場合、比較演算子が正常に機能せず、移植できない動作を引き起こす場合があります。自動文字列削除の利点は、データベースから取得された文字列が、データベースに挿入された文字列と同じになることです。次に例を示します。

- 主キー・フィールドがデータベース内のchar(10)データ型にマップされています。

- データベース列に「smith」という値を挿入します。

- "smith"は5文字であり、char型は固定長の10文字であるため、データベースは5個のスペースを末尾に追加して値を埋めます。この結果、データベースには"smith "という値が挿入されます。

- SELECT文を使用して、データベースから"smith"を検索します。データベースによって追加された文字列である"smith "が取得されます。

取得した"smith "と元の"smith"の比較演算は、取得した値の末尾のスペースを事前に削除しない限り失敗します。このリリースのWebLogic Serverでは、末尾のスペースは自動的に削除されるため、比較演算が失敗することはありません。

文字列の削除を無効にする

このリリースでは、デフォルトによって自動文字列削除が有効になっています。DDConverterを使用して旧リリースのWebLogic Serverのデプロイメント記述子を変換する場合、DDConverterは作成する新しいデプロイメント記述子で文字列削除を自動的に無効にします。

このリリースのWebLogic Serverで新しく作成するデプロイメント記述子で文字列削除を無効にする場合、weblogic-cmp-jar.xmlのdisable-string-trimmingをTrueに設定します。disable-string-trimming要素の詳細については、「disable-string-trimming」を参照してください。

データベース操作に向けたエンティティEJBの構成

この節では、エンティティEJBをデータベース表にマップし、データベース・アクセスの動作を制御する方法を示します。

表マッピングの構成

CMP Beanは、1つまたは複数のデータベース表にマップできます。1つのCMP Beanを複数の表にマップする場合、各表には、1つの特定のBeanインスタンスに対応する1行が含まれます。このため、Beanがマップされる各表にはいつでも同じ数の行が含まれ、同種の主キー値が同じように格納されます。したがって、各表には同数の主キー列が含まれ、別々の表の対応している主キー列どうしは名前は違うとしても同じタイプでなければなりません。同じBeanにマップされる複数の表の主キー間に、参照一貫性制約を課してはなりません。参照一貫性制約がある場合は、Beanインスタンスを削除すると実行時エラーが発生します。

Beanのcmp-fieldを表の列にマップするには、weblogic-cmp-jar.xmlのtable-map要素を使用します。その際、Beanがマップされるデータベース表ごとに1つのtable-map要素を指定します。各table-map要素は、表の主キー列をBeanの主キー・フィールドにマップします。主キー以外のフィールドは、1つの表にマップされるだけの場合もあります。

例6-1と例6-2は、1つの表にマップされるBeanと複数の表にマップされるBeanのtable-map要素を示しています。

例6-1 CMPエンティティの1つのデータベース表へのマッピング

<table-map>
<table-name>TableName</table-name>
<field-map>
<cmp-field>name</cmp-field>
<dbms-column>name_in_tablename</dbms-column>
</field-map>
<field-map>
<cmp-field>street_address</cmp-field>
<dbms-column>street_address_in_tablename
</dbms_column>
</field-map>
<field-map>
<cmp-field>phone</cmp-field>
<dbms-column>phone_in_tablename</dbms-column>
</field-map>

例6-2 CMPエンティティの2つのDBMS表へのマッピング

<table-map>
<table-name>TableName_1</table-name>
<field-map>
<!--Note 'name'is the primary key field of this EJB -->
<cmp-field>name</cmp-field>
<dbms-column>name_in_tablename_1</dbms-column>
</field-map>
<field-map>
<cmp-field>street_address</cmp-field>
<dbms-column>street_address_in_tablename_1</dbms-column>
</field-map>
</table-map>
<table-map>
<table-name>TableName_2</table-name>
<field-map>
<!--Note 'name'is the primary key field of this EJB -->
<cmp-field>name</cmp-field>
<dbms-column>name_in_tablename_2</dbms-column>
</field-map>
<field-map>
<cmp-field>phone</cmp-field>
<dbms-column>phone_in_tablename_2</dbms-column>
</field-map>
</table-map>

自動表作成(開発のみ)

WebLogic ServerのEJBコンテナは、反復的な開発を容易にするために、エンティティBeanが変更されたときに自動的に基底の表スキーマを変更するように構成できます。そのように構成すると、表はオブジェクトの関係の最新のマッピングを常に反映するようになります。

注意:

この機能は、サーバー・インスタンスがプロダクション・モードで実行されている場合は無効です。プロダクション環境では、より正確な表スキーマ定義を使用することが必要な場合があるからです。確実にコンテナによって作成された表だけが変更されるように、コンテナで作成された表には、wls_tempという追加列が含まれています。

表作成文の構文(DDL)はデータベースによって異なるので、表の作成はフル・サポートされていないデータベースでは失敗する場合があります。その場合、表は手作業で作成します。

表6-2 <create-default-dbms-tables>を使用した自動表作成動作の制御

を使用した自動表作成動作の制御" title="<create-default-dbms-tables>を使用した自動表作成動作の制御" width="100%">

<create-default-dbms-tables>の設定値

得られる動作

Disabled

基底の表スキーマが変更されてもEJBコンテナはアクションを行いません。これがデフォルト値です。

CreateOnly

JARの各CMP Beanについて、データベース内にそのBeanの表がなければ、コンテナはデプロイメント記述子の情報に基づいて表を作成しようとします(結合表、シーケンス表、およびOracleデータベース・シーケンスを含む)。表作成が失敗した場合は、「Table Not Found」エラーが送出され、ユーザーが手動で表を作成することが必要となります。

DropAndCreate

JARの各CMP Beanについて、次のような動作が行われます。

- 表列が変更されていない場合は、アクションは行われず、既存のデータは維持されます。

- 列に変更があれば、コンテナは表を削除して再作成し、すべての表データが失われます。

注意: 列タイプとcmpフィールド・タイプの間に互換性があることを確認する必要があります。EJBコンテナは、列タイプとcmpフィールド・タイプの間に互換性があることを確認しません。

DropAndCreate

Always

JARに示される各CMP Beanについて、列に変更があるとコンテナは表を削除して作成します。

AlterOrCreate

JARの各CMP Beanについて、次のような動作が行われます。

- 表がある場合、コンテナはALTER TABLE SQLコマンドを使用して表スキーマを変更しようとし、データは保存されます。

- 既存の表がなければ、コンテナはデプロイメントの過程で表を作成します。

注意: 新しい列が主キーとして指定されているか、値がnullの列が新しい主キー列として指定されている場合には、AlterOrCreateを使用しません。データベースの制限のため、代わりにDropAndCreateを使用します。

注意:

シーケンス表、結合表、およびOracleデータベースのSEQUENCEがサポートされています。

weblogic-cmp-jar.xmlのcreate-default-dbms-table要素を使用してこの機能を有効化します。この機能の動作は、次の表で説明するように、要素の値に応じて変わります。この表に示すEJBコンテナのアクションは、デプロイ中に発生します。

データベース挿入の遅延

CMP Beanを作成するときに発生する場合のあるタイミングの問題のため、WebLogic ServerではBeanの作成プロセスのどの時点でBeanがデータベースに挿入されるのかを指定することができます。

データベースの挿入を遅延させる理由

cmr-fieldは、Beanの主キー値(ejbPostCreateが呼び出されて設定される)がアクセス可能になるまで設定できません。したがって、cmr-fieldはejbPostCreateが呼び出されるまで設定できません。この要因が他の条件と重なると、以下の問題が生じることがあります。

- 問題1: 非nullの外部キーの制約
データベースの行がejbCreateの後(つまり、ejbPostCreateの前)に挿入された場合、外部キーはnull値になります。その理由は、外部キー列がcmr-fieldの設定時に設定されるからです。

解決策: weblogic-cmp-jar.xmlのdelay-insert-untilをejbCreateに設定し(この設定で、挿入はejbCreateの直後に行われます)、ejbPostCreateの過程で関係を設定します。

- 問題2 : ejbPostCreateの過程でのBeanの作成
関連するBeanが作成されるときに、そのBeanのデータベースの挿入が、作成の呼出しが終了する前に行われます。関連するBeanのデータベース行に、現在のBeanを表す外部キーが含まれており、その外部キーで参照一貫性制約が定義されている場合、挿入は現在のBeanのデータベース行がまだ挿入されていない場合は失敗します。

解決策: delay-insert-untilをejbCreateに設定し、現在のBeanの行がejbPostCreateの間存在するようにします。

注意:

1対1の関係では、親Beanの主キーが子BeanのCMRフィールドに埋め込まれている場合、EJBコンテナがBeanを作成するときに、パフォーマンス上の理由からその親Beanに子があるかどうかが確認されません。duplicationKeyExceptionデータベース例外を防止するには、データベースの子表で外部キー制約を設定する必要があります。

- 問題3: 問題1と問題2の両方がある
解決策: ejbPostCreateの間に関連するBeanを作成しないようにします。現在のBeanを作成し、その作成が終了した後に、関連するBeanを作成して関係を設定します。

これが、アプリケーションで常に行われるようにすることをお薦めします。アプリケーションでは、別のBeanの作成時に関連するBeanを作成してはなりません。

データベースの挿入遅延の構成

weblogic-cmp-jar.xmlのdelay-database-insert-until要素を使用すると、EJBCreateメソッドまたはejbPostCreateメソッドが終了するまでデータベースの挿入を遅らせることができます。トランザクションの最後に更新を一括で順序付けして実行するには、weblogic-cmp-jar.xmlでenable-batch-operationsとorder-database-operationsの両方を「True」に設定します。

関連するBeanを更新するトランザクションでデータベースの更新を遅延させる場合は、weblogic-cmp-jar.xmlのweblogic-rdbms-relationでBean間の関係を定義する必要があります。そのように定義しないと、EJBコンテナが更新を実行しようとしたときに、データベースの制約エラーが発生する場合があります。

cache-between-transactionsによるデータベース読込みの制限

「ejbLoad()とejbStore()の動作について」で説明されているように、デフォルトでは、WebLogic ServerはエンティティBeanでトランザクションが開始されるたびにejbLoad()を呼び出します。

クライアントが最初にBeanを参照するとき、またはトランザクションがロールバックされたときにのみejbLoad()を呼び出すようにWebLogic Serverを構成できます。この動作は、長期キャッシングと呼ばれます。長期キャッシングを有効化するには、weblogic-ejb-jar.xmlのcache-between-transactions要素をtrueに設定します。

長期キャッシングは、Beanのconcurrency-strategyがExclusive、ReadOnly、またはOptimisticの場合のみ許可されます。長期キャッシングが構成されている場合の動作は以下のとおりです。

- ReadOnly Beanの場合、WebLogic Serverはcache-between-transactionsの値を無視します。WebLogic Serverは、cache-between-transactionsの値に関係なく常に読取り専用データの長期キャッシングを実行します。

- Exclusive Beanの場合、EJBコンテナは基底データへの排他的な更新アクセスが可能である必要があります。データが、EJBコンテナ外の別のアプリケーションで更新されることはあってはなりません。

注意:

Exclusive同時実行性のBeanがクラスタにデプロイされた場合、長期キャッシングが自動的に無効になります。クラスタ内では、どのサーバー・インスタンスもBeanデータを更新できるからです。このため、トランザクション間のキャッシングは不可能になります。

- Optimistic Beanの場合、EJBコンテナはクライアントが最初にBeanを参照した後に各トランザクションでキャッシュされたデータを再利用しますが、各トランザクションの最後にオプティミスティックな衝突をチェックすることで更新がトランザクションとして一貫性を持つようにします。

注意:

クラスタでは、オプティミスティック同時実行性のBeanが更新されると、オプティミスティックな衝突を防止するために他のクラスタ・メンバーに通知がブロードキャストされます。

表6-3は、エンティティBeanのタイプおよび同時実行性ストラテジ別のcache-between-transactions 要素の有効値を示しています。

表6-3 同時実行性ストラテジおよびエンティティ・タイプ別のcache-between-transactionsの有効値

同時実行性ストラテジ

BMPエンティティ

CMP 2.0 Bean

CMP 1.1エンティティ

Database

False。

False。

False。

Exclusive

TrueまたはFalse。

TrueまたはFalse。

TrueまたはFalse。

Optimistic

適用不可。Optimistic同時実行性はBMP Beanでは利用できません。

TrueまたはFalse。

適用不可。Optimistic同時実行性はCMP 1.1 Beanでは利用できません。

トランザクション終了前のデータベースの更新

「ejbLoad()とejbStore()の動作について」で説明されているように、デフォルトでは、WebLogic Serverはトランザクションのコミット時にのみejbStore()を呼び出します。

未コミット・トランザクションの中間結果を他のデータベース・ユーザーが利用できるようにするには、weblogic-ejb-jar.xmlのpersistence要素のdelay-updates-until-end-of-txをFalseに設定します。この設定により、WebLogic Serverは各メソッド呼出しの後にejbStore()を呼び出すようになります。

注意:

delay-updates-until-end-of-txをfalseに設定すると、各メソッド呼出しの後にデータベースの更新が行われますが、その更新はトランザクションが終わるまでコミットされません。

動的問合せ

動的問合せを使用すると、各自のアプリケーション・コードでEJB-QLまたはSQL問合せをプログラム的に作成および実行できるようになります。

動的問合せの使用には、次のような利点があります。

- EJBを更新してデプロイせずに、新しい問合せを作成して実行する機能。

- EJBデプロイメント記述子ファイルのサイズを縮小する機能。ファインダ問合せがデプロイメント記述子内で静的に定義される代わりに、動的に作成されるようになるためです。

動的問合せの有効化

動的問合せを有効化するには、次の手順に従います。

1. EJBのweblogic-ejb-jar.xmlのenable-dynamic-queries要素をTrueに設定します。

<enable-dynamic-queries>True</enable-dynamic-queries>

2. ejb-jar.xmlデプロイメント記述子ファイルのmethod-permission 要素を指定することによって、標準メソッド権限を設定し、動的問合せへのアクセスを制御します。
weblogic.ejb.QueryHomeインタフェースのcreateQuery()メソッドのmethod-permissionを設定することによって、動的問合せを実行するweblogic.ejb.Queryオブジェクトへのアクセスを制御します。

createQuery()メソッドのmethod-permissionを指定した場合、method-permissionの設定がQueryクラスの実行と検索メソッドに適用されます。

動的問合せの実行

次のサンプル・コードでは、動的問合せをどのように実行するかを示します。

InitialContext ic=new InitialContext();
FooHome fh=(FooHome)ic.lookup("fooHome");
QueryHome qh=(QueryHome)fh;
String ejbql="SELECT OBJECT(e)FROM EmployeeBean e WHERE e.name='rob'"
Query query=qh.createQuery();
query.setMaxElements(10)
Collection results=query.find(ejbql);

OracleまたはDB2データベースのBLOBおよびCLOB列のサポートの有効化

WebLogic Serverは、OracleおよびDB2データベースのBinary Large Object (BLOB)およびCharacter Large Object (CLOB) DBMS列をCMPエンティティBeanでサポートしています。

WebLogic Serverは、バイト配列またはシリアライズ可能な型を持つcmp-fieldにBLOBをマップします。現時点では、char配列をCLOB列にマップすることはできません。

BLOB/CLOBサポートを有効にするには次の手順に従います。

1. Beanクラスで変数を宣言します。

2. weblogic-cmp-jar.xmlファイルでdbms-default-valueおよびdbms-column-typeデプロイメント記述子を宣言してXMLを編集します。

3. OracleまたはDB2データベースにBLOBまたはCLOBを作成します。

デプロイメント記述子によるBLOB列の指定

次のXMLコードは、weblogic-cmp-jar-xmlファイルのdbms-column-type要素を使用してBLOBオブジェクトを指定する方法を示しています。

<field-map>
<cmp-field>photo</cmp-field>
<dbms-column>PICTURE</dbms-column>
<dbms-column-type>Blob</dbms-column-type>
<dbms-default-value>DB2</dbms-default-value>
</field-map>

Oracle Blobにマップされたbyte[]型のcmp-fieldsのシリアライゼーション

このリリースのWebLogic Serverでは、Blobにマップされるbyte[]型のcmp-fieldはデフォルトによってシリアライズされません。EJBコンテナはbyte[]型を直接保持し、シリアライズしません。

WebLogic ServerがOracleデータベース内のBlobにマップされたbyte[]型のcmp-fieldをシリアライズするようにするには、WebLogic Server 8.1 SP02で導入されたserialize-byte-array-to-oracle-blob互換性フラグをTrueに設定します。

デプロイメント記述子によるCLOB列の指定

次のXMLコードは、weblogic-cmp-jar-xmlファイルのdbms-column要素を使用してCLOBオブジェクトを指定する方法を示しています。

<field-map>
<cmp-field>description</cmp-field>
<dbms-column>product_description</dbms-column>
<dbms_column-type>Clob</dbms-column-type>
<dbms-default-value>Oracle</dbms-default-value>
</field-map>

Oracle 10gにおけるCLOB列の挿入の最適化

Oracle 9iドライバと10gドライバでは、CLOB列をデータベースに正常に挿入するための要件が異なっています。Oracle 9iドライバでは、CLOB値を挿入する前に、データベース行をロックする必要があります。したがって、Oracle 9iの場合、WebLogic Serverは以下の手順でCLOB列値を含む行を表に挿入しています。

1. CLOB列以外のすべての値を含む行を表に挿入します。

2. 手順1で作成された行に対してSELECT FOR UPDATE文を発行します。

3. その行にCLOB値を挿入します。

Oracle 9iでCLOB値を含む行を正常に挿入するにはこのような手順が必要ですが、Oracle 10gでこの手順を行うと、パフォーマンスに不要な影響を与えます。Oracle 10gドライバではCLOBの処理方法が改良されており、CLOB列値を挿入する前に行をロックする必要はありません。Oracle 10gの場合、WebLogic Serverは単一のINSERT文を使用して、CLOB列値を含む行を表に挿入します。その結果、CMP EJBのパフォーマンスは向上します。

このようなOracle 10gに関するWebLogic Serverの最適化を利用するために、追加の構成は必要ありません。データベースとしてOracleを指定すれば、WebLogic ServerはOracleのバージョンがOracle 9iかOracle 10gかを確認します。WebLogic ServerがデータベースをOracle 10gと識別した場合、CLOB値を含む行は単一のINSERT文で表に挿入されます。WebLogic ServerがデータベースをOracle 9iと識別した場合、CLOB値を含む行は前述の3つの手順で表に挿入されます。

詳細は、「Handling CLOBs - Made easy with Oracle JDBC 10g」(http://www.oracle.com/technetwork/java/jms/index.html#DUPS_OK_ACKNOWLEDGE)を参照してください。

フィールド・グループの指定

フィールド・グループは、Beanのコンテナ管理による永続性(CMP)フィールドとコンテナ管理による関係(CMR)フィールドのサブセットを表します。パフォーマンスを向上させるために、Bean内の関連フィールドを、障害のあったグループにまとめて1つのユニットとしてメモリー内に入れることができます。

グループを問合せまたは関係に関連付けることができます。それによって、問合せを実行するか、または関係に従った結果としてBeanがロードされたときに、グループ内の指定フィールドのみがロードされます。

指定したグループを持たない問合せと関係に対して、「default」という特殊なグループを使用します。デフォルトでは、defaultグループには、BeanのすべてのCMPフィールドと、Bean表に外部キーを追加するすべてのCMRフィールドが格納されます。

フィールドは複数のグループに関連付けられている場合があります。この場合、フィールドに対してgetXXX()メソッドを実行すると、そのフィールドを含む最初のグループで障害が発生します。

フィールド・グループは、例6-3のようにweblogic-cmp-jar.xmlファイルのfield-group要素で指定します。

例6-3 フィールド・グループの指定

<weblogic-rdbms-bean>
<ejb-name>XXXBean</ejb-name>
<field-group>
<group-name>medical-data</group-name>
<cmp-field>insurance</cmp-field>
<cmr-field>doctors</cmr-fields>
</field-group>
</weblogic-rdbms-bean>

処理の順序付けとバッチ処理

同じコンテナ管理による永続性(CMP)エンティティBeanの複数のインスタンスは、多くの場合単一のトランザクションで変更されます。EJBコンテナがCMPエンティティBeanのインスタンスごとにSQLを発行する場合、更新はパフォーマンスのボトルネックになります。

EJBバッチ処理機能は、1まとまりのSQL文でデータベース表内の複数エントリを更新することにより、この問題を解決します。これにより、CMP Beanの複数のデータベース挿入、削除、または更新を一度のデータベース・アクセスで実行することでパフォーマンスが大幅に向上します。

バッチ処理によるデータベース挿入、更新、または削除を許可するには、weblogic-cmp-jar.xmlファイルのenable-batch-operations要素をTrueに設定します。

処理の順序付け

データベースの処理を順序付けすると、データベースの依存関係を考慮し、それに応じて挿入、更新、および削除を順序付けすることで制約エラーが起こらなくなります。

データベースの順序付けを有効化すると、EJBコンテナが次の2つの処理を行うようになります。

- データベースのすべての処理(挿入、更新、および削除)をコミット時間まで遅延させる

- コミット時間になったらデータベース処理を順序付けする

たとえば、販売員Aと関連する顧客Aを想定します。販売員Aが削除され、顧客Aが販売員Bに割り当てられる場合、コンテナは次のように処理を順序付けします。

1. 販売員Bを参照するように顧客Aを更新します。

2. 販売員Aを削除します。

これで、顧客Aは存在しない販売員を参照しなくなり、データベースの参照整合性エラーが発生しなくなります。

EJBコンテナが関連するBeanのデータベース処理を適切に順序付けするには、weblogic-cmp-jar.xmlのweblogic-rdbms-relationでBean間の関係を定義する必要があります。そのように定義しないと、EJBコンテナが更新を実行しようとしたときに、データベースの制約エラーが発生する場合があります。

バッチ処理に関するガイドラインおよび制限

バッチ処理を使用する場合、トランザクションの開始からコミットまでの間にバッチ処理だけが挿入、更新または削除に適用されるように、トランザクションの境界を設定しなければなりません。

バッチ処理は、addBatch()とexecuteBatch()メソッドをサポートしているドライバのみに機能します。サポートされていないドライバを検出すると、EJBコンテナはバッチ処理がサポートされていないことを報告し、バッチ処理を無効化します。

バッチ処理の使用には、いくつかの制限があります。

- generator-typeがsybaseまたはsqlServerに設定されていると、バッチ処理で主キーの自動生成機能を使用できません。これらのタイプのいずれかで自動主キー生成を有効化していた場合、WebLogic Serverは自動的にバッチ処理を無効化し、警告を発行します。

- 1回のバッチ処理で作成するエントリの総数が、weblogic-ejb-jar.xmlファイルで指定したmax-beans-in-cacheの設定値を超えることはできません。

- weblogic-cmp-jar.xmlのdbms-column-type要素でBlobかClobを設定した場合、バッチ処理は自動的に無効になります。BlobまたはClob列がデータベース表に含まれている状況では、時間をあまり短縮できないからです。この場合、デフォルトではWebLogic ServerはBeanごとに挿入を実行します。

問合せキャッシングの使用(読取り専用エンティティBean)

読取り専用エンティティEJBを問合せレベルでキャッシュできます。読取り専用エンティティEJBを問合せレベルでキャッシュすると、パフォーマンスが向上します。これは、ファインダがキャッシュ内のEJBにアクセスできるようになり、データベースへのアクセスを回避できるからです。詳細については、「enable-query-caching」を参照してください。

エンティティBeanでのSQLの使用

このリリースのWebLogic Serverでは、コンテナ管理による永続性(CMP)を使用するエンティティBeanでEJB-QL、標準のSQL、またはデータベース固有のSQLを使用できます。ほとんどの問合せではEJB-QL (WebLogic拡張ありまたはなし)を使用し、SQLは必要な場合にのみ(たとえば、ベンダー固有のSQLを使用しないとアクセスできないベンダー固有機能を使用する場合に)使用することをお薦めします。

SQLは、複数の関連オブジェクトをキャッシュする問合せでファインダおよび選択メソッドを実装するために使用したり、ストアド・プロシージャと一緒に使用したりできます。

このリリースのWebLogic Serverの問合せでEJB-QLを使用する場合、weblogic-cmp-jar.xmlのマッピング情報を変更する必要はありません。9.0より前のリリースのWebLogic Serverでの操作と同じように、各CMPおよびCMRフィールドをデータベース列にマップするだけです。詳細は、「データベース操作に向けたエンティティEJBの構成」および「コンテナ管理による関係(CMR)の使用」を参照してください。問合せでSQLを使用するには、sql-shape要素を使用してSQL結果の形式を記述する必要があります。SQLの形式は、主に返されるSQL表と列で構成されます。EJBコンテナは、SQLの形式とCMPおよびCMPフィールド・マッピングを使用して問合せからオブジェクトを返します。詳細は、次を参照してください:

- sql-shape

- sql-query

コンテナ管理による関係(CMR)の使用

コンテナ管理による関係(CMR)は2つのエンティティEJB間で定義する関係であり、データベースの表間の関係と似ています。同じ処理タスクに関わる2つのEJB間でCMRを定義した場合、アプリケーションは以下の機能の恩恵を受けることができます。

- 関連するBeanを一緒にキャッシュでき、処理タスクを完遂するために必要な問合せの数を減らすことができる

- バッチ処理されるデータベース操作をトランザクションの最後に正しく順序付けし、データ一貫性の問題を避けることができる

- カスケード削除機能を使用して、関連するBeanを自動的に削除できる

以降の節では、WebLogic Server CMRの特徴と制限について説明します。CMRの構成手順については、「コンテナ管理による関係(CMR)の定義」を参照してください。

CMRの要件と制限

同じJARにパッケージ化され、データが同じデータベースに格納される2つのWebLogic ServerエンティティBeanの間で関係を定義できます。同じ関係に属するエンティティは、同じデータ・ソースにマップされていなければなりません。WebLogic Serverは、データ・ソースの異なるエンティティBean間の関係をサポートしていません。コンテナ管理による関係に参加する各Beanの抽象スキーマは、同じejb-jar.xmlファイルで定義されなければなりません。

EJB 2.1では、エンティティBeanにローカル・インタフェースがない場合、そのBeanが参加できる唯一のCMRはそれ自体から別のエンティティBeanへの一方向のCMRであるとされています。ただし、WebLogic Serverではリモート・インタフェースのみのエンティティBeanに以下のことを許可しています。

- 双方向のCMRに参加する

- 別のエンティティとの一方向CMRのターゲットになる

この機能はEJB 2.1では規定されていないので、リモート・インタフェースしか持たず、双方向の関係に参加するか、一方向の関係のターゲットとなるエンティティBeanは他のアプリケーション・サーバーには移行できない場合があります。

CMRのカーディナリティ

エンティティBeanは、別のエンティティBeanとの間で1対1、1対多、または多対多の関係を持つことができます。

CMRの方向

1対1、1対多、多対多のどれであるかに関係なく、CMRは一方向か双方向のいずれかになります。CMRの方向は、関係の片側のBeanがもう片側のBeanからアクセスできるかどうかを決めます。

一方向のCMRは一方通行であり、「従属」Beanは関係のもう一方のBeanを意識しません。カスケード削除などのCMR関連の機能は、従属Beanにのみ適用できます。たとえば、EJB1からEJB2への一方向のCMRでカスケード削除が構成されている場合、EJB1を削除するとEJB2も削除されますが、EJB2を削除してもEJB1は削除されません。

注意:

カスケード削除の機能には、関係のカーディナリティが影響します。関係が双方向だとしても、カスケード削除は関係の多サイドからはサポートされません。

双方向の関係は両側通行であり、関係の各Beanは他方のBeanを意識しています。CMR関連の機能は、両方向でサポートされます。たとえば、EJB1とEJB2の間の双方向CMRでカスケード削除が構成されている場合、CMRのいずれかのBeanを削除するともう片方のBeanも削除されます。

CMRの削除

関係に参加しているBeanインスタンスが削除されると、コンテナは自動的にその関係を削除します。たとえば従業員と部署の間の関係があるとして、その従業員が削除されると、コンテナはその従業員と部署の間の関係も削除します。

コンテナ管理による関係(CMR)の定義

CMRの定義では、その関係とカーディナリティおよび方向をejb-jar.xmlで指定します。weblogic-cmp-jar.xmlでは、関係のデータベース・マッピング情報を定義し、リレーションシップ・キャッシングを有効にします。手順については、以下を参照してください。

- ejb-jar.xmlでの関係の指定

- weblogic-cmp-jar.xmlでの関係の指定

ejb-jar.xmlでの関係の指定

コンテナ管理による関係は、ejb-jar.xmlのejb-relation要素で定義します。例6-4は、2つのエンティティEJB (TeacherEJBとStudentEJB)間の関係のejb-relation要素を示しています。

ejb-relation要素には、関係の各サイドのejb-relationship-roleがあります。role要素は、各Beanの関係に対する見方を指定します。

例6-4 ejb-jar.xmlでの1対多、双方向のCMR

<ejb-relation>
<ejb-relation-name>TeacherEJB-StudentEJB</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>teacher-has-student
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>TeacherEJB</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>teacher</cmr-field-name>
</cmr-field>
</ejb-relationship-role>
<ejb-relationship-role>
<ejb-relationship-role-name>student-has-teacher
</ejb-relationship-role-name>
<multiplicity>Many</multiplicity>
<relationship-role-source>
<ejb-name>StudentEJB</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>student</cmr-field-name>
<cmr-field-type>java.util.Collection</cmr-field-type>
</cmr-field>
</ejb-relationship-role>

関係のカーディナリティの指定

関係の各サイドのカーディナリティは、ejb-relationship-role要素のmultiplicity要素で示します。

例6-5では、関係TeacherEJB-StudentEJBのカーディナリティは1対多です。このカーディナリティは、TeacherEJB側でmultiplicityをoneに、StudentEJB側ではManyに設定することで指定します。

例6-5のCMRのカーディナリティは1対1です。関係の両方のrole要素でmultiplicityがoneに設定されています。

例6-5 ejb-jar.xmlでの1対1、一方向のCMR

<ejb-relation>
<ejb-relation-name>MentorEJB-StudentEJB</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>mentor-has-student
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>MentorEJB</ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name>mentorID</cmr-field-name>
</cmr-field>
</ejb-relationship-role>
<ejb-relationship-role>
<ejb-relationship-role-name>student-has-mentor
</ejb-relationship-role-name>
<multiplicity>One</multiplicity>
<relationship-role-source>
<ejb-name>StudentEJB</ejb-name>
</relationship-role-source>
</ejb-relationship-role>

関係の片側の<multiplicity>がManyである場合、その<cmr-field>は集合であり、例6-4の関係StudentEJB側のように、<cmr-field-type>をjava.util.Collectionとして指定する必要があります。cmr-fieldが単一値のオブジェクトである場合は、cmr-field-typeを指定する必要はありません。

表6-4は、関係のカーディナリティに基づいて、関係の各Beanのcmr-fieldの内容を示しています。

表6-4 カーディナリティとcmr-field-type

EJB1とEJB2の関係

EJB1のcmr-fieldの内容

EJB2のcmr-fieldの内容

1対1

単一値のオブジェクト

単一値のオブジェクト

1対多

単一値のオブジェクト

集合

多対多

集合

集合

関係の方向の指定

CMRの方向は、関係の各サイドのejb-relationship-role要素でcmr-fieldを含めるかどうかによって構成します。

双方向CMRでは、関係の両サイドのejb-relationship-role要素にcmr-field 要素があります(図6-1を参照)。

一方向の関係では、関係のrole要素の片方だけにしかcmr-fieldがありません。開始側EJBのejb-relationship-roleにはcmr-fieldがありますが、ターゲットBeanのrole要素にはありません。図6-1では、MentorEJBからStudentEJBへの一方向の関係が指定されています。StudentEJBのejb-relationship-role要素にはcmr-field 要素がありません。

weblogic-cmp-jar.xmlでの関係の指定

ejb-jar.xmlで定義される各CMRは、weblogic-cmp-jar.xmlのweblogic-rdbms-relation要素でも定義する必要があります。weblogic-rdbms-relationは関係を識別し、relationship-role-map要素を格納します。この要素は、関係の片側または両側で、関係の参加者間のデータベース・レベルの関係をマップします。

weblogic-rdbms-relationのrelation-nameは、ejb-jar.xmlのCMRのejb-relation-nameと同じでなければなりません。

1対1の関係と1対多の関係

対1の関係と1対多の関係では、関係の片側だけでrelationship-role-mapが定義されます。

1対1の関係の場合、マッピングは片方のBeanの外部キーからもう片方のBeanの主キーです。

図6-1は、MentorEJBとStudentEJB間の1対1の関係のweblogic-rdbms-relation要素です。<ejb-relation>は、図6-1に示してあります。

例6-6 1対1のCMRのweblogic-cmp-jar.xml

<weblogic-rdbms-relation>
<relation-name>MentorEJB-StudentEJB</relation-name>
<weblogic-relationship-role>
<relationship-role-name>
mentor-has-student
</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>student</foreign-key-column>
<key-column>StudentID/key-column>
</column-map>
</relationship-role-map>
</weblogic-relationship-role>

1対多の関係の場合、マッピングは常に片方のBeanの外部キーから別のBeanの主キーです。1対多の関係では、外部キーは常に関係の多サイドにあるBeanと関連付けられます。

例6-7は、TeacherEJBとStudentEJB間の1対多の関係のweblogic-rdbms-relation要素です。<ejb-relation>は、例6-4に示してあります。

例6-7 1対多CMRのweblogic-rdbms-relation

<weblogic-rdbms-relation>
<relation-name>TeacherEJB-StudentEJB</relation-name>
<weblogic-relationship-role>
<relationship-role-name>
teacher-has-student
</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>student</foreign-key-column>
<key-column>StudentID/key-column>
</column-map>
</relationship-role-map>
</weblogic-relationship-role>

多対多の関係

多対多の関係では、関係の各サイドでweblogic-relationship-role要素を指定します。そのマッピングには、結合表が関わります。結合表の各行には、関係に関与するエンティティの主キーに対応する2つの外部キーが格納されます。関係の方向は、関係のデータベース・マッピングを指定する方法に影響しません。

例6-8は、2人の従業員間のfriends関係のweblogic-rdbms-relation要素を示しています。

FRIENDS結合表には、first-friend-idとsecond-friend-idという2つの列があります。各列には、別の従業員の友人である特定の従業員を示す外部キーが格納されます。従業員表の主キー列はidです。例では、従業員Beanが単一表にマップされているものと想定しています。従業員Beanが複数の表にマップされている場合は、主キー列を格納する表をrelation-role-mapで指定する必要があります。例については、「複数の表にマップされるEJBのCMRの指定」を参照してください。

例6-8 多対多CMRのweblogic-rdbms-relation

<weblogic-rdbms-relation>
<relation-name>friends</relation-name>
<table-name>FRIENDS</table-name>
<weblogic-relationship-role>
<relationship-role-name>first-friend
</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>first-friend-id</foreign-key-column>
<key-column>id</key-column>
</column-map
</relationship-role-map>
<weblogic-relationship-role>
<weblogic-relationship-role>
<relationship-role-name>second-friend</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>second-friend-id</foreign-key-column>
<key-column>id</key-column>
</column-map>
</relationship-role-map>
</weblogic-relationship-role>
</weblogic-rdbms-relation>

複数の表にマップされるEJBのCMRの指定

関係に参加するCMP Beanは、複数のDBMS表にマップできます。

- 1対1または1対多の関係の外部キー側のBeanが複数の表にマップされている場合は、外部キー列が含まれる表の名前をforeign-key-table要素で指定する必要があります。

- 逆に1対1または1対多の関係の主キー側のBeanまたは多対多の関係に参加しているBeanが複数の表にマップされている場合は、主キーが含まれる表の名前をprimary-key-table要素で指定する必要があります。

関係のどちら側のBeanも複数の表にマップされていない場合、foreign-key-table要素とprimary-key-table要素は省略可能です(使用される表が暗黙的であるため)。

例6-9は、1対1の関係の外部キー側のBean (Fk_Bean)が2つの表(Fk_BeanTable_1とFk_BeanTable_2)にマップされているCMRのrelationship-role-mapです。

関係の外部キー列(Fk_column_1とFk_column_2)は、Fk_BeanTable_2に配置されています。主キー側のBean (Pk_Bean)は、主キー列Pk_table_pkColumn_1とPk_table_pkColumn_2を持つ1つの表にマップされています。

外部キー列を持つ表は、<foreign-key-table>要素で指定する必要があります。

例6-9 1対1のCMR、1つのBeanの複数表へのマッピング

<relationship-role-map
<foreign-key-table>Fk_BeanTable_2</foreign-key-table>
<column-map>
<foreign-key-column>Fk_column_1</foreign-key-column>
<key-column>Pk_table_pkColumn_1</key-column>
</column-map>
<column-map>
<foreign-key-column>Fk_column_2</foreign-key-column>
<key-column>Pk_table_pkColumn_2</key-column>
</column-map>
</relationship-role-map>

CMRフィールドとCMRフィールド・アクセサ・メソッドについて

CMRフィールドは、実装クラスの属性としては格納されません。CMRフィールドは、記述したCMRフィールドのアクセサ・メソッドを使用してBeanの中でアクセスできます。CMRフィールド・アクセサ・メソッドは次のとおりです。

- get...()およびset...()で始まる必要があり、get.../set...の後のテキストはejb-jar.xmlで宣言されている関係フィールドの名前と同じでなければならない

- 各CMRフィールドの実装クラスに存在している必要がある

- abstractとして宣言する必要がある

リモート・クライアントがCMRフィールドのアクセサ・メソッドを使用できるようにするには、ゲッターおよびセッター・メソッドのシグネチャをリモート・インタフェースに配置します。ただし、Collectionデータ型のCMRフィールドはリモート・インタフェースでエクスポーズできません。Collectionデータ型のCMRフィールドは、ローカル・メソッドでのみアクセスできます。

CMRのエンティティのカスケード削除の使用

カスケード削除が実行される場合、別のbeanインスタンスとの関係に参加しているbeanインスタンスを削除すると、コンテナは従属するすべてのbeanインスタンスも自動的に削除します。この機能では、データの整合性を効率的に維持できます。

たとえば、Employee BeanがEmployee_Projects Beanとの間で1対多の関係にある場合、Employee Beanのインスタンスを削除するとEmployee_Projects Beanのインスタンスも削除されます。

指定できるカスケード削除は1対1関係と1対多関係についてであり、多対多関係については指定できません。

WebLogic Serverは、2通りのカスケード削除をサポートしています。

- Java EEカスケード削除 - この方法では、基底のデータベースでカスケード削除がサポートされている必要がありません。構成するには、次の例のようにejb-jar.xmlでcascade-delete要素を使用します。

<ejb-relation>
<ejb-relation-name>Customer-Account</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>Account-Has-Customer
</ejb-relationship-role-name>
<multiplicity>one</multiplicity>
<cascade-delete/>
</ejb-relationship-role>
</ejb-relation>

注意:

cascade-delete要素は、関係のもう片方のejb-relationship-roleでmultiplicityがoneに設定されている場合にのみejb-relationship-role要素で指定できます。

- データベース・レベルのカスケード削除(Oracleのみ) - この方法では、アプリケーションはデータベースに組み込まれているカスケード削除のサポートを利用でき、パフォーマンスの向上を実現できる場合があります。db-cascade-deleteが有効になっている場合は、基底のデータベースをカスケード削除対応に設定する必要があります。Oracle WebLogic Serverでデータベースのカスケード削除を設定する手順と例については、「db-cascade-delete」を参照してください。

大規模なトランザクション環境では、カスケード削除を実行するトランザクションが、カスケード削除を実行しないトランザクションと同じBeanにアクセスする必要がある場合に、排他的同時実行性を使用するトランザクションでデッドロックが発生する可能性があります。そのようなデッドロックを回避する方法については、「排他的同時実行性およびカスケード削除を使用するデッドロックの回避」を参照してください。

リレーションシップ・キャッシング

リレーションシップ・キャッシング(「プリフェッチ」または「期待されるリレーションシップ・キャッシング」とも呼ばれる)では、関係する複数Beanをキャッシュにロードし、それらに結合問合せを発行して問合せの発行回数を削減することによって、エンティティBeanのパフォーマンスが高められます。Beanの集合が同じ処理単位の中でアクセスされる場合、アプリケーションはそれらを同時にキャッシュにロードする必要があります。

アプリケーションに、次のような関係を持つエンティティBeanが含まれているとします。

customerBean has a one-to-many relationship with  accountBean
accountBean has a one-to-one relationship with addressBean
customerBean has a one-to-one relationship with phoneBean

accountBeanおよびaddressBeanのEJBコード(1対1の関係を持つ)を検討します。

Account acct = acctHome.findByPrimaryKey("103243");
Address addr = acct.getAddress();

リレーションシップ・キャッシングが行われなければ、コードの1行目でaccountBeanをロードするSQL問合せが発行され、2行目でaddressBeanをロードする別のSQL問合せが発行されます。これにより、データベースには2つの問合せが生じます。

リレーションシップ・キャッシングが行われると、accountBeanとaddressBeanの双方をロードする1つの問合せがコードの1行目で発行されるため、パフォーマンスは向上するはずです。したがって、ある特定のファインダ・メソッドの実行後に関連のBeanへのアクセスがあることが分かっている場合は、リレーションシップ・キャッシング機能によってそれをファインダ・メソッドに知らせることをお薦めします。

リレーションシップ・キャッシングの機能には次のような制限があります。

- リレーションシップ・キャッシングは、one-to-one、one-to-many、およびmany-to-oneの関係でサポートされます。many-to-manyの関係ではサポートされていません。

- weblogic-qlを使用した場合、この機能は、EJBObject BeanまたはEJBLocalObject Beanへの参照を返すファインダ・メソッドを使ったときのみ機能します。

ファインダ・メソッドまたは選択メソッドでリレーションシップ・キャッシングを有効にする場合、問合せの結果は、たとえdistinctキーワードを指定していなくても常に異なる集合になります。これは、EJBコンテナが基底のJDBC結果セットで重複を区別できないようにする技術的な限界によるものです。

リレーションシップ・キャッシングが有効な場合は、関係に変更を加えるとそれが自動的にキャッシュでも反映されます。たとえば、1対多の関係の「多」サイドでインスタンスが追加されると、その変更はキャッシュ内の関係でも反映されます。関係の「1」サイドにあるBeanに対してそれ以降問合せを行うと、新しいインスタンスがその問合せから利用可能なように関係がキャッシュで更新されます。

リレーションシップ・キャッシングの有効化

リレーションシップ・キャッシングを有効化するには、次の手順に従います。

1. weblogic-cmp-jar.xmlファイルのweblogic-query要素でcaching-name要素を指定します。
weblogic-query要素でcaching-name要素が指定されている場合、ファインダ問合せが実行されると、WebLogic Serverはcaching-name要素が指定するrelationship-caching要素の指定に従って関連するBeanのデータをロードします。

2. ファインダを格納するBeanのfinders-load-bean要素(weblogic-ejb-jar.xml)が、Falseに設定されていないようにします。Falseの場合は、リレーションシップ・キャッシングが有効になりません。finder-load-beanのデフォルト値はTrueです。

3. weblogic-cmp-jar.xmlファイルでdatabase-type要素を指定します。リレーションシップ・キャッシングは問合せに外部結合を使用し、外部結合の構文はデータベースのタイプによって異なります。

リレーションシップ・キャッシングは結合問合せを使用するので、relationship-caching要素のcaching-element要素の数は結果セットの重複を増加させる場合があります。caching-elementごとに1つずつ1対多の関係を指定すると、結果セットで重複を回避できます。

次の例のように、weblogic-cmp-jar.xmlでrelationship-caching要素を指定します。

<relationship-caching>
<caching-name>cacheMoreBeans</caching-name>
<caching-element>
<cmr-field>accounts</cmr-field>
<group-name>acct_group</group-name>
<caching-element>
<cmr-field>address</cmr-field>
<group-name>addr_group</group-name>
</caching-element>
</caching-element>
<caching-element>
<cmr-field>phone</cmr-field>
<group-name>phone_group</group-name>
</caching-element>
</relationship-caching>

accountsフィールドとphoneフィールドはcustomerBeanのcmrフィールド、addressフィールドはaccountBeanのcmrフィールド、addr_groupとphone_groupはaddressBeanとphoneBeanのグループです。

caching-element要素をネストすることにより、関係するBeanを複数レベルでロードできるようになります。上記のサンプルでは、addressBeanがaccountBean内でネストになっているので、第2レベルの関連Beanにあたります。現在、指定できるcaching-elementの数に制限はありません。しかし、caching-elementのレベルをあまり多く設定しすぎると、そのトランザクションのパフォーマンスに影響すると考えられます。

同時実行性ストラテジの選択

エンティティBeanの同時実行性ストラテジは、EJBコンテナがBeanへの同時アクセスをどのように管理するのかを指定します。つまり、WebLogic Serverが、エンティティのキャッシュされたコピーとデータベースをいつどのように同期させるのかを指定します。

WebLogic Serverでサポートされている同時実行性については、以降の節で説明します。

排他的同時実行性

排他的同時実行性の場合、コンテナはBeanがトランザクションに関連付けられている場合に、キャッシュされたEJBインスタンスを排他的にロックします。EJBインスタンスに対する要求は、トランザクションが完了するまでブロックされます。排他的なロックはサーバー・インスタンスでローカルに行われるので、この方式は単一サーバー・アーキテクチャに最も適しています。クラスタで使用した場合、排他的同時実行性はサーバー・インスタンス内でBeanインスタンスに対する要求をすべてシリアライズしますが、同じBeanに同時にアクセスするクラスタ内のサーバー間の同時実行性はデータベースによって管理されます。

複数のクライアントが排他的同時実行性オプションを使用して、エンティティEJBに連続してアクセスできます。この排他的オプションを使用する場合、2つのクライアントでエンティティEJBの同じインスタンス(主キーが同じインスタンス)へのアクセスが同時に試行されると、2番目のクライアントはEJBが利用可能になるまでブロックされます。

データベース同時実行性

データベース同時実行性を使用する場合、各トランザクションのEJBの同時実行性制御は基底のデータベースに委ねられます。WebLogic Serverは、独立したエンティティBeanインスタンスを各トランザクションに割り当て、同時実行性制御をデータベースで処理できるにようにします。これは現在のデフォルト・オプションです。

Database メカニズムでは、EJBコンテナが継続してエンティティBeanのインスタンスをキャッシュします。しかし、コンテナはトランザクション間のBeanインスタンスの中間状態をキャッシュしません。その代わりとして、WebLogic Serverは、トランザクションの開始時に各インスタンスに対しSQL SELECTを発行して最新のEJBデータを取得します。SQL UPDATEは、変更がある場合に発行されます。

続いて、データのコミット要求がデータベースに送られます。このためデータベースは、EJBのデータの同時実行性制御とデッドロックの検出をすべて処理します。

オプティミスティック同時実行性

Database同時実行性ストラテジの場合と同じように、Optimistic同時実行性ストラテジでは各トランザクションにそれ専用のBeanインスタンスが割り当てられます。Optimistic同時実行性ストラテジは、トランザクションの実行中、EJBコンテナまたはデータベースでどのようなロックも行いません。

注意:

読込みロックを行うデータベース(Oracle以外のデータベース)では、オプティミスティックなBeanは独立したローカルのトランザクションでデータを読み込みます。そのローカル・トランザクションは、読込みが完了するとすぐコミットされます。この方式では読込みロックが回避され、複数のトランザクションが同じデータを同時に更新しない場合にスケーラビリティを向上させることができます。

オプティミスティックなBeanデータが古くなるのを防ぐ

オプティミスティックなデータが古くなるのを防ぐために、コンテナはトランザクションごとに新しいBeanインスタンスをアクティブ化して、複数の要求を並行処理します。cache-between-transactionsの値がTrueの場合、WebLogic Serverはread-timeout-secondsの値に基づいてエンティティBeanのejbLoad()を呼び出します。

オプティミスティックなBeanを明示的に無効化する

基底データがEJBコンテナの外部で更新された場合、オプティミスティックなBeanを明示的に無効にできます(「バックドア更新」とも呼ぶ)。詳細については、「エンティティEJBの明示的な無効化」を参照してください。

クラスタ内のオプティミスティック同時実行性の無効化オプション

デフォルトによって、concurrency-strategyがOptimisticであるBeanがクラスタにデプロイされており、クラスタのメンバーがそのBeanを更新した場合、EJBコンテナは、クラスタ内のすべてのサーバーに存在するそのBeanのすべてのコピーを無効にしようとします。この無効化の処理によって、オプティミスティック同時実行性の失敗を防ぐことができます。しかし、この処理はリソースを大量に消費するため、パフォーマンスが低下する可能性があります。必要な場合、weblogic-cmp-jar.xmlのcluster-invalidation-disabledをTrueに設定して、EJBコンテナがクラスタ内のBeanのコピーを無効化しないようにできます。

オプティミスティック同時実行性でのデータ有効性のチェック

トランザクションで読み込みまたは更新されたデータが別のトランザクションで変更されていないことを検証するために、トランザクションのコミットの前にオプティミスティックなBeanのトランザクション・データを検証するようにEJBコンテナを構成できます。データの変更が検出された場合、EJBコンテナはトランザクションをロールバックします。

注意:

EJBコンテナは、Optimistic同時実行性ではBeanのBlobまたはClobフィールドを検証しません。これを回避するには、バージョン・チェックまたはタイムスタンプ・チェックを行います。

Optimistic同時実行性のBeanの有効性チェックを構成するには、weblogic-cmp-jar.xmlファイルのそのBeanのtable-map要素でverify-columns要素とverify-rows要素を使用します。

verify-rows要素は、オプティミスティック同時実行性の使用時にEJBコンテナがチェックすべきである、表内の行を指定します。verify-columns要素は、オプティミスティック同時実行性ストラテジを使用する場合に、表の列の有効性がどのようにチェックされるのかを指定します。

1. verify-rows要素の設定値は以下のとおりです。

- Read - トランザクションの間に参照した表のすべての行をチェックします。これには、単に読み込まれるだけの行と、読み込まれた後でトランザクションによって更新または削除される行の両方が含まれます。すべての行をチェックすると、通常はEJBコンテナで実行しなければならないオプティミスティック・チェックの量が増えるのでオーバーヘッドが大きくなります。Readオプションを使用する場合、コミットされたトランザクションは、トランザクションがコミットされるまで別のトランザクションで修正されることのない行を読み込みます。その結果として、SERIALIZABLEの一貫性のANSI定義と非常に近い高度な一貫性が実現します。

- Modified - 現在のトランザクションで更新または削除した行だけをチェックします。この設定にすると、2つのトランザクションが同時に同じ行を更新することがなく、更新が損失することはありませんが、異なるトランザクションで読込みと更新を交互に行うことは可能です。その結果、得られる一貫性のレベルは、ANSIのREAD_COMMITTEDレベルとREPEATABLE_READレベルの間になります。

2. verify-columns要素の設定値は以下のとおりです。

- Read - トランザクションの間に参照した表のすべての列をチェックします。これには、単に読み込まれるだけの行と、読み込まれた後でトランザクションによって更新または削除される行の両方が含まれます。

- Modified - 現在のトランザクションで更新または削除した列だけをチェックします。

注意:

verify-rowsがReadに設定されていると、verify-columns要素ではModifiedを指定できません。この組み合わせでは、修正された行だけがチェックされることになるためです。

- Version - 表にバージョン列が含まれ、この列がオプティミスティック同時実行性を実施するのに使われていることをチェックします。
Version列は、初期値0または正の整数で作成し、行が変更される度に1ずつ加算されるようにしてください。詳細については、「version-column-initial-value」を参照してください。

また、データベース・トリガーを使用してデータベース内のバージョン列を更新し、trigger-updates-optimistic-columnをTrueに設定した場合、データベース・トリガーはBeanの作成時にデータベース内のバージョン列を初期化する必要があります。

- Timestamp - 表にタイムスタンプ列が含まれ、この列がオプティミスティック同時実行性を実施するのに使われていることをチェックします。タイムスタンプ・ベースのオプティミスティック同時実行性では、このデータベース列の粒度を1秒にする必要があります。

デフォルトによって、EJBコンテナはバージョンおよびタイムスタンプ列を管理し、これらの列を常に最新の状態に保ちます。代わりに、データベース・トリガーによってバージョンおよびタイムスタンプ列が管理されるようにする場合、trigger-updates-optimistic-columnの値をTrueに設定します。

注意:

バージョンまたはタイムスタンプ列は、トランザクションが通常のCMPまたはCMRフィールドを修正しなかった場合は更新されません。トランザクションの過程で変更された唯一のデータがバージョンまたはタイムスタンプ列の値である場合(トランザクションの開始の結果として)、オプティミスティック・チェックで使用される列はトランザクションの最後に更新されません。

3. verify-columnsがVersionまたはTimestampに設定されている場合、以下のことを行います。

1. weblogic-cmp-jar.xmlファイルのtable-map要素のoptimistic-columnを使用してバージョンまたはタイムスタンプ列を指定します。この列をcmp-fieldにマップするかどうかは任意です。
optimistic-column要素は、オプティミスティック同時実行性を実装するためのバージョン値またはタイムスタンプ値を格納するデータベース列を示します。すべてのデータベースで大文字と小文字が区別されるわけではありませんが、この要素では大文字と小文字がそのまま維持されます。この要素の値は、verify-columnsがVersionまたはTimestampに設定されていない場合は無視されます。

2. weblogic-cmp-jar.xmlファイルのversion-column-initial-value要素を使用してバージョン列の初期値を指定します。

EJBが複数の表にマップされる場合、トランザクション中に更新した表に対してのみオプティミスティックなチェックが実行されます。

オプティミスティック同時実行性とOracleデータベース

Oracleデータベースでは、CMPのキー以外のフィールドの型がjava.util.Dateで実装型がOracle DATEであるエンティティEJBでverify-columnsをModifiedに設定すると、キーではないDATEフィールドに対して単純な更新が行われたときに、たとえ1人のユーザーしかレコードを更新していなくてもWebLogic Serverがオプティミスティック同時実行性の違反例外を送出します。

この問題は、Oracle DATE列とjava.util.Date型の日付値の精度が異なるために発生します。java.util.Date型はミリ秒単位ですが、Oracle DATE列は違います。このエラーは、以下の2通りの方法で防止できます。

- Oracleデータベースの列の型をTimestamp (Oracle9iで導入されたより精度の高い型)に設定します。

- java.util.Date値のミリ秒を削除するロジックをアプリケーションに追加します。そのためには、次のようにしてエンティティBeanのjava.util.Dateフィールドに合わせて日付フィールドを準備します。

Calendar cal = Calendar.getInstance();
cal.set(Calendar.MILLISECOND, 0); // clears millisecond
Date myDate = cal.getTime();

読取り専用同時実行性

Beanが読取り専用であることを示すために使用します。コンテナは、複数の要求が並行して処理されるように各トランザクションで新しいBeanインスタンスをアクティブ化します。WebLogic Serverは、read-timeout-secondsパラメータに基づいて読取り専用BeanのejbLoad()を呼び出します。

このリリースのWebLogic Serverでは、読取り専用Beanのコードを効率化するために、ReadOnly同時実行性を使用するEJBで作成と削除は許可されていません。

読取り専用Beanが作成および削除操作を使用できるようにするには、weblogic-cmp-jar.xmlのallow-readonly-create-and-remove要素をTrueに設定します。

同時実行性ストラテジのトレードオフ

同時実行性は、パフォーマンスとデータの鮮度の間でトレードオフを生じさせます。アプリケーションでどの要素がより重要であるかに基づいて、同時実行性ストラテジを選択してください。トレードオフについては、表6-5を参照してください。

表6-5 同時実行性ストラテジのトレードオフ

同時実行性ストラテジ

メリット

リスクと制限

選択する場合

Database

同時実行性制御をデータベースに委ねると、データへの同時アクセスの点で排他的同時実行性と比べてスループットが向上するとともに、デッドロックが検出されるようになります。

デッドロックのリスクがあります。各トランザクションがデータベースから更新ロックを取得する必要があるため。

デッドロックのリスクを小さくするには、次でuse-select-for-updateを設定します:weblogic-cmp-jar.

xml。そうすると、読込みが行われるときにデータベースが排他的ロックを解除し、読込みロックが排他的なロックにアップグレードされたときに発生するデッドロックが回避されます。

Beanのデータベースのロック・ポリシーに対する依存度を高めます。Beanの移植性が低下する場合があります。

データベース同時実行性の制御がアプリケーションにとって十分であり、コンテナ提供の追加機能が必要ない場合。

注意 : transaction-isolation要素は、望ましい同時実行性の動作を実現するためにデータベース同時実行性と一緒に使用します。

Optimistic

トランザクションの間にEJBコンテナまたはデータベースでロックが行われないため、最高レベルの同時アクセスが実現します。

複数のトランザクションが同時に同じアプリケーション・データにアクセスできます。

複数のトランザクションが同時に同じアプリケーション・データを修正することが考えられない場合。

Exclusive

高度な一貫性を実現するために、単一サーバー(クラスタ化されていない環境)でEJBデータへのアクセスをシリアライズします。ロックのアップグレードに起因するデッドロックを回避し、ejbLoad()を不必要に呼び出してBeanインスタンスの永続フィールドをリフレッシュするのを防ぎます。

パフォーマンスが低下することがあります。いったんクライアントがEJBインスタンスをロックすると、他のクライアントは読込みアクセスのみが必要な場合でもそのEJBのデータからブロックされてしまいます。

この方式に依存するアプリケーションに下位互換性を提供する場合。

高レベルの同時実行性が不可欠で、それがパフォーマンスよりも重要であるアプリケーションで使用します。

Read Only

なし

なし

なし

同時実行性ストラテジの構成

Beanで同時実行性メカニズムを指定するには、weblogic-ejb-jar.xmlでentity-cache要素のconcurrency-strategy要素を設定します。concurrency-strategyはBeanレベルで定義されるので、同じアプリケーションでも異なるBeanは必要に応じて別々の同時実行性を使用できます。

concurrency-strategyを指定しない場合、WebLogic ServerはデフォルトでDatabase同時実行性を使用します。

排他的同時実行性とカスケード削除を使用するデッドロックの防止

スループットが高い状況では、カスケード削除を実行するトランザクションが、カスケード削除を実行しないトランザクションと同じエンティティBeanにアクセスする必要がある場合に、排他的同時実行性ストラテジを使用するトランザクションでデッドロックが発生する可能性があります。

このようなデッドロックは、weblogic-cmp-jar.xmlデプロイメント記述子ファイルのlock-order要素を使用して回避できます。lock-orderは、関連するBeanのカスケード削除の過程でBeanがロックされる順序を定義します。その値は、整数値です。lock-orderの値が最低のBeanは最初に処理され、次に低いlock-order値のBeanがその次に処理されます。

指定するロックの順序は、アプリケーションの他のトランザクションで使用されるロックの順序と同じでなければなりません。

lock-orderを指定すると、他のトランザクションと同じ順序でカスケード削除がBeanインスタンスをロックします。通常のロック順序がBeanA、BeanBの順である場合に、このlock-orderを指定すると、カスケード削除でもその順序が使用されます。

read-mostlyパターンの使い方

あまり更新されない永続データの場合は、読取り専用エンティティBeanと読み書き対応エンティティBeanを同じデータにマップすることでWebLogic Serverで「read-mostlyパターン」を実装できます。読取り専用エンティティBeanは読込みに、読み書き対応エンティティBeanは書込みに使用します。

読取り専用エンティティEJBは、weblogic-ejb-jar.xmlでそのBeanのentity-cache (またはentity-cache-ref)要素のread-timeout-seconds要素に指定された間隔でBeanのデータをロードします。読取り専用Beanが常に最新のデータを返すようにするには、読み書き対応BeanがエンティティBeanのデータを変更するときに読取り専用Beanを無効にする必要があります。WebLogic Serverが読取り専用Beanを自動的に無効化するように構成するか、Beanコードで明示的に無効化することができます。詳細については、それぞれ「読取り専用エンティティEJBの暗黙的な無効化」および「エンティティEJBの明示的な無効化」を参照してください。

WebLogic Serverクラスタでread-mostlyパターンを利用すると、読取り専用EJBのクライアントではキャッシュからの読込みでパフォーマンスが向上し、読み書き対応EJBのクライアントでは真のトランザクション動作が実現します(read-write EJBのキャッシュされた状態が常にデータベースの永続データと一致します)。

エンティティBeanのread-mostlyパターンの構成

以下のプラクティスを行うと、read-mostlyパターンでデータ一貫性の問題が発生する可能性が低下します。

- weblogic-ejb-jar.xmlでの読取り専用Beanのread-timeout-seconds要素の構成

- 同じトランザクションで更新できるすべてのBeanで同じ値に設定します。

- 許容可能なパフォーマンス・レベルになる最短の期間に設定します。

- 読み書き対応Beanの設計

- 必要最低限のデータ・セットを更新するようにします。ejbStore()のたびに変更のない多くのフィールドをデータ・ストアに書き込むBeanを実装しないようにします。

- データを適時に更新するようにします。読取り専用Beanのread-timeout-seconds設定を超える時間の長いトランザクションでは読み書き対応Beanを使用しないようにします。

- 読み書き対応BeanがBeanのデータを更新するときに読み書き対応Beanに対応する読取り専用Beanを無効化します。

EJB 2.xを実行する場合は、オプティミスティック同時実行性を使用する単一Beanでread-mostlyパターンを模倣することができます。オプティミスティックなBeanは、読込みを実行するときに読取り専用Beanのように機能します(キャッシュから読み込み、古いデータを返すことがあります)。ただし、オプティミスティックなBeanが書込みを実行するときは、コンテナによって更新対象のデータが変更されていないようにします(データベース同時実行性を使用するBeanと同じレベルの書込みの一貫性が提供されます)。「同時実行性ストラテジの選択」を参照してください。

読取り専用エンティティEJBの暗黙的な無効化

weblogic-ejb-jar.xmlのentity-descriptor要素のinvalidation-target要素は、CMPエンティティBeanが修正されたときに無効化すべき読取り専用エンティティEJBを特定します。

invalidation-targetは、EJB 2.x CMPエンティティBeanでのみ指定できます。ターゲットのejb-nameは、読取り専用エンティティEJBでなければなりません。

エンティティEJBの明示的な無効化

このリリースのWebLogic Serverでは、cache-between-transactionsが有効化されているオプティミスティックなエンティティBeanを無効化できます。そのためには、CachingHomeまたはCachingLocalHomeインタフェースの次のinvalidate()メソッドを呼び出します。

例6-10 CachingHomeインタフェースとCachingLocalHomeインタフェース

package weblogic.ejb;

public interface CachingHome {
public void invalidate(Object pk) throws RemoteException;
public void invalidate (Collection pks) throws RemoteException;
public void invalidateAll() throws RemoteException;

public interface CachingLocalHome {
public void invalidate(Object pk) throws RemoteException;
public void invalidate (Collection pks) throws RemoteException;
public void invalidateAll() throws RemoteException
}

次のサンプル・コードは、ホームをCachingHomeにキャストしてからメソッドを呼び出す方法を示したものです。

例6-11 ホームのキャストとメソッドの呼出し

import javax.naming.InitialContext;
import weblogic.ejb.CachingHome;

Context initial = new InitialContext();
Object o = initial.lookup("CustomerEJB_CustomerHome");
CustomerHome customerHome = (CustomerHome)o;

CachingHome customerCaching = (CachingHome)customerHome;
customerCaching.invalidateAll();

invalidate()メソッドを呼び出すと、エンティティBeanはローカル・サーバー・インスタンスで無効化されます。サーバー・インスタンスがクラスタに属している場合は、Beanのキャッシュされたコピーを無効化するように他のクラスタ化されたサーバーにメッセージがマルチキャストされます。無効化された読取り専用エンティティBeanに対して次にgetXXX()が呼び出されたときには、コンテナはBeanの永続データの最新バージョンをデータベースからエンティティ・キャッシュにロードします(「ejbLoad()とejbStore()の動作について」を参照)。

WebLogic Serverは、更新トランザクションの完了後にinvalidate()を呼び出します。トランザクションの更新中に無効化処理が行われた場合、トランザクションのisolation-levelでコミットされていないデータの読出しが許可されていないと、更新前のデータが読み出される可能性があります。

機能別のCMPエンティティBeanの記述子

以下の節では、CMPエンティティBeanのWebLogic Server固有のデプロイメントを簡単に参照できます。各節では、特定のタイプの機能または動作に関連する要素が取り上げられています。各節の表では、制御する動作、その要素が含まれるweblogic-cmp-jar.xmlの親要素、およびweblogic-cmp-jar.xmlで明示的に指定しない場合に予想される動作に基づいて関連要素が定義されています。

- コンテナ管理による関係の要素

- 主キーの要素

コンテナ管理による関係の要素

次の表に、weblogic-cmp-jar.xmlのコンテナ管理による関係要素を示します。

表6-6 weblogic-cmp-jar.xmlのコンテナ管理による関係要素

要素

説明

relation-name

関係の名前。

注意: 関係のejb-relation-nameがejb-jar.xmlで指定されている場合、relation-nameの値はejb-relation-nameと同じでなければなりません。

relationship-role-name

関係ロールの名前。(関係には、各サイドに1つで2つのロールがあります。)

1対1または1対多の関係の場合は、foreign-key側のロールのみ指定します。例については、「1対1の関係の定義」および「1対多の関係の定義」を参照してください。

多対多の関係の場合は、関係の両側でロールを指定します。例については、「多対多の関係の定義」を参照してください。

注意 : <relationship-role-

name>の値は、ejb-jar.xmlのejb-relationship-roleの名前と同じでなければなりません。

foreign-key-column

関係のキー列マッピングのターゲット側を指定します(外部キー列)。

key-column

関係のキー列マッピングの開始側を指定します(主キー列)。

主キーの要素

次の表に、weblogic-cmp-jar.xmlの主キー要素を示します。

表6-7 weblogic-cmp-jar.xmlの主キー要素

要素

説明

デフォルト値

generator-type

主キーの生成に使用する機能を特定します。値は、Oracle、SQLServer、SQLServer2000、またはNamedSequenceTable。

なし

generator-name

Oracle SEQUENCE (使用するSEQUENCE表の名前)を定義します。

なし

key-cache-size

キー・キャッシュのサイズを指定します。

1

create-default-dbms-table

EJBコンテナがデータベース表を作成するのか、およびどのように作成するのかに関連する動作を指定します。

Disabled

7 メッセージドリブンEJB

『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』では、メッセージドリブンBean(MDB)のライフサイクル、設計上の考慮事項、および主要な実装タスクの手順について説明します。EJB開発の全体的なプロセスについては、「Enterprise JavaBeansの実装」を参照してください。

8 Enterprise JavaBeansのデプロイメント・ガイドライン

この章では、EJB固有のデプロイメント・ガイドラインについて説明します。すべてのデプロイ可能なアプリケーション・ユニットに共通のデプロイメント・トピックについては、『Oracle WebLogic Serverへのアプリケーションのデプロイ』(WebLogic Serverアプリケーションおよびモジュールのデプロイメントに関する包括的なガイド)のトピックへの相互参照を参照してください。

- EJBをデプロイする前に

- デプロイメント・タスクの概要と実行

- EJBデプロイメントのガイドライン

EJBをデプロイする前に

デプロイメントのプロセスを開始する前に、以下の準備が必要です。

- 展開ディレクトリ形式の、またはデプロイメント記述子と一緒にアーカイブ・ファイル(スタンドアロンEJBの場合はJAR、EJBがエンタープライズ・アプリケーションの一部である場合はEAR)にパッケージされた、動作可能でテスト済みのBeanコード。プロダクション環境では、アプリケーションをEARとしてパッケージ化することをお薦めします。
EJBの作成とパッケージ化に必要な手順の概要については、「EJB開発プロセスの概要」を参照してください。

- 必要なデプロイメント記述子の構成。ejb-jar.xml、weblogic-ejb-jar.xml、およびコンテナ管理による永続性を使用するエンティティEJBの場合はweblogic-cmp-jar.xml。
EJBデプロイメント記述子の作成については、「デプロイメント記述子を生成する」を参照してください。

デプロイメント・タスクの概要と実行

表8-1は、デプロイメント方法についての決定を支援したり、デプロイメント・タスクを実行する手順を説明したりするWebLogic Serverドキュメントのトピックへのガイドです。EJB固有のデプロイメント・トピックについては、「EJBデプロイメントのガイドライン」を参照してください。

表8-1 デプロイメントのタスクとトピック

目的とする作業

参照先

開発環境でのデプロイメント

『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項

デプロイメント・ツールの選択

『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・ツールに関する項

デプロイメント用の適切なパッケージ化の指定

『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーションおよびモジュールのデプロイメント準備に関する項

分割ディレクトリ構造でのEJBコンポーネントの配置

『Oracle WebLogic Serverへのアプリケーションのデプロイ』のEJBに関する項

ステージング・モードの選択

『Oracle WebLogic Serverへのアプリケーションのデプロイ』のステージング・モードによるデプロイメント・ファイルのコピーの制御に関する項

特定のデプロイメント・タスクの実行

『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・プロセスの概要に関する項

EJBデプロイメントのガイドライン

以降の節では、EJBをデプロイするためのガイドラインを示します。

- エンタープライズ・アプリケーションの一部としてのEJBのデプロイメント

- お互いに呼出しあう複数のEJBの同じアプリケーションでのデプロイメント

- 依存関係インジェクションを使用するEJBのデプロイメント

- クラスタへの均一なデプロイメント

- 固定EJBのクラスタへのデプロイメント

- EJBの再デプロイメント

- FastSwapデプロイメントによるデプロイメントの最小化

- 警告メッセージについて

- EJBデプロイメントの警告メッセージの無効化

エンタープライズ・アプリケーションの一部としてのEJBのデプロイメント

スタンドアロンのEJBアプリケーションは、エンタープライズ・アプリケーションの一部としてパッケージ化およびデプロイすることをお薦めします。エンタープライズ・アプリケーションは、Webアプリケーション、EJB、およびリソース・アダプタが1つのデプロイメント・ユニットにまとめられたJava EEデプロイメント・ユニットです。

これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト・プラクティスです。また、アプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリ環境の概要に関する項を参照してください。

お互いに呼出しあう複数のEJBの同じアプリケーションでのデプロイメント

あるアプリケーションのEJBが別のアプリケーションのEJBを呼び出す場合、WebLogic Serverはクラスローディング上の必要からメソッドの引数を値で渡します。EJBが同じアプリケーション内にある場合、WebLogic Serverは参照によってメソッド引数を渡せます。それにより、パラメータのコピーが行われないので、メソッド呼出しのパフォーマンスが向上します。

最高のパフォーマンスを引き出すには、お互いに呼出しあうコンポーネントを同じアプリケーションにパッケージ化し、weblogic-ejb-jar.xmlのenable-call-by-referenceをTrueに設定します。デフォルトでは、enable-call-by-referenceはFalseです。

依存関係インジェクションを使用するEJBのデプロイメント

EJBで依存関係インジェクションを使用する場合、クラスで定義したリソース名とスーパークラスは、ユニークでなければなりません。例:

public class ClientServlet extends HttpServlet {
@EJB(name = 'DateServiceBean', beanInterface = DateService.class)
private DateService bean; .... }
public class DerivedClientServlet extends ClientServlet {
@EJB(name = MyDateServiceBean', beanInterface = DateService.class)
private DateService bean; .... }

依存関係インジェクションについては、『Oracle WebLogic Serverアプリケーションの開発』のJava EEアノテーションと依存関係インジェクションの使用に関する項を参照してください。

クラスタへの均一なデプロイメント

EJBがWebLogic Serverクラスタで動作する場合は、それらのEJBを均一に(クラスタ内の各管理対象サーバーに)デプロイすることをお薦めします。EJBは、クラスタ内の1つのサーバーのみにデプロイする(つまり、モジュールをサーバーに"固定"する)こともできます。このタイプのデプロイメントはそれほど一般的ではなく、固定サービスが要求される特別な状況においてのみ行うようにする必要があります。詳細は、『Oracle WebLogic Serverクラスタの使用』のクラスタの構成についてに関する項を参照してください。

固定EJBのクラスタへのデプロイメント

JARファイルに未コンパイルのクラスおよびインタフェースが含まれているときに、クラスタ内の単一のサーバー・インスタンスへEJBをデプロイまたは再デプロイする場合(固定デプロイメント)に関して、確認済みの問題があります。

未コンパイルのEJBは、デプロイ中にクラスタ内の各サーバー・インスタンスにコピーされますが、このEJBはデプロイ先のサーバー・インスタンス上でしかコンパイルされません。その結果、クラスタ内でEJBのターゲットとなっていないサーバー・インスタンスでは、EJBの呼出しに必要な、コンパイル中に生成されるクラスが不足します。別のサーバー・インスタンスのクライアントが固定EJBを呼び出そうとしても失敗し、RMIレイヤーでアサーション・エラーが送出されます。

クラスタ内の1つのサーバー・インスタンスにEJBをデプロイまたは再デプロイする場合は、生成されたクラスが、クラスタ内のすべてのノードで利用可能なすべてのサーバー・インスタンスに必ずコピーされるように、デプロイ前にそのEJBをappcでコンパイルしてください。

固定デプロイメントの詳細は、『Oracle WebLogic Serverクラスタの使用』の単一のサーバー・インスタンスへのデプロイ(固定デプロイメント)に関する項を参照してください。

EJBの再デプロイメント

デプロイしたEJBのクラスに変更を加えたら、そのEJBを再デプロイする必要があります。自動デプロイメントを使用すると、WebLogic Serverの再起動時にデプロイメントが自動的に行われます。それ以外の場合は、EJBを明示的に再デプロイする必要があります。

EJBデプロイメントを再デプロイすると、EJBプロバイダがデプロイ済みのEJBクラスを変更し、再コンパイルしてから、動作中のサーバーのクラスを「更新」できるようになります。

再デプロイを行うと、そのEJBで現在ロードされているクラスがサーバー内ですぐに使用不可になったことが示され、EJBのクラスローダーと関連クラスが削除されます。同時に、改版されたEJBのクラスをロードして維持する新規のEJBクラスローダーが作成されます。

クライアントが次にEJBへの参照を必要とする場合、クライアントのEJBメソッドの呼出しでは、変更済みのEJBクラスが使用されます。

EJBは、スタンドアロンで、またはアプリケーションの一部として、weblogic.Deployerツールまたは管理コンソールを使用して再デプロイできます。手順については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番環境でのアプリケーションの再デプロイに関する項を参照してください。

以下のものに対しては、プロダクション再デプロイメントはサポートされません。

- JTSドライバを使用するアプリケーション。

- EJB 1.1のコンテナ管理による永続性(CMP) EJBを含むアプリケーション。CMP EJBを含むアプリケーションでプロダクション再デプロイメントを使用するには、EJB 1.1 CMPではなくEJB 2.x CMPを使用します。

本番再デプロイメントの制限の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番再デプロイメントの要件と制限事項に関する項を参照してください。

FastSwapデプロイメントによるデプロイメントの最小化

あるEJBアプリケーションを繰返し開発する場合は、EJBの実装クラス・ファイルに多くの変更を加えて、通常は開発中に何度もEJBモジュールを再デプロイします。

Java EE 5では、ClassLoaderを削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。

FastSwapを使用すると、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、変更がアプリケーションによって再デプロイされて有効になるまで待つ必要はありません。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。

FastSwapの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。

警告メッセージについて

特定の警告に関する詳細情報は、weblogic.GetMessageツールで取得できます。例:

java weblogic.GetMessage -detail -id BEA-010202

EJBデプロイメントの警告メッセージの無効化

WebLogic Serverでは、デプロイメント中に発生する特定の警告メッセージを無効化できます。この機能は、すでにわかっている情報をメッセージが通知する場合に便利です。

たとえば、EJBのメソッドが値ではなく参照で呼出しを行う場合、WebLogic Serverはデプロイメントの過程で「Call-by-reference not enabled.」という警告メッセージを生成します。

weblogic-ejb-jar.xmlでdisable-warning要素を使用すると、特定のメッセージを無効化できます。無効にできるメッセージのリスト、およびメッセージを無効にする手順については、「disable-warning」を参照してください。

A デプロイメント記述子スキーマおよび文書型定義リファレンス

以下の節では、WebLogic ServerのEJB XSDベースのデプロイメント記述子とネームスペース宣言、および9.0より前リリースのWebLogic ServerのEJB DTDベースのデプロイメント記述子とDOCTYPEヘッダーについて説明します。

WebLogic Serverのデプロイメント記述子はXMLスキーマ定義(XSD)に基づいています。9.0より前のリリースのWebLogic Serverでは、デプロイメント記述子はドキュメント型定義(Document Type Definition : DTD)に基づいていました。下位互換性を保持するために、WebLogic Serverは、XSDベースとDTDベースのデプロイメント記述子をサポートしています。このため、DTDベースのデプロイメント記述子を使用するアプリケーションも記述子を変更せずにデプロイできます。

注意:

EJB 3.x実装でJava EE 6メタデータ・アノテーションを使用している場合は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEJBメタデータ・アノテーション・リファレンスに関する項を参照してください。

以下の節では、このリリースのWebLogic ServerのEJB XSDベースのデプロイメント記述子とネームスペース宣言、および9.0より前リリースのWebLogic ServerのEJB DTDベースのデプロイメント記述子とDOCTYPEヘッダーについて説明します。

- XMLスキーマ定義とネームスペース宣言

- 文書型定義およびDOCTYPEヘッダー情報

WebLogic Server EJBデプロイメント記述子の要素については、以下の節を参照してください。

- weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス

- weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス

EJB 1.1デプロイメント記述子の要素については、「EJB 1.1ユーザーへの重要な情報」を参照してください。

XMLスキーマ定義とネームスペース宣言

デプロイメント記述子ファイルの内容と要素の配置は、適切なXSDに準拠している必要があります。

XSDデプロイメント記述子ファイルでは、ルート要素にネームスペース宣言が必要です。デプロイメント記述子ファイルのルート要素のネームスペース宣言は、その記述子のすべての要素に適用されます。ただし、特定の要素の中にルート・ネームスペース宣言をオーバーライドする別のネームスペース宣言が含まれている場合を除きます。

注意:

DDConverterを使用してDTDベースのデプロイメント記述子をXSDベースに変換する場合、適切なネームスペース宣言が記述子ファイルに自動的に書き込まれます。

XMLデプロイメント記述子ファイルには、ネームスペース宣言と共にスキーマのURLを常に書き込むことをお薦めします。スキーマURLを書き込まない場合、サード・パーティ・ツールで記述子ファイルを編集できない場合があります。

weblogic-ejb-jar.xmlのネームスペース宣言とスキーマの場所

WebLogic Serverのweblogic-ejb-jar.xmlファイルのネームスペース宣言とスキーマの場所を表す正確なテキストは次のとおりです。

<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar  http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.1/weblogic-ejb-jar.xsd">
...
</weblogic-ejb-jar>

weblogic-cmp-jar.xmlのネームスペース宣言とスキーマの場所

WebLogic Serverのweblogic-cmp-jar.xmlファイルのネームスペース宣言とスキーマの場所を表す正確なテキストは次のとおりです。

<weblogic-rdbms-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-rdbms-jar" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-rdbms-jar/1.0/weblogic-rdbms-jar.xsd">
...
</weblogic-rdbms-jar>

ejb-jar.xmlのネームスペース宣言とスキーマの場所

Enterprise JavaBeans 2.1のejb-jar.xmlファイルのネームスペース宣言とスキーマの場所を表す正確なテキストは次のとおりです。

<ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
...
</ejb-jar>

文書型定義およびDOCTYPEヘッダー情報

旧リリースのWebLogic Serverでは、デプロイメント記述子ファイルの内容と要素の配置は、適切なDTDに準拠している必要がありました。

WebLogic Serverでは、XMLデプロイメント・ファイルのDOCTYPEヘッダーに埋めこまれたDTDの場所は無視され、代わりにサーバーと一緒にインストールされたDTDの場所が使用されます。ただし、DOCTYPEヘッダー情報には、パーサー・エラーを避けるために有効なURL構文を指定する必要があります。

XMLデプロイメント・ファイルの編集、作成時に、各デプロイメント・ファイルに対して正しいDOCTYPEヘッダーを指定することが重要です。特に、DOCTYPEヘッダー内部に不正なPUBLIC要素を使用すると、原因究明が困難なパーサー・エラーになることがあります。

このヘッダーは、デプロイメント記述子の文書型定義(DTD)ファイルの場所およびバージョンを表します。このヘッダーは外部URLのjava.sun.comを参照していますが、WebLogic Serverには独自のDTDファイルが用意されているので、ホスト・サーバーがインターネットにアクセスする必要はありません。ただし、この要素のDTDのバージョンはデプロイメント記述子のバージョンの識別に使用されるので、<!DOCTYPE...>要素をweblogic-ejb-jar.xmlファイルおよびweblogic-cmp-jar.xmlファイルに含めて、外部URLを参照させる必要があります。

XMLの解析ツール(appcなど)でヘッダー情報が不正なXMLファイルを解析すると、次のようなエラー・メッセージが表示されることがあります。

SAXException: This document may not have the identifier `identifier_name'

identifier_nameには通常、PUBLIC要素内の不正な文字列が表示されます。

表A-1に、WebLogic Server固有のweblogic-ejb-jar.xmlファイルのPUBLIC要素の正確なテキストをWebLogic Serverのリリース別に示します。

表A-1 weblogic-ejb-jar.xmlのPUBLIC要素

WebLogic Serverのリリース

XMLファイル

PUBLIC要素の文字列

8.1.x

weblogic-ejb-jar.xml

'-//BEA Systems, Inc.//DTD WebLogic 8.1.0 EJB//EN' 'http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd'

7.0.x

weblogic-ejb-jar.xml

'-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN' 'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'

6.1.x

および

6.0.x

weblogic-ejb-jar.xml

'-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'

5.1.0

weblogic-ejb-jar.xml

'-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN'

'http://www.bea.com/servers/wls510/dtd/weblogic-ejb-jar.dtd'

表A-2に、WebLogic Server固有のweblogic-cmp-jar.xmlファイルのPUBLIC要素の正確なテキストをWebLogic Serverのリリース別に示します。

表A-2 weblogic-cmp-jar.xmlのPUBLIC要素

WebLogic Serverのリリース

XMLファイル

PUBLIC要素の文字列

8.1.x

weblogic-cmp-jar.xml

'-// BEA Systems, Inc.//DTD WebLogic 8.1.0 EJB RDBMS Persistence//EN' 'http://www.bea.com/servers/wls810/dtd/weblogic-rdbms20-persistence-810.dtd'

7.0.x

weblogic-cmp-jar.xml

'-// BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB RDBMS Persistence//EN' 'http://www.bea.com/servers/wls700/dtd/weblogic-rdbms20-persistence-700.dtd'

6.1.x

および

6.0.x

weblogic-cmp-jar.xml

'-// BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB RDBMS Persistence//EN' 'http://www.bea.com/servers/wls600/dtd/weblogic-rdbms20-persistence-600.dtd'

weblogic-cmp-jar.xmlファイルの詳細については、「weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス」を参照してください。

表A-3に、Sun Microsystems固有のejb-jar.xmlファイルのPUBLIC要素の正確なテキストをEnterprise JavaBeansのバージョン別に示します。

表A-3 ejb-jar.xmlのPUBLIC要素

EJBバージョン

XMLファイル

PUBLIC要素の文字列

2.0

ejb-jar.xml

'-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN'

'http://java.sun.com/dtd/ejb-jar_2_0.dtd'

1.1

ejb-jar.xml

'-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN'

'http://www.java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'

B weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス

以下の節では、WebLogic固有のXMLスキーマ・ベース(XSD)デプロイメント記述子ファイル、weblogic-ejb-jar.xmlのEJB 2.1の要素について説明します。これらの定義を使用して、EJBデプロイメントを構成するWebLogic固有のweblogic-ejb-jar.xmlファイルを作成します。

9.0より前のリリースのWebLogic Serverでは、weblogic-ejb-jar.xmlは文書型定義(DTD)に基づいていました。下位互換性を保持するために、WebLogic ServerではXSDベースとDTDベースのEJB記述子が引き続きサポートされています。そのため、WebLogic ServerのDTDベースの記述子を使用するアプリケーションも記述子を変更せずにデプロイできます。

注意:

EJB 3.x実装でJava EE 6メタデータ・アノテーションを使用している場合は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEJBメタデータ・アノテーション・リファレンスに関する項を参照してください。

- 2.1のweblogic-ejb-jar.xmlファイルの構造

- 2.1のweblogic-ejb-jar.xmlの要素

詳細情報:

- weblogic-ejb-jar.xmlに必要なXMLスキーマ定義とネームスペース宣言、および文書型定義とDOCTYPEヘッダーについては、「デプロイメント記述子スキーマおよび文書型定義リファレンス」を参照してください。

- weblogic-cmp-jar.xmlファイルについては、「weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス」を参照してください。

- EJB 1.1デプロイメント記述子の要素については、「EJB 1.1ユーザーへの重要な情報」を参照してください。

完全なweblogic-ejb-jar.xsdスキーマは、http://www.oracle.com/technology/weblogic/weblogic-ejb-jar/1.1/weblogic-ejb-jar.xsdを参照してください。

2.1のweblogic-ejb-jar.xmlファイルの構造

WebLogic Serverのweblogic-ejb-jar.xmlデプロイメント記述子ファイルには、WebLogic Server固有の要素を記述します。

WebLogic Serverのweblogic-ejb-jar.xmlの最上位要素は次のとおりです。

- description

- weblogic-enterprise-bean

- ejb-name

- entity-descriptor | stateless-session-descriptor | stateful-session-descriptor | message-driven-descriptor

- transaction-descriptor

- iiop-security-descriptor

- enable-call-by-reference

- network-access-point

- clients-on-same-server

- run-as-principal-name

- create-as-principal-name

- remove-as-principal-name

- passivate-as-principal-name

- jndi-name

- local-jndi-name

- dispatch-policy

- remote-client-timeout

- stick-to-first-server

- security-role-assignment

- run-as-role-assignment

- security-permission

- transaction-isolation

- message-destination-descriptor

- idempotent-methods

- retry-methods-on-rollback

- enable-bean-class-redeploy

- timer-implementation

- disable-warning

- work-manager

- component-factory-class-name

- weblogic-compatibility

2.1のweblogic-ejb-jar.xmlの要素

以下のweblogic-ejb-jar.xml要素のリストには、このリリースのWebLogic Serverでサポートされているすべての要素が含まれています。

- allow-concurrent-calls

- allow-remove-during-transaction

- cache-between-transactions

- cache-type

- client-authentication

- client-cert-authentication

- clients-on-same-server

- component-factory-class-name

- concurrency-strategy

- confidentiality

- connection-factory-jndi-name

- connection-factory-resource-link

- create-as-principal-name

- delay-updates-until-end-of-tx

- description

- destination-jndi-name

- destination-resource-link

- disable-warning

- dispatch-policy

- distributed-destination-connection

- durable-subscription-deletion

- ejb-name

- ejb-reference-description

- ejb-ref-name

- enable-bean-class-redeploy

- enable-call-by-reference

- enable-dynamic-queries

- entity-always-uses-transaction

- entity-cache

- entity-cache-name

- entity-cache-ref

- entity-clustering

- entity-descriptor

- estimated-bean-size

- externally-defined

- finders-load-bean

- generate-unique-jms-client-id

- global-role

- home-call-router-class-name

- home-is-clusterable

- home-load-algorithm

- idempotent-methods

- identity-assertion

- idle-timeout-seconds

- iiop-security-descriptor

- init-suspend-seconds

- initial-beans-in-free-pool

- initial-context-factory

- integrity

- invalidation-target

- is-modified-method-name

- isolation-level

- jms-client-id

- jms-polling-interval-seconds

- jndi-binding

- jndi-name

- local-jndi-name

- max-beans-in-cache

- max-beans-in-free-pool

- max-messages-in-transaction

- max-queries-in-cache

- max-suspend-seconds

- message-destination-descriptor

- message-destination-name

- message-driven-descriptor

- method

- method-intf

- method-name

- method-param

- method-params

- network-access-point

- passivate-as-principal-name

- persistence

- persistence-use

- persistent-store-dir

- persistent-store-logical-name

- pool

- principal-name

- provider-url

- read-timeout-seconds

- remote-client-timeout

- remove-as-principal-name

- replication-type

- resource-env-ref-name

- res-ref-name

- resource-adapter-jndi-name

- resource-description

- resource-env-description

- resource-link

- retry-count

- retry-methods-on-rollback

- role-name

- run-as-identity-principal

- run-as-principal-name

- run-as-role-assignment

- security-permission

- security-permission-spec

- security-role-assignment

- service-reference-description

- session-timeout-seconds

- stateful-session-cache

- stateful-session-clustering

- stateful-session-descriptor

- stateless-bean-call-router-class-name

- stateless-bean-is-clusterable

- stateless-bean-load-algorithm

- stateless-clustering

- stateless-session-descriptor

- stick-to-first-server

- timer-descriptor

- timer-implementation

- transaction-descriptor

- transaction-isolation

- transport-requirements

- trans-timeout-seconds

- type-identifier

- type-storage

- type-version

- use-serverside-stubs

- use81-style-polling

- weblogic-compatibility

- weblogic-ejb-jar

- weblogic-enterprise-bean

- work-manager

allow-concurrent-calls

注意:

allows-concurrent-calls要素は、WebLogic Server EJB 3.1コンテナでは非推奨です。代わりにjavax.ejb.AccessTimeoutメタデータ・アノテーションを使用することをお薦めします。これにより、タイムアウトする前に同時アクセス試行がブロックされる時間を指定できます。詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEJBメタデータ・アノテーション・リファレンスに関する項を参照してください。

値の範囲: True | False

デフォルト値: False

親要素:

- weblogic-enterprise-bean

- stateful-session-descriptor

機能

ステートフル・セッションBeanインスタンスがメソッドの同時呼出しを許可するかどうかを指定します。デフォルトでは、EJBの仕様に従ってallows-concurrent-callsはFalseであり、ステートフル・セッションBeanのインスタンスでメソッド呼出しを処理しているときにまた別の(同時)メソッド呼出しがサーバーに到着するとWebLogic ServerからRemoteExceptionが送出されます。

Trueに設定すると、EJBコンテナはメソッドの同時呼出しをブロックするため、前の呼出しが完了してから次のメソッドが呼び出されるようになります。

例

「stateful-session-descriptor」を参照してください。

allow-remove-during-transaction

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-enterprise-bean
stateful-session-descriptor

機能

ステートフル・セッションBeanのremoveメソッドをトランザクション・コンテキスト内で呼び出すことができることを指定します。

注意:

Synchronizationインタフェースを実装しているステートフル・セッションBeanでは、このタグを使用し、その後トランザクション終了前にremoveを呼び出すことがないようにしてください。それが行われた場合、EJBコンテナは同期コールバックを呼び出しません。

例

「stateful-session-descriptor」を参照してください。

cache-between-transactions

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-cache or entity cache-ref

機能

以前のdb-is-shared要素に相当し、EJBコンテナがエンティティBeanの永続データをトランザクション間でキャッシュするかどうかを指定します。

EJBコンテナによるデータの長期キャッシングの実行を有効にする場合、Trueを指定します。EJBコンテナによるデータの短期キャッシングの実行を有効にする場合、Falseを指定します。

読取り専用Beanの場合、WebLogic Serverはこれの長期キャッシングを常に実行するので、cache-between-transactions要素の値は無視されます。

詳細は、「cache-between-transactionsによるデータベース読込みの制限」を参照してください。

例

「persistence」を参照してください。

cache-type

値の範囲: NRU | LRU

デフォルト値: NRU

親要素:

weblogic-enterprise-bean
stateful-session-cache

機能

EJBがキャッシュから削除される順番を指定します。値は次のとおりです。

- 最長時間未使用(LRU : Least Recently Used)

- 最近未使用(NRU : Not Recently Used)
NRUの最小キャッシュ・サイズは8です。max-beans-in-cacheが8より小さい場合、WebLogic Serverではmax-beans-in-cacheの値に8が使用されます。

例

<stateful-session-cache>
<cache-type>NRU</cache-type>
</stateful-session-cache>

client-authentication

値の範囲: none | supported | required

デフォルト値:なし

親要素:

weblogic-enterprise-bean
iiop-security-descriptor

機能

EJBがクライアント認証をサポートするか、または、必要とするかを指定します。

例

「iiop-security-descriptor」を参照してください。

client-cert-authentication

値の範囲: none | supported | required

デフォルト値:なし

親要素:

weblogic-enterprise-bean
iiop-security-descriptor
transport-requirements

機能

EJBが転送レベルでのクライアント証明書認証をサポートするか、または、必要とするかを指定します。

例

「transport-requirements」を参照してください。

clients-on-same-server

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-enterprise-bean

機能

EJBがデプロイされた際、WebLogic ServerがこのEJBにJNDIの通知を送るかどうかが指定されます。この属性がFalse (デフォルト)の場合、WebLogic Serverクラスタでは、ある特定のサーバー上にあるこのEJBの場所を示すために、自動的にJNDIツリーを更新します。これにより、そのクライアントが同じサーバー上で連結されてなくても、すべてのクライアントがこのEJBにアクセスできるようになります。

EJBにアクセスするクライアントのすべてが、そのBeanがデプロイされているのと同じサーバー上からアクセスすることが分かっている場合には、clients-on-same-serverをTrueに設定できます。この場合、EJBがデプロイされる際、WebLogic ServerクラスタはJNDIの通知をこのEJBに送信しません。クラスタ内のJNDIの更新ではマルチキャスト・トラフィックが利用されるため、clients-on-same-serverをTrueに設定することにより大容量のクラスタでの起動時間を短縮できます。

コロケートEJBの詳細は、『Oracle WebLogic Serverクラスタの使用』のコロケート・オブジェクトの最適化に関する項を参照してください。

例

<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
...
<clients-on-same-server>True</clients-on-same-server>
</weblogic-enterprise-bean>

component-factory-class-name

値の範囲:なし

デフォルト値: null

親要素:

weblogic-ejb-jar

機能

この要素をorg.springframework.jee.interfaces.SpringComponentFactoryに設定してSpring拡張機能を有効にします。この要素は、EJB、Web、およびアプリケーション記述子に含まれています。モジュール・レベルの記述子は、アプリケーション・レベルの記述子を上書きします。このタグをnull (デフォルト)に設定すると、Spring拡張機能は無効になります。

concurrency-strategy

値の範囲: Exclusive | Database | ReadOnly | Optimistic

デフォルト値: Database

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-cache

または

weblogic-enterprise-bean
entity-descriptor
entity-cache-ref

機能

コンテナがエンティティBeanへの同時アクセスを管理する方法を指定します。以下の4つの値のいずれかに設定します。

- Exclusiveを指定すると、Beanがトランザクションに関連付けられている場合、WebLogic ServerはキャッシュされたエンティティEJBインスタンスを排他的にロックします。EJBインスタンスに対する要求は、トランザクションが完了するまでブロックされます。このオプションは、WebLogic Server 3.1 - 5.1までのデフォルトのロック動作です。

- Databaseを設定すると、WebLogic ServerはエンティティEJBに対する要求のロックを基底のデータ・ストアに委ねます。Database同時実行性ストラテジでは、WebLogic Serverは、独立したエンティティBeanインスタンスを割り当て、ロックとキャッシングをデータベースが処理できるにようにします。これは現在のデフォルト・オプションです。

- ReadOnlyは、読取り専用エンティティBeanで使用されます。複数の要求が並行して処理されるように各トランザクションで新しいインスタンスをアクティブ化します。WebLogic Serverは、read-timeout-secondsパラメータに基づいてReadOnly BeanのejbLoad()を呼び出します。

- Optimisticでは、トランザクションの間にEJBコンテナまたはデータベースでロックを行いません。EJBコンテナは、トランザクションをコミットする前に、あるトランザクションが更新したデータが変化していないことを確かめます。更新データのどれかが変わっていた場合、EJBコンテナはトランザクションをロールバックします。

注意:

concurrency-strategyがOptimisticであるBeanがクラスタにデプロイされており、クラスタのメンバーがそのBeanを更新した場合、EJBコンテナは、クラスタ内のすべてのサーバーに存在するそのBeanのすべてのコピーを無効にしようとします。この動作を無効にするには、weblogic-cmp-jar.xmlのcluster-invalidation-disabledをTrueに設定します。詳細については、「クラスタ内のオプティミスティック同時実行性の無効化オプション」を参照してください。

ExclusiveおよびDatabaseのロック動作の詳細については、「同時実行性ストラテジの選択」を参照してください。read-onlyエンティティBeanの詳細については、「読み書き対応エンティティBeanと読取り専用エンティティBean」を参照してください。

例

<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<concurrency-strategy>ReadOnly</concurrency-strategy>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>

confidentiality

値の範囲: none | supported | required

デフォルト値:なし

親要素:

weblogic-enterprise-bean
iiop-security-descriptor
transport-requirements

機能

EJBにおける転送の機密性の要件を指定します。confidentiality 要素を使用すると、他のエンティティに内容を見られることなく、クライアントとサーバー間でデータが送信されるようになります。

例

「transport-requirements」を参照してください。

connection-factory-jndi-name

値の範囲:有効なJNDI名

デフォルト値:この要素が指定されていない場合、デフォルトはweblogic.jms.MessageDrivenBeanConnectionFactory (config.xmlのJMSConnectionFactory要素で宣言されていなければならない)。

親要素:

weblogic-enterprise-bean
message-driven-descriptor

機能

メッセージドリブンEJBがキューとトピックを作成するためにルックアップするJMS接続ファクトリのJNDI名を指定します。「宛先を考慮したMDBの構成」および「connection-factory-jndi-nameの設定方法」を参照してください。

例

<message-driven-descriptor>
<connection-factory-jndi-name>
java:comp/env/jms/MyConnectionFactory
</connection-factory-jndi-name>
</message-driven-descriptor>

connection-factory-resource-link

値の範囲: JMSモジュール内の有効なリソース

デフォルト値:なし

親要素:

weblogic-enterprise-bean
message-destination-descriptor

機能

ejb-jar.xmlに定義されているJMSモジュール内のリソースをWebLogic Serverの実際のJMSモジュール参照にマップします。

create-as-principal-name

値の範囲:有効なプリンシパル名

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

WebLogic Server 8.1 SP01で導入され、本来はejbCreateが匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。

create-as-principal-nameが設定されている場合

そのプリンシパルを使用します。

あるいは

ejb-jar.xmlでBeanに対してrun-asロールが指定されている場合

run-as-role-assignmentを設定するためのルールに従ってプリンシパルを使用します。

あるいは

ejbCreateを匿名プリンシパルとして実行します。

create-as-principal-name要素は、ejbCreate内の処理が匿名プリンシパルよりも高レベルの権限を必要とする場合にのみ指定する必要があります。

この要素は、ステートレス・セッションBeanとメッセージドリブンBeanのejbCreateメソッドに影響します。

「remove-as-principal-name」、「passivate-as-principal-name」、および「principal-name」も参照してください。

delay-updates-until-end-of-tx

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-enterprise-bean
entity-descriptor
persistence

機能

トランザクションの完了時にトランザクションですべてのBeanの永続ストレージを更新するには、delay-updates-until-end-of-tx要素をTrue (デフォルト)に設定します。通常、この設定によって不要な更新を防ぐことができるため、パフォーマンスが向上します。ただし、データベース・トランザクション内のデータベース更新の順序は保持されません。

データベースがアイソレーション・レベルとしてTransactionReadUncommittedを使用している場合は、進行中のトランザクションに関する中間結果を他のデータベースのユーザーに表示することもできます。この場合、delay-updates-to-end-of-txをFalseに設定して、各メソッド呼出しの完了時にBeanの永続ストレージを更新するように指定します。詳細については、「ejbLoad()とejbStore()の動作について」を参照してください。

注意:

delay-updates-until-end-of-txをFalseに設定しても、各メソッド呼出しの後にデータベース更新が「コミットされた」状態になるわけではありません。更新はデータベースに送信されるだけです。更新は、トランザクションの完了時にのみデータベースにコミットまたはロールバックされます。

例

<entity-descriptor>
<persistence>
...
...
<delay-updates-until-end-of-tx>False</delay-updates-until-end-of-tx>
</persistence>
</entity-descriptor>

description

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

および

weblogic-ejb-jar
transaction-isolation
method

および

weblogic-ejb-jar
idempotent-methods
method

および

weblogic-ejb-jar
retry-methods-on-rollback

機能

親要素を説明します。

例

<description>Contains a description of parent element</description>

destination-jndi-name

値の範囲:有効なJNDI名

デフォルト値:なし

親要素:

weblogic-enterprise-bean
message-destination-descriptor

および

weblogic-enterprise-bean
message-driven-descriptor

機能

WebLogic Server JNDIツリーにデプロイされている実際のJMSキューまたはトピックにメッセージドリブンBeanを関連付けるために使用するJNDI名を指定します。

例

「message-destination-descriptor」および「message-driven-descriptor」を参照してください。

destination-resource-link

値の範囲: JMSモジュール内の有効なリソース

デフォルト値:なし

親要素:

weblogic-enterprise-bean
message-destination-descriptor

機能

ejb-jar.xmlに定義されているJMSモジュール内のリソースをWebLogic Serverの実際のJMSモジュール参照にマップします。

disable-warning

値の範囲: BEA-010001 | BEA-010054 | BEA-010200 | BEA-010202

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

IDを指定した警告メッセージをWebLogic Serverが無効化するように指定します。以下の4つの値のいずれかに設定します。

- BEA-010001 - 警告メッセージ「EJB class loaded from system classpath during deployment.」を無効化します。

- BEA-010054 - 警告メッセージ「EJB class loaded from system classpath during compilation.」を無効化します。

- BEA-010200 - 警告メッセージ「EJB impl class contains a public static field, method or class.」を無効化します。

- BEA-010202 - 警告メッセージ「Call-by-reference not enabled.」を無効化します。

例

警告メッセージ「Call-by-reference not enabled」を無効にするには、次のように<disable-warning>を設定します。

<disable-warning>BEA-010202</disable-warning>

dispatch-policy

値の範囲:有効な実行キューの名前

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

EJBが実行されるべきスレッド・プールをどのサーバーが実行するかを指定します。ディスパッチ・ポリシーは、エンティティ、セッション、メッセージドリブンなど、すべての種類のBeanでサポートされています。

dispatch-policyが指定されていないか、指定されたdispatch-policyが存在しないサーバー実行スレッド・プールを参照していた場合、代わりにサーバーのデフォルトの実行スレッド・プールが使用されます。

WebLogic Serverは、対応する名前を持つ実行スレッド・キューがホスト・サーバー・インスタンスになければ、dispatch-policyを無視します。

メッセージドリブンBean (MDB)が外部の(WebLogic以外の)宛先ソースによって駆動されている場合、MDBは外部プロバイダのスレッド・メカニズムで実行される可能性があるので、WebLogic Serverはdispatch-policyを無視することがあります。たとえば、IBM WebSphere MQSeriesメッセージング・ソフトウェアの場合、dispatch-policyは非トランザクション・キューについては対応されていません。アプリケーション・コードはMQSeriesスレッド内で実行されます。MQSeriesトランザクション・キュー、および非トランザクションとトランザクションの両トピックにおいては、dispatch-policyは受け付けられます。

同時に実行中のMDBインスタンスの最大数は、max-beans-in-free-poolとdispatch-policyの値の組合せによって指定されます。『Oracle WebLogic Serverパフォーマンスおよびチューニング』のMDBスレッド管理に関する項を参照してください。

例

<dispatch-policy>queue_name</dispatch-policy>

distributed-destination-connection

値の範囲: LocalOnly | EveryMember

デフォルト値: LocalOnly

親要素:

weblogic-ejb-jar
weblogic-enterprise-bean
message-driven-descriptor

機能

注意:

この要素は9.0以降のWebLogic JMSで有効です。

同じクラスタ内のWebLogic JMS分散キューにアクセスするMDBが、リソースをすべての分散宛先メンバーから消費するか、現在のWeblogic Serverのローカル・メンバーのみから消費するかを指定します。

有効な値は次のとおりです:

- LocalOnly - デプロイメント記述子とメッセージドリブンBeanが同じクラスタにあります。

- EveryMember - デプロイメント記述子がリモート・サーバー上にあります。

EveryMemberに設定すると、合計接続数が(メッセージドリブンBeanがデプロイされているサーバーの数) x (宛先の数)に等しくなります。より大きなデプロイメントの場合、この接続数により、かなりのリソースが消費される場合があります。

EveryMember設定では、リモート・サーバーからローカルMDBへメッセージを転送するため、ネットワークおよびCPUのオーバーヘッドが増大します。したがって、この設定は、現在のサーバーにユニークなJMSセレクタ・フィルタを使用するMDBなど、限定的なケースで利用するようにしてください。

例

<distributed-destination-connection>EveryMember</distributed-destination-connection>

durable-subscription-deletion

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-ejb-jar
weblogic-enterprise-bean
message-driven-descriptor

機能

MDBがアンデプロイまたは削除されるときに、恒久トピック・サブスクリプションが自動的に削除されるようにするかどうかを指定します。

例

<durable-subscription-deletion>True</durable-subscription-deletion>

ejb-name

値の範囲: ejb-jar.xmlで定義されているEJBの名前NMTOKENの命名規則に準拠)

デフォルト値:なし

親要素:

weblogic-enterprise-bean

および

weblogic-enterprise-bean
method

機能

ejb-jar.xmlで指定された同じ名前を使用して、エンタープライズBeanの名前を指定します。エンタープライズBeanのコードは名前に左右されないので、アプリケーション・アセンブリ処理中に名前を変更してもエンタープライズBeanの機能には影響しません。デプロイメント記述子のejb-nameと、デプロイヤがエンタープライズBeanのホームに割り当てるJNDI名との間には、構築された関係はありません。

注意:

weblogic-enterprise-beanでは推奨されていません。詳細は、「EJBリンクの使用」を参照してください。

例

「method」を参照してください。

ejb-reference-description

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

WebLogic ServerのEJBのJNDI名を、ejb-jar.xmlのejb-ref-name要素でそれを指定するのに使われる名前にマップします。

例

<ejb-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>

ejb-ref-name

値の範囲:関連するejb-jar.xmlファイルで指定されている有効なejb-ref-name

デフォルト値:なし

親要素:

weblogic-enterprise-bean
ejb-reference-description

機能

リソース参照名を指定します。この要素は、EJBプロバイダがejb-jar.xmlデプロイメント・ファイル内に配置する参照です。

例

<ejb-reference-description>
<ejb-ref-name>AdminBean</ejb-ref-name>
<jndi-name>payroll.AdminBean</jndi-name>
</ejb-reference-description>

enable-bean-class-redeploy

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-enterprise-jar

機能

デフォルトでは、EJB実装クラスは他のEJBクラスと同じクラスローダーにロードされます。enable-bean-class-redeploy要素が有効化されていると、実装クラスは、スーパー・クラスと共に、EJBモジュール・クラスローダーの子クラスローダーにロードされます。これにより、EJB実装クラスはEJBモジュール全体を再デプロイしなくても再デプロイできるようになります。

Beanクラスを子クラスローダーにロードすると、いくつかの問題が発生する可能性があります。まず、Beanクラスが親クラスローダーにロードされたどのクラスからも見えなくなってしまうため、これらのクラスがBeanクラスを参照できなくなったり、エラーが発生したりします。また、Beanクラスは別のクラスローダーにロードされたクラスに対しては、パッケージ保護されたメソッドを呼び出せなくなります。したがって、Beanクラスが同じパッケージ内のヘルパー・クラスを呼び出した場合、ヘルパー・クラス・メソッドはpublicとして宣言する必要があります。そうしないと、IllegalAccessErrorsが発生します。

注意:

この要素はEJB 3.0に対して非推奨になっています。WebLogic Server 10.3.0以降では、この機能はFastSwapに替わりました。『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。

例

次のXML要素では、単独のBeanクラスの再デプロイメントが可能です。

<enable-bean-class-redeploy>True</enable-bean-class-redeploy>

enable-call-by-reference

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-enterprise-bean

機能

enable-call-by-referenceがFalseの場合、EJBメソッドのパラメータはEJBがリモートから呼び出されるか、同じEARから呼び出されるかに関係なくコピーされます(または値で渡されます)。

enable-call-by-referenceがTrueの場合、同じEARファイル内またはスタンドアロンのJARファイルから呼び出されたEJBメソッドは引数を参照で渡します。パラメータはコピーされないので、これによってメソッド呼出しのパフォーマンスが向上します。

注意:

メソッドのパラメータは、EJBがリモートで呼び出されたときには常に値で渡されます。

例

<weblogic-enterprise-bean>
<entity-descriptor>
<ejb-name>AccountBean</ejb-name>
...
<enable-call-by-reference>False</enable-call-by-reference>
</entity-descriptor>
</weblogic-enterprise-bean>

enable-dynamic-queries

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-enterprise-bean
entity-descriptor

機能

Trueに設定すると、動的問合せが有効になります。動的問合せは、EJB 2.x CMP Beanを使用している場合にのみ使用できます。

例

<enable-dynamic-queries>True</enable-dynamic-queries>

entity-always-uses-transaction

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-ejb-jar
weblogic-compatibility

機能

WebLogic Server 9.0で導入された要素で、エンティティBeanが常にトランザクションを使用しなければならないかどうかを指定します。WebLogic Server 9.0より前では、エンティティBeanが不特定のトランザクションで動作している場合、EJBコンテナはそのエンティティBeanのトランザクションを作成しました。現在は、エンティティBeanが不特定のトランザクションで動作している場合、EJBコンテナはトランザクションを作成しません。この動作を無効にし、EJBコンテナが不特定のトランザクションで動作するエンティティBeanのトランザクションを作成するようにする場合、この要素の値をTrueに設定します。

entity-cache

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor

機能

WebLogic Server内のエンティティEJBインスタンスのキャッシュに使用する以下のオプションを定義します。

- max-beans-in-cache

- idle-timeout-seconds

- read-timeout-seconds

- concurrency-strategy

詳細については、「エンティティのキャッシングについて」を参照してください。

例

<entity-descriptor>
<entity-cache>
<max-beans-in-cache>...</max-beans-in-cache>
<idle-timeout-seconds>...</idle-timeout-seconds>
<read-timeout-seconds>...<read-timeout-seconds>
<concurrency-strategy>...</concurrency-strategy>
</entity-cache>
<persistence>...</persistence>
<entity-clustering>...</entity-clustering>
</entity-descriptor>

entity-cache-name

値の範囲: weblogic-application.xmlでアプリケーション・レベルのエンティティ・キャッシュに割り当てられた名前

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-cache-ref

機能

エンティティBeanが使用する、アプリケーション・レベルのエンティティ・キャッシュを参照します。アプリケーション・レベルのキャッシュは、同じアプリケーション内の複数エンティティBeanによって共有されるキャッシュです。entity-cache-nameで指定する値は、weblogic-application.xmlファイルでアプリケーション・レベルのエンティティ・キャッシュに当てた名前と一致させる必要があります。

weblogic-application.xmlファイルの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

例

「entity-cache-ref」を参照してください。

entity-cache-ref

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor

機能

同じアプリケーションに属する複数のエンティティBeanのインスタンスをキャッシュできるアプリケーション・レベルのエンティティ・キャッシュを表します。アプリケーション・レベルのエンティティ・キャッシュは、weblogic-application.xmlファイルで宣言されます。

concurrency-strategyを使用し、そのBeanに使用させたい同時実行性のタイプを定義します。concurrency-strategyはアプリケーション・レベル・キャッシュのキャッシュ戦略と適合していなくてはなりません。たとえば、Exclusiveキャッシュは、concurrency-strategyがExclusiveであるBeanだけをサポートします。MultiVersionキャッシュは、Database、ReadOnly、およびOptimistic同時実行性をサポートします。

例

<entity-cache-ref>
<entity-cache-name>AllEntityCache</entity-cache-name>
<read-timeout-seconds>600</read-timeout-seconds>
<cache-between-transactions>true</cache-between-transactions>
<concurrency-strategy>ReadOnly</concurrency-strategy>
<estimated-bean-size>20</estimated-bean-size>
</entity-cache-ref>

entity-clustering

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor

機能

エンティティBeanがWebLogicクラスタでどのようにレプリケートされるのかを指定します。

- home-is-clusterable

- home-load-algorithm

- home-call-router-class-name

- use-serverside-stubs

例

<entity-clustering>
<home-is-clusterable>True</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
<home-call-router-class-name>beanRouter</home-call-router-class-name>
<use-serverside-stubs>True</use-serverside-stubs>
</entity-clustering>

entity-descriptor

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

エンティティBeanに適用する以下のデプロイメント・パラメータを指定します。

- pool

- timer-descriptor

- entity-cache (またはentity-cache-ref)

- persistence

- entity-clustering

- invalidation-target

- enable-dynamic-queries

例

<entity-descriptor>
<pool>...</pool>
<timer-descriptor>...</timer-descriptor>
<entity-cache>...</entity-cache>
<persistence>...</persistence>
<entity-clustering>...</entity-clustering>
<invalidation-target>...</invalidation-target>
<enable-dynamic-queries>...</enable-dynamic-queries>
</entity-descriptor>

estimated-bean-size

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor

機能

エンティティBeanのインスタンスの推定平均サイズ(バイト単位)を指定します。各インスタンスが消費するメモリーのバイト数の平均値です。

estimated-bean-size要素は、Beanをキャッシュするのに使用する、アプリケーション・レベルのキャッシュがともにバイト数やMB単位で指定されている場合に併せて使用します。

エンティティBeanインスタンスが消費する正確なバイト数が分からなくても、サイズを指定することにより、ある一時点でキャッシュを共有するBeanに対し相対的な重みを与えることができます。

たとえば、Bean AとBean Bが1000バイトのキャッシュを共有し、Aのサイズが10バイト、Bのサイズが20バイトであるとします。その場合、キャッシュに格納できるのは、最大で、Aのインスタンスで100、Bのインスタンスで50です。Aのインスタンスが100個キャッシュされた場合、Bのインスタンスは0個キャッシュされたことになります。

例

「entity-cache-ref」を参照してください。

externally-defined

値の範囲: True | False

デフォルト値:なし

親要素:

weblogic-ejb-jar
security-role-assignment

機能

特定のセキュリティ・ロールが、デプロイメント記述子の外の、セキュリティ・レルム内で外部定義されていることを示します。セキュリティ・ロールおよびそのprincipal-nameのマッピングが別のところで定義されているため、principal-nameはデプロイメント記述子内では指定されません。このタグは、principal-name要素のセットの代わりに、指示を行うプレースホルダーとして使用されます。この要素は、非推奨になってWebLogic Server 9.0で削除されたグローバル・ロールの代わりに使用します。

finders-load-bean

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-enterprise-bean
entity-descriptor
persistence

機能

CMPエンティティEJBでのみ有効です。finders-load-beanは、ファインダ・メソッドの呼出しによってBeanへの参照が返されてからWebLogic ServerがEJBをキャッシュにロードするかどうかを指定します。この要素をTrueに設定した場合、Beanへの参照がファインダによって返されると、WebLogic ServerはすぐにそのBeanをキャッシュにロードします。この要素をFalseに設定した場合、WebLogic Serverは、最初のメソッドが呼び出されるまでBeanを自動的にロードしません。この動作は、EJB 1.1の仕様と一致しています。

例

<entity-descriptor>
<persistence>
<finders-load-bean>True</finders-load-bean>
</persistence>
</entity-descriptor>

generate-unique-jms-client-id

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-ejb-jar
weblogic-enterprise-bean
message-driven-descriptor

機能

EJBコンテナがMDBのインスタンスごとにユニークなクライアントIDを生成するかどうかを指定します。このフラグを有効にすると、恒久MDBをWebLogic Serverクラスタ内の複数のサーバー・インスタンスに簡単にデプロイできるようになります。

global-role

global-role要素は非推奨となっており、WebLogic Server 9.0で削除されました。代わりにexternally-defined要素を使用してください。

home-call-router-class-name

値の範囲:カスタム・クラスタの有効な名前

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-clustering

および

weblogic-enterprise-bean
stateful-session-descriptor
stateful-session-clustering

および

weblogic-enterprise-bean
stateless-session-descriptor
stateless-session-clustering

機能

Beanのメソッド呼出しのルーティングに使用するカスタム・クラスの名前を指定します。このクラスはweblogic.rmi.cluster.CallRouter()を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼出しの前に呼び出されます。ルーター・クラスでは、メソッドのパラメータを基に、ルーティングするサーバーを選択できます。このクラスは、サーバー名を返すか、または現在のロード・アルゴリズムがサーバーを選択する必要があることを示すnullを返します。

例

「entity-clustering」および「stateful-session-clustering」を参照してください。

home-is-clusterable

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-clustering

および

weblogic-enterprise-bean
stateful-session-descriptor
stateful-session-clustering

および

weblogic-enterprise-bean
stateful-session-descriptor
stateless-clustering

機能

home-is-clusterableがTrueの場合、クラスタ内の複数のWebLogic ServerからEJBをデプロイできます。ホーム・スタブの呼出しは、Beanがデプロイされるサーバー間で負荷が分散されます。Beanのホスト・サーバーにアクセスできなかった場合、呼出しは、Beanを提供する他のサーバーに自動的にフェイルオーバーします。

例

「entity-clustering」を参照してください。

home-load-algorithm

値の範囲: round-robin | random | weight-based | RoundRobinAffinity | RandomAffinity | WeightBasedAffinity

デフォルト値: weblogic.cluster.defaultLoadAlgorithmの値

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-clustering

および

weblogic-enterprise-bean
stateful-session-descriptor
stateful-session-clustering

および

weblogic-enterprise-bean
entity-descriptor
entity-clustering

機能

クラスタ内のEJBホームのレプリカ間のロード・バランシングに使用するアルゴリズムを指定します。この要素を定義しない場合、WebLogic Serverはサーバー要素、weblogic.cluster.defaultLoadAlgorithmで指定されたアルゴリズムを使用します。

home-load-algorithmは以下のいずれかの値に定義できます。

- round-robin - Beanのホスト・サーバー間で順番にロード・バランシングを実行します。

- random - Beanのホスト・サーバー間でEJBホームのレプリカがランダムにデプロイされます。

- weight-based - ホスト・サーバーの現在の負荷に従って、EJBホームのレプリカをデプロイするサーバーが決まります。

- round-robin-affinity - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、ラウンドロビン・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

- weight-based-affinity - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、重みベース・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

- random-affinity - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、ランダム・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

詳細は、『Oracle WebLogic Serverクラスタの使用』のEJBとRMIオブジェクトのロード・バランシングに関する項を参照してください。

例

「entity-clustering」および「stateful-session-clustering」を参照してください。

idempotent-methods

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

同じメソッドを同じ引数で繰返し呼び出したとしても、1回呼び出したときとまったく同じ結果になるように記述される、クラスタ化されたEJBのメソッドのリストを定義します。これにより、フェイルオーバー・ハンドラは、失敗したサーバー上で実際に呼出しがコンパイルされるかどうかを知らなくても、失敗した呼出しを再試行できるようになります。あるメソッドに対し多重呼出し不変メソッドを有効にした場合、EJBスタブは、EJBのホスト・サーバーに接続できるかぎり、あらゆる失敗から自動的に回復することができます。

EJBでクラスタリングが有効である必要があります。クラスタ化を有効にするには、「entity-clustering」、「stateful-session-clustering」、および「stateless-clustering」を参照してください。

ステートレス・セッションBeanホームおよび読取り専用エンティティBeanのメソッドは、自動的に多重呼出し不変に設定されます。これらについては多重呼出し不変を明示的に設定する必要はありません。

例

<idempotent-method>
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
</idempotent-method>

identity-assertion

値の範囲: none | supported | required

デフォルト値:なし

親要素:

weblogic-enterprise-bean
iiop-security-descriptor

機能

EJBがIDアサーションをサポートするか、または、必要とするかを指定します。

例

「iiop-security-descriptor」を参照してください。

idle-timeout-seconds

指定できる値: 1 - maxSecondsです。maxSecondsは整数の最大値です。

デフォルト値: 600

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-cache

および

weblogic-enterprise-bean
entity-descriptor
entity-cache-ref

および

weblogic-enterprise-bean
stateful-session-descriptor
stateful-session-cache

および

weblogic-enterprise-bean
stateless-session-descriptor or message-driven-descriptor or entity-descriptor
pool

機能

EJBがキャッシュに保持される最長時間を定義します。この時間を過ぎると、キャッシュ内のBeanの数がmax-beans-in-cacheで指定した値を超えている場合、WebLogic ServerではBeanインスタンスが削除されます。削除されたBeanインスタンスに対してはパッシブ化が行われます。詳細については、「ステートフル・セッションEJBのキャッシュとパッシブ化」および「エンティティBeanのプールとキャッシュの管理」を参照してください。

また、フリー・プール内のEJBが削除されるまでの最長アイドル時間を定義します。この時間の経過後、WebLogic ServerはBeanの数がinitial-beans-in-free-poolの値を下回らない限り、そのBeanをフリー・プールから削除します。

注意:

idle-timeout-secondsはentity-cache要素で使用しますが、WebLogic Server 8.1 SP1とSP2では、エンティティEJBのライフサイクルの管理にその値を使用しません。それらのサービス・パックでは、idle-timeout-secondsはエンティティBeanがいつキャッシュから削除されるのかに影響を与えません。

例

次のエントリでは、max-beans-in-cacheの値に達し、Beanがキャッシュに20分保持されている場合、ステートフル・セッションEJB AccountBeanが削除の対象になります。

<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<stateful-session-descriptor>
<stateful-session-cache>
<max-beans-in-cache>200</max-beans-in-cache>
<idle-timeout-seconds>1200</idle-timeout-seconds>
</stateful-session-cache>
</stateful-session-descriptor>
</weblogic-enterprise-bean>

iiop-security-descriptor

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

Beanレベルのセキュリティ構成パラメータを指定します。これらのパラメータにより、IORに含まれるIIOPセキュリティ情報が決定します。

例

<iiop-security-descriptor>
<transport-requirements>...</transport-requirements>
<client-authentication>supported<client-authentication>
<identity-assertion>supported</identity-assertion>
</iiop-security-descriptor>

init-suspend-seconds

値の範囲:任意の整数

デフォルト値: 5

親要素:

weblogic-enterprise-bean
message-driven-descriptor

機能

EJBコンテナがJMSリソースの停止を検出したときにMDBのJMS接続を中断する初期秒数を指定します。詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のJMSリソース停止中のメッセージ配信の中断の構成に関する項を参照してください。

initial-beans-in-free-pool

指定できる値: 0 - maxBeans

デフォルト値: 0

親要素:

weblogic-enterprise-bean
stateless-session-descriptor or message-driven-descriptor or entity-descriptor
pool

機能

initial-beans-in-free-poolの値を指定する場合は、プールの初期サイズを設定することになります。WebLogic Serverは起動時に、Beanクラスごとに指定された数のBeanインスタンスをフリー・プールに格納します。この方法でBeanインスタンスをフリー・プールに格納しておくと、要求が来てから新しいインスタンスを生成せずにBeanに対する初期要求が可能になるため、EJBの初期応答時間が短縮されます。

例

「pool」を参照してください。

initial-context-factory

値の範囲:初期コンテキスト・ファクトリの有効な名前

デフォルト値: weblogic.jndi.WLInitialContextFactory

親要素:

weblogic-enterprise-bean
message-destination-descriptor

および

weblogic-enterprise-bean
message-driven-descriptor

機能

JMSプロバイダが初期コンテキストの作成に使用する初期コンテキスト・ファクトリを指定します。『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』の宛先を考慮したMDBの構成に関する項およびinitial-context-factoryの設定方法に関する項を参照してください。

例

<message-driven-descriptor>
<initial-context-factory>fiorano.jms.rtl.FioranoInitialContextFactory
</initial-context-factory>
</message-driven-descriptor>

「message-destination-descriptor」も参照してください。

integrity

値の範囲: none | supported | required

デフォルト値:なし

親要素:

weblogic-enterprise-bean
iiop-security-descriptor
transport-requirements

機能

EJBの転送の整合性の要件を指定します。integrity要素を使用すると、クライアントとサーバー間で、データが途中で変化することなく転送されるようになります。

例

「transport-requirements」を参照してください。

invalidation-target

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor

機能

コンテナ管理による永続性エンティティEJBが変更された場合に、無効化する読取り専用エンティティEJBを指定します。

ターゲットのejb-nameは読取り専用エンティティEJBでなければならないので、この要素はEJB 2.xのコンテナ管理による永続性エンティティEJBに対してのみ指定できます。

例

<invalidation-target>
<ejb-name>StockReaderEJB</ejb-name>
</invalidation-target>

is-modified-method-name

値の範囲:有効なエンティティEJBメソッド名

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor
persistence

機能

EJBの保存時にWebLogic Serverによって呼び出されるメソッドを指定します。指定したメソッドはブール値を返す必要があります。メソッドを指定しない場合、WebLogic Serverでは、EJBは常に変更されていると見なされて保存されます。

メソッドを指定して適切な値を設定すると、EJB 1.1準拠のBean、およびBean管理の永続性を使用するBeanのパフォーマンスが向上します。ただし、メソッドの戻り値にエラーがあると、データに矛盾が発生する場合があります。

注意:

isModified()は、EJB 2.x仕様に基づく2.x CMPエンティティEJBでは必要ありません。しかし、BMPおよび1.1 CMP EJBには引続き適用されます。コンテナ管理の永続性を使用してEJB 2.xエンティティBeanをデプロイする場合、WebLogic Serverによって、変更されているEJBフィールドが自動的に検出され、そのフィールドのみが基底のデータ・ストアに書き込まれます。

例

<entity-descriptor>
<persistence>
<is-modified-method-name>semidivine</is-modified-method-name>
</persistence>
</entity-descriptor>

isolation-level

値の範囲: TransactionSerializable | TransactionReadCommitted | TransactionReadUncommitted | TransactionRepeatableRead | TransactionReadCommittedForUpdate | TransactionReadCommittedForUpdateNoWait

デフォルト値:基底のデータベースのデフォルト値

親要素:

weblogic-ejb-jar
transaction-isolation

機能

EJBのメソッド・レベルのトランザクション・アイソレーション設定を定義します。有効な値は以下のとおりです。

- TransactionSerializable - このトランザクションを同時に複数回実行すると、トランザクションを順番に複数回実行することと同じことになります。

注意:

Oracleデータベースの場合は、TransactionSerializableアイソレーション・レベルの代わりにTransactionReadCommittedForUpdateアイソレーション・レベルを使用することをお薦めします。Oracleデータベースは、TransactionSerializableアイソレーション・レベルではデータの読取りをロックしないためです。また、TransactionSerializableアイソレーション・レベルでは、Oracleデータベースに対する現在のトランザクションが、Oracle例外ORA-08177「このトランザクションのアクセスをシリアル化できません」を送出せずに続行することが可能です。TransactionReadCommittedForUpdateアイソレーション・レベルの詳細については、「Oracleデータベースのみのアイソレーション・レベル」を参照してください。

- TransactionReadCommitted - コミットした他のトランザクションの更新のみをトランザクションで表示できます。

- TransactionReadUncommitted - コミットしていない他のトランザクションの更新をトランザクションで表示できます。

- TransactionRepeatableRead - トランザクションでデータの一部を読み取ると、そのデータが他のトランザクションで変更されても、最初の読取り時と同じ値が返されます。

Oracleデータベースのみのアイソレーション・レベル

以下の追加の値は、Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされています。

- TransactionReadCommittedForUpdate - Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされます。この値を使用すると、アイソレーション・レベルはTransactionReadCommittedに設定され、トランザクションの間、メソッドで実行されるSQL SELECT文はすべてFOR UPDATEが付加されて実行されます。この結果、隔離された行が更新用にロックされます。Oracleデータベースで問合せの影響を受ける行をすぐにロックできない場合は、それらの行が解放されるまで待ちます。この状況は、トランザクションでCOMMITまたはROLLBACKが実行されるまで続きます。
このアイソレーション・レベルを使用すると、次のエラーを防止できます。

java.sql.SQLException: ORA-08177: can't serialize access for this transaction

このエラーは、OracleデータベースでTransactionSerializableアイソレーション・レベルを使用したときに発生することがあります。

注意:

Oracleデータベースの場合は、TransactionSerializableアイソレーション・レベルの代わりにこのアイソレーション・レベル(TransactionReadCommittedForUpdate)を使用することをお薦めします。Oracleデータベースは、TransactionSerializableアイソレーション・レベルではデータの読取りをロックしないためです。

- TransactionReadCommittedForUpdateNoWait - Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされます。
この値を使用すると、アイソレーション・レベルはTransactionReadCommittedに設定され、トランザクションの間、メソッドで実行されるSQL SELECT文はすべてFOR UPDATE NO WAITが付加されて実行されます。この結果、選択された行が更新用にロックされます。

TransactionReadCommittedForUpdate設定とは違って、必要なときロックがすぐに達成されない場合、TransactionReadCommittedForUpdateNoWaitではOracle DBMSが NOT WAITになります。このため、影響を受けるSELECT問合せは失敗し、コンテナから例外が送出されます。

異なるアイソレーション・レベルのサポートの詳細については、各データベースのドキュメントを参照してください。

例

「transaction-isolation」を参照してください。

jms-client-id

値の範囲:なし

デフォルト値: EJBのejb-name

親要素:

message-driven-descriptor

機能

JMS宛先に接続するときのMDBのクライアントIDを指定します。JMSトピックに対する恒久サブスクリプションで必須です。

connection-factory-jndi-nameでMDBが使用する接続ファクトリを指定した場合、クライアントIDはconfig.xml内の関連付けられているJMSConnectionFactory要素のClientID要素で定義できます。

config.xmlのJMSConnectionFactoryでClientIDを指定しないか、デフォルト接続ファクトリを使用する(connection-factory-jndi-nameを指定しない)場合、メッセージドリブンBeanはjms-client-id値をそのクライアントIDとして使用します。

例

<jms-client-id>MyClientID</jms-client-id>

jms-polling-interval-seconds

値の範囲:なし

デフォルト値: 10秒

親要素:

message-driven-descriptor

機能

JMS宛先に再接続しにいく間隔の秒数を指定します。各メッセージドリブンBeanは、関連付けられているJMS宛先でリスンします。JMS宛先が別のWebLogic Serverインスタンスまたは外部JMSプロバイダに配置されている場合には、JMS宛先にアクセスできなくなることもあります。この場合、EJBコンテナは自動的にJMSサーバーに再接続しようとします。JMSサーバーが再び起動した時点で、メッセージドリブンBeanは再びメッセージを受信できるようになります。

例

<jms-polling-interval-seconds>5</jms-polling-interval-seconds>

jndi-binding

値の範囲: カスタムJNDI名

デフォルト値:なし

親要素:

weblogic-enterprise-bean

および

weblogic-enterprise-bean
resource-description

および

weblogic-enterprise-bean
ejb-reference-description

機能

特定のクライアント・ビューに対するJNDI名を示すためにBeanクラスまたはビジネス・インタフェースに適用できるカスタムJNDI名を指定します。インタフェースなしのビューのJNDI名を示すためにBeanクラス適用する場合、classNameは省略可能です。

例

「resource-description」および「ejb-reference-description」を参照してください。

jndi-name

注意:

このリリースのWebLogic Serverでは、jndi-name要素は非推奨です。代わりにjndi-bindingを使用します。

値の範囲:有効なJNDI名

デフォルト値:なし

親要素:

weblogic-enterprise-bean

および

weblogic-enterprise-bean
resource-description

および

weblogic-enterprise-bean
ejb-reference-description

機能

WebLogic Serverで使用可能な実際のEJB、リソース、または参照のJNDI名を指定します。

注意:

JNDI名をBeanに割り当てるのは望ましくありません。グローバルJNDI名は、クラスタ化サーバーの起動時に大量のマルチキャスト・トラフィックを引き起こします。より適切なプラクティスについては、「EJBリンクの使用」を参照してください。EJBを含むEARライブラリがある場合、JNDI名の競合が起きるため、そのライブラリを参照するアプリケーションを複数デプロイすることはできません。これは、EARライブラリ内の個々のEJBに対してグローバルJNDI名を設定できないからです。グローバルJNDI名はライブラリ全体に対してのみ設定できます。

例

「resource-description」および「ejb-reference-description」を参照してください。

local-jndi-name

注意:

このリリースのWebLogic Serverでは、local-jndi-name要素は非推奨です。代わりにjndi-bindingを使用します。

値の範囲:有効なJNDI名

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

Beanのローカル・ホームのJNDI名。Beanがリモート・ホームとローカル・ホームを持つ場合は、それぞれのホームに1つずつのJNDI名を割り当てることもできます。

注意:

JNDI名をBeanに割り当てるのは望ましくありません。より適切なプラクティスについては、「EJBリンクの使用」を参照してください。

例

<local-jndi-name>weblogic.jndi.WLInitialContext
</local-jndi-name>

max-beans-in-cache

値の範囲: 1 - maxBeans

デフォルト値: 1000

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-cache

および

weblogic-enterprise-bean
stateful-session-descriptor
stateful-session-cache

機能

メモリーの許容範囲内で、このクラスのオブジェクトの最大数を指定します。max-bean-in-cacheの値に達すると、WebLogic Serverでは、最近クライアントに使用されていないEJBの一部に対してパッシブ化が行われます。また、「ステートフル・セッションEJBのキャッシュとパッシブ化」で説明されているように、max-beans-in-cacheの値は、EJBをWebLogic Serverのキャッシュからいつ削除するかにも影響を与えます。

例

<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<max-beans-in-cache>200</max-beans-in-cache>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>

max-beans-in-free-pool

指定できる値: 0 - maxBeans

デフォルト値: 1000

親要素:

weblogic-enterprise-bean
stateless-session-descriptor
pool

および

weblogic-enterprise-bean
message-driven-descriptor
pool

および

weblogic-enterprise-bean
entity-descriptor
pool

機能

WebLogic Serverは、すべてのエンティティBean、ステートレス・セッションBean、およびメッセージドリブンBeanクラスについてEJBのフリー・プールを保持します。max-beans-in-free-pool要素は、このフリー・プールのサイズを定義します。

例

「pool」を参照してください。

max-messages-in-transaction

値の範囲:すべての正の整数

デフォルト値:なし

親要素:

weblogic-enterprise-bean
message-driven-descriptor

機能

MDBのトランザクションに入れることができるメッセージの最大数を指定します。

max-queries-in-cache

値の範囲:すべての正の整数

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor

機能

WebLogic Server 9.0で導入された要素です。Beanレベルでキャッシュできる読取り専用エンティティ問合せの最大数を指定します。アプリケーション・レベルでの読取り専用エンティティ問合せのキャッシュについては、「問合せキャッシングの使用(読取り専用エンティティBean)」を参照してください。

max-suspend-seconds

値の範囲:任意の整数

デフォルト値: 60

親要素:

weblogic-enterprise-bean
message-driven-descriptor

機能

EJBコンテナがJMSリソースの停止を検出したときにMDBのJMS接続を中断する最大秒数を指定します。EJBコンテナがJMSリソースの停止を検出したときにJMS接続が中断しないようにするには、この要素の値を0に設定します。詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のJMSリソース停止中のメッセージ配信の中断の構成に関する項を参照してください。

message-destination-descriptor

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

ejb-jar.xmlファイル内のメッセージ宛先の参照を、WebLogic Serverの実際のメッセージ宛先(JMSキュー、トピックなど)にマップします。

例

<message-destination-descriptor>
<message-destination-name>...</message-destination-name>
<destination-jndi-name>...</destination-jndi-name>
<resource-link>...</resource-link>
<initial-context-factory>...</initial-context-factory>
<provider-url>...</provider-url>
</message-destination-descriptor>

message-destination-name

指定できる値: ejb-jar.xmlファイルにある有効なメッセージ定義参照名

デフォルト値:なし

要件:この要素は、EJBがejb-jar.xmlのメッセージ定義参照を指定する場合に必要です。

親要素:

weblogic-enterprise-bean
message-destination-descriptor

機能

メッセージ定義参照の名前を指定します。これは、EJBプロバイダによってejb-jar.xmlデプロイメント記述子ファイル内に記載される参照です。

例

「message-destination-descriptor」を参照してください。

message-driven-descriptor

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

メッセージドリブンBeanをWebLogic ServerのJMS宛先に関連付けます。

例

<message-driven-descriptor>
<pool>...</pool>
<timer-descriptor>...</timer-descriptor>
<destination-jndi-name>...</destination-jndi-name>
<initial-context-factory>...</initial-context-factory>
<provider-url>...</provider-url>
<connection-factory-jndi-name>...</connection-factory-jndi-name>
<jms-polling-interval-seconds>...</jms-polling-interval-seconds>
<jms-client-id>...</jms-client-id>
<generate-unique-jms-client-id>...</generate-unique-jms-client-id>
<durable-subscription-deletion>...</durable-subscription-deletion>
<max-messages-in-transaction>...</max-messages-in-transaction>
<distributed-destination-connection>...</distributed-destination-connection>
<use81-style-polling>...</use81-style-polling>
<init-suspend-seconds>...</init-suspend-seconds>
<max-suspend-seconds>...</max-suspend-seconds>
</message-driven-descriptor>

method

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar
transaction-isolation

および

weblogic-ejb-jar
idempotent-methods

および

weblogic-ejb-jar
retry-methods-on-rollback

機能

エンタープライズBeanのホームまたはリモート・インタフェースのメソッドあるいはメソッドのセットを定義します。

例

<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>

method-intf

値の範囲: Home | Remote | Local | Localhome

デフォルト値:なし

親要素:

weblogic-ejb-jar
transaction-isolation
method

および

weblogic-ejb-jar
idempotent-methods
method

機能

WebLogic Serverがアイソレーション・レベルのプロパティを適用するEJBのインスタンスを指定します(メソッドが複数のインタフェースで同じシグネチャを持つ場合)。

例

「method」を参照してください。

method-name

値の範囲: ejb-jar.xmlで定義したEJBの名前| *

デフォルト値:なし

親要素:

weblogic-ejb-jar
transaction-isolation
method

および

weblogic-ejb-jar
idempotent-methods
method

機能

WebLogic Serverがアイソレーション・レベルのプロパティを適用する個々のEJBメソッドの名前を指定します。アスタリスク(*)を使用するとEJBのホームおよびリモート・インタフェースの全メソッドを指定できます。

method-nameを指定する場合、そのメソッドは指定のejb-nameになければなりません。

例

「method」を参照してください。

method-param

値の範囲:メソッド・パラメータの完全修飾Javaタイプ名

デフォルト値:なし

親要素:

weblogic-ejb-jar
transaction-isolation
method
method-params

および

weblogic-ejb-jar
idempotent-methods
method
method-params

機能

メソッド・パラメータの完全修飾Javaタイプ名を指定します。

例

「method-params」を参照してください。

method-params

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar
transaction-isolation
method

および

weblogic-ejb-jar
idempotent-methods
method

機能

各メソッド・パラメータのJavaタイプ名を定義する1つまたは複数の要素があります。

例

method-params要素には、次のように1つまたは複数のmethod-param要素が含まれます。

<method-params>
<method-param>java.lang.String</method-param>
...
</method-params>

network-access-point

値の範囲:カスタム・ネットワーク・アクセス・ポイントの名前

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

EJBでネットワーク通信に使用されるカスタム・ネットワーク・チャネルを割り当てます。ネットワーク・チャネルによって、一連の接続属性が定義されます。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください。

例

<weblogic-enterprise-bean>
<network-access-point>SSLChannel</network-access-point>
</weblogic-enterprise-bean>

passivate-as-principal-name

値の範囲:有効なWebLogic Serverプリンシパル

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

WebLogic Server 8.1 SP01で導入されたpassivate-as-principal-name要素は、本来はejbPassivateが匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。

passivate-as-principal-nameが設定されている場合

そのプリンシパルを使用します。

あるいは

ejb-jar.xmlでBeanに対してrun-asロールが指定されている場合

run-as-role-assignmentを設定するためのルールに従ってプリンシパルを使用します。

あるいは

ejbPassivateを匿名プリンシパルとして実行します。

passivate-as-principal-name要素は、ejbPassivate内の処理が匿名プリンシパルよりも高レベルの権限を必要とする場合にのみ指定する必要があります。

この要素は、キャッシュのタイムアウトでパッシブ化が行われたときにステートレス・セッションBeanのejbPassivateメソッドに影響します。

「remove-as-principal-name」、「create-as-principal-name」、および「principal-name」も参照してください。

persistence

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor

機能

コンテナ管理の永続性サービスを使用するエンティティEJBでのみ必須です。persistence要素は、WebLogic ServerのエンティティEJBに対する永続性タイプ、トランザクション・コミット動作、ejbLoad()動作、およびejbStore()動作を決定するプロパティを定義します。

- is-modified-method-name

- delay-updates-until-end-of-tx

- finders-load-bean

- persistence-use

例

<entity-descriptor>
<persistence>
<is-modified-method-name>...</is-modified-method-name>
<delay-updates-until-end-of-tx>...</delay-updates-until-end-of-tx>
<finders-load-beand>...</finders-load-bean>
<persistence-use>...</persistence-use>
</persistence>
</entity-descriptor>

persistence-use

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor
persistence

機能

コンテナ管理の永続性サービスを使用するエンティティEJBでのみ必須です。persistence-use要素は、この特定のBeanに使用する永続性タイプの識別子を格納します。

例

<persistence-use>
<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
<type-version>5.1.0</type-version>
<type-storage>META-INF/weblogic-cmp-jar.xml</type-storage>
</persistence-use>

persistent-store-dir

値の範囲:有効なファイル・システム・ディレクトリ

デフォルト値: pstore

親要素:

weblogic-enterprise-bean
stateful-session-descriptor

機能

パッシブ化されたステートフル・セッションBeanインスタンスの状態をWebLogic Serverが格納するファイル・システム・ディレクトリを指定します。詳細については、「パッシブ化されたBeanの永続ストア・ディレクトリの指定」を参照してください。

例

<stateful-session-descriptor>
<stateful-session-cache>...</stateful-session-cache>
<allow-concurrent-calls>...</allow-concurrent-calls>
<persistent-store-dir>MyPersistenceDir</persistent-store-dir>
<stateful-session-clustering>...</stateful-session-clustering>
<allow-remove-during-transaction>
</stateful-session-descriptor>

persistent-store-logical-name

値の範囲:ファイル・システムの永続ストアの有効な名前

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor
timer-descriptor

および

weblogic-enterprise-bean
message-driven-descriptor
timer-descriptor

機能

WebLogic Serverがタイマー・オブジェクトを格納する、サーバーのファイル・システム上の永続ストアの名前を指定します。この要素で永続ストアの名前を指定しない場合、タイマー・オブジェクトはデフォルト・ストアに格納されます。

pool

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
stateless-session-descriptor or message-driven-descriptor

および

entity-descriptor

機能

エンティティEJB、ステートレス・セッションEJB、およびメッセージドリブンEJBのWebLogic Serverフリー・プールの動作を構成します。オプションは以下のとおりです。

- max-beans-in-free-pool

- initial-beans-in-free-pool

- idle-timeout-seconds

例

<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>500</max-beans-in-free-pool>
<initial-beans-in-free-pool>250</initial-beans-in-free-pool>
</pool>
</stateless-session-descriptor>

principal-name

値の範囲:有効なWebLogic Serverプリンシパル名

デフォルト値:なし

親要素:

weblogic-ejb-jar
security-role-assignment

機能

指定したrole-nameに適用される実際のWebLogic Serverプリンシパルの名前を指定します。security-role-assignment要素に少なくとも1つのprincipal-nameが必要です。各role-nameに対し複数のprincipal-nameを定義できます。

例

「security-role-assignment」を参照してください。

provider-url

値の範囲:有効なURL

デフォルト値: t3://localhost:7001

親要素:

weblogic-enterprise-bean
message-destination-descriptor

および

weblogic-enterprise-bean
message-driven-descriptor

機能

InitialContextで使用されるURLを指定します。『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』の宛先を考慮したMDBの構成に関する項およびprovider-urlの設定方法に関する項を参照してください。

例

<message-driven-descriptor>
<provider-url>WeblogicURL:Port</provider-url>
</message-driven-descriptor>

「message-destination-descriptor」も参照してください。

read-timeout-seconds

指定できる値: 0 - maxSecondsです。maxSecondsは整数の最大値です。

デフォルト値: 600

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-cache

または

weblogic-enterprise-bean
entity-descriptor
entity-cache-ref

機能

Read-OnlyエンティティBeanでejbLoadを呼び出す間隔の秒数を指定します。値を0にすると、WebLogic ServerはBeanがキャッシュに送られたときだけejbLoad()を呼び出します。

例

次の例では、インスタンスが最初にキャッシュされた場合にのみWebLogic ServerがAccountBeanクラスのインスタンスに対してejbLoad()を呼び出します。

<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
<entity-descriptor>
<entity-cache>
<read-timeout-seconds>0</read-timeout-seconds>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>

remote-client-timeout

指定できる値: 0 - maxSecondsです。maxSecondsは整数の最大値です。

デフォルト値: 0

親要素:

weblogic-enterprise-bean

機能

リモートRMIクライアントがタイムアウトするまでの待機時間を指定します。『Oracle WebLogic Server RMIのプログラミング』のRMIタイムアウトの使用に関する項を参照してください。

例

以下のエントリの場合、リモートRMIクライアントは5秒待機してからタイムアウトします。

<weblogic-enterprise-bean>
<ejb-name>AccountBean</ejb-name>
...
<remote-client-timeout>5</remote-client-timeout>
</weblogic-enterprise-bean>

remove-as-principal-name

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

このパラメータは、ejbRemove内の処理が匿名プリンシパル以上の権限を必要とする場合にのみ指定する必要があります。

WebLogic Server 8.1 SP1で導入されたremove-as-principal-name要素は、本来はejbRemoveが匿名プリンシパルで実行される状況で使用されるプリンシパルを指定します。そのような状況では、どのプリンシパルを選択するかは次のルールで決まります。

remove-as-principal-nameが設定されている場合

そのプリンシパルを使用します。

あるいは

ejb-jar.xmlでBeanに対してrun-asロールが指定されている場合

run-as-role-assignmentを設定するためのルールに従ってプリンシパルを使用します。

あるいは

ejbRemoveを匿名プリンシパルとして実行します。

remove-as-principal-name要素は、ejbRemove内の処理が匿名プリンシパルよりも高レベルの権限を必要とする場合にのみ指定する必要があります。

この要素は、ステートレス・セッションBeanとメッセージドリブンBeanのejbRemoveメソッドに影響します。

「passivate-as-principal-name」、「create-as-principal-name」、および「principal-name」も参照してください。

replication-type

値の範囲: InMemory | None

デフォルト値:なし

親要素:

weblogic-enterprise-bean
stateful-session-descriptor
stateful-session-clustering

機能

クラスタ内のWebLogic Serverインスタンスのステートフル・セッションEJBの状態をWebLogic Serverがレプリケートするかどうかを指定します。InMemoryを指定した場合、EJBの状態はレプリケートされます。Noneを指定した場合、状態はレプリケートされません。

例

「stateful-session-clustering」を参照してください。

resource-env-ref-name

値の範囲: ejb-jar.xmlファイルにある有効なリソース環境参照名

デフォルト値:なし

親要素:

weblogic-enterprise-bean
resource-env-description

機能

リソース環境参照名を指定します。

例

「resource-description」を参照してください。

res-ref-name

値の範囲: ejb-jar.xmlファイルにある有効なリソース参照名

デフォルト値:なし

親要素:

weblogic-enterprise-bean
resource-description

機能

resourcefactory参照の名前を指定します。これは、EJBプロバイダによってejb-jar.xmlデプロイメント記述子ファイル内に記載される参照です。EJBがejb-jar.xmlのリソース参照を指定する場合にのみ必須になります。

例

「resource-description」を参照してください。

resource-adapter-jndi-name

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar
weblogic-enterprise-bean
message-driven-descriptor

機能

このMDBがメッセージを受け取るリソース・アダプタを指定します。

resource-description

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

ejb-jar.xmlに定義されているリソース参照をWebLogic Server内に用意されている実際のリソースのJNDI名にマップします。

例

<resource-description>
<res-ref-name>. . .</res-ref-name>
<jndi-name>...</jndi-name>
</resource-description>
<ejb-reference-description>
<ejb-ref-name>. . .</ejb-ref-name>
<jndi-name>. . .</jndi-name>
</ejb-reference-description>

resource-env-description

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

ejb-jar.xmlに定義されているリソース環境参照をWebLogic Server内に用意されている実際のリソースのJNDI名にマップします。

例

<resource-env-description>
<resource-env-ref-name>. . .</resource-env-ref-name>
<jndi-name>...</jndi-name>
</reference-env-description>

jndi-nameが有効なURLでない場合、WebLogic ServerはそれをURLに対応し、すでにJNDIツリーにバインドされているオブジェクトとして取り扱い、LinkRefとそのjndi-nameをバインドします。

resource-link

値の範囲: JMSモジュール内の有効なリソース

デフォルト値:なし

親要素:

weblogic-enterprise-bean
message-destination-descriptor

機能

ejb-jar.xmlに定義されているJMSモジュール内のリソースをWebLogic Serverの実際のJMSモジュール参照にマップします。

例

「message-destination-descriptor」を参照してください。

retry-count

値の範囲:任意の正の整数

注意:

この値を0以下に設定することは可能ですが、推奨されません。この値が1以上でない場合、EJBコンテナはトランザクションを再試行しません。

デフォルト値:なし

親要素:

weblogic-ejb-jar
retry-methods-on-rollback

機能

EJBコンテナが、ロールバックされたコンテナ管理によるトランザクション・メソッドを自動的に再試行する回数を指定します。

retry-methods-on-rollback

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

ここで指定したメソッドに対して、EJBコンテナはロールバックされたコンテナ管理によるトランザクションを自動的に再試行します。自動的なトランザクションの再試行は、コンテナ管理のトランザクションの境界設定を使用するセッションBeanおよびエンティティBeanについて、サポートされています。また、この要素で指定されたメソッドに関わらず、EJBコンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。

role-name

値の範囲:有効なアプリケーション・ロール名

デフォルト値:なし

親要素:

weblogic-enterprise-bean
security-role-assignment

機能

EJBプロバイダがejb-jar.xmlデプロイメント記述子に指定したアプリケーションのロール名を示します。要素の次のprincipal-name要素で、WebLogic Serverプリンシパルを、指定したrole-nameにマップします。

例

「security-role-assignment」を参照してください。

run-as-identity-principal

値の範囲:有効なセキュリティ・プリンシパル名

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

注意:

run-as-identity-principal要素は、このリリースのWebLogic Serverでは非推奨です。代わりにrun-as-principal-nameを使用します。

run-as-identity-principal要素は、ejb-jar.xmlデプロイメント記述子で、セキュリティID run-as-role-nameを指定したBeanのrun-asプリンシパルとして使用されるセキュリティ・プリンシパル名を指定します。

run-as-role-nameのrun-as-identity-principalまたはrun-as-principal-nameへのマッピングがどのようにして生じるかの説明は、run-as-role-assignment要素のコメントを参照してください。

例

<run-as-identity-principal>
Fred
</run-as-identity-principal>

run-as-principal-name

値の範囲:有効なプリンシパル

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

ejb-jar.xmlデプロイメント記述子で、security-identity run-as role-nameを指定したBeanのrun-asプリンシパルとして使用されるセキュリティ・プリンシパル名を指定します。

run-as role-nameのrun-as-principal-nameへのマッピングがどのようにして生じるかの説明は、run-as-role-assignment要素のコメントを参照してください。

例

<run-as-principal-name>
Fred
</run-as-principal-name>

run-as-role-assignment

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

ejb-jar.xmlデプロイメント記述子ファイルで指定されたsecurity-identity run-as role-nameをrun-as-principal-nameにマップします。

ここで指定した特定のrole-nameに対するrun-as-principal-nameの値は、ejb-jar.xmlデプロイメント記述子内のすべてのBeanを対象とし、role-nameをsecurity-identity run-as-role-nameとして指定したすべてのBeanに適用されます。

ここで指定したrun-as-principal-name値は、そのBeanのweblogic-enterprise-bean要素の下でrun-as-principal-nameを指定することによって、個々のBeanレベルでオーバーライドできます。

注意:

特定のBeanについて、run-as-role-assignmentまたはBean固有のrun-as-principal-nameタグでrun-as-principal-nameが指定されていない場合、EJBコンテナはweblogic-enterprise-bean security-role-assignmentのセキュリティ・ユーザーの最初のprincipal-nameをrole-nameとして選択し、そのprincipal-nameをrun-as-principal-nameとして使用します。

例

ejb-jar.xmlデプロイメント記述子ファイルが、次のような状況であると仮定します。

- Beans 'A_EJB_with_runAs_role_X'および'B_EJB_with_runAs_role_X'
security-identity run-as role-name 'runAs_role_X'を指定します。

- Bean 'C_EJB_with_runAs_role_Y'
security-identity run-as role-name 'runAs_role_Y'を指定します。

対応するデプロイメント記述子ファイルweblogic-ejb-jar.xmlから抜粋した次のコードを検討してください。

<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>
A_EJB_with_runAs_role_x
</ejb-name>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>
B_EJB_with_runAs_role_X
</ejb-name>
<run-as-principal-name>
Joe
</run-as-principal-name>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>
C_EJB_with_runAs_role_Y
</ejb-name>
</weblogic-enterprise-bean>
<security-role-assignment>
<role-name>
runAs_role_Y
</role-name>
<principal-name>
first_principal_of_role_Y
</principal-name>
<principal-name>
second_principal_of_role_Y
</principal-name>
</security-role-assignment>
<run-as-role-assignment>
<role-name>
runAs_role_X
</role-name>
<run-as-principal-name>
Fred
</run-as-principal-name>
</run-as-role-assignment>
</weblogic-ejb-jar>

各Beanは、そのrun-as-principal-nameとして異なるプリンシパル名を選択します。

A_EJB_with_runAs_role_X

このBeanのrun-as-role-nameは「runAs_role_X」です。使用するプリンシパルの名前のルックアップには、jarスコープの<run-as-role-assignment>マッピングが使用されます。

<run-as-role-assignment>マッピングにより、<role-name>「runAs_role_X」に対して、<run-as-principal-name>「Fred」を使用すべきであることが指定されます。

「Fred」が、使用されるプリンシパル名です。

B_EJB_with_runAs_role_X

このBeanのrun-as-role-nameも「runAs_role_X」です。このBeanは使用するプリンシパルの名前のルックアップにjarスコープの<run-as-role-assignment>を使用することはありません。なぜなら、この値はこのBeanの<weblogic-enterprise-bean> <run-as-principal-name>値である「Joe」でオーバーライドされているからです。

「Joe」が、使用されるプリンシパル名です。

C_EJB_with_runAs_role_Y

このBeanのrun-as-role-nameは「runAs_role_Y」です。「runAs_role_Y」のrun-asプリンシパル名としての明示的なマッピングはありません。つまり、「runAs_role_Y」に対するjarスコープの<run-as-role-assignment>も、Beanスコープの<run-as-principal-name>も、このBeanのweblogic-enterprise-beanでは指定されていません。

使用するプリンシパル名を決定するには、<role-name>「runAs_role_Y」の<security-role-assignment>を検証します。ユーザー(つまり、グループではない)に対応する最初の<principal-name>が選択されます。

「first_principal_of_role_Y」が、使用されるプリンシパル名です。

security-permission

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

Java EE Sandboxと関連するセキュリティ権限を指定します。

詳細は、セキュリティ権限の仕様を参照してください。

http://download.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html#FileSyntax

例

<security-permission>
<description>Optional explanation goes here</description>
<security-permission-spec>
...
</security-permission-spec>
</security-permission>

security-permission-spec

値の範囲:なし

デフォルト値:なし

親要素:

security-permission

機能

セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ権限を指定します。

詳細は、セキュリティ権限の仕様を参照してください。

http://download.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html#FileSyntax

例

「java.vm.version」に「read」権限を与え、それが上書きされるのを防止するには、次の手順に従います。

1. 次のようにsecurity-permission-specを設定します。

<security-permission>
<description>Optional explanation goes here</description>
<security-permission-spec> grant { permission     java.util.PropertyPermission "java.vm.version", "read"; };
</security-permission-spec>
</security-permission>

2. 次のオプションを使用してサーバーを起動するようにstartWeblogicスクリプトを修正します。

JAVA_OPTIONS=-Djava.security.manager

3. ドメイン・ディレクトリにlibという名前のディレクトリを作成します。

4. 次の表を%WL_HOME%\server\lib\weblogic.policyファイルに追加します。

add grant codeBase "file:/<Your user_projects dir>/YourDomain/lib/-" { permission java.security.AllPermission; };

これは、EJBスタブのクラスパスがlibであるために必要です。

security-role-assignment

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

ejb-jar.xmlファイルのアプリケーション・ロールをWebLogic Serverのセキュリティ・プリンシパルの名前にマップします。

例

<security-role-assignment>
<role-name>PayrollAdmin</role-name>
<principal-name>Tanya</principal-name>
<principal-name>system</principal-name>
<externally-defined>True</externally-defined>
...
</security-role-assignment>

service-reference-description

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

ejb-jar.xml内のWebサービス宛先の参照を、WebLogic Serverの実際のWebサービスにマップします。

- wsdl-url - リモートWebサービスを呼び出すためのスタブを作成するためにクライアントによって使用される、参照対象Webサービスの動的wsdlのURL。

- port-info - wsdlに指定されるwsdl:port情報を定義します。

- port-name - wsdl:portのローカル名を定義します。

- stub-property - クライアント・サイドのスタブで設定されるプロパティ。javax.xml.rpc.Stub._setProperty(prop_name, prop_value)と同じ効果があります。

例

<service-reference-description>
<service-ref-name>service/WebServiceBroker</service-ref-name>
<wsdl-url>
http://@PROXY_SERVER@/webservice/BrokerServiceBean?wsdl
</wsdl-url>
<call-property>...</call-property>
<port-info>
<port-name>BrokerServiceIntfPort</port-name>
<stub-property>
<name>javax.xml.rpc.service.endpoint.address</name>
<value>http://@PROXY_SERVER@/webservice/BrokerServiceBean<;/value>
</stub-property>
</port-info>
</service-reference-description>

session-timeout-seconds

値の範囲: (指定なし)

デフォルト値: idle-timeout-seconds

親要素:

weblogic-enterprise-bean
stateful-session-descriptor
stateful-session-cache

機能

EJBコンテナがパッシブ化されたステートフル・セッションBeanをどのくらいディスクに置いておくのかを指定します。コンテナは、Beanインスタンスをディスクにパッシブ化した後にパッシブ化されたEJBのsession-timeout-secondsを削除します。session-timeout-secondsを指定しない場合、デフォルトはidle-timeout-secondsで指定された値です。

例

<stateful-session-descriptor>
<stateful-session-cache>
<max-beans-in-cache>4</max-beans-in-cache>
<idle-timeout-seconds>5</idle-timeout-seconds>
<session-timeout-seconds>120</session-timeout-seconds>
<cache-type>LRU</cache-type>
</stateful-session-cache>
</stateful-session-descriptor>

stateful-session-cache

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
stateful-session-descriptor

機能

ステートフル・セッションEJBインスタンスのキャッシュに使用する以下のオプションを定義します。

- max-beans-in-cache

- idle-timeout-seconds

- session-timeout-sections

- cache-type

ステートフル・セッションBeanのキャッシュの詳細については、「ステートフル・セッションEJBのキャッシュとパッシブ化」を参照してください。

例

次の例では、stateful-session-cache要素の指定方法を示します。

<stateful-session-cache>
<max-beans-in-cache>...</max-beans-in-cache>
<idle-timeout-seconds>...</idle-timeout-seconds>
<session-timeout-seconds>...</session-timeout-seconds>
<cache-type>...</cache-type>
</stateful-session-cache>

stateful-session-clustering

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
stateful-session-descriptor

機能

WebLogic Serverがクラスタ内のステートフル・セッションEJBインスタンスをレプリケートする方法を決める以下のオプションを指定します。

- home-is-clusterable

- home-load-algorithm

- home-call-router-class-name

- replication-type

例

<stateful-session-clustering>
<home-is-clusterable>True</home-is-clusterable>
<home-load-algorithm>random</home-load-algorithm>
<home-call-router-class-name>beanRouter</home-call-router-class-name>
<replication-type>InMemory</replication-type>
</stateful-session-clustering>

stateful-session-descriptor

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

WebLogic Serverのステートレス・セッションEJBに対するキャッシュ、クラスタ化、および永続性などのデプロイメント動作を定義します。

例

<stateful-session-descriptor>
<stateful-session-cache>...</stateful-session-cache>
<allow-concurrent-calls>...</allow-concurrent-calls>
<allow-remove-during-transaction>...
</allow-remove-during-transaction>
<persistent-store-dir>/myPersistenceStore</persistent-store-dir>
<stateful-session-clustering>...</stateful-session-clustering>
</stateful-session-descriptor>

stateless-bean-call-router-class-name

値の範囲:有効なカスタム・クラス名

デフォルト値:なし

親要素:

weblogic-enterprise-bean
stateless-session-descriptor
stateless-clustering

機能

Beanのメソッド呼出しのルーティングに使用するカスタム・クラスの名前を指定します。このクラスはweblogic.rmi.cluster.CallRouter()を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼出しの前に呼び出されます。ルーター・クラスでは、メソッドのパラメータを基に、ルーティングするサーバーを選択できます。このクラスは、サーバー名を返すか、または現在のロード・アルゴリズムがサーバーを選択する必要があることを示すnullを返します。

例

「stateless-clustering」を参照してください。

stateless-bean-is-clusterable

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-enterprise-bean
stateless-session-descriptor
stateless-clustering

機能

stateless-bean-is-clusterableがTrueの場合、EJBをクラスタ内の複数のWebLogic Serverからデプロイできます。ホーム・スタブの呼出しは、Beanがデプロイされるサーバー間で負荷が分散されます。Beanのホスト・サーバーにアクセスできなかった場合、呼出しは、Beanを提供する他のサーバーに自動的にフェイルオーバーします。

例

「stateless-clustering」を参照してください。

stateless-bean-load-algorithm

値の範囲: round-robin | random | weight-based | RoundRobinAffinity | RandomAffinity | WeightBasedAffinity

デフォルト値: weblogic.cluster.defaultLoadAlgorithmの値

親要素:

weblogic-enterprise-bean
stateless-session-descriptor
stateless-clustering

機能

EJBホームのレプリカ間のロード・バランシングに使用するアルゴリズムを指定します。

stateless-bean-load-algorithmを以下のいずれかの値で定義できます。

- round-robin - Beanのホスト・サーバー間で順番にロード・バランシングを実行します。

- random - Beanのホスト・サーバー間でEJBホームのレプリカがランダムにデプロイされます。

- weight-based - ホスト・サーバーの現在の負荷に従って、EJBホームのレプリカをデプロイするサーバーが決まります。

- round-robin-affinity - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、ラウンドロビン・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

- weight-based-affinity - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、重みベース・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

- random-affinity - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、ランダム・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

詳細は、『Oracle WebLogic Serverクラスタの使用』のEJBとRMIオブジェクトのロード・バランシングに関する項を参照してください。

例

「stateless-clustering」を参照してください。

stateless-clustering

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
stateless-session-descriptor

機能

WebLogic Serverがクラスタ内のステートレス・セッションEJBインスタンスをレプリケートする方法を決めるオプションを指定します。

例

<stateless-clustering>
<stateless-bean-is-clusterable>
True
</stateless-bean-is-clusterable>
<stateless-bean-load-algorithm>
random</stateless-bean-load-algorithm>
<stateless-bean-call-router-class-name>
beanRouter
</stateless-bean-call-router-class-name>
<stateless-bean-methods-are-idempotent>
True
</stateless-bean-methods-are-idempotent>
</stateless-clustering>

stateless-session-descriptor

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

WebLogic Serverのステートレス・セッションEJBに対するキャッシュ、クラスタ化、および永続性などのデプロイメント・パラメータを定義します。

例

<stateless-session-descriptor>
<pool>...</pool>
<stateless-clustering>...</stateless-clustering>
</stateless-session-descriptor>

stick-to-first-server

値の範囲: TrueまたはFalse

デフォルト値: False

親要素:

weblogic-enterprise-bean

機能

クラスタにセッション維持型ロード・バランシングを定義します。最初のリクエストをサービスするために選ばれたサーバーが、後続のすべてのリクエストにも使用されます。

例

<stick-to-first-server>
True
</stick-to-first-server>

timer-descriptor

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor

または

message-driven-descriptor

または

stateless-session-descriptor

機能

EJBタイマー・オブジェクトを指定します。

timer-implementation

値の範囲:

有効な値は次のとおりです:

- Clustered - タイマーがクラスタ対応であることを指定します。このオプションを選択すると、EJBタイマーに対して自動フェイルオーバー、ロード・バランシング、クラスタ内の強化したアクセシビリティなどの機能が提供されます。WebLogic ServerのクラスタにデプロイされるEJBの場合はこのオプションをお薦めします。

- Local - タイマーが作成されたサーバー上でのみタイマーが動作し、そのサーバー上のBeanからしか見えないことを指定します。この要素をLocalに設定すると、EJBをクラスタにデプロイし、タイマーを作成するためにEJBを呼び出した場合、その呼出しはクラスタ内のいずれかのサーバーに届きます。別の呼出し(タイマーの取り消しなど)もクラスタ内のどのサーバーにも届く可能性があり、必ずしも、タイマーを作成する呼出しが届いた同じサーバーに届くとは限りません。たとえば、タイマーを作成する呼出しがserver1にリダイレクトされ、タイマーを取り消す呼出しがserver2にリダイレクトされた場合、server2にあるEJBにはserver1にあるタイマーが見えないため、タイマーを取り消すことはできません。

ローカル・タイマーを使用するときにこの制限を回避するには、以下のいずれかの方法を使用できます。

- クラスタ内の1つのサーバーにEJBデプロイメントを固定します。こうすると、EJBに対するすべての呼出しはEJBが固定されているサーバーに届き、すべてのタイマーはその同じサーバー上に存在することになります。ただし、この方法を使用すると、そのEJBはロード・バランシングやフェイルオーバーなどのクラスタ化の利点を利用できなくなります。

- JMSトピックをリスンするメッセージドリブンBean (MDB)を使用して、クラスタ内のすべてのサーバーにタイマーを取り消す呼出しが届くようにします。タイマーを取り消すメッセージはJMSトピックにパブリッシュされ、各サーバー上のMDBによって処理されます。次に、各サーバー上のMDBはBeanのcancelTimerメソッドを呼び出します。ただし、この方法を使用するとアプリケーションがより複雑になり、すべてのサーバー上でタイマーを取り消そうとするのは効率がよくません。

デフォルト値: Local (ファイル・ストアの現在のEJBタイマー・サービスを使用)

親要素:

weblogic-ejb-jar

機能

EJBタイマー・サービスがクラスタ対応であるかどうかを指定します。

例

<timer-implementation>
Clustered
</timer-implementation>

transaction-descriptor

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean

機能

WebLogic Serverのトランザクション動作を定義するオプションを指定します。現在、この要素にはtrans-timeout-secondsという子要素だけがあります。

例

<transaction-descriptor>
<trans-timeout-seconds>20</trans-timeout-seconds>
</transaction-descriptor>

transaction-isolation

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

EJBのメソッド・レベルのトランザクション・アイソレーション設定を定義します。

例

<transaction-isolation>
<isolation-level>...</isolation-level>
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
</transaction-isolation>

詳細については、「isolation-level」を参照してください。

transport-requirements

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-enterprise-bean
iiop-security-descriptor

機能

EJBの転送の要件を指定します。

例

<iiop-security-descriptor>
<transport-requirements>
<confidentiality>supported</confidentiality>
<integrity>supported</integrity>
<client-cert-authentication>suppoted
</client-cert-authentication>
</transport-requirements>
</iiop-security-descriptor>

trans-timeout-seconds

値の範囲: 0 - max

デフォルト値:ドメイン・レベルJTA構成によるもの。

親要素:

weblogic-enterprise-bean
transaction-descriptor

機能

EJBのコンテナで初期化されたトランザクションの最長継続時間を指定します。トランザクションの継続時間がtrans-timeout-secondsの値を超えると、WebLogic Serverによってトランザクションがロールバックされます。

例

「transaction-descriptor」を参照してください。

type-identifier

値の範囲:有効な文字列。WebLogic_CMP_RDBMSはWebLogic ServerのRDBMSベースの永続性を指定します。

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor
persistence
persistence-use

機能

コンテナ管理の永続性サービスを使用するエンティティEJBでのみ必須です。エンティティEJBの永続性タイプを指定します。WebLogic Server RDBMSベースの永続性では、WebLogic_CMP_RDBMSという識別子を使用します。別の永続性ベンダーを使用している場合の正しいtype-identifierについてはベンダーのドキュメントを参照してください。

例

WebLogic Server RDBMSベースの永続性に関する完全な永続性タイプの定義の例については、「persistence-use」を参照してください。

type-storage

値の範囲:有効な文字列

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor
persistence
persistence-use

機能

コンテナ管理の永続性サービスを使用するエンティティEJBでのみ必須です。この永続性タイプのデータを格納するファイルの絶対パスを定義します。パスは、EJBのデプロイメントJARファイルまたはデプロイメント・ディレクトリの最上位を基準にしたファイルの場所を指定する必要があります。

WebLogic Server RDBMSベースの永続性では通常、Beanの永続性データを格納するのにweblogic-cmp-jar.xmlというXMLファイルを使用します。このファイルは、JARファイルのMETA-INFサブディレクトリにあります。

例

WebLogic Server RDBMSベースの永続性に関する完全な永続性タイプの定義の例については、「persistence-use」を参照してください。

type-version

値の範囲:有効な文字列

デフォルト値:なし

親要素:

weblogic-enterprise-bean
entity-descriptor
persistence
persistence-use

機能

同じ永続性タイプの複数バージョンがインストールされている場合に、コンテナ管理による永続性サービスを使用するエンティティEJBの場合に必須です。指定した永続性タイプのバージョンを指定します。たとえば、WebLogic 2.0 CMPの永続性の場合は、次の値を使用します。

6.0

WebLogic 1.1 CMPの永続性の場合は、次の値を使用します。

5.1.0

この要素は、同じ永続性タイプの複数のバージョンがインストールされている場合に必須です。

WebLogic ServerのRDBMSベースの永続性を使用する場合、指定したバージョンは、WebLogic ServerのRDBMS永続性バージョンと完全に一致させる必要があります。バージョンが一致していないと、次のエラーが発生します。

weblogic.ejb.persistence.PersistenceSetupException: Error initializing the CMP
Persistence Type for your bean: No installed Persistence Type matches the signature of
(identifier 'Weblogic_CMP_RDBMS', version 'version_number').

例

WebLogic Server RDBMSベースの永続性に関する完全な永続性タイプの定義の例については、「persistence-use」を参照してください。

use-serverside-stubs

値の範囲: true | false

デフォルト値: false

親要素:

weblogic-enterprise-bean
entity-descriptor
entity-clustering

および

weblogic-enterprise-bean
stateful-session-descriptor
stateful-session-clustering

および

weblogic-enterprise-bean
entity-descriptor
entity-clustering

機能

Beanホームがサーバーのコンテキストでサーバー・サイド・スタブを使用するようにします。

例

「entity-clustering」の例を参照してください。

use81-style-polling

値の範囲: true | false

デフォルト値: false

親要素:

weblogic-ejb-jar
weblogic-enterprise-bean
message-driven-descriptor

機能

WLSバージョン8.1方式のポーリングの下位互換性を有効にします。

WLSバージョン8.1以前では、バッチ処理が有効になっているトランザクション対応MDBは、デプロイ済の各MDBごとに専用のポーリング・スレッドを作成していました。このポーリング・スレッドはdispatch-policyで指定されたプールから割り当てられるものではなく、システムで動作している他のすべてのスレッドに追加される、完全に新しいスレッドでした。詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』のWLS 10.0以前のバージョン方式のポーリングに対する下位互換性に関する項を参照してください。

例

「entity-clustering」の例を参照してください。

weblogic-compatibility

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

WebLogic Server 9.0で導入された要素で、互換性フラグを指定する要素が含まれます。

weblogic-ejb-jar

値の範囲:なし

デフォルト値:なし

親要素:なし

機能

weblogic-ejb-jarは、EJBデプロイメント記述子のWebLogicコンポーネントのルート要素です。

weblogic-enterprise-bean

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

WebLogic Server内で利用可能なBeanに関するデプロイメント情報が含まれます。

work-manager

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-ejb-jar

機能

EJBの作業要求を管理するワーク・マネージャを指定します。

ワーク・マネージャの詳細は、『Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

C weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス

以下の節では、WebLogic固有のXMLスキーマ・ベース(XSD)デプロイメント記述子ファイル、weblogic-cmp-jar.xmlのEJB 2.1の要素について説明します。これらの定義を使用して、EJBデプロイメントを構成するWebLogic固有のweblogic-cmp-jar.xmlファイルを作成します。このデプロイメント記述子ファイルを使用して、コンテナ管理による永続性(CMP)の動作を指定します。

注意:

EJB 3.x実装でJava EE 6メタデータ・アノテーションを使用している場合は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEJBメタデータ・アノテーション・リファレンスに関する項を参照してください。

WebLogic Serverのweblogic-cmp-jar.xmlファイルは、XMLスキーマ(XSD)に基づいています。9.0より前のリリースのWebLogic Serverでは、weblogic-cmp-jar.xmlは文書型定義(DTD)に基づいていました。下位互換性を保持するために、WebLogic ServerではXSDベースとDTDベースのEJB記述子が引き続きサポートされています。そのため、WebLogic ServerのDTDベースの記述子を使用するアプリケーションも記述子を変更せずにデプロイできます。

EJB 1.1デプロイメント記述子の要素については、「EJB 1.1ユーザーへの重要な情報」を参照してください。

- 2.1のweblogic-cmp-jar.xmlデプロイメント記述子ファイルの構造

- 2.1のweblogic-cmp-jar.xmlデプロイメント記述子の要素

詳細情報:

- weblogic-cmp-jar.xmlに必要なXMLスキーマ定義とネームスペース宣言、および文書型定義とDOCTYPEヘッダーについては、「デプロイメント記述子スキーマおよび文書型定義リファレンス」を参照してください。

- weblogic-ejb-jar.xmlファイルについては、「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」を参照してください。

EJB 1.1デプロイメント記述子の要素については、「EJB 1.1ユーザーへの重要な情報」を参照してください。

2.1のweblogic-cmp-jar.xmlデプロイメント記述子ファイルの構造

weblogic-cmp-jar.xmlファイルは、WebLogic ServerのRDBMSベースの永続性サービスを使用するエンティティEJBのデプロイメント記述子を定義します。EJBコンテナでは、9.0より前のバージョンのWebLogic Serverで提供されていたXMLとは異なるバージョンのweblogic-cmp-jar.xmlを使用します。

旧バージョンのweblogic-cmp-jar.xml DTD Beanも引続きこのリリースのWebLogic Serverにデプロイできます。同様に、WebLogic Server 8.1でサポートされていたweblogic-cmp-jar.xml DTDも引続き使用できます。WebLogic Server 9.0から、デプロイメント記述子はXSDベースになりましたが、下位互換性を保持するためにWebLogic ServerはDTDベースの記述子も引続きサポートしています。ただし、CMP 2.1の機能を使用する場合は、下記のXSDを使用する必要があります。

このリリースのWebLogic Serverに対応させるため、DDConverterを実行して9.0より前のリリースのEJBデプロイメント記述子を変換することをお薦めします。DDConverterでは、9.0より前のリリースのWebLogic ServerのDTDベースのEJBデプロイメント記述子を、このリリースでサポートされているXSDベースの記述子に変換します。

注意:

アプリケーションを新しいWebLogic Serverリリースに移行するときには、必ず記述子を変換することをお薦めします。

WebLogic Serverのweblogic-cmp-jar.xmlの最上位要素は、weblogic-rdbms-jar要素で構成されます。

weblogic-rdbms-jar
weblogic-rdbms-bean
ejb-name
data-source-jndi-name
table-map
field-group
relationship-caching
sql-shape
weblogic-query
delay-database-insert-until
use-select-for-update
lock-order
instance-lock-order
automatic-key-generation
check-exists-on-method
cluster-invalidation-disabled

weblogic-rdbms-relation
relation-name
table-name
weblogic-relationship-role
order-database-operations
enable-batch-operations
create-default-dbms-tables
validate-db-schema-with
database-type
default-dbms-tables-ddl

compatibility
serialize-byte-array-to-oracle-blob
serialize-char-array-to-bytes
allow-readonly-create-and-remove
disable-string-trimming

2.1のweblogic-cmp-jar.xmlデプロイメント記述子の要素

以下のweblogic-cmp-jar.xml要素のリストには、このリリースのWebLogic Serverでサポートされているすべての要素が含まれています。

- allow-readonly-create-and-remove

- automatic-key-generation

- caching-element

- caching-name

- check-exists-on-method

- cluster-invalidation-disabled

- cmp-field

- cmr-field

- column-map

- compatibility

- create-default-dbms-table

- database-specific-sql

- database-type

- data-source-jndi-name

- db-cascade-delete

- dbms-column

- dbms-column-type

- dbms-default-value

- default-dbms-tables-ddl

- delay-database-insert-until

- description

- disable-string-trimming

- ejb-name

- ejb-ql-query

- enable-batch-operations

- enable-query-caching

- field-group

- field-map

- finders-return-nulls

- foreign-key-column

- foreign-key-table

- generator-name

- generator-type

- group-name

- include-updates

- instance-lock-order

- key-cache-size

- key-column

- lock-order

- max-elements

- method-name

- method-param

- method-params

- optimistic-column

- order-database-operations

- pass-through-columns

- primary-key-table

- query-method

- relation-name

- relationship-caching

- relationship-role-map

- relationship-role-name

- serialize-byte-array-to-oracle-blob

- serialize-char-array-to-bytes

- sql

- sql-query

- sql-select-distinct

- sql-shape

- sql-shape-name

- table-map

- table-name

- trigger-updates-optimistic-column

- unknown-primary-key-field

- use-select-for-update

- validate-db-schema-with

- verify-columns

- verify-rows

- version-column-initial-value

- weblogic-ql

- weblogic-query

- weblogic-rdbms-bean

- weblogic-rdbms-jar

- weblogic-rdbms-relation

- weblogic-relationship-role

allow-readonly-create-and-remove

値の範囲: true | false

デフォルト値: false

親要素:

weblogic-rdbms-jar
compatibility

機能

WebLogic Server 8.1 SP02で導入されたこの要素は、下位互換性のフラグです。ReadOnly同時実行性を使用するEJBで作成と削除を有効にするために使用します。

WebLogic Server 8.1 SP2より前は、それらの処理は許可されていました(ただしトランザクション的な意味はありませんでした)。ReadOnly Beanでより効率的なコードを生成できるように、また、それらを使用するのがプラクティスとして良くないという理由から、作成と削除は許可されなくなっています。

例

<compatibility>
<allow-readonly-create-and-remove>
true
</allow-readonly-create-and-remove>
</compatibility>

automatic-key-generation

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-bean

機能

automatic-key-generation要素は、主キーが自動的に生成される方法を指定します。この機能の詳細については、「主キーの自動生成」を参照してください。

例

以下のサンプル・コードは、さまざまな主キー生成方法のautomatic-key-generation要素を示しています。サポートされている生成方法については、「generator-type」を参照してください。

例C-1 generator-type=Oracleのautomatic-key-generation

<automatic-key-generation>
<generator-type>Oracle</generator-type>
<generator-name>test_sequence</generator-name>
<key-cache-size>10</key-cache-size>
</automatic-key-generation>

例C-2 generator-type=SQL-SERVERのautomatic-key-generation

<automatic-key-generation>
<generator-type>SQL-SERVER</generator-type>
</automatic-key-generation>

例C-3 generator-type=NamedSequenceTableのautomatic-key-generation

<automatic-key-generation>
<generator-type>NamedSequenceTable</generator-type>
<generator-name>MY_SEQUENCE_TABLE_NAME</generator-name>
<key-cache-size>100</key-cache-size>
</automatic-key-generation>

caching-element

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean
relationship-caching

機能

関連するBeanでcmr-field とgroup-nameを指定します。group-nameを指定しなかった場合、デフォルトのgroup-name (全フィールドをロード)が使用されます。詳細については、「group-name」を参照してください。

caching-elementでは、relationship-cachingの例のようにネストされたキャッシュ要素を格納できます。

リレーションシップ・キャッシングについては、「リレーションシップ・キャッシング」を参照してください。

例

「relationship-caching」を参照してください。

caching-name

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean
relationship-caching

機能

caching-name要素は、リレーションシップ・キャッシュの名前を指定します。リレーションシップ・キャッシングについては、「リレーションシップ・キャッシング」を参照してください。

例

「relationship-caching」を参照してください。

check-exists-on-method

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-rdbms-bean

機能

デフォルトでは、EJBコンテナはコンテナ管理による永続性(CMP)エンティティBeanの有無を、Bean上で呼び出されたビジネス・メソッドが完了する前にチェックします。これは、削除されたコンテナ管理のエンティティBean上で何らかのビジネス・メソッドが呼び出されると、直ちにコンテナがアプリケーションに対して通知を行うことを意味します。

EJBコンテナが、存在するかどうかのチェックをする前にトランザクションの完了を待機するように指定するには、check-exists-on-methodをFalseに設定します。これにより、大半のアプリケーションで高いパフォーマンスを実現しつつ、十分なレベルのチェックが提供されます。

例

次の例では、削除されたCMPエンティティBean上でビジネス・メソッドが呼び出されたことをWebLogic Serverがアプリケーションに通知するように指定しています。

<check-exists-on-method>True</check-exists-on-method>

cluster-invalidation-disabled

値の範囲: true | false

デフォルト値: false

親要素:

weblogic-rdbms-bean

機能

WebLogic Server 9.0で採用されたこのフラグは、OptimisticまたはReadOnly同時実行性を使用するEJBがデプロイ先のクラスタのメンバーによって更新されたときにそのEJBを無効化するかどうかを指定するために使用します。詳細については、「クラスタ内のオプティミスティック同時実行性の無効化オプション」を参照してください。

例

<cluster-invalidation-disabled>true</cluster-invalidation-disabled>

cmp-field

値の範囲: Beanのフィールドの有効な名前。フィールドは、ejb-jar.xml内に対応するcmp-entryエントリを持つ必要があります。フィールド名は大文字と小文字が区別されます。

デフォルト値:なし

親要素:

weblogic-rdbms-bean
field-map

および

weblogic-rdbms-relation
field-group

機能

この名前は、Beanインスタンスのマップされたフィールドを指定します。Beanインスタンスのフィールドには、データベースから取得した情報が指定されている必要があります。

例

「field-map」を参照してください。

cmr-field

値の範囲: Beanのフィールドの有効な名前。フィールドは、ejb-jar.xmlに対応するcmr-fieldエントリを持つ必要があります。

デフォルト値:なし

親要素:

weblogic-rdbms-relation
field-group

および

relationship-caching
caching-element

機能

コンテナ管理による関係フィールドの名前を指定します。

例

<cmr-field>stock options</cmr-field>

column-map

値の範囲:なし

デフォルト値:なし

親要素:

<weblogic-rdbms-relation>
<weblogic-relationship-role>
<relationship-role-map>

機能

この要素は、データベース内の表の外部キー列と対応する主キーのマッピングを表します。2つの列は同じ表にある場合も別の表にある場合もあります。列が属している表は、column-map要素がデプロイメント記述子に表示されるコンテキストに対しては暗黙的です。

例

column-map要素の例は以下のとおりです。

注意:

foreign-key-columnがリモートBeanを参照する場合は、key-column要素を指定する必要はありません。

<column-map>
<foreign-key-column>account-id</foreign-key-column>
<key-column>id</key-column>
</column-map>

compatibility

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar

機能

WebLogic Server 8.1 SP02で導入された<compatibility>要素では、記述子ファイルで記述されているすべてのcmp Beanの互換性フラグを指定する要素を設定します。

例

<compatibility>
<serialize-byte-array-to-oracle-blob>...</serialize-byte-array-to-oracle-blob>
<serialize-char-array-to-bytes>...</serialize-char-array-to-bytes>
<allow-readonly-create-and-remove>...</allow-readonly-create-and-remove>
<disable-string-trimming>...</disable-string-trimming>
</compatibility>

create-default-dbms-table

値の範囲: Disabled | CreateOnly | DropAndCreate | DropAndCreateAlways | AlterOrCreate

デフォルト値: Disabled

親要素:

weblogic-rdbms-jar

機能

create-default-dbms-table要素は、以下の2つの機能を実行します。

- 基底の表スキーマが変更されたときに、WebLogic Serverがデプロイメント・ファイルおよびBeanクラスの記述に基づいて自動的にデフォルト表を作成するかどうか、またはどのように作成するのかを決める

- WebLogic ServerがOracleデータベースのSEQUENCEを自動的に作成するかどうか、またはどのように作成するのかを決める

この要素は、開発段階で役立つ場合にのみ使用します。使用するDBMS CREATE文の表スキーマがコンテナの最適な定義になります。プロダクション環境では通常、より正確なスキーマ定義が必要です。

自動表作成

次の表は、WebLogic Serverがcreate-default-dbms-tablesの値に基づいてどのように自動表作成を処理するのかを説明しています。

表C-1 自動表作成

<create-default-dbms-tables>の設定値

自動表作成に関連する動作

Disabled

EJBコンテナは自動表作成に関して何も行いません。これがデフォルト値です。

CreateOnly

EJBコンテナは、スキーマの変更を検出すると自動的に表を生成します。

コンテナは、デプロイメント・ファイルおよびBeanクラス内の情報に基づいて表を作成しようとします。表作成が失敗した場合は、「Table Not Found」エラーが送出され、ユーザーは手動で表を作成する必要があります。

DropAndCreate

EJBコンテナは、スキーマの変更を検出すると自動的に表を生成します。

コンテナは、列が変更されている場合はデプロイメント時に表を削除してから再作成します。コンテナはデータを保存しません。

列タイプとcmpフィールド・タイプの間に互換性があることを確認する必要があります。EJBコンテナは、列タイプとcmpフィールド・タイプの間に互換性があることを確認しません。

DropAndCreateAlways

EJBコンテナは、スキーマの変更を検出すると自動的に表を生成します。

コンテナは、列が変更されているかどうかに関係なくデプロイメント時に表を削除してから作成します。コンテナはデータを保存しません。

AlterOrCreate

EJBコンテナは、スキーマの変更を検出すると自動的に表を生成します。

コンテナは、まだ存在していない場合は表を作成します。表が存在する場合、コンテナは表スキーマを変更します。データは保存されます。

注意: 新しい列が主キーとして指定されているか、値がnullの列が新しい主キー列として指定されている場合には、この設定を選択しないでください。

TABLE CREATIONが失敗した場合、サーバーはTable Not Foundエラーを送出するので、表を手動で作成しなければなりません。

「自動表作成(開発のみ)」を参照してください。

OracleデータベースのSEQUENCEの自動生成

注意:

OracleデータベースのSEQUENCEの自動生成は、開発モードで動作しているサーバーでのみ機能します。

次の表は、WebLogic Serverがcreate-default-dbms-tablesの値に基づいてどのように自動SEQUENCE生成を処理するのかを説明しています。

表C-2 OracleデータベースのSEQUENCEの自動生成

<create-default-dbms-tables>の設定値

得られる動作

Disabled

EJBコンテナはSEQUENCE生成に関して何も行いません。これがデフォルト値です。

CreateOnly

EJBコンテナはSEQUENCEを作成し、enerator-name要素の値に「_WL」を追加してその名前を作成します。

DropAndCreate

EJBコンテナはSEQUENCEを作成し、generator-name要素の値に「_WL」を追加してその名前を作成します。

SEQUENCEのインクリメント値がkey-cache-size要素の値と一致しない場合、コンテナはkey-cache-sizeの値と一致するようにインクリメント値を変更します。

DropAndCreateAlways

EJBコンテナはSEQUENCEを作成し、generator-name要素の値に「_WL」を追加してその名前を作成します。

SEQUENCEのインクリメント値がkey-cache-size要素の値と一致しない場合、コンテナはkey-cache-sizeの値と一致するようにインクリメント値を変更します。

AlterOrCreate

EJBコンテナはSEQUENCEを作成し、generator-name要素の値に「_WL」を追加してその名前を作成します。

SEQUENCEのインクリメント値がkey-cache-size要素の値と一致しない場合、コンテナはkey-cache-sizeの値と一致するようにインクリメント値を変更します。

OracleデータベースのSEQUENCEの自動生成の詳細については、「OracleデータベースのSEQUENCEのサポート」を参照してください。

例

次の例では、create-default-dbms-tables要素を指定します。

<create-default-dbms-tables>CreateOnly</create-default-dbms-tables>

database-specific-sql

値の範囲:なし

デフォルト値:なし

要件: database-typeの指定が必要

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean
weblogic-query
sql-query

機能

database-specific-sql要素では、データベース固有のSQL文を指定します。

例

<database-specific-sql>
<database-type>SQLServer</database-type>
<sql>SELECT name, phone, location, testid FROM medrecappPharmacyBeanTable WHERE
testid = ?1 AND SUBSTRING(testid, 1,5) = 'local' ORDER BY name
</sql>
</database-specific-sql>

database-type

値の範囲: DB2 | Informix | MySQL | Oracle | SQLServer | SQLServer2000 | Sybase

デフォルト値:なし

親要素:

weblogic-rdbms-jar

および

weblogic-rdbms-jar
weblogic-rdbms-bean
weblogic-quer
sql-query
database-specific-sql

機能

database-type要素では、基底WebLogic Server DBMSまたはベンダー固有のSQL文の実行対象となるDBMSとして使用するデータベースを指定します。weblogic-rdbms-jar要素でdatabase-typeを指定した場合、指定したデータベースは、database-specific-sql要素の別のdatabase-type要素によってオーバーライドされない限り、weblogic-rdbms-jarデプロイメント記述子ファイル全体に適用されます。

例

<database-type>Oracle</database-type>

data-source-jndi-name

値の範囲:有効なWebLogic Server JDBCデータ・ソース名

デフォルト値:なし

親要素:

weblogic-rdbms-bean

機能

このBeanのデータベース接続で使用するJDBCデータ・ソース名を指定します。データ・ソースの詳細は、『Oracle WebLogic Server JDBCのプログラミング』を参照してください。

注意:

WebLogic Server 9.0より前では、この要素はdata-source-nameでした。

例

「table-name」を参照してください。

db-cascade-delete

値の範囲:なし

デフォルト値:デフォルトでは、データベースのカスケード削除は使用されません。EJBコンテナは、個別にSQL DELETEを発行してカスケード削除を実行します。

親要素:

weblogic-rdbms-bean
weblogic-relationship-role

機能

アプリケーションが、データベースに組み込まれているカスケード削除のサポートを利用し、パフォーマンスが向上するようにします。この機能は、以下の場合にのみサポートされます。

- Oracleデータベース

- 1対1または1対多の関係

weblogic-cmp-rdbms-jar.xmlでdb-cascade-deleteが有効になっている場合は、以下のようにする必要があります。

- ejb-jar.xmlでcascade-deleteを有効にする

- データベースの表定義でカスケード削除を有効にする

注意:

db-cascade-deleteを指定しない場合は、データベースのカスケード削除機能を有効にしないようにしてください(結果が不正確になります)。

Oracleデータベースでのカスケード削除の設定

次のOracleデータベースの表定義では、データベースで親のdeptが削除されるとemp行がすべて削除されます。

CREATE TABLE dept
(deptno   NUMBER(2) CONSTRAINT pk_dept PRIMARY KEY,
dname    VARCHAR2(9) );
CREATE TABLE emp
(empno    NUMBER(4) PRIMARY KEY,
ename    VARCHAR2(10),
deptno   NUMBER(2)   CONSTRAINT fk_deptno
REFERENCES dept(deptno)
ON DELETE CASCADE );

例

<weblogic-relationship-role>
<db-cascade-delete/>
</weblogic-relationship-role>

dbms-column

値の範囲:有効なデータベース列

デフォルト値:なし

親要素:

weblogic-rdbms-bean
field-map

機能

フィールドがマップされるデータベース列の名前です。

注意:

大文字/小文字を区別しないデータベースの場合でも、dbms-columnでは大文字/小文字を区別します。

例

「field-map」を参照してください。

dbms-column-type

値の範囲: Blob | Clob | LongString | SybaseBinary

デフォルト値:なし

要件: BlobまたはClobを指定するには、dbms-default-valueをOracleまたはDB2データベースに設定する必要がある

親要素:

weblogic-rdbms-bean
field-map

機能

cmp-fieldの型を指定します。現在のフィールドをOracleまたはDB2データベース内のBlobまたはClob、またはSybaseデータベース内のLongStringまたはSybaseBinaryにマップします。

- Blob - フィールドをOracleまたはDB2データベースのBlobにマップします。

- Clob - フィールドをOracleまたはDB2データベースのClobにマップします。

- LongString - setCharacterStreamを使用して文字列データをデータベースに書き込むようにコンテナに通知します。一部のJDBCドライバでは、4KBを超えるデータをsetStringで書き込むことに問題があります。

- SybaseBinary - setBytesを使用してバイトをバイナリ列に書き込むようにコンテナに通知します(setBinaryStreamがSybaseXADriverでは機能しないため)。

例

<field-map>
<cmp-field>photo</cmp-field>
<dbms-column>PICTURE</dbms-column>
<dbms_column-type>OracleBlob</dbms-column-type>
</field-map>

dbms-default-value

値の範囲: DB2 | Informix| MySQL | Oracle | SQLServer | SQLServer2000 | Sybase

デフォルト値:

親要素:

weblogic-rdbms-bean
field-map

機能

デフォルトの基底DBMSとして使用するデータベースを指定します。この値は、database-type要素によってオーバーライドできます。

例

<dbms-default-value>Oracle</dbms-default-value>

default-dbms-tables-ddl

値の範囲:有効なファイル名

デフォルト値:

親要素:

weblogic-rdbms-jar

機能

EJBコンテナが表作成スクリプトを記述するDDLファイル名を指定します。

delay-database-insert-until

値の範囲: ejbCreate | ejbPostCreate

デフォルト値: ejbPostCreate

要件:

親要素:

weblogic-rdbms-bean

機能

新しいCMP Beanがいつデータベースに挿入されるのかを指定します。指定可能な値で、以下の動作が行われます。

- ejbCreate - ejbCreateの直後にデータベース挿入を実行します。この設定の場合は、不要な格納操作を避けることでejbCreateよりもパフォーマンスが良くなります。

- ejbPostCreate - ejbPostCreateの直後に挿入を実行します。

この要素は、order-database-operationsがFalseの場合のみ有効です。デフォルトでは、order-database-operationsはtrueです。デフォルトの場合は、トランザクションがコミットされたときに新しいBeanが挿入されます。

cmr-fieldがnull値を許可しないforeign-key列にマップされている場合、データベースの挿入はejbPostCreateの後まで遅延する必要があります。この場合、cmr-fieldをejbPostCreateでnull以外の値に設定してからBeanをデータベースに挿入しなければなりません。

最大限の柔軟性を実現するため、関連BeanをejbPostCreateメソッドで作成することは避けてください。ejbPostCreateで関連Beanが作成され、データベースの制約によって関連Beanが未作成のBeanを参照できない場合は、メソッドが完了するまでデータベースの挿入は実行できません。

注意:

cmr-fieldは、Beanの主キーが不明な段階でejbCreateの中で設定することはできません。

例

<delay-database-insert-until>ejbPostCreate</delay-database-insert-until>

description

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean
weblogic-query

または

weblogic-rdbms-jar
weblogic-rdbms-bean
sql-shape

機能

description要素は、親要素を示すテキストの指定に使用します。

例

<description>Contains a description of parent element</description>

disable-string-trimming

値の範囲: True | False

デフォルト値: False

親要素:

compatibility

機能

この要素は、WebLogic Server 9.0で導入された互換性フラグです。この要素では、String[]型のcmp-fieldを削除するかどうかを指定します。Trueに設定すると、文字列の削除が無効になります。文字列の削除の詳細については、「文字列値CMPフィールドの削除」および「文字列の削除を無効にする」を参照してください。

例

<compatibility>
<disable-string-trimming>True</disable-string-trimming>
</compatibility>

ejb-name

値の範囲: ejb-jar.xmlで定義したCMPエンティティBeanのejb-nameに一致する必要があります。

デフォルト値:なし

親要素:

weblogic-rdbms-bean

機能

ejb-cmp-rdbms.xmlで定義したEJBを指定する名前です。この名前は、ejb-jar.xmlで定義したCMPエンティティBeanのejb-nameに一致している必要があります。

例

「table-name」を参照してください。

ejb-ql-query

値の範囲:

デフォルト値:

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean
weblogic-query

機能

ejb-ql-query要素では、EJB-QL問合せを指定します。weblogic-cmp-jar.xmlデプロイメント記述子では、EJBファインダを実装しているか、またはWebLogic固有の拡張を備えているEJB-QLだけを指定します。標準EJB-QL機能だけを使用する問合せはejb-jar.xmlデプロイメント記述子で指定します。

例

「weblogic-query」を参照してください。

enable-batch-operations

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-rdbms-jar

機能

WebLogic Server 8.1で導入されたこの要素は、EJBコンテナがデータベースのバッチ処理を許可するのかどうかを管理します(バッチ挿入、バッチ更新、およびバッチ削除を含む)。

この要素をTrueに設定すると、EJBはトランザクション中のデータベース処理をコミット時間まで遅延させます。

例

次のXMLサンプルでは、enable-batch-operations要素の使い方を示します。

<enable-batch-operations>True</enable-batch-operations>

enable-query-caching

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean
weblogic-query

または

weblogic-rdbms-jar
weblogic-rdbms-relation

機能

WebLogic Server 9.0で導入された要素で、読取り専用エンティティEJBを問合せレベルでキャッシュするかどうかを指定します。読取り専用エンティティEJBを問合せレベルでキャッシュすると、パフォーマンスが向上します。これは、ファインダがキャッシュ内のEJBにアクセスできるようになり、データベースへのアクセスを回避できるからです。この値をTrueに設定した場合、アプリケーションまたはBeanレベルでキャッシュされる問合せの最大数を指定できます。キャッシュされる問合せの最大数を指定するには、weblogic-ejb-jar.xmlデプロイメント記述子のmax-queries-in-cacheを設定します。詳細については、「max-queries-in-cache」を参照してください。

例

次のXMLサンプルでは、enable-query-caching要素の使い方を示します。

<enable-query-caching>True</enable-query-caching>

field-group

値の範囲:なし

デフォルト値: field-groupが指定されていないファインダと関係に対して、defaultという特殊なグループを使用します。デフォルト・グループには、Beanのcmp-fieldがすべて含まれますが、cmr-fieldは含まれません。

親要素:

weblogic-rdbms-relation

機能

field-group要素は、Beanのcmp-fieldとcmr-fieldのサブセットを表します。Bean内の関連フィールドを、フォルトのあったグループに1つのユニットとしてまとめることができます。グループをファインダまたは関係に関連付けることができます。それによって、ファインダを実行するか、または関係に従った結果としてBeanがロードされたときに、グループ内の指定フィールドのみがロードされます。

フィールドは複数のグループに関連付けられている場合があります。この場合、フィールドに対してgetXXXメソッドを実行すると、そのフィールドを含む最初のグループで障害が発生します。

例

field-group要素には、以下の要素を指定できます。

<weblogic-rdbms-bean>
<ejb-name>XXXBean</ejb-name>
<field-group>
<group-name>medical-data</group-name>
<cmp-field>insurance</cmp-field>
<cmr-field>doctors</cmr-fields>
</field-group>
</weblogic-rdbms-bean>

field-map

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-bean

機能

field-map要素は、データベースの特定の列とBeanインスタンスのcmp-fieldの間のマッピングを表します。

任意指定のgroup-name要素は、cmp-fieldのgetXXXメソッドが呼び出され、値がメモリーにないために、EJBコンテナがDBMSから値を読み込む必要がある場合にロードされるフィールド・グループを指定します。group-nameを省略すると、cmp-fieldがどのフィールド・グループでも明示的にリストされていない場合はデフォルト・グループ(すべてのcmp-fieldが含まれている)が使用されます。明示的にリストされている場合には、cmp-fieldのあるフィールド・グループが選択されます。したがって、cmp-fieldが複数のフィールド・グループでリストされている場合、またはコンテナがグループのいずれかを任意に選択する場合、開発者はgroup-nameを指定する必要があります。

dbms-column-type要素は任意で指定します。

例

field-map要素には、以下の要素を指定できます。

<field-map>
<cmp-field>....</cmp-field>
<dbms-column>...</dbms-column>
<dbms-column-type>...</dbms-column-type>
<group-name>...</group name>
</field-map>

finders-return-nulls

値の範囲: True | False

デフォルト値:なし

親要素:

weblogic-rdbms-jar
compatibility
weblogic-query

機能

この要素は、WebLogic Server 9.0で導入された互換性フラグです。ファインダが結果としてNULLを返すことができるかどうかを指定します。

デフォルト

例

<compatibility>
<finders-return-nulls>True</finders-return-value>
</compatibility>

foreign-key-column

値の範囲:有効な外部キー・データベース列名

デフォルト値:なし

親要素:

weblogic-rdbms-bean
column-map

機能

foreign-key-column要素は、データベース内の外部キーの列を表します。

例

「column-map」を参照してください。

foreign-key-table

値の範囲:有効なデータベース表名

デフォルト値:なし

親要素:

weblogic-rdbms-jar
weblogic-rdbms-relation
weblogic-relationship-role
relationship-role-map

機能

foreign-key-table要素は、外部キーを格納するDBMS表名を指定します。

例

「relationship-role-map」を参照してください。

generator-name

値の範囲:

デフォルト値:

親要素:

weblogic-rdbms-bean
automatic-key-generation

機能

generator-name要素は、主キー・ジェネレータの名前を指定する場合に使用します。

- generator-type要素がOracleで、WebLogic Serverが開発モードで動作している場合、EJBコンテナは自動SEQUENCE生成機能の過程でgenerator-nameに「_WL」を追加してそのOracleデータベースのSEQUENCEの名前を作成します。
OracleデータベースのSEQUENCEの自動生成の詳細については、「OracleデータベースのSEQUENCEのサポート」を参照してください。

- generator-type要素がOracleで、WebLogic Serverがプロダクション・モードで動作している場合、EJBコンテナはOracleデータベースのSEQUENCEの名前をgenerator-nameの値に設定します。

- generator-type要素がNamedSequenceTableの場合、generator-name要素は使用されるSEQUENCE_TABLEの名前になります。

例

「automatic-key-generation」を参照してください。

generator-type

値の範囲: Identity | Sequence | SequenceTable

デフォルト値:

親要素:

weblogic-rdbms-bean
automatic-key-generation

機能

generator-type要素は、使用する主キー生成方法を指定します。

注意:

automatic-key-generationを使用する際は、database-type要素を設定する必要があります。

また、generator-typeはOracleデータベースのSEQUENCEの自動生成でも使用します。「OracleデータベースのSEQUENCEのサポート」を参照してください。

各generator-typeに対しては、次のデータベースがサポートされています。

- Identity : Oracleデータベースはサポートされません。

- Sequence : Oracle、DB2、およびInformix (バージョン9.2以降)データベースがサポートされます。

- SequenceTable: すべてのデータベースがサポートされます。

例

「automatic-key-generation」を参照してください。

group-name

値の範囲:なし

デフォルト値:

field-group

および

caching-element

および

weblogic-query

および

field-map

および

weblogic-relationship-role

親要素:

weblogic-rdbms-relation
field-group

機能

フィールド・グループの名前を指定します。

例

「field-group」を参照してください。

include-updates

値の範囲: True | False

デフォルト値: オプティミスティック同時実行性を使用するBeanではFalse他の同時実行性を使用するBeanではTrue

親要素:

weblogic-rdbms-bean
weblogic-query

機能

現在のトランザクション中の更新を必ず問合せの結果に反映するかどうかを指定します。この要素をTrueに設定した場合、コンテナは現在のトランザクションによる変更をすべてディスクにフラッシュしてから問合せを実行します。値をFalseにすると、最高のパフォーマンスが得られます。

例

<weblogic-query>
<query-method>
<method-name>findBigAccounts</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
</query-method>
<ejb-ql-query>
<weblogic-ql>WHERE BALANCE>10000 ORDER BY NAME</weblogic-ql>
</ejb-ql-query>
<include-updates>True</include-updates>
</weblogic-query>

instance-lock-order

値の範囲: AccessOrder | ValueOrder

デフォルト値: AccessOrder

親要素:

weblogic-rdbms-bean

機能

特定EJBのインスタンスのロックまたは処理順序を指定します。この要素は、この要素を使用しなければデッドロックが起こるアプリケーションでデッドロックを防止するために使用できます。instance-lock-orderは、同じEJBの複数のインスタンスに適用されるデータベース操作(更新など)がコンテナによって実行される場合に常に使用します。この要素は、Beanインスタンスでデータベース・ロックを取得させる操作の順序を指定します。

たとえば、instance-lock-orderを使用すると、データベース同時実行性を使用する特定のEJBインスタンスでEJBコンテナがejbStoreを呼び出す順序を指定できます。ejbStoreは、データベースが更新されるときに排他的ロックを取得できます。instance-lock-orderは、オプティミスティック同時実行性を使用するBeanがオプティミスティック・チェックの実行時にロックされる順序も制御します。

- AccessOrder - コンテナは、トランザクションの過程でアプリケーションがBeanにアクセスした順序でロックが取得(またはアップグレード)されるようにBeanを処理します。これは、システムのすべてのトランザクションがBeanのインスタンス(最終的にはデータベース表の行)に同じ順序でアクセスする場合の推奨値です。

- ValueOrder - Beanは、主キーの値に基づく順序で処理されます。複数の同時トランザクションが異なる順序で同じEJBのインスタンスにアクセスする場合のデッドロックを防止するために、ValueOrderを指定する必要があります。

注意:

ValueOrderが指定されている場合、EJBの主キー・クラスはjava.lang.Comparableインタフェースを実装する必要がありません(ただし、全体的な順序付けになります)。主キーがjava.lang.Comparableを実装しない場合、Beanは主キーのハッシュ・コード値を使用して部分的に順序付けされます。

例

<instance-lock-order>ValueOrder</instance-lock-order>

key-cache-size

値の範囲:

デフォルト値: 1

親要素:

weblogic-rdbms-bean
automatic-key-generation

機能

自動主キー生成機能で利用可能な主キー・キャッシュのサイズをオプションとして指定します。また、EJBコンテナは自動SEQUENCE生成が有効なときにはこの値を使用してOracleデータベースのSEQUENCEのインクリメント値を計算します。「OracleデータベースのSEQUENCEのサポート」を参照してください。

generator-typeの値が、

- Oracleである場合、key-cache-sizeはOracleデータベースのSEQUENCE INCREMENT値と一致していなければなりません。この値とOracleデータベースのSEQUENCE INCREMENT値が一致していない場合は、キー重複の問題が起こります。

- NamedSequenceTableである場合、key-cache-sizeは1回のDBMS呼出しでコンテナが取得するキーの数を指定します。

- SQLServerである場合、key-cache-sizeは無視されます。

例

「automatic-key-generation」を参照してください。

key-column

値の範囲:有効な主キー列名

デフォルト値:なし

親要素:

weblogic-rdbms-bean
column-map

機能

key-column要素は、データベース内の主キーの列を表します。

例

「column-map」を参照してください。

lock-order

値の範囲:すべての正の整数

デフォルト値: 0

親要素:

weblogic-rdbms-bean

機能

このフラグを使用すると、トランザクションに複数のBeanおよび排他的同時実行性が関与する場合に、エンティティBeanのデータベース・ロックの順番を指定できます。最も小さい数値を付けられたBeanが最初にロックされます。

このフラグは、デッドロック状況を回避するためのみに使用します。現時点では、トランザクションがカスケード削除を実行する場合にのみ適用されます。

例

lock-order要素の例は次のとおりです。

<lock-order>1</lock-order>
<!ELEMENT lock-order (PCDATA)>

max-elements

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-bean
weblogic-query

機能

max-elementsは多値問合せによって返される要素の最大数を指定します。この要素は、JDBCのmaxRows機能とほぼ同じです。

例

max-elements要素の例は次のとおりです。

<max-elements>100</max-elements>
<!ELEMENT max-element (PCDATA)>

method-name

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-bean
query-method

機能

method-name要素は、ファインダ・メソッドまたはejbSelectメソッドの名前を指定します。

注意:

「*」文字はワイルドカードとして使用できません。

例

「weblogic-query」を参照してください。

method-param

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-bean
method-params

機能

method-param要素には、Javaタイプのメソッド・パラメータの完全修飾名が含まれます。

例

<method-param>java.lang.String</method-param>

method-params

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-bean
query-method

機能

method-params要素には、Javaタイプのメソッド・パラメータの完全修飾名の順序付きリストが含まれます。

例

「weblogic-query」を参照してください。

optimistic-column

値の範囲:有効なデータベース列名

デフォルト値:なし

親要素:

weblogic-rdbms-bean
table-map

機能

optimistic-column要素は、オプティミスティック同時実行性を実装するためのバージョン値またはタイムスタンプ値を格納するデータベース列を示します。オプティミスティック同時実行性の詳細については、「同時実行性ストラテジの選択」を参照してください。

注意:

すべてのデータベースで大文字と小文字が区別されるわけではありませんが、この要素では、大文字と小文字を区別します。

例

次のXML例では、optimistic-column要素の使い方を示します。

<optimistic-column>ROW_VERSION</optimistic-column>

ROW_VERSIONは、同時実行性のチェックに使用する値が格納されるデータベース列の名前です。

order-database-operations

値の範囲: True | False

デフォルト値: True

親要素:

weblogic-rdbms-jar

機能

WebLogic Server 8.1で導入されたこの要素は、EJBコンテナが、トランザクション内のすべてのデータベース処理をコミット時間まで遅延し、処理間でのデータベースの依存関係を自動的にソートし、これらの処理を、一切のデータベース制約エラーが生じない方式でデータベースに送るかどうかを決定します。

enable-batch-operationsがTrueの場合、コンテナは自動的にorder-database-operationsをTrueに設定します。order-database-operationsを無効にするには、order-database-operationsとenable-batch-operationsの両方をFalseに設定します。

「ejb-ql-query」と「delay-database-insert-until」も参照してください。

例

<order-database-operations>True</order-database-operations>

pass-through-columns

値の範囲:任意の正の整数

デフォルト値:

親要素:

weblogic-rdbms-bean
sql-shape

機能

WebLogic Server 9.0で導入された要素で、マップされずにSQL問合せの結果セットに渡される集合列の数を指定します。

例

「sql-shape」を参照してください。

primary-key-table

値の範囲:有効なデータベース表名

デフォルト値:なし

親要素:

weblogic-rdbms-jar
weblogic-rdbms-relation
weblogic-relationship-role
relationship-role-map

機能

primary-key-table要素は、主キーを格納するDBMS表名を指定します。主キーの詳細については、「主キーの使用」を参照してください。

注意:

すべてのデータベースで大文字と小文字が区別されるわけではありませんが、この要素では、大文字と小文字を区別します。

例

例については、「relationship-role-map」および「関係の主キー側のBeanの複数表へのマッピング」を参照してください。

query-method

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-bean

機能

weblogic-queryと関連付けられたメソッドを指定します。ejb-jar.xml記述子と同じ形式を使用します。

例

「weblogic-query」を参照してください。

relation-name

値の範囲:関連するejb-jar.xmlデプロイメント記述子ファイルで定義したejb-relationのejb-relation-nameに一致する必要があります。ejb-relation-nameは省略可能ですが、関連するejb-jar.xmlデプロイメント記述子ファイルで定義したejb-relationごとに必要になります。

デフォルト値:なし

親要素:

weblogic-rdbms-relation

機能

relation-name要素は関係の名前を指定します。

コンテナ管理による関係の詳細については、「コンテナ管理による関係(CMR)の使用」を参照してください。

例

relationship-name要素の例は次のとおりです。

<weblogic-rdbms-jar>
<weblogic-rdbms-relation>
<relation-name>stocks-holders</relation-name>
<table-name>stocks</table-name>
</weblogic-rdbms-relation>
</weblogic-rdbms-jar>

relationship-caching

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean

機能

relationship-caching 要素では、リレーションシップ・キャッシングを指定します。リレーションシップ・キャッシングについては、「リレーションシップ・キャッシング」を参照してください。

例

relationship-caching要素には、以下の要素を指定できます。

<relationship-caching>
<caching-name>cacheMoreBeans</caching-name>
<caching-element>
<cmr-field>accounts<</cmr-field>
<group-name>acct_group</group-name>
<caching-element>
<cmr-field>address</cmr-field>
<group-name>addr_group</group-name>
</caching-element>
</caching-element>
<caching-element>
<cmr-field>phone</cmr-field>
<group-name>phone_group</group-name>
</caching-element>
</relationship-caching>

relationship-role-map

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-relation
weblogic-relationship-role

機能

relationship-role-map要素は、ある関係に加わっているBeanのキー列マッピングに対する外部キー列を指定します。

関係の中で呼び出されるCMP Beanは、複数のDBMS表にマップできます(詳細については、table-map要素を参照)。1対1または1対多の関係の外部キー側のBeanが複数の表にマップされている場合は、外部キー列が含まれる表の名前をforeign-key-table要素で指定する必要があります。

逆に、1対1または1対多の関係の主キー側のBeanまたは多対多の関係に参加しているBeanが複数の表にマップされている場合は、主キーが含まれる表の名前をprimary-key-table要素で指定する必要があります。

関係のどちら側のBeanも複数の表にマップされていない場合、foreign-key-table要素とprimary-key-table要素は省略可能です(使用される表が暗黙的であるため)。

コンテナ管理による関係の詳細については、「コンテナ管理による関係(CMR)の使用」を参照してください。

例

関係の外部キー側のBeanの複数表へのマッピング

1対1の関係の外部キー側のBean (Fk_Bean)は、複数の表にマップされます。外部キー列を持つ表は、foreign-key-table要素で指定する必要があります。

Fk_Beanは、2つの表Fk_BeanTable_1とFk_BeanTable_2にマップされます。関係の外部キー列は、表Fk_BeanTable_2にあります。外部キー列の名前は、Fk_column_1とFk_column_2です。主キー側のBean (Pk_Bean)は、主キー列Pk_table_pkColumn_1とPk_table_pkColumn_2を持つ1つの表にマップされています。

<relationship-role-map
<foreign-key-table>Fk_BeanTable_2</foreign-key-table>
<column-map>
<foreign-key-column>Fk_column_1</foreign-key-column>
<key-column>Pk_table_pkColumn_1</key-column>
</column-map>
<column-map>
<foreign-key-column>Fk_column_2</foreign-key-column>
<key-column>Pk_table_pkColumn_2</key-column>
</column-map>
</relationship-role-map>

外部キー列のある表をコンテナが確認できるように、foreign-key-table要素は必ず指定します。

関係の主キー側のBeanの複数表へのマッピング

1対1の関係の主キー側のBean (Pk_bean)は複数の表にマップされますが、その関係の外部キー側のBean (Fk_Bean)は1つの表Fk_BeanTableにマップされます。外部キー列の名前は、Fk_column_1とFk_column_2です。

Pk_beanは、以下の表にマップされます。

- Pk_BeanTable_1。主キー列は、Pk_table1_pkColumn_1とPk_table1_pkColumn_2。

- Pk_BeanTable_2。主キー列は、Pk_table2_pkColumn_1とPk_table2_pkColumn_2。

<relationship-role-map>
<primary-key-table>Pk_BeanTable_1</primary-key-table>
<column-map>
<foreign-key-column>Fk_column_1</foreign-key-column>
<key-column>Pk_table1_pkColumn_1</key-column>
</column-map>
<column-map>
<foreign-key-column>Fk_column_2</foreign-key-column>
<key-column>Pk_table1_pkColumn_2</key-column>
</column-map>
</relationship-role-map>

relationship-role-name

値の範囲:関連するejb-jar.xmlで定義したejb-relationship-roleのejb-relationship-role-nameに一致する必要があります。

デフォルト値:なし

親要素:

weblogic-rdbms-relation
weblogic-relationship-role

機能

relationship-role-name要素は関係のロール名を指定します。

コンテナ管理による関係の詳細については、「コンテナ管理による関係(CMR)の使用」を参照してください。

例

「weblogic-relationship-role」の例を参照してください。

serialize-byte-array-to-oracle-blob

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-rdbms-jar
compatibility

機能

WebLogic Server 8.1 SP02で導入されたこの要素は、互換性フラグです。この要素では、Oracleデータベース内のBlobにマップされたbyte[]型のcmp-fieldをシリアライズするかどうかを指定します。デフォルトでは、このフラグの値はfalseです。つまり、コンテナはbyte[]を直接保持し、シリアライズしません。

WebLogic Server 8.1 SP02より前のバージョンでは、デフォルトによって、Oracleデータベース内のBlobにマップされたbyte[]型のcmp-fieldはシリアライズされました。旧式の動作に戻るには、erialize-byte-array-to-oracle-blobの値をtrueに設定します。

例

<compatibility>
<serialize-byte-array-to-oracle-blob>true</serialize-byte-array-to-oracle-blob>
</compatibility>

serialize-char-array-to-bytes

値の範囲:True | False

デフォルト値: False

親要素:

weblogic-rdbms-jar
compatibility

機能

この要素は、WebLogic Server 9.0で導入された互換性フラグです。この要素では、char[]型のcmp-fieldをシリアライズするかどうかを指定します。デフォルトでは、このフラグの値はFalseです。つまり、EJBコンテナはchar[]を直接保持し、シリアライズしません。char[]をシリアライズするには、この値をTrueに設定します。

例

<compatibility>
<serialize-char-array-to-bytes>true</serialize-char-array-to-bytes>
</compatibility>

sql

値の範囲:有効なSQL

デフォルト値:なし

要件: データベース固有のSQLを使用するには、その対象となるデータベースをdatabase-type要素で指定する必要がある

親要素:

weblogic-rdbms-bean
weblogic-query
sql-query

および

weblogic-rdbms-bean
weblogic-query
sql-query
database-specific-query

機能

sql要素には、標準またはデータベース固有のSQL問合せを指定します。EJB-QL言語の標準機能だけを使用する問合せは、ejb-jar.xmlデプロイメント記述子に指定しなければなりません。標準SQL、データベース固有のSQL、またはEJB-QLのWebLogic拡張を使用する問合せは、weblogic-cmp-jar.xmlデプロイメント記述子に指定します。

例

...
<weblogic-rdbms-bean>
<weblogic-query>
<sql-query>
<sql>SELECT date_prescribed, dosage, drug, id, frequency,
instructions, pat_id, issuing_phys_id, record_id,
refills_remaining FROM medrecappPrescription
WHERE testid = ?1</sql>
</sql-query>
</weblogic-query>
...
</weblogic-rdbms-bean>

sql-query

値の範囲:

デフォルト値:なし

要件:データベース固有のSQLを使用するには、その対象となるデータベースをdatabase-typeで指定する必要がある

親要素:

weblogic-rdbms-bean
weblogic-query

機能

sql-query要素では、標準およびデータベース固有のSQL問合せを指定できます。EJB-QLのWebLogicの拡張機能を使用しないEJB-QL問合せは、ejb-jar.xmlデプロイメント記述子に指定する必要があります。

WebLogic Server 9.0より前のリリースではEJB-QL問合せ(WebLogic拡張あり、なし)だけがサポートされていましたが、このリリースではSQL問合せ、EJB-QL問合せ(WebLogic拡張あり、なし)、またはこの2つの組み合わせがサポートされています。

例

<sql-query>
<sql-shape-name>...</sql-shape-name>
<sql>...</sql>
<database-specific-sql>...</database-specific-sql>
<database-type>...</database-type>
<sql>...</sql>
<unknown-primary-key-field>...</unknown-primary-key-field>
<cmp-field>...</cmp-field>
</sql-query>

sql-select-distinct

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-query

注意:

このリリースのWebLogic Serverでは、この要素は非推奨です。同じ機能を得るには、ファインダ問合せでSELECT DISTINCT句を直接使用してください。

機能

sql-select-distinct要素は、生成されるSQL SELECT文にDISTINCT修飾子が含まれるかどうかを指定します。DISTINCT修飾子を使用すると、データベースからユニークな行が返されます。

Oracleデータベースでは、FOR UPDATE句をSELECT DISTINCTと一緒に使用することはできません。したがって、呼出しチェーンのBeanにisolation-levelがTransactionReadCommittedForUpdateのメソッドがある場合は、sql-select-distinct要素を使用できません。transaction-isolation要素はweblogic-ejb-jar.xmlで指定します。

例

この要素を含むXMLの例を示します。

<sql-select-distinct>True</sql-select-distinct>

sql-shape

値の範囲:

デフォルト値:

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean
sql-query

機能

sql-shape要素では、SQL問合せによって返されるデータを指定します。この情報は常にデータベース側で提供されるわけではないので、sql-shapeの指定が必要になります。通常、sql-shape要素では返されるデータベースの表と列を指定します。より複雑な問合せの場合、sql-shapeでは、データベースによって返されるデータに存在する関係と、渡される必要がある(マップされてはならない)集合列が存在するかどうかも指定します。

例

sql-shape
description
sql-shape-name
table
pass-through-columns
ejb-relation-name

sql-shape-name

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar
weblogic-rdbms-bean
weblogic-query
sql-query
sql-shape

機能

sql-shape-name要素を使用すると、sql-shapeを複数の問合せに関連付けることができます。同じsql-shapeを使用する問合せが複数存在する場合、その形式をいったん定義すれば、sql-shape-nameを参照することによって何度でも使用できます。

例

「sql-shape」を参照してください。

table-map

値の範囲:なし

デフォルト値:なし

要件:各table-map要素に、そのBeanの主キー・フィールドのマッピングが含まれる必要があります。

親要素:

weblogic-rdbms-bean

機能

CMP Beanは、1つまたは複数のDBMS表にマップできます。table-map要素は、Beanのcmp-fieldと、表にマップされたすべてのcmp-fieldの表列の間のマッピングを指定します。CMP Beanを複数のDBMS表にマップする場合は、表ごとにtable-map要素を指定する必要があります。

1つのCMP Beanを複数の表にマップする場合、各表には、1つの特定のBeanインスタンスにマップする1行が含まれます。そのため、すべての表にはどの時点でも同数の行が含まれます。また、各表には均一の主キーの値の並びが含まれます。したがって、各表には均一の主キー列が含まれ、別々の表の対応している主キー列どうしは名前は違うとしても同じタイプでなければなりません。

table-map要素は、特定表の主キー列から、Beanの主キー列フィールドへのマッピングを指定しなければなりません。主キー以外のフィールドは1つの表にマップできるのみです。

verify-rows、verify-columns、およびoptimistic-column要素の使い方については、「オプティミスティック同時実行性でのデータ有効性のチェック」を参照してください。

例

table-map要素には、以下の要素を指定できます。

<table-map>
<table-name>DeptTable</table-name>
<field-map>
<cmp-field>deptId1</cmp-field>
<dbms-column>t1_deptId1_column</dbms-column>
</field-map>
<field-map>
<cmp-field>deptId2</cmp-field>
<dbms-column>t1_deptId2_column</dbms-column>
</field-map>
<field-map>
<cmp-field>location</cmp-field>
<dbms-column>location_column</dbms-column>
</field-map>
<cmp-field>budget</cmp-field>
<dbms-column>budget</dbms-column>
</field-map>
<verify-rows>Read</verify-rows>
<verify-columns>Version</verify-columns>
<optimistic-column>ROW_VERSION</optimistic-column>
<trigger-updates-optimistic-column>False
</trigger-updates-optimistic-column>
<version-column-initial-value>0</version-column-initial-value>
</table-map>

table-name

値の範囲:データベース内にあるソース表の有効な完全修飾SQL名

デフォルト値:

要件: table-nameを必ず設定する必要があります。

親要素:

weblogic-rdbms-bean
weblogic-rdbms-relation

機能

表の完全修飾SQL名です。このBeanのdata-source用に定義したユーザーには、指定した表の読取りおよび書込み権限が必要ですが、スキーマ変更権限は必要ありません。

例

<weblogic-rdbms-jar>
<weblogic-rdbms-bean>
<ejb-name>containerManaged</ejb-name>
<data-source-jndi-name>examples-dataSource-demoPool</data-source-jndi-name>
<table-name>ejbAccounts</table-name>
</weblogic-rdbms-bean>
</weblogic-rdbms-jar>

trigger-updates-optimistic-column

値の範囲:True | False

デフォルト値: False

親要素:

weblogic-rdbms-bean
table-map

機能

WebLogic Server 9.0で導入されたtrigger-updates-optimistic-column要素は、同時実行性のチェックに使用されるoptimistic-columnで指定されたデータベース列値をEJBコンテナが自動更新するかどうかを指定します。trigger-updates-optimistic-columnのデフォルト値はFalseで、EJBコンテナはJDBCにSQL UPDATE文を送信するときにoptimistic-columnで指定されたデータベース列を自動更新します。データベース行の更新時にデータベース・トリガーを使用してバージョン値を更新する従来のアプリケーションが存在し、EJBコンテナによってバージョン値が自動更新されないようにする場合、この要素の値をTrueに設定します。

注意:

trigger-updates-optimistic-columnをTrueに設定した場合、Beanの作成時にデータベース・トリガーによってデータベース内のバージョン列が初期化されるようにしておく必要があります。

例

「table-map」を参照してください。

unknown-primary-key-field

値の範囲:有効なデータ型

デフォルト値:なし

親要素:

weblogic-rdbms-bean

機能

unknown-primary-key-field要素では、主キーがejb-jar.xml記述子で指定されていない場合に主キーとして使用されるcmpフィールドを指定できます。指定した主キー・フィールドは、field-map要素でデータベース列にマップしなければなりません。指定した主キー・フィールドがejb-jar.xml記述子でcmpフィールドとして宣言されなかった場合、自動キー生成を有効にしなければならず、主キー・タイプはjava.lang.Longになります。

例

「weblogic-rdbms-bean」を参照してください。

use-select-for-update

値の範囲: True | False

デフォルト値: False

親要素:

weblogic-rdbms-bean

機能

Bean単位でペシミスティック同時実行性を強制します。Trueを指定すると、Beanがデータベースからロードされるときは常にSELECT ... FOR UPDATEが使用されます。TransactionReadCommittedForUpdateのトランザクション・アイソレーション・レベルとの相違点は、これがトランザクション・レベルではなく、Beanレベルで設定されるということです。

注意:

Sybase JConnectドライバでペシミスティックなロック方式(HOLDLOCKなど)を使用している場合、問合せにFOR UPDATE句が含まれている場合にカーソルが生成されるように、SELECT_OPENS_CURSOR=trueを指定する必要があります。

例

<weblogic-rdbms.jar>
<weblogic-rdbms-bean>
<ejb-name>containerManaged</ejb-name>
<use-select-for-update>True</use-select-for-update>
/weblogic-rdbms-bean>
</weblogic-rdbms-jar>

validate-db-schema-with

値の範囲: MetaData | TableQuery

デフォルト値: TableQuery

親要素:

weblogic-rdbms-jar

機能

validate-db-schema-with要素を指定すると、デプロイメント時にBeanが有効なデータベース・スキーマにマップされているかどうかをコンテナ管理による永続性でチェックします。

MetaDataを指定すると、WebLogic Serverは、JDBCメタデータを使用してスキーマを検証します。

TableQuery (デフォルト設定)を指定すると、WebLogic Serverは、表を直接問合せし、CMP実行時によって予期されているスキーマが表にあるかどうかを確認します。

例

validate-db-schema-with要素の例は次のとおりです。

<validate-db-schema-with>TableQuery</validate-db-schema-with>

verify-columns

値の範囲: Read | Modified | Version | Timestamp

デフォルト値: なし

要件: table-nameを必ず設定する必要があります。

親要素:

weblogic-rdbms-bean
table-map

機能

verify-columns 要素は、Optimistic同時実行性ストラテジを使用したときに、WebLogic Serverに有効性をチェックさせたい表列を指定します。WebLogic Serverは、トランザクションの終了時、データベースにコミットする前に列をチェックし、他のどのトランザクションもそのデータを変更していないことを確かめます。

詳細については、「同時実行性ストラテジの選択」を参照してください。

例

<verify-columns>Modified</verify-columns>

verify-rows

値の範囲: Read | Modified

デフォルト値: Modified

要件: table-nameを必ず設定する必要があります。

親要素:

weblogic-rdbms-bean
table-map

機能

verify-rows要素は、オプティミスティック同時実行性の使用時にEJBコンテナがチェックすべきである、表内の行を指定します。

- Modified - トランザクションで更新または削除された行のみがチェックされます。この値にすると、2つのトランザクションが同時に同じ行を更新することがなく、更新が損失することはありませんが、異なるトランザクションで読込みと更新を交互に行うことは可能です。その結果、得られる一貫性のレベルは、ANSIのREAD_COMMITTEDレベルとREPEATABLE_READレベルの間になります。

- Read - トランザクションが読み取るすべての行がチェックされるべきであることを指定します。これには、単に読み込まれるだけの行と、読み込まれた後でトランザクションによって更新または削除される行の両方が含まれます。Readオプションを指定すると、一般に、EJBコンテナが実行しなくてはならないオプティミスティック・チェックの回数が増えるため、付加的なオーバーヘッドが生じます。Readオプションを指定すると、コミットされたトランザクションは、トランザクションのコミット後まで別のトランザクションによって修正されないことが確認されている一連の行を読み込みます。この結果、SERIALIZABLEの一貫性のANSI定義と非常に近い、高度な一貫性が得られます。

注意:

verify-rowsがReadに設定されていると、verify-columns要素ではModifiedの値を指定できません。この組み合わせでは、修正された行だけがEJBコンテナによってチェックされることになるためです。

詳細については、「同時実行性ストラテジの選択」を参照してください。

例

<verify-rows>Modified</verify-rows>

version-column-initial-value

値の範囲: 0または任意の正の整数

デフォルト値:なし

親要素:

weblogic-rdbms-bean
table-map

機能

WebLogic Server 9.0で導入されたversion-column-initial-value要素では、オプティミスティック同時実行性を実装するために使用されるバージョン列の初期値を指定します。バージョン列は、optimistic-column要素で指定するデータベース列です。詳細については、「optimistic-column」を参照してください。

例

「table-map」を参照してください。

weblogic-ql

値の範囲:

デフォルト値:

親要素:

weblogic-rdbms-bean
weblogic-query

機能

weblogic-ql要素は、EJB-QLに対するWebLogic固有の拡張機能を含む問合せを指定します。ejb-jar.xmlデプロイメント記述子では、EJB-QL言語の標準機能だけを使用する問合せを指定しなければなりません。

例

「weblogic-query」を参照してください。

weblogic-query

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-bean

機能

weblogic-query要素では、標準またはデータベース固有のSQL問合せ、またはEJB-QLのWebLogic固有の拡張機能を使用する問合せを指定できます。SQLまたはEJB-QLのWebLogic拡張機能を使用しない問合せは、ejb-jar.xmlデプロイメント記述子で指定する必要があります。

問合せによってあらかじめキャッシュにロードしておく必要があるエンティティBeanを問合せで取得する場合は、weblogic-query要素を使用して、field-groupを問合せに関連付けます。

例

weblogic-query要素には、以下の要素を指定できます。

<weblogic-query>
<description>...</description>
<query-method>
<method-name>findBigAccounts</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
</query-method>
<ejb-ql-query>
<weblogic-ql>WHERE BALANCE>10000 ORDER BY NAME
</weblogic-ql>
<group-name>...</group-name>
<caching-name>...</caching-name>
</ejb-ql-query>
<sql-query>
<sql-shape>...</sql-shape>
<sql>SELECT date_prescribed, dosage, drug, id, frequency, instructions,
pat_id, issuing_phys_id, record_id, refills_remaining FROM
medrecappPrescription WHERE testid = ?1</sql>
<database-specific-sql>
<database-type>SQLServer</database-type>
<sql>SELECT name, phone, location, testid FROM medrecappPharmacyBeanTable
WHERE testid = ?1 AND
SUBSTRING(testid, 1,5) = 'local' ORDER BY name</sql>
</database-specific-sql>
</sql-query>
<max-elements>...</max-elements>
<include-updates>...</include-updates>
<sql-select-distinct>...</sql-select-distinct>
</weblogic-query>

weblogic-rdbms-bean

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar

機能

weblogic-rdbms-beanは、WebLogic RDBMS CMP永続性タイプによって管理されるエンティティBeanを指定します。

例

weblogic-rdbms-bean
ejb-name
data-source-jndi-name
unkonown-primary-key-field
table-map
field-group
relationship-caching
weblogic-query
dalay-database-insert-until
automatic-key-generation
check-exists-on-method

weblogic-rdbms-jar

ここでは、weblogic-rdbms-jar要素について説明し、その例を示します。

機能

weblogic-rdbms-jar 要素は、WebLogic RDBMS CMPデプロイメント記述子の最上位の要素です。この要素には、1つまたは複数のエンティティBeanと、一連の関係(これについては省略可能)についてのデプロイメント情報が含まれます。

例

weblogic-rdbms-jarのXML構造を示します。

weblogic-rdbms-jar
weblogic-rdbms-bean
weblogic-rdbms-relation
create-default-dbms-tables
validate-db-schema-with
database-type

weblogic-rdbms-relation

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar

機能

weblogic-rdbms-relation要素は、WebLogic CMP永続性タイプによって管理されている1つの関係を表します。WebLogic Serverでは、以下の3種類の関係のマッピングをサポートしています。

- 1対1の関係では、一方のBeanの外部キーがもう一方のBeanの主キーにマップされます。

- 1対多の関係では、あるBeanの外部キーが別のBeanの主キーにマップされます。

- 多対多の関係には、結合表のマッピングが伴います。結合表の各行には、関係に関与するエンティティの主キーに対応する2つの外部キーが格納されます。

コンテナ管理による関係の詳細については、「コンテナ管理による関係(CMR)の使用」を参照してください。

例

1対1、1対多、および多対多の関係の構成方法の例については、以降の節を参照してください。

1対1の関係の定義

例C-4と例C-5に定義されているエンティティ間の1対1の関係を定義するweblogic-rdbms-bean要素を例C-6に示します。weblogic-rdbms-relation 要素は、weblogic-cmp-jar.xmlファイルのweblogic-rdbms-bean要素の後に存在します。

例C-4 Bean 1

<weblogic-rdbms-bean>
<ejb-name>CountryEJB</ejb-name>
<data-source-jndi-name>wlsd21-datasource</data-source-jndi-name>
<table-map>
<table-name>EXAMPLE07_COUNTRY</table-name>
<field-map>
<cmp-field>name</cmp-field>
<dbms-column>NAME</dbms-column>
</field-map>
<field-map>
<cmp-field>continent</cmp-field>
<dbms-column>CONTINENT</dbms-column>
</field-map>
</table-map>
</weblogic-rdbms-bean>

例C-5 Bean 2

<weblogic-rdbms-bean>
<ejb-name>CapitalEJB</ejb-name>
<data-source-jndi-name>wlsd21-datasource</data-source-jndi-name>
<table-map>
<table-name>EXAMPLE07_CAPITAL</table-name>
<field-map>
<cmp-field>CAPITAL_NAME</cmp-field>
<dbms-column>NAME</dbms-column>
</field-map>
<field-map>
<cmp-field>continent</cmp-field>
<dbms-column>CONTINENT</dbms-column>
</field-map>
</table-map>
</weblogic-rdbms-bean>

例C-6 1対1の関係の<weblogic-rdbms-relation>要素

<weblogic-rdbms-relation>
<relation-name>CountryCapitalRel</relation-name>
<weblogic-relationship-role>
<relationship-role-name>CountryRole</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>CAPITAL_NAME</foreign-key-column>
<key-column>NAME</key-column>
</column-map>
</relationship-role-map>
</weblogic-relationship-role>
</weblogic-rdbms-relation>

注意:

NAMEは、Capital表の主キーの列名です。

<relationship-role-name>には、ejb-jar.xmlの<ejb-relationship-role>要素の<cmr-field>で指定された関連フィールドが入ります。

1対多の関係の定義

例C-7は、1対多の関係を定義するサンプルの<weblogic-rdbms-relation>要素を示しています。

例C-7 1対多の関係の<weblogic-rdbms-relation>要素

<weblogic-rdbms-relation>
<relation-name>OwnerDogRel</relation-name>
<weblogic-relationship-role>
<relationship-role-name>DogRole</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>OWNER_NAME</foreign-<key-column>
<key-column>NAME</key-column>
</column-map>
<relationship-role-map>
</weblogic-relationship-role>
</weblogic-rdbms-relation>

注意:

<relationship-role-name>には、ejb-jar.xmlの<ejb-relationship-role>要素の<cmr-field>で指定された関連フィールドが入ります。

<foreign-key-column>は、関係の「多」側の表の列を指定する必要があります。

多対多の関係の定義

WebLogic Serverの多対多の関係には、結合表の物理的なマッピングが伴います。結合表の各行には、関係に関与するエンティティの主キーに対応する2つの外部キーが格納されます。

次の例は、FRIENDS BeanとEMPLOYEES Beanの間の多対多の関係を示しています。

例C-8 多対多の関係の<weblogic-rdbms-relation>要素

<weblogic-rdbms-relation>
<relation-name>friends</relation-name>
<table-name>FRIENDS</table-name>
<weblogic-relationship-role>
<relationship-role-name>friend</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>first-friend-id</foreign-key-column>
<key-column>id</key-column>
</column-map
</relationship-role-map>
</weblogic-relationship-role>
<weblogic-relationship-role>
<relationship-role-name>second-friend</relationship-role-name>
<relationship-role-map>
<column-map>
<foreign-key-column>second-friend-id</foreign-key-column>
<key-column>id</key-column>
</column-map>
</relationship-role-map>
</weblogic-relationship-role>
</weblogic-rdbms-relation>

図C-0のFRIENDS結合表には、first-friend-idとsecond-friend-idという2つの列があります。各列には、別の従業員の友人である特定の従業員を示す外部キーが格納されます。EMPLOYEES表の主キー列(key-column)はidです。この例では、EMPLOYEES Beanが1つの表にマップされています。EMPLOYEES Beanが複数の表にマップされている場合、主キー列(key-column)を格納する表をrelationship-role-mapで指定する必要があります。詳細については、「relationship-role-map」を参照してください。

weblogic-relationship-role

値の範囲:なし

デフォルト値:なし

親要素:

weblogic-rdbms-jar
weblogic-rdbms-relation

機能

weblogic-relationship-role要素は、ejb-jar.xmlで指定されたejb-relationship-roleの以下のDBMSスキーマ情報を指定します。

- relationship-role-mapサブ要素は、関係の片側の外部キーと主キーのマッピングを指定します。1対1または1対多の関係の場合、関係の外部キー側のロールのみがマッピングを指定します。多対多の関係では、両方のロールがマッピングを指定します。詳細と例については、「relationship-role-map」を参照してください。

- group-nameを使用すると、ロールに対応するBeanが関係を移動した(つまりcmr getXXXメソッドを呼び出した)結果としてロードされたときにロードされるfield-groupを示すことができます。

- db-cascade-deleteタグを使用すると、カスケード削除が、基底DBMSの組込みカスケード削除機能を使用するように指定できます。詳細については、「db-cascade-delete」を参照してください。

コンテナ管理による関係の詳細については、「コンテナ管理による関係(CMR)の使用」を参照してください。

例

<weblogic-relationship-role>
<relationship-role-name>...</relationship-role-name>
<group-name> ....</group-name>
<relationship-role-map>...
....
</relationship-role-map>
<db-cascade-delete/>
</weblogic-relationship-role>

D appcリファレンス

ここでは、EJBコードのコンパイル、検証、生成に使用するWebLogic Server appcツールの詳細なリファレンスを提供します。

- appc

appc

appcコンパイラは、EJBおよびJSPをWebLogic Serverにデプロイするのに必要なクラスを生成し、コンパイルします。また、個別のモジュール・レベルとアプリケーション・レベルの両方で、現在の仕様に準拠しているかどうかデプロイメント記述子を検証します。アプリケーション・レベルのチェックでは、個別のモジュールに対するアプリケーション・レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。

Kodo永続性ユニットを含むアプリケーションをコンパイルしている場合、appcコンパイラはKodoエンハンサも実行します。Kodoエンハンサは、Javaコンパイラが生成したバイト・コードを後処理して、必要な永続機能の実装に必要なフィールドとメソッドを追加します。このバイト・コードの変更では、スタック・トレースの行番号は完全に維持され、Javaデバッガとの互換性を維持します。Kodoの使用については、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のWebLogic ServerでのOracle Kodoの使用に関する項を参照してください。

注意:

Kodoの管理による永続性ユニットとKodo以外の管理による永続性ユニットの両方を含むアプリケーションに対してappcを実行する場合、kodcはKodoの管理による永続性ユニットだけを実行します。

appcの利点

appcツールの利点は以下のとおりです。

- 個々のモジュールを別々にコンパイルして、事後にEARとして結合するのではなく、アプリケーション全体をコンパイルできる柔軟性。

- EARコンパイル中にWebLogic Serverがすべてのモジュールにアクセスできることによる、すべてのモジュールにわたる検証チェック、およびさまざまなモジュールに対するアプリケーション・レベルのデプロイメント記述子検証。
appcがなかったときは、EARファイル内のすべてのモジュールをコンパイルする場合、ユーザーはEARの個々のコンポーネントを抽出し、適切なコンパイラ(jspcまたはejbc)を手動で実行して、デプロイメント用モジュールを準備しなければなりませんでした。appcはこのプロセスを自動化し、従来はできなかった追加の検証チェックをデプロイメント前に実行します。

- appcのエラーを簡単に特定して修正できます。
コマンド・ラインでappcを実行中にエラーが発生すると、エラー・メッセージが表示され、appcが終了します。

それに対して、コンパイルをデプロイメント時に行うことにした場合、コンパイル・エラーが発生すると、サーバーはデプロイメントが失敗しても作業を続けます。デプロイメントの失敗の原因を特定するには、サーバー出力を調べ、問題を修正し、再デプロイする必要があります。

- デプロイメントの前にappcを実行すると、Beanのコンパイル時間を短縮できます。
たとえば、JARファイルを3つのサーバーのクラスタにデプロイする場合、JARファイルが各サーバーにコピーされてデプロイされます。JARファイルがコンパイルされていない場合、各サーバーは、デプロイメント時にファイルをコンパイルする必要があります。

appcの構文

appcの実行には、次の構文を使用します。

prompt>java weblogic.appc [options] <ear, jar, or war file or directory>

代替デプロイメント記述子の指定

Java EEでは、application.xmlの<module>要素の<alt-dd>要素を使用して、EJBまたはWebアプリケーション・モジュールの代替Java EEデプロイメント記述子を指定できます。

<alt-dd>を使用することで、Java EEデプロイメント記述子web.xmlおよびejb-jar.xmlについてのみ代替デプロイメント記述子を指定できます。WebLogic Server 8.1 SP01からは、alt-ddでモジュールの代替デプロイメント記述子を指定すると、appcはその代替記述子ファイルを使用してEJBをコンパイルします。

<alt-dd要素の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

WebLogic Server 8.1 SP01以降では、次のようにappcのコマンドライン・オプションを使用して、アプリケーションの代替Java EEおよびWebLogic Serverデプロイメント記述子を指定できます。

- -altappdd <file> - このオプションを使用すると、代替Java EEデプロイメント記述子ファイル(application.xml)のフルパスとファイル名を指定できます。

- -altwlsappdd <file> - このオプションを使用すると、代替WebLogicアプリケーション・デプロイメント記述子ファイル(weblogic-application.xml)の絶対パスとファイル名を指定できます。

appcのオプション

表D-1は、appcのコマンド・ライン・オプションのリストです。

表D-1 appcのコマンド・ライン・オプション

オプション

説明

-advanced

高度な使用オプションを出力します。

-altappdd

代替Java EEアプリケーション・デプロイメント記述子を指定します。

-altwlsappdd

代替WebLogic Serverアプリケーション・デプロイメント記述子を指定します。

-basicClientJar

EJB用に生成されたクライアントJARのデプロイメント記述子を含みません。

-classpath <path>

コンパイル中に使用するクラスパスを選択します。

-clientJarOutputDir <dir>

生成されたクライアントjarファイルを配置するディレクトリを指定します。これが設定されていないと、生成されたjarファイルはJVMが実行しているディレクトリと同じ場所に配置されます。

-compiler <javac>

使用するJavaコンパイラを選択します。

-deprecation

非推奨となった呼出しについて警告します。

-forceGeneration

EJBおよびJSPクラスを強制的に生成します。このフラグがないと、チェックサムでその必要性が示されない限りクラスは再生成されません。

-g

デバッグ情報をクラス・ファイルにコンパイルします。

-help

標準の使い方メッセージを出力します。

-idl

EJBリモート・インタフェース用のIDLを生成します。

-idlDirectory <dir>

IDLファイルを作成するディレクトリを指定します(デフォルト: ターゲット・ディレクトリまたはJAR)。

-idlFactories

値タイプ用にファクトリ・メソッドを生成します。

-idlMethodSignatures <>

IDLコードを生成するトリガーとして使用されるメソッド・シグネチャを指定します。

-idlNoAbstractInterfaces

抽象インタフェース、およびそれを含むメソッドと属性を生成しません。

-idlNoValueTypes

値タイプ、およびそれを含むメソッドと属性を生成しません。

-idlOrbix

Orbix 2000 2.0 C++と多少の互換性を持つIDLを生成します。

-idlOverwrite

常に既存のIDLファイルを上書きします。

-idlVerbose

IDL生成についての詳細な情報を表示します。

-idlVisibroker

Visibroker 4.5 C++と多少の互換性を持つIDLを生成します。

-iiop

EJB用にCORBAのスタブを生成します。

-iiopDirectory <dir>

IIOPのスタブ・ファイルを記述するディレクトリを指定します(デフォルト: ターゲット・ディレクトリまたはJAR)。

-J<option>

Java実行時にフラグを渡します。

-keepgenerated

生成された.javaファイルを保持します。

-library <file>

ライブラリのカンマ区切りのリスト。各ライブラリは、マニフェストで設定されていない場合、その名前とバージョンを次の構文で設定できます。

<file>[@name=<string>@libspecver=<version>

@libimplver=<version|string>]

-librarydir <dir>

指定したディレクトリ内のすべてのファイルをライブラリとして登録します。

-lineNumbers

生成されたクラス・ファイルに行番号を追加し、デバッグを支援します。

-normi

Symantecのsjにフラグを渡します。

-nowarn

警告なしでコンパイルします。

-O

最適化を有効にしてコンパイルします。

-output <file>

代替的な出力アーカイブまたはディレクトリを指定します。これが設定されていないと、出力はソース・アーカイブまたはディレクトリに置かれます。

-plan <file>

デプロイメント・プラン(省略可能)を指定します。

-verbose

冗長情報を出力してコンパイルします。

-version

appcのバージョン情報を出力します。

appcおよびEJB

weblogic.appcは、以下のEJB関連機能を実行します。

- EJB用のWebLogic Serverコンテナ・クラスを生成します。

- すべてのEJBクラスおよびインタフェースがEJB仕様に準拠しているかどうかをチェックします。

- デプロイメント記述子に潜在的な構成上の問題がないかをチェックします。たとえば、ejb-jar.xmlでcmpフィールドが宣言されていれば、appcは、列がweblogic-cmp-jar.xmlデプロイメント記述子にマップされているかどうかを検証します。

- RMIコンパイラを使用して各EJBコンテナ・クラスを実行し、スタブとスケルトンを動的に生成するのに必要なRMI記述子を作成します。

appcは、デフォルトでjavacをコンパイラとして使用します。パフォーマンスを向上させるには、コマンドライン-compilerフラグを使用して別のコンパイラ(Symantecのsjなど)を指定します。

weblogic-ejb-jar.xmlのパブリック・バージョンの場所については、付録B「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」を参照してください。weblogic-cmp-jar.xmlのパブリック・バージョンの場所については、付録C「weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス」を参照してください。

E EJBGenリファレンス

EJBGenは、Enterprise JavaBeans 2.xのコード・ジェネレータです。Beanのクラス・ファイルにJDK 1.5のアノテーションを追加すると、EJBGenを使用してEJBアプリケーションのリモート・クラス、ホーム・クラス、およびデプロイメント記述子ファイルを生成できます。

デプロイメント記述子の生成には、EJBGenの使用をお薦めします。このOracleのベスト・プラクティスでは、EJBの維持を容易化および簡略化できます。EJBGenを使用する場合、1つのBeanクラス・ファイルを記述してアノテーションを追加するだけなので、記述、デバッグ、および管理が簡素化されます。以下の節では、EJBGenの使い方について説明し、EJBGenのコマンド・オプションとアノテーションの定義を示します。

- EJBGenの実行

- EJBGenタグの使用例

- Enum属性定数値

- EJBGenアノテーション・リファレンス

- EJBコンテナ・アノテーション

EJBGenの実行

以下の節では、EJBGenを使用してアノテーション付きBeanファイルを処理する方法を説明します。

- EJBGenの配布と例

- EJBGenの起動

- 主要なEJBGenの機能の使い方

EJBGenの配布と例

このリリースのWebLogic Serverでは、EJBGenとその関連クラスはWebLogic Server配布キットのWL_HOME/server/libのweblogic.jarに含まれています。EJBGenを使用するには、CLASSPATHでweblogic.jarを指定してください。EJBGenのアノテーションは、weblogic.ejbgenパッケージに含まれています。

Oracle WebLogic Serverのサンプルがインストールされている場合、EJBGenを使用するアプリケーションについてはWL_HOME\samples\server\examples\src\examples\ejb\ejb20およびWL_HOME\samples\server\examples\src\examples\ejb\ejb21\を参照してください。

EJBGenの起動

次のコマンドを使用すると、Beanのソース・ファイルでEJBGenを実行できます。

com.bea.wls.ejbgen.EJBGen

注意:

このコマンドを実行するには、weblogic.jarがCLASSPATHに存在しなければなりません。

他のEJBとの関係があるEJBに対してEJBGenを呼び出す場合は、次のようにEJBの後に、関係するEJBを指定してそのEJBを呼び出します。

com.bea.wls.ejbgen.EJBGen (YourBean).java (RelatedBean).java

注意:

EJBGenは、Antタスクのejbgenからも呼び出せます。これもweblogic.jarに含まれています。

EJBGenのコマンド・オプション

表E-1に、EJBGenのコマンド・オプションの定義を示します。

表E-1 EJBGenのコマンド・オプション

オプション

デフォルト値

定義

-checkTags

なし

このオプションで起動した場合、EJBGenはどのクラスも生成しませんが、コマンド・ラインで指定したクラスに対して有効でないEJBGenタグを見つけます。

-classPath [directory]

なし

クラス・ローダーが.class形式の依存クラスを検索できるディレクトリ。

複数のクラス・パスを指定するには、パスをセミコロン(;)で区切ります(-classpath /dir1;/dir2など)。

依存クラスが.java形式の場合は、かわりに-sourcePathを使用します。

-d [directory]

なし

このディレクトリの下にすべてのファイルが作成されます。

-ddOnlyGen [boolean]

0

コンパイラでデプロイメント記述子ファイルのみを生成することを指定します。

-descriptorDir [directory]

なし

-d [directory]オプションで指定された出力ディレクトリに相対的な、すべての記述子ファイルが作成されるディレクトリ。

-docTag tagName

なし

これを指定すると、EJBGenは把握されているすべての属性など、このタグの詳細な説明を出力します。注意: このオプションがどのソース・ファイルも必要としなくても、コマンド・ラインで既存の.javaクラスを指定する必要があり、そうしないと、このフラグを認識したにもかかわらずJavadocはエラー・メッセージを返します。

-docTags

なし

EJBGenによって把握された、すべてのタグを出力します。注意: このオプションがどのソース・ファイルも必要としなくても、コマンド・ラインで既存の.javaクラスを指定する必要があり、そうしないと、このフラグを認識したにもかかわらずJavadocはエラー・メッセージを返します。

-docTagsHtml

なし

-docTagsと同じですが、HTMLドキュメントを生成します。

-ejbPrefix [string]

" "

EJBクラス生成時に使用する接頭辞。

-ejbSuffix [string]

BeanまたはEJB

EJBクラス生成時に使用する接尾辞。

-ejbgenQuiet [boolean]

なし

EJBGenの冗長度を低くします。

-ejbgenVerbose [boolean]

なし

冗長モード。

-errorFile

なし

エラーがリダイレクトされるファイルのパス。

-exitOnError [boolean]

なし

EJBGenはエラーの発生時に終了する必要があります。

-homeBaseClass [string (className)]

なし

ホーム・リモート・インタフェースのベース・クラス。

-extractTemplates [directory]

なし

テンプレートを抽出するディレクトリ。

-forceGeneration [boolean]

なし

タイムスタンプに関係なくすべてのファイルの生成を強制します。

-homeBaseClass [string (className)]

なし

ホーム・リモート・インタフェースのベース・クラス。

-ignorePackage

なし

このフラグを設定すると、EJBGenは生成したJavaファイルのパッケージ名を無視し、-dフラグで指定された出力ディレクトリにファイルを作成します(-dフラグが指定されていない場合は、カレント・ディレクトリ)。

-jndiPrefix [string]

" "

@remoteJndiNameおよび@localJndiNameで使用する接頭辞。

-jndiSuffix [string]

" "

@remoteJndiNameおよび@localJndiNameで使用する接尾辞。

-localBaseClass [string (className)]

なし

ローカル・インタフェースのベース・クラス。

-localHomeBaseClass [className]

なし

ローカル・ホーム・インタフェースのベース・クラス。

-localHomePrefix [string]

" "

ローカルEJBクラス生成時に使用する接頭辞。

-localHomeSuffix [string]

LocalHome

ローカルEJBクラス生成時に使用する接尾辞。

-localPrefix [string]

" "

ローカルEJBクラス生成時に使用する接頭辞。

-localSuffix [string] (

" "

ローカルEJBクラス生成時に使用する接尾辞。

-noDDGen [boolean]

0

コンパイラでデプロイメント記述子ファイルを生成しません。

-noImports [boolean]

false

java importsの生成されたクラスへの伝播を無効にします。

-noLocalInterfaces

なし

これを指定すると、ローカル・インタフェースは生成されません。

-noRedirection noRedirection ejbgen.noRedirection [boolean]

なし

EJBGenによって実行されるすべてのリダイレクトを取り消します。

-noRemoteInterfaces [boolean]

なし

これを指定すると、リモート・インタフェースは生成されません。

-noticeFile [file]

なし

通知がリダイレクトされるファイルのパス。

-noValueClasses [boolean]

なし

これを指定すると、Valueクラスは生成されなくなります。

-primaryKeyBaseClass [string (class name)]

なし

生成された主キーのベース・クラス。

-printDiagnostic [boolean]

なし

EJBGenが見つけたすべてのタグの診断を出力します。

-printTags [boolean]

なし

EJBGenで認識されたすべてのタグを表示します。

-propertyFile [fileName]

なし

EJBGenが置換変数を定義するのに読み込む、プロパティ・ファイルの名前。「EJBGenでのプロパティ・ファイルの使用」を参照してください。

-remoteBaseClass [string (className)]

なし

リモート・インタフェースのベース・クラス。

-remoteHomePrefix [string]

" "

リモートEJBホーム・クラス生成時に使用する接頭辞。

-remoteHomeSuffix [string]

" "

リモートEJBホーム・クラス生成時に使用する接尾辞。

-remotePrefix [string]

" "

リモートEJBクラス生成時に使用する接頭辞。

-remoteSuffix [string]

" "

リモートEJBクラス生成時に使用する接尾辞。

-source [version number]

1.5

使用するJDKのバージョン。

-sourcepath [directory]

なし

クラス・ローダーが.java形式の依存クラスを検索できるディレクトリ。

複数のソース・パスを指定するには、パスをセミコロン(;)で区切ります(-sourcePath /dir1;/dir2など)。

依存クラスが.class形式の場合は、かわりに-classPathを使用します。

-templateDir [directory]

なし

テンプレートが格納されるディレクトリ。

-toStringForPrimitivesOnly

なし

これを指定すると、値オブジェクトのtoString()メソッドはプリミティブであるコンテナ管理による永続性フィールドのみを表示します。このフラグは、値オブジェクト間での循環的な参照の問題(AValue.toString()がBValue.toString()を呼び出し、それがさらにAValue.toString()を呼び出すなど)を解消します。

-valueBaseClass [string (class name)]

なし

EJBGenによって生成される値クラスのベース・クラス。

-valueObjectPrefix [string]

なし

Valueオブジェクト・クラス生成時に使用する接頭辞。

-valueObjectSuffix [string]

なし

Valueオブジェクト・クラス生成時に使用する接尾辞。

-valuePackage [string (package name)]

なし

値クラスが属するパッケージ。

-verbose [boolean]

false

より多くの情報を表示します。

-workshopDocTags [boolean]

なし

ヘルプをOracle Workshop for WebLogic PlatformのHTML形式で表示します。

-xmlEncoding [string]

なし

XMLファイルを生成するときに使用するエンコーディング(デフォルト: UTF-8)。

主要なEJBGenの機能の使い方

以下の節では、主要なEJBGenの機能とその使い方について説明します。

- EJBGenが生成するファイルの管理

- EJBGenでのプロパティ・ファイルの使用

- ユーザー変数の使い方

- スペースを含む属性は二重引用符で囲む

- 定義済み変数の使い方

- スペースを含む属性は二重引用符で囲む

- EJBGenによるタグ継承のサポート

EJBGenが生成するファイルの管理

デフォルトでは、EJBGenは次のファイルを生成します。

- リモートBeanおよびホーム・インタフェース(weblogic.ejbgen.JndiNameの「remote」が指定された場合)

- ローカルBeanおよびホーム・インタフェース(weblogic.ejbgen.JndiNameの「local」が指定された場合)

- 値オブジェクト・クラス

- 主キー・クラス(該当する場合)

これらのファイルの生成は、weblogic.ejbgen.FileGeneration タグを使用して個別に無効化できます。これは、Beanごとに実行できます。

EJBGenでのプロパティ・ファイルの使用

EJBGenは、この節で説明するように、プロパティ・ファイルから生成のための情報を収集できます。

EJBGenにプロパティ・ファイルの解析を指示するには、-propertyFileオプションを使用します。

-propertyFileオプションを指定してEJBGenを呼び出すには、次の構文を使用します。

com.bea.wls.ejbgen.EJBGen -propertyFile property-file AccountBean.java

EJBGenは、プロパティ・ファイル内にユーザー変数およびあらかじめ定義された変数という、2種類の変数を認識します。

ユーザー変数の使い方

EJBGenタグでは、文字列のかわりに変数を使用できます。これらの変数は、「${」と「}」で囲まなければなりません。

変数は、EJBGenタグの後ろであればどこでも使用できます。このため、変数にはタグ定義全体を含めることができます。

定義済変数の使い方

EJBGenは、いくつかのあらかじめ定義された変数を認識します。これらの変数はタグでは使用しないことになっていますが、EJBGenではロールに応じて様々な場所で使用します。認識されるタグは以下のとおりです。

- remote.baseClass
これを指定すると、この変数の値は生成されたすべてのリモート・クラスのベース・クラスとして使用されます。

- home.baseClass
これを指定すると、この変数の値は生成されたすべてのリモート・ホーム・クラスのベース・クラスとして使用されます。

- local.baseClass
これを指定すると、この変数の値は生成されたすべてのローカル・クラスのベース・クラスとして使用されます。

- localHome.baseClass
これを指定すると、この変数の値は生成されたすべてのローカル・ホーム・クラスのベース・クラスとして使用されます。

- value.baseClass
これを指定すると、この変数の値は生成されたすべての値クラスのベース・クラスとして使用されます。

- value.package
これを指定すると、この変数の値は生成されたすべての値クラスのパッケージとして使用されます。

- value.interfaces
これを指定すると、この変数の値は値クラスが実装すべきインタフェースとして使用されます。この変数は、カンマで区切ったインタフェースのリストにもできます。

これらの変数は、EJBNameを接頭辞とすることでより特定的にできます。たとえば、次のようなプロパティ・ファイルの場合を考えます。

#
# property-file
#
Account.home.baseClass = BaseAccountHome
home.baseClass = BaseHome
value.package = value
containerManaged.value.package=valuePackageForContainerManaged

EJBGenによって生成されたホームはすべて、クラスBaseHomeを拡張します。ただし、EJB「Account」のホームは例外で、BaseAccountHomeを拡張します。

スペースを含む属性は二重引用符で囲む

スペースの含まれる属性を指定する際には、その属性値を二重引用符で囲みます。例:

group-names = "group1, group2"

EJBGenによるタグ継承のサポート

EJBGen 2.xの主要な機能の1つに、タグの継承があります。EJBGenのアノテーションは、Javaの場合と同じように継承されます。たとえば、例E-1に示すように、ベース・クラスBaseAccountのAccountEJBというEJBがあるとします。

weblogic.ejbgen.JndiName

例E-1 タグの継承

@JndiName(remote = "BaseRemote")

public class BaseAccount implements EntityBean {
// ...
}
Now, define your EJB class:
@Entity(ejbName = containerManaged,
tableName = ejbAccounts,
datasourceJndiName = examples-dataSource-demoPool)

//Note that we inherit the JNDI name defined in BaseAccount

public class AccountEJB extends BaseAccount {
// ...

EJBGenタグの使用例

以下の節では、EJBGenタグでアノテーションが付けられたソース・コードのサンプルを示します。

- EJBGenによる複数表へのエンティティBeanのマッピング

- EJBGenタグによるリレーションシップ・キャッシングの指定

- EJBGenタグによる関係の指定

EJBGenによる複数表へのエンティティBeanのマッピング

デフォルトでは、エンティティBeanは、タグ@Entityに属性tableNameを指定することによって1つの表にマップされます。エンティティBeanを複数の表にマップする場合、CMPフィールドが各表の対応する主キー列にマップされている主キー・フィールドであれば、個々の@CmpFieldでtable-name属性を使用できます。tableName属性のないコンテナ管理による永続性フィールドは、@Entityで指定した表を使用します(したがって、これを「デフォルト」表と考えることができます)。

エンティティBeanを複数の表にマップする場合、tableName属性において(および列上で)カンマ区切りの表リストを指定する必要があります。表の数と列数が一致しており、列が対応する表内に存在することを確認してください。

EJBGenタグによるリレーションシップ・キャッシングの指定

@RelationshipCachingタグを使用すると、リレーションシップ・キャッシング要素を指定できます。この要素はネストできます(再帰的)。つまり、キャッシュするリレーションシップ要素をすべて表すツリーを指定できます。

このツリー構造をサポートするため、@RelationshipCachingにはidとparentIdという2つの属性があります。これらの属性はどのXMLにも対応しません。単に、これらを使うとツリー構造が指定できるというだけです。

たとえば、キャッシング要素Aに子要素BおよびCが必要な場合、Aのためのid(たとえば「root0」)と、その名前に等しいBおよびCのparentIdを指定するのみで済みます。

例E-2に、リレーションシップ・キャッシングの指定を示します。

例E-2 リレーションシップ・キャッシングの指定

@RelationshipCachingElements(
@RelationshipCachingElement(cachingName = cacheMoreBeans,
cmrField = employee,
groupName = emp-group,
id = A),

@RelationshipCachingElement(cachingName = cacheMoreBeans,
cmrField = employee_ssn,
groupName = emp-group,
parentId = A),

@RelationshipCachingElement(cachingName = cacheMoreBeans,
cmrField = employee_zip,
groupName = emp-group,
parentId = A)
)

EJBGenタグによる関係の指定

一方向の関係は、関係タグの最初の2つのパラメータのみ(CMR_fieldやjoin tableはなし)を指定することで実現します。

注意:

「join table」は9.0より前のリリースのWebLogic Serverでは「joint table」と呼ばれていました。

多対多の関係では、少なくとも2つの列を含む、追加の表(パラメータ「join table」)を指定する必要があります。これらの列の名前は、結合される2つのBeanの外部キーを含む列の名前に一致している必要があります。

ローカル・インタフェースを使用するように関係を更新する

PFD2より前に公開されたEJB 2.0仕様のバージョンに基づくEJBを使用している場合は、更新が必要です。PFD2では、関係はリモート・インタフェースではなく、ローカル・インタフェースに基づいている必要があります。EJBのアップグレードを行う手順は次のとおりです。

1. ローカル・ホーム・インタフェースのJNDI名を追加します。

@JndiName
remote = AccountHome
local = AccountLocalHome

2. ローカル・ホーム・インタフェース上に置くすべてのメソッドに@LocalMethodタグを追加します。1つのメソッドに@LocalMethodと@RemoteMethodの両方が存在してもかまいません。

3. コンテナ管理の関係(CMR)アクセス・メソッドの戻り値の型を、ローカルEJBオブジェクトの戻り値の型に変更します(複数の値を持つCMRフィールドは集合なので、これは単一の値を持つCMRフィールドのみに適用されます。これらの集合にローカルEJBオブジェクトが含まれることに留意してください)。

@CmrField

@RemoteMethod
@LocalMethod

abstract public LocalCustomer getCustomer();

Enum属性定数値

多くのEJBGen属性では、以下のEnum値が使用されます。

Constants.Bool

Constant.Boolの有効な値は以下のとおりです。

- Constants.Bool.UNSPECIFIED

- Constants.Bool.TRUE

- Constants.Bool.FALSE

Constants.TransactionAttribute

Constants.TransactionAttributeの有効な値は以下のとおりです。

- Constants.TransactionAttribute.UNSPECIFIED

- Constants.TransactionAttribute.NOT_SUPPORTED

- Constants.TransactionAttribute.SUPPORTS

- Constants.TransactionAttribute.REQUIRED

- Constants.TransactionAttribute.REQUIRES_NEW

- Constants.TransactionAttribute.MANDATORY

- Constants.TransactionAttribute.NEVER

Constants.IsolationLevel

Constants.IsolationLevelの有効な値は次のとおりです。

- Constants.IsolationLevel.UNSPECIFIED

- Constants.IsolationLevel.TRANSACTION_SERIALIZABLE

- Constants.IsolationLevel.TRANSACTION_READ_COMMITTED

- Constants.IsolationLevel.TRANSACTION_READ_UNCOMMITTED

- Constants.IsolationLevel.TRANSACTION_REPEATABLE_READ

- Constants.IsolationLevel.TRANSACTION_READ_COMMITTED_FOR_UPDATE

Constants.RefType

Constant.RefTypeの有効な値は以下のとおりです。

- Constants.RefType.UNSPECIFIED

- Constants.RefType.ENTITY

- Constants.RefType.SESSION

Constants.HomeLoadAlgorithm

Constants.HomeLoadAlgorithmの有効な値は次のとおりです。

- Constants.HomeLoadAlgorithm.UNSPECIFIED

- Constants.HomeLoadAlgorithm.ROUND_ROBIN

- Constants.HomeLoadAlgorithm.RANDOM

- Constants.HomeLoadAlgorithm.WEIGHT_BASED

- Constants.HomeLoadAlgorithm.ROUND_ROBIN_AFFINITY

- Constants.HomeLoadAlgorithm.RANDOM_AFFINITY

- Constants.HomeLoadAlgorithm.WEIGHT_BASED_AFFINITY

Constants.Interface

Constants.Interfaceの有効な値は以下のとおりです。

- Constants.Interface.UNSPECIFIED

- Constants.Interface.HOME

- Constants.Interface.REMOTE

- Constants.Interface.LOCAL_HOME

- Constants.Interface.LOCAL

Constants.ConcurrencyStrategy

Constants.ConcurrencyStrategyの有効な値は以下のとおりです。

- Constants.ConcurrencyStrategy.UNSPECIFIED

- Constants.ConcurrencyStrategy.READ_ONLY

- Constants.ConcurrencyStrategy.EXCLUSIVE

- Constants.ConcurrencyStrategy.DATABASE

- Constants.ConcurrencyStrategy.OPTIMISTIC

EJBGenアノテーション・リファレンス

この節は、Beanのクラス・ファイルで使用できるEJBGenアノテーションの詳細なリファレンスです。

- weblogic.ejbgen.ActivationConfigProperties

- weblogic.ejbgen.ActivationConfigProperty

- weblogic.ejbgen.AutomaticKeyGeneration

- weblogic.ejbgen.CmpField

- weblogic.ejbgen.CmrField

- weblogic.ejbgen.Compatibility

- weblogic.ejbgen.CreateDefaultDbmsTables

- weblogic.ejbgen.CreateDefaultRdbmsTables

- weblogic.ejbgen.DBSpecificSQL

- weblogic.ejbgen.EjbClientJar

- weblogic.ejbgen.EjbInterface (非推奨)

- weblogic.ejbgen.EjbLocalRef

- weblogic.ejbgen.EjbLocalRefs

- weblogic.ejbgen.EjbRef

- weblogic.ejbgen.EjbRefs

- weblogic.ejbgen.Entity

- weblogic.ejbgen.EntityCacheRef

- weblogic.ejbgen.EnvEntries

- weblogic.ejbgen.EnvEntry

- weblogic.ejbgen.FileGeneration

- weblogic.ejbgen.Finder

- weblogic.ejbgen.Finders

- weblogic.ejbgen.ForeignJmsProvider

- weblogic.ejbgen.JarSettings

- weblogic.ejbgen.JndiName

- weblogic.ejbgen.LocalHomeMethod

- weblogic.ejbgen.LocalMethod

- weblogic.ejbgen.MessageDestination

- weblogic.ejbgen.MessageDestinationRef

- weblogic.ejbgen.MessageDestinationRefs

- weblogic.ejbgen.MessageDestinations

- weblogic.ejbgen.MessageDriven

- weblogic.ejbgen.MethodIsolationLevelPattern

- weblogic.ejbgen.MethodIsolationLevelPatterns

- weblogic.ejbgen.MethodPermissionPattern

- weblogic.ejbgen.MethodPermissionPatterns

- weblogic.ejbgen.PrimKeyField

- weblogic.ejbgen.Relation

- weblogic.ejbgen.Relations

- weblogic.ejbgen.RelationshipCachingElement

- weblogic.ejbgen.RelationshipCachingElements

- weblogic.ejbgen.RemoteHomeMethod

- weblogic.ejbgen.RemoteMethod

- weblogic.ejbgen.ResourceEnvRef

- weblogic.ejbgen.ResourceEnvRefs

- weblogic.ejbgen.ResourceRef

- weblogic.ejbgen.ResourceRefs

- weblogic.ejbgen.RoleMapping

- weblogic.ejbgen.RoleMappings

- weblogic.ejbgen.SecurityRoleRef

- weblogic.ejbgen.SecurityRoleRefs

- weblogic.ejbgen.Select

- weblogic.ejbgen.ServiceEndpointMethod

- weblogic.ejbgen.ServiceRef

- weblogic.ejbgen.ServiceRefs

- weblogic.ejbgen.Session

- weblogic.ejbgen.SqlFinder

- weblogic.ejbgen.SqlFinders

- weblogic.ejbgen.SqlShape

- weblogic.ejbgen.SqlShapeTable

- weblogic.ejbgen.SqlShapes

- weblogic.ejbgen.ValueObject

- weblogic.ejbgen.ValueObjectField

EJBコンテナ・アノテーション

以下に、アノテーションの配列のみで構成されるコンテナ・アノテーションのリストを示します。

注意:

1つのクラスまたはメソッドには、1つのアノテーション・インスタンスだけを記述できます。

アノテーション(内部のアノテーション配列を含む)の詳細は、そのアノテーション名をクリックしてください。

- weblogic.ejbgen.ActivationConfigProperties

- weblogic.ejbgen.EjbLocalRefs

- weblogic.ejbgen.EjbRefs

- weblogic.ejbgen.EnvEntries

- weblogic.ejbgen.Finders

- weblogic.ejbgen.MessageDestinationRefs

- weblogic.ejbgen.MethodIsolationLevelPatterns

- weblogic.ejbgen.MethodPermissionPatterns

- weblogic.ejbgen.Relations

- weblogic.ejbgen.RelationshipCachingElements

- weblogic.ejbgen.ResourceEnvRefs

- weblogic.ejbgen.ResourceRefs

- weblogic.ejbgen.RoleMappings

- weblogic.ejbgen.SecurityRoleRefs

- weblogic.ejbgen.ServiceRefs

- weblogic.ejbgen.SqlFinders

- weblogic.ejbgen.SqlShapes

weblogic.ejbgen.ActivationConfigProperties

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.ActivationConfigPropertyアノテーションの配列以外の属性はありません。

weblogic.ejbgen.ActivationConfigProperty

ターゲット:クラス

属性

表E-2 ActivationConfigProperty EJBGenアノテーションの属性

名前

説明

データ型

必須?

value

プロパティ値。

String

はい

name

プロパティ名。

String

はい

weblogic.ejbgen.AutomaticKeyGeneration

ターゲット:クラス

属性

表E-3 AutomaticKeyGeneration EJBGenアノテーションの属性

属性

説明

データ型

必須?

type

キー・ジェネレータのタイプ。

この属性の有効な値は次のとおりです:

- AutomaticKeyGeneration.AutomaticKeyGenerationType.UNSPECIFIED

- AutomaticKeyGeneration.AutomaticKeyGenerationType.IDENTITY

- AutomaticKeyGeneration.AutomaticKeyGenerationType.SEQUENCE

- AutomaticKeyGeneration.AutomaticKeyGenerationType.SEQUENCE_TABLE

Enum

はい

cacheSize

主要キャッシュのサイズ。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ(以前は必須)

name

ジェネレータの名前。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.CmpField

ターゲット:メソッド

属性

表E-4 CmpField EJBGenアノテーションの属性

属性

説明

データ型

必須?

column

CMPフィールドがマップされる列。「EJBGenによる複数表へのエンティティBeanのマッピング」を参照してください。

String

はい

readOnlyInValueObject

Trueであれば、値オブジェクトのこのフィールドでゲッターだけが生成されます。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

tableName

このフィールドがマップされる表。

「EJBGenによる複数表へのエンティティBeanのマッピング」を参照してください。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

groupNames

このフィールドが属するグループ名をカンマで区切ったもの。グループ名のリストを二重引用符で囲みます。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

orderingNumber

このフィールドがシグネチャおよびコンストラクタ内に置かれるべき順番。この順序付けを有効にするためには、すべてのcmrおよびcmpフィールドでこの属性に異なる数値を設定する必要があります。この属性のデフォルト値は0です。

String

いいえ

excludeFromValueObject

Trueであれば、このフィールドは値オブジェクトで生成されません。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

columnType

この列のタイプ。この属性の有効な値は次のとおりです:

- CmpField.ColumnType.UNSPECIFIED

- CmpField.ColumnType.CLOB

- CmpField.ColumnType.BLOB

- CmpField.ColumnType.LONG_STRING

- CmpField.ColumnType.SYBASE_BINARY

デフォルト値はCmpField.ColumnType.UNSPECIFIEDです。

Enum

いいえ

primkeyField

このフィールドが複合主キーの一部であるかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

dbmsDefaultValue

このフィールドがデフォルトのDBMS値であるかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

weblogic.ejbgen.CmrField

ターゲット:メソッド

属性

表E-5 CmrField EJBGenアノテーションの属性

属性

説明

データ型

必須?

readOnlyInValueObject

Trueであれば、値オブジェクトのこのフィールドでゲッターだけが生成されます。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

groupNames

このフィールドが属するグループ名をカンマで区切ったもの。グループ名のリストを二重引用符で囲みます。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

orderingNumber

このフィールドがシグネチャおよびコンストラクタ内に置かれるべき順番。この順序付けを有効にするためには、すべてのcmrおよびcmpフィールドがこの属性で異なる数値を持つ必要があります。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

excludeFromValueObject

Trueであれば、このフィールドは値オブジェクトで生成されません。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

weblogic.ejbgen.Compatibility

ターゲット:クラス

属性

表E-6 Compatibility EJBGenアノテーションの属性

属性

説明

データ型

必須?

serializeCharArrayToBytes

OracleデータベースのBlobにマップされたbyte[]型のcmp-fieldをシリアライズするかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

disableStringTrimming

String型の削除を無効にするかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

serializeByteArrayToOracleBlob

OracleBlobにマップされたbyte[]型のcmp-fieldをシリアライズするかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

allowReadonlyCreateAndRemove

読取り専用の作成と削除を有効にするかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

findersReturnNulls

ファインダ・メソッドがNULLを返すことができるかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

weblogic.ejbgen.CreateDefaultDbmsTables

このタグは非推奨になりました。かわりにweblogic.ejbgen.JarSettingsを使用してください。

weblogic.ejbgen.CreateDefaultRdbmsTables

このタグは非推奨になりました。かわりにweblogic.ejbgen.JarSettingsを使用してください。

weblogic.ejbgen.DBSpecificSQL

ターゲット:クラス、メソッド、フィールド

属性

表E-7 DBSpecificSQL EJBGenアノテーションの属性

属性

説明

データ型

必須?

databaseType

データベースのタイプ。

String

はい

sql

SQL文。

String

はい

weblogic.ejbgen.EjbClientJar

このタグは非推奨になりました。かわりにweblogic.ejbgen.JarSettingsを使用してください。

weblogic.ejbgen.EjbInterface(非推奨)

注意:

このクラスは非推奨になりました。今後のリリースで削除される予定です。

ターゲット:クラス

属性

表E-8 EjbInterface EJBGenアノテーションの属性

属性

説明

データ型

必須?

ejbType

EJBのタイプを指定します。このタグは通常は使用しません。

有効な値は以下のとおりです。

- javax.ejb.MessageDrivenBean

- javax.ejb.EntityBean

- javax.ejb.SessionBean

String

はい

weblogic.ejbgen.EjbLocalRef

ターゲット:クラス

属性

表E-9 EjbLocalRef EJBGenアノテーションの属性

属性

説明

データ型

必須?

jndiName

参照のJNDI名を指定します。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

type

参照のタイプを指定します。

この属性の有効な値については、「Constants.RefType」を参照してください。デフォルト値はConstants.RefType.UNSPECIFIEDです。

Enum(Constants.RefType)

いいえ

local

Beanのローカル・クラスの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

name

参照の名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

link

Beanのリンクの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

home

Beanのホーム・クラスの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.EjbLocalRefs

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.EjbLocalRefsアノテーションの配列以外の属性はありません。

weblogic.ejbgen.EjbRef

ターゲット:クラス

属性

表E-10 EjbRef EJBGenアノテーションの属性

属性

説明

データ型

必須?

jndiName

参照のJNDI名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

type

参照のタイプを指定します。

この属性の有効な値については、「Constants.RefType」を参照してください。デフォルト値はConstants.RefType.UNSPECIFIEDです。

Enum(Constants.RefType)

いいえ

remote

Beanのローカル・クラスの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

name

参照の名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

link

Beanのリンクの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

home

Beanのホーム・クラスの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.EjbRefs

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.EjbRefアノテーションの配列以外の属性はありません。

weblogic.ejbgen.Entity

ターゲット:クラス

属性

表E-11 Entity EJBGenアノテーションの属性

属性

説明

データ型

必須?

ejbName

エンティティBeanの名前。

String

はい

primKeyClass

主キーのJavaクラスの名前。複合主キーの場合、このクラスはEJBGenによって生成されます。

String

はい

tableName

このエンティティBeanのマップ先の表の名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

verifyRows

オプティミスティック同時実行性を使用するときにチェックの対象にする表の行を指定します。

この属性の有効な値は次のとおりです:

- Entity.VerifyRows.UNSPECIFIED

- Entity.VerifyRows.READ

- Entity.VerifyRows.MODIFIED

デフォルト値はEntity.VerifyRows.UNSPECIFIEDです。

Enum

いいえ

clientsOnSameServer

クライアントが同じサーバー上のEJBと連結されるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

invalidationTarget

このコンテナ管理による永続性エンティティEJBが変更されたときに無効にする読取り専用エンティティBeanのejb-name。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

useCallerIdentity

このEJBが、呼出し側のIDを使用するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

cacheBetweenTransactions

エンティティBeanの永続データをトランザクション間でキャッシュするかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

defaultDbmsTablesDdl

DDLファイル名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

defaultTransaction

トランザクション属性が設定されていないすべてのメソッドに適用されるデフォルトのトランザクション属性を設定します。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

checkExistsOnMethod

コンテナがメソッド呼出しごとにBeanの有無をチェックするかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

clusterInvalidationDisabled

オプティミスティックまたは読取り専用の同時実行性を使用するEJBの場合、デプロイ先のクラスタのメンバーによって更新されたときにEJBを無効にするかどうかを指定します。trueの場合、そのようなEJBが更新されたときに、コンテナはマルチキャスト無効化メッセージを送信しません。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

optimisticColumn

オプティミスティック同時実行性のためのタイムスタンプを保持する列を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

orderDatabaseOperations

データベース操作をソートするかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

runAsIdentityPrincipal

非推奨です。かわりにrunAsPrincipalNameを使用することを推奨します。

String

いいえ

runAsPrincipalName

ロールを複数のプリンシパルにマップする場合のプリンシパル名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

delayDatabaseInsertUntil

データベース挿入をいつまで遅延させるかを指定します。

この属性の有効な値は次のとおりです:

- Entity.DelayDatabaseInsertUntil.UNSPECIFIED

- Entity.DelayDatabaseInsertUntil.EJB_CREATE

- Entity.DelayDatabaseInsertUntil.EJB_POST_CREATE

デフォルト値はEntity.DelayDatabaseInsertUntil.UNSPECIFIEDです。

Enum

いいえ

enableCallByReference

コンテナでこのEJBの参照呼出しを行うかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

validateDbSchemaWith

EJBコンテナによって作成される表の検証に使用するメソッドを指定します。

この属性の有効な値は次のとおりです:

- Entity.ValidateDBSchemaWith.UNSPECIFIED

- Entity.ValidateDBSchemaWith.META_DATA

- Entity.ValidateDBSchemaWith.TABLE_QUERY

デフォルト値はEntity.ValidateDBSchemaWith.UNSPECIFIEDです。

Enum

いいえ

dispatchPolicy

このBeanのディスパッチ・ポリシー・キューを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

remoteClientTimeout

リモートRMIクライアントがタイムアウトするまでの待機時間を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

lockOrder

トランザクションに複数のBeanが関与する場合の、このBeanのデータベース・ロック順を設定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

findersLoadBean

Trueに設定した場合、Beanはファインダによってすぐにキャッシュにロードされます。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

concurrencyStrategy

このBeanの同時実行性ストラテジを定義します。

この属性の有効な値については、「Constants.ConcurrencyStrategy」を参照してください。デフォルト値はConstants.ConcurrencyStrategy.UNSPECIFIEDです。

Enum(Constants.ConcurrencyStrategy)

いいえ

persistenceType

エンティティBeanのタイプを指定します。

この属性の有効な値は次のとおりです:

- Entity.PersistenceType.UNSPECIFIED

- Entity.PersistenceType.CMP

- Entity.PersistenceType.BMP

デフォルト値はEntity.PersistenceType.UNSPECIFIEDです。

Enum

いいえ

maxBeansInCache

キャッシュ内のBeanの最大数を設定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

primKeyClassNogen

このキーワードを指定した場合、EJBGenは主キー・クラスを生成しなくなります(ユーザー側が提供するものと見なします)。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

initialBeansInFreePool

フリー・プール内のBeanの初期数を指定します。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

verifyColumns

オプティミスティック同時実行性で、トランザクション中の列の変更の有無を確認する方法を指定します。

この属性の有効な値は次のとおりです:

- Entity.VerifyColumns.UNSPECIFIED

- Entity.VerifyColumns.READ

- Entity.VerifyColumns.MODIFIED

- Entity.VerifyColumns.VERSION

- Entity.VerifyColumns.TIMESTAMP

デフォルト値はEntity.VerifyColumns.UNSPECIFIEDです。

Enum

いいえ

idleTimeoutSeconds

あるEJBがキャッシュ内に置かれる最大秒数を設定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

transTimeoutSeconds

トランザクションのタイムアウトを秒単位で指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

enableBatchOperations

バッチ処理を実行するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

maxBeansInFreePool

空きプール内のBeanの最大数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

disableWarning

ejbcの実行時に無効化する警告のカンマ区切りのリスト。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

readTimeoutSeconds

読取り専用エンティティBeanのejbLoad()を呼び出す間隔を秒単位で設定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

databaseType

基底DBMSのデータベース・タイプを指定します。

この属性の有効な値は次のとおりです:

- Entity.DatabaseType.UNSPECIFIED

- Entity.DatabaseType.DB2

- Entity.DatabaseType.INFORMIX

- Entity.DatabaseType.ORACLE

- Entity.DatabaseType.SQL_SERVER

- Entity.DatabaseType.SYBASE

- Entity.DatabaseType.SQL_SERVER200

デフォルト値はEntity.DatabaseType.UNSPECIFIEDです。

Enum

いいえ

reentrant

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

homeLoadAlgorithm

このホームのレプリカ間のロード・バランシングに使用するアルゴリズムを指定します。

この属性の有効な値については、「Constants.HomeLoadAlgorithm」を参照してください。

デフォルト値はConstants.HomeLoadAlgorithm.UNSPECIFIEDです。

Enum(Constants.HomeLoadAlgorithm)

いいえ

delayUpdatesUntilEndOfTx

トランザクション・コミット後に更新が送信されるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

runAs

このEJBのロール名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

abstractSchemaName

このEJBの抽象スキーマ名を指定します。指定されない場合、ejb-nameの値が使用されます。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

dbIsShared

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

enableDynamicQueries

動的問合せを有効にするかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

homeIsClusterable

このBeanがクラスタ内の複数のサーバーからデプロイ可能かどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

dataSourceName

config.xmlで宣言されるデータ・ソースの名前。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

useSelectForUpdate

Trueを指定すると、Beanがデータベースからロードされるときは常にSELECT ... FOR UPDATEが使用されます。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

instanceLockOrder

このエンティティBeanのロック順序。

- この属性の有効な値は次のとおりです:

- Entity.InstanceLockOrder.UNSPECIFIED

- Entity.InstanceLockOrder.ACCESS_ORDER

- Entity.InstanceLockOrder.VALUE_ORDER

デフォルト値はEntity.InstanceLockOrder.UNSPECIFIEDです。

Enum

いいえ

homeCallRouterClassName

ホーム・メソッド呼出しのルーティングに使用するクラスの名前。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

networkAccessPoint

EJBでネットワーク通信に使用されるカスタム・ネットワーク・チャネルを割り当てます。ネットワーク・チャネルによって、一連の接続属性が定義されます。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

unknownPrimaryKeyField

主キーが指定されていない場合に主キーとして使用するcmpフィールド。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.EntityCacheRef

ターゲット:クラス

属性

表E-12 EntityCacheRef EJBGenアノテーションの属性

属性

説明

データ型

必須?

concurrencyStrategy

このBeanの同時実行性ストラテジを定義します。

この属性の有効な値については、「Constants.ConcurrencyStrategy」を参照してください。

Enum(Constants.ConcurrencyStrategy)

はい

name

キャッシュの名前。

String

はい

idleTimeoutSeconds

あるEJBがキャッシュ内に置かれる最長の時間。この属性のデフォルト値は0です。

int

いいえ

readTimeoutSeconds

読取り専用エンティティBeanにejbLoad()を呼び出す間隔の秒数。この属性のデフォルト値は0です。

int

いいえ

cacheBetweenTransactions

エンティティBeanの永続データをトランザクション間でキャッシュするかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

estimatedBeanSize

エンティティBeanのインスタンスの推定平均サイズ(バイト単位)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.EnvEntries

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.EnvEntryアノテーションの配列以外の属性はありません。

weblogic.ejbgen.EnvEntry

ターゲット:クラス

属性

表E-13 EnvEntry EJBGenアノテーションの属性

属性

説明

データ型

必須?

value

この環境エントリの値を指定します。

String

はい

type

この環境エントリのJavaタイプを指定します(java.langであっても完全修飾しなければなりません)。

標準の値は次のとおりです:

- java.lang.Boolean

- java.lang.String

- java.lang.Character

- java.lang.Integer

- java.lang.Double

- java.lang.Byte

- java.lang.Short

- java.lang.Long

- java.lang.Float

String

はい

name

この環境エントリの名前。

String

はい

weblogic.ejbgen.FileGeneration

ターゲット:クラス

属性

表E-14 FileGeneration EJBGenアノテーションの属性

属性

説明

データ型

必須?

pkClass

このEJBの主キー・クラスを生成するかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.TRUEです。

Enum(Constants.Bool)

いいえ

remoteClassName

生成されるリモート・クラスの名前。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

remotePackage

リモート・インタフェースのパッケージ。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

valueClass

EJBの値クラスを生成するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

valueClassName

生成される値クラスの名前。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

localClassName

生成されるローカル・クラスの名前。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

localPackage

ローカル・インタフェースのパッケージ。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

remoteHome

このEJBのリモート・ホーム・インタフェースを生成するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

localHomePackage

ローカル・ホーム・インタフェースのパッケージ。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

remoteHomePackage

リモート・ホーム・インタフェースのパッケージ。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

remoteClass

このEJBのリモート・インタフェースを生成するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

localHomeName

生成されるローカル・ホーム・クラスの名前。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

localHome

このEJBのローカル・ホーム・インタフェースを生成するかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

remoteHomeName

生成されるリモート・ホーム・クラスの名前。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

localClass

このEJBのローカル・インタフェースを生成するかどうか。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

weblogic.ejbgen.Finder

ターゲット:クラス

属性

表E-15 Finder EJBGenアノテーションの属性

属性

説明

データ型

必須?

isolationLevel

このメソッドのトランザクション・アイソレーションのタイプを指定します。

この属性の有効な値については、「Constants.IsolationLevel」を参照してください。

デフォルト値はConstants.IsolationLevel.UNSPECIFIEDです。

Enum(Constants.IsolationLevel)

いいえ

transactionAttribute

ローカル・メソッドのトランザクション属性を指定します。指定されない場合、デフォルトのトランザクション属性が使用されます。このタグを付けたメソッドが、ローカル・クラス上に生成されます。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

generateOn

このファインダの生成場所となるホームを指定します。この属性の値を指定しない場合、ファインダはリモート・ホームとローカル・ホームの両方で生成されます。

この属性の有効な値は次のとおりです:

- Finder.GenerateOn.UNSPECIFIED

- Finder.GenerateOn.LOCAL

- Finder.GenerateOn.REMOTE

デフォルト値はFinder.GenerateOn.UNSPECIFIEDです。

Enum

いいえ

comment

生成されたファインダJavaメソッドの上に再現されるコメント。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

cachingName

即時リレーションシップ・キャッシングの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

groupName

WebLogic Server問合せのグループの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

maxElements

多値問合せによって返される要素の最大数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

signature

ホーム・クラスで生成されるシグネチャを正確に指定します。EJBGenは適合例外を追加しますが、各パラメータ(java.langに属している場合でも)の完全修飾タイプを指定する必要があります。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

sqlSelectDistinct

生成されたSQL SELECTにDISTINCT修飾子が含まれるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

includeUpdates

現在のトランザクション中に実行された更新を問合せの結果に反映する必要があるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

ejbQL

デプロイメント記述子に含まれるものと同じEJB QLリクエストを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogicEjbQl

デプロイメント記述子に含まれるものと同じWebLogic Server EJB QLリクエストを指定します。

注意: このリクエストが必要になる場合、EJB QLとWebLogic EJB QLを二重引用符で囲んでください。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.Finders

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.Finderアノテーションの配列以外の属性はありません。

weblogic.ejbgen.ForeignJmsProvider

ターゲット:クラス

属性

表E-16 ForeignJmsProvider EJBGenアノテーションの属性

属性

説明

データ型

必須?

connectionFactoryJndiName

接続ファクトリのJNDI名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

providerUrl

プロバイダURLを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

initialContextFactory

初期JNDIコンテキスト・ファクトリを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.JarSettings

ターゲット:クラス

属性

表E-17 JarSettings EJBGenアノテーションの属性

属性

説明

データ型

必須?

createTables

表を作成するかどうかを指定します。

この属性の有効な値は次のとおりです:

- JarSettings.CreateTables.UNSPECIFIED

- JarSettings.CreateTables.CREATE_ONLY

- JarSettings.CreateTables.DISABLED

- JarSettings.CreateTables.DROP_AND_CREATE

- JarSettings.CreateTables.DROP_AND_CREATE_ALWAYS

- JarSettings.CreateTables.ALTER_OR_CREATE

デフォルト値はarSettings.CreateTables.UNSPECIFIEDです。

Enum

いいえ

ejbClientJar

生成するクライアントJARの名前を指定します。複数のEJBにこのタグがある場合、指定されたJARファイルの1つだけがデプロイメント記述子に含まれます。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

enableBeanClassRedeploy

モジュール全体を再デプロイすることなくこのEJBを再デプロイできるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

disableWarning

ejbcの実行時に無効化する警告のカンマ区切りのリスト。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.JndiName

ターゲット:クラス

属性

表E-18 JndiName EJBGenアノテーションの属性

属性

説明

データ型

必須?

local

EJBのローカルJNDI名を指定します。ローカルJNDI名が指定されていない場合、ローカル・インタフェースは生成されません。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

remote

EJBのリモートJNDI名を指定します。リモートJNDI名が指定されていない場合、リモート・インタフェースは生成されません。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.LocalHomeMethod

ターゲット:メソッド

属性

表E-19 LocalHomeMethod EJBGenアノテーションの属性

属性

説明

データ型

必須?

orderingNumber

このメソッドが生成されたクラス内に置かれる順番を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

isolationLevel

このメソッドのトランザクション・アイソレーションのタイプを指定します。

この属性の有効な値については、「Constants.IsolationLevel」を参照してください。デフォルト値はConstants.IsolationLevel.UNSPECIFIEDです。

Enum(Constants.IsolationLevel)

いいえ

transactionAttribute

ローカル・メソッドのトランザクション属性を指定します。指定されない場合、デフォルトのトランザクション属性が使用されます。このタグを付けたメソッドが、ローカル・クラス上に生成されます。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

roles

このメソッドを呼び出すことができるロールのカンマ区切りのリストを定義します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

isIdempotent

このメソッドが多重呼出し不変かどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

retryCount

ロールバック時のメソッドの再試行回数。この属性のデフォルト値は0です。

int

いいえ

weblogic.ejbgen.LocalMethod

ターゲット:メソッド

属性

表E-20 LocalMethod EJBGenアノテーションの属性

属性

説明

データ型

必須?

orderingNumber

このメソッドが生成されたクラス内に置かれる順番を指定します。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

isolationLevel

このメソッドのトランザクション・アイソレーションのタイプを指定します。

この属性の有効な値については、「Constants.IsolationLevel」を参照してください。デフォルト値はConstants.IsolationLevel.UNSPECIFIEDです。

Enum(Constants.IsolationLevel)

いいえ

transactionAttribute

ローカル・メソッドのトランザクション属性を指定します。指定されない場合、デフォルトのトランザクション属性が使用されます。このタグを付けたメソッドが、ローカル・クラス上に生成されます。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

roles

このメソッドを呼び出すことができるロールのカンマ区切りのリストを定義します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

isIdempotent

このメソッドが多重呼出し不変かどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

retryCount

ロールバック時のメソッドの再試行回数。この属性のデフォルト値は0です。

int

いいえ

weblogic.ejbgen.MessageDestination

ターゲット:クラス

属性

表E-21 MessageDestination EJBGenアノテーションの属性

属性

説明

データ型

必須?

name

メッセージ定義の論理名。

String

はい

destinationJndiName

物理メッセージ宛先のJNDI名。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

providerUrl

プロバイダのURL。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

initialContextFactory

初期コンテキスト・ファクトリこの属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.MessageDestinationRef

ターゲット:クラス

属性

表E-22 MessageDestinationRef EJBGenアノテーションの属性

属性

説明

データ型

必須?

messageDestinationType

参照のタイプ。

String

はい

messageDestinationLink

メッセージ宛先へのリンク。

String

はい

name

参照の名前。

String

はい

messageDestinationUsage

参照の使用。

String

はい

weblogic.ejbgen.MessageDestinationRefs

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.MessageDestinationRefアノテーションの配列以外の属性はありません。

weblogic.ejbgen.MessageDestinations

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.MessageDestinationアノテーションの配列以外の属性はありません。

weblogic.ejbgen.MessageDriven

ターゲット:クラス

属性

表E-23 MessageDriven EJBGenアノテーションの属性

属性

説明

データ型

必須?

ejbName

このメッセージドリブンBeanの名前を指定します。

String

はい

destinationJndiName

このメッセージドリブンBeanの宛先のJNDI名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

destinationType

有効な値は、javax.jms.Queueおよびjavax.jms.Topicです。この属性のデフォルト値はUNSPECIFIEDです。

String

はい

messageSelector

JMSメッセージ・セレクタ。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

durable

destinationTypeがトピックの場合、この属性をTrueに設定するとサブスクリプションが恒久になります。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

initialBeansInFreePool

フリー・プール内のBeanの初期数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

clientsOnSameServer

クライアントが同じサーバー上のEJBと連結されるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

jmsPollingIntervalSeconds

JMS宛先に再接続しにいく間隔の秒数。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

removeAsPrincipalName

ejbRemoveが匿名プリンシパルで実行される場合に使用するプリンシパルの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

transactionType

このEJBのトランザクションがどこで管理されるのかを指定します。

この属性の有効な値は次のとおりです:

- MessageDriven.MessageDrivenTransactionType.UNSPECIFIED

- MessageDriven.MessageDrivenTransactionType.BEAN

- MessageDriven.MessageDrivenTransactionType.CONTAINER

デフォルト値はMessageDriven.MessageDrivenTransactionType.UNSPECIFIEDです。

Enum

いいえ

transTimeoutSeconds

トランザクションのタイムアウトを秒数で指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

useCallerIdentity

このEJBが、呼出し側のIDを使用するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

maxBeansInFreePool

空きプール内のBeanの最大数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

defaultTransaction

トランザクション属性が設定されていないすべてのメソッドに適用されるトランザクション属性を指定します。

この属性の有効な値は次のとおりです:

- MessageDriven.DefaultTransaction.UNSPECIFIED

- MessageDriven.DefaultTransaction.NOT_SUPPORTED

- MessageDriven.DefaultTransaction.REQUIRED

デフォルト値はMessageDriven.DefaultTransaction.UNSPECIFIEDです。

Enum

いいえ

runAsIdentityPrincipal

非推奨です。かわりにrunAsPrincipalNameを使用することを推奨します。

String

いいえ

runAsPrincipalName

ロールを複数のプリンシパルにマップする場合のプリンシパル名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

dispatchPolicy

このBeanのディスパッチ・ポリシー・キューを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

remoteClientTimeout

リモートRMIクライアントがタイムアウトするまでの待機時間を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

passivateAsPrincipalName

ejbPassivateが匿名プリンシパルで実行される場合に使用するプリンシパルの名前を指定します。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

acknowledgeMode

メッセージドリブンBeanの応答確認モードを指定します。

この属性の有効な値は次のとおりです:

- MessageDriven.AcknowledgeMode.UNSPECIFIED

- MessageDriven.AcknowledgeMode.AUTO_ACKNOWLEDGE

- MessageDriven.AcknowledgeMode.DUPS_OK_ACKNOWLEDGE

デフォルト値はMessageDriven.AcknowledgeMode.UNSPECIFIEDです。

Enum

いいえ

runAs

このEJBのロール名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

jmsClientId

このEJBのクライアントID。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

createAsPrincipalName

ejbCreateが匿名プリンシパルで実行される場合に使用するプリンシパルの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

networkAccessPoint

EJBでネットワーク通信に使用されるカスタム・ネットワーク・チャネルを割り当てます。ネットワーク・チャネルによって、一連の接続属性が定義されます。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

messagingType

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

initSuspendSeconds

EJBコンテナがJMSリソースの停止を検出したときにMDBのJMS接続を中断する初期秒数。この属性のデフォルト値は0です。

int

いいえ

maxSuspendSeconds

EJBコンテナがJMSリソースの停止を検出したときにMDBのJMS接続を中断する最大秒数を指定します。この属性のデフォルト値は0です。

int

いいえ

generateUniqueJmsClientId

EJBコンテナがMDBのインスタンスごとに一意のクライアントIDを生成するかどうかを指定します。これにより、恒久MDBをWebLogic Serverの複数のサーバー・インスタンスに簡単にデプロイできるようになります。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

durableSubscriptionDeletion

MDBがアンデプロイまたは削除されるときに恒久トピック・サブスクリプションが自動的に削除されるようにするかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

maxMessagesInTransaction

トランザクション内のメッセージの最大数。この属性のデフォルト値は0です。

int

いいえ

resourceAdapterJndiName

リソース・アダプタのJNDI名。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.MethodIsolationLevelPattern

ターゲット:クラス

属性

表E-24 MethodIsolationLevelPattern EJBGenアノテーションの属性

属性

説明

データ型

必須?

isolationLevel

パターン・タグで指定されるメソッドの分離レベルを指定します。

この属性の有効な値については、「Constants.IsolationLevel」を参照してください。

Enum(Constants.IsolationLevel)

はい

pattern

この分離レベルを受け取るすべてのメソッドに一致するパターン("*"など)。

String

はい

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.MethodIsolationLevelPatterns

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.MethodIsolationLevelPatternアノテーションの配列以外の属性はありません。

weblogic.ejbgen.MethodPermissionPattern

ターゲット:クラス

属性

表E-25 MethodPermissionPattern EJBGenアノテーションの属性

属性

説明

データ型

必須?

pattern

このメソッド許可を受け取るすべてのメソッドに一致するパターン("*"など)を指定します。

String

はい

roles

パターン・タグで指定されるメソッドのロールをカンマで区切って指定します。

String

はい

itf

この許可パターンが適用されるインタフェースを指定します。

この属性の有効な値については、「Constants.Interface」を参照してください。

デフォルト値はConstants.Interface.UNSPECIFIEDです。

Enum(Constants.Interface)

いいえ

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

unchecked

このパターンをチェックされないメソッドに適用するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

weblogic.ejbgen.MethodPermissionPatterns

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.MethodPermissionPatternアノテーションの配列以外の属性はありません。

weblogic.ejbgen.PrimKeyField

このタグは非推奨になりました。かわりにweblogic.ejbgen.CmpFieldのprimkeyField属性を使用してください。

weblogic.ejbgen.Relation

ターゲット:クラス

属性

表E-26 Relation EJBGenアノテーションの属性

属性

説明

データ型

必須?

multiplicity

関係の多重度を設定します。

この属性の有効な値は次のとおりです:

- Relation.Multiplicity.UNSPECIFIED

- Relation.Multiplicity.ONE

- Relation.Multiplicity.MANY

Enum

はい

name

関係の名前を指定します。関係の両端で同じ名前を使用します(一方向の関係にも同様に適用されます)。

String

はい

jointTable

非推奨です。かわりにjoinTableを使用することを推奨します。

String

いいえ

joinTable

多対多関係のみで必要になります。この関係を含む結合表を格納するのに使用する既存の表の名前。複合主キーを使用する場合、対応する一連の外部キーをカンマで区切って指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

fkColumn

少なくとも1つの一方向関係のある場合にのみ必要になります。一方向以外のEJBでは、相手の主キーを保持する列を宣言しなければなりません。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

roleName

このロールの名前(ParentHasChildrenなど)。ロールの名前を指定されない場合、EJBGenがかわりにこれを生成します。関係を継承するにはロール名を指定する必要があります。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

foreignKeyTable

foreign-keyを含むDBMS表の名前。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

primaryKeyTable

primary-keyを含むDBMS表の名前。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

cmrField

この関係が保持されるCMRフィールドを指定します。このフィールドは省略可能です。これを指定しない場合、関係は一方向となります。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

dbCascadeDelete

カスケード削除時に、基底DBMSの組込みカスケード削除機能を使用するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

cascadeDelete

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

targetEjb

この関係のターゲットのEJB名を指定します(ロール名を生成するために使用します)。指定しない場合、任意の一意の文字列が生成されます。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.Relations

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.Relationアノテーションの配列以外の属性はありません。

weblogic.ejbgen.RelationshipCachingElement

ターゲット:クラス

属性

表E-27 RelationshipCachingElement EJBGenアノテーションの属性

属性

説明

データ型

必須?

cachingName

即時リレーションシップ・キャッシングの名前を指定します。

String

はい

cmrField

CMRフィールド名のカンマ区切りのリストを指定します。

String

はい

groupName

CMRフィールドに対してロードされるグループ名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

parentId

この要素の親IDを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.RelationshipCachingElements

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.RelationshipCachingElementアノテーションの配列以外の属性はありません。

weblogic.ejbgen.RemoteHomeMethod

ターゲット:メソッド

属性

表E-28 RemoteHomeMethod EJBGenアノテーションの属性

属性

説明

データ型

必須?

orderingNumber

このメソッドが生成されたクラス内に置かれる順番を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

isolationLevel

このメソッドのトランザクション・アイソレーションのタイプを指定します。

この属性の有効な値については、「Constants.IsolationLevel」を参照してください。デフォルト値はConstants.IsolationLevel.UNSPECIFIEDです。

Enum(Constants.IsolationLevel)

いいえ

transactionAttribute

リモート・メソッドのトランザクション属性を指定します。指定されない場合、デフォルトのトランザクション属性が使用されます。このタグを付けたメソッドが、リモート・クラス上に生成されます。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

roles

このメソッドを呼び出すことができるロールのカンマ区切りのリストを定義します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

isIdempotent

このメソッドが多重呼出し不変かどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

retryCount

ロールバック時のメソッドの再試行回数。

この属性のデフォルト値は0です。

int

いいえ

weblogic.ejbgen.RemoteMethod

ターゲット:メソッド

属性

表E-29 RemoteMethod EJBGenアノテーションの属性

属性

説明

データ型

必須?

orderingNumber

このメソッドが生成されたクラス内に置かれる順番を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

isolationLevel

このメソッドのトランザクション・アイソレーションのタイプを指定します。

この属性の有効な値については、「Constants.IsolationLevel」を参照してください。デフォルト値はConstants.IsolationLevel.UNSPECIFIEDです。

Enum(Constants.IsolationLevel)

いいえ

transactionAttribute

リモート・メソッドのトランザクション属性を指定します。指定されない場合、デフォルトのトランザクション属性が使用されます。このタグを付けたメソッドが、リモート・クラス上に生成されます。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

roles

このメソッドを呼び出すことができるロールのカンマ区切りのリストを定義します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

isIdempotent

このメソッドが多重呼出し不変かどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

retryCount

ロールバック時のメソッドの再試行回数。この属性のデフォルト値は0です。

int

いいえ

weblogic.ejbgen.ResourceEnvRef

ターゲット:クラス

属性

表E-30 ResourceEnvRef EJBGenアノテーションの属性

属性

説明

データ型

必須?

type

リソース環境参照のタイプ(javax.jms.Queueなど)を指定します。

String

はい

name

リソース環境参照の名前を指定します。

String

はい

jndiName

リソースのJNDI名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.ResourceEnvRefs

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.ResourceEnvRefアノテーションの配列以外の属性はありません。

weblogic.ejbgen.ResourceRef

ターゲット:クラス

属性

表E-31 ResourceRef EJBGenアノテーションの属性

属性

説明

データ型

必須?

jndiName

リソースのJNDI名を指定します。

String

はい

type

リソースのタイプ(javax.sql.DataSourceなど)を指定します。

String

はい

auth

この属性の有効な値は次のとおりです:

- ResourceRef.Auth.UNSPECIFIED

- ResourceRef.Auth.APPLICATION

- ResourceRef.Auth.CONTAINER

デフォルト値はResourceRef.Auth.UNSPECIFIEDです。

Enum

いいえ

name

リソースの名前を指定します。

String

はい

sharingScope

共有スコープを定義します。

この属性の有効な値は次のとおりです:

- ResourceRef.SharingScope.UNSPECIFIED

- ResourceRef.SharingScope.SHAREABLE

- ResourceRef.SharingScope.UNSHAREABLE

デフォルト値はResourceRef.SharingScope.UNSPECIFIEDです。

Enum

いいえ

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.ResourceRefs

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.ResourceRefアノテーションの配列以外の属性はありません。

weblogic.ejbgen.RoleMapping

ターゲット:クラス

属性

表E-32 RoleMapping EJBGenアノテーションの属性

属性

説明

データ型

必須?

roleName

このロールの名前を指定します。

String

はい

externallyDefined

このロールが外部で定義される場合はTrueです。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

注意: principals属性を指定しない場合、externallyDefined属性を指定する必要があります。

Enum(Constants.Bool)

(説明を参照)

principals

このロールのプリンシパルの名前をカンマ区切りで指定します。この属性のデフォルト値はUNSPECIFIEDです。

注意: externallyDefined属性を指定しない場合、principals属性を指定する必要があります。

String

(説明を参照)

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.RoleMappings

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.RoleMappingアノテーションの配列以外の属性はありません。

weblogic.ejbgen.SecurityRoleRef

ターゲット:クラス

属性

表E-33 SecurityRoleRef EJBGenアノテーションの属性

属性

説明

データ型

必須?

roleName

このセキュリティ・ロールの名前を指定します。

String

はい

id

このタグのID (タグの継承でのみ使用します)。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

roleLink

定義済みセキュリティ・ロールを参照します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.SecurityRoleRefs

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.SecurityRoleRefアノテーションの配列以外の属性はありません。

weblogic.ejbgen.Select

ターゲット:メソッド

属性

表E-34 Select EJBGenアノテーションの属性

属性

説明

データ型

必須?

cachingName

即時リレーションシップ・キャッシングの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

groupName

WebLogic Server問合せのグループの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

maxElements

多値問合せによって返される要素の最大数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

sqlSelectDistinct

生成されたSQL SELECTにDISTINCT修飾子が含まれるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

includeUpdates

現在のトランザクション中に実行された更新を問合せの結果に反映する必要があるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

orderingNumber

このメソッドが生成されたクラス内に置かれる順番を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

ejbQl

この選択メソッドを定義するEJB QLを指定します。メソッド名はejbSelectで始める必要があります。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogicEjbQl

デプロイメント記述子に含まれるものと同じWebLogic Server EJB QLリクエストを指定します。このリクエストが必要になる場合、EJB QLとWebLogic EJB QLを二重引用符で囲んでください。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

resultTypeMapping

返されたオブジェクトをEJBLocalObjectまたはEJBObjectにマップするかどうかを指定します。

この属性の有効な値は次のとおりです:

- Select.ResultTypeMapping.UNSPECIFIED

- Select.ResultTypeMapping.LOCAL

- Select.ResultTypeMapping.REMOTE

デフォルト値はSelect.ResultTypeMapping.UNSPECIFIEDです。

Enum

いいえ

weblogic.ejbgen.ServiceEndpointMethod

ターゲット:メソッド

属性

表E-35 ServiceEndpointMethod EJBGenアノテーションの属性

属性

説明

データ型

必須?

transactionAttribute

ステートレス・セッションBeanのサービス・エンドポイント・メソッドのトランザクション属性を指定します。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

unchecked

このメソッドに誰でもアクセスできるようにするかどうかを指定します

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

roles

このメソッドを呼び出すことができるロールのカンマ区切りのリストを定義します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.ServiceRef

ターゲット:クラス

属性

表E-36 ServiceRef EJBGenアノテーションの属性

属性

説明

データ型

必須?

serviceInterface

WSDLファイル内のこのサービスの名前。

String

はい

weblogic.ejbgen.ServiceRefs

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.ServiceRefアノテーションの配列以外の属性はありません。

weblogic.ejbgen.Session

ターゲット:クラス

属性

表E-37 Session EJBGenアノテーションの属性

属性

説明

データ型

必須?

ejbName

セッションBeanの名前を指定します。

String

はい

isClusterable

このBeanがクラスタ化可能かどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

replicationType

クラスタ内のステートフル・セッションBeanをレプリケートする方法を指定します。

この属性の有効な値は次のとおりです:

- Session.ReplicationType.UNSPECIFIED

- Session.ReplicationType.IN_MEMORY

- Session.ReplicationType.NONE

デフォルト値はSession.ReplicationType.UNSPECIFIEDです。

Enum

いいえ

clientsOnSameServer

クライアントが同じサーバー上のEJBと連結されるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

serviceEndpoint

エンタープライズBeanのエンドポイント・インタフェースの完全修飾名。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

useCallerIdentity

このEJBが、呼出し側のIDを使用するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

persistentStoreDir

パッシブ化されたBeanが格納されるディレクトリを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

callRouterClassName

ホーム・メソッド呼出しのルーティングに使用するクラスの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

defaultTransaction

トランザクション属性が設定されていないすべてのメソッドに適用されるトランザクション属性を指定します。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

methodsAreIdempotent

ステートレス・セッションBeanのメソッドが多重呼出し不変かどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

runAsIdentityPrincipal

非推奨です。かわりにrunAsPrincipalNameを使用することを推奨します。

String

いいえ

runAsPrincipalName

ロールを複数のプリンシパルにマップする場合のプリンシパル名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

enableCallByReference

コンテナでこのEJBの参照呼出しを行うかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

dispatchPolicy

このBeanのディスパッチ・ポリシー・キューを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

remoteClientTimeout

リモートRMIクライアントがタイムアウトするまでの待機時間を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

passivateAsPrincipalName

ejbPassivateが匿名プリンシパルで実行される場合に使用するプリンシパルの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

maxBeansInCache

キャッシュ内のBeanの最大数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

initialBeansInFreePool

フリー・プール内のBeanの初期数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

allowRemoveDuringTransaction

トランザクション中にremove()を呼び出せるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

idleTimeoutSeconds

EJBがキャッシュに置かれる最長時間を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

type

セッションBeanのタイプを指定します。この属性が指定されない場合、EJBGenは各自のクラスのejbCreate()メソッドを調べることによって正確なタイプを推測します。

この属性の有効な値は次のとおりです:

- Session.SessionType.UNSPECIFIED

- Session.SessionType.STATELESS

- Session.SessionType.STATEFUL

デフォルト値はSession.SessionType.UNSPECIFIEDです。

Enum

いいえ

removeAsPrincipalName

ejbRemoveが匿名プリンシパルで実行される場合に使用するプリンシパルの名前を指定します。

この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

transTimeoutSeconds

トランザクションのタイムアウトを秒数で指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

transactionType

このEJBのトランザクションの管理元を指定します。

この属性の有効な値は次のとおりです:

- Session.SessionTransactionType.UNSPECIFIED

- Session.SessionTransactionType.BEAN

- Session.SessionTransactionType.CONTAINER

デフォルト値はSession.SessionTransactionType.UNSPECIFIEDです。

Enum

いいえ

allowConcurrentCalls

このEJBの同時呼出しを許可するかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

maxBeansInFreePool

空きプール内のBeanの最大数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

sessionTimeoutSeconds

EJBのパッシブ化が行われるまでの生存期間を秒単位で指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

beanLoadAlgorithm

このBeanのレプリカ間のロード・バランシングに使用されるアルゴリズムを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

homeLoadAlgorithm

このホームのレプリカ間のロード・バランシングに使用するアルゴリズムを指定します。

この属性の有効な値については、「Constants.HomeLoadAlgorithm」を参照してください。デフォルト値はConstants.HomeLoadAlgorithm.UNSPECIFIEDです。

Enum(Constants.HomeLoadAlgorithm)

いいえ

cacheType

このステートフル・セッションBeanのキャッシュのタイプを指定します。

この属性の有効な値は次のとおりです:

- Session.CacheType.UNSPECIFIED

- Session.CacheType.N_R_U

- Session.CacheType.L_R_U

デフォルト値はSession.CacheType.UNSPECIFIEDです。

Enum

いいえ

runAs

このEJBのロール名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

homeIsClusterable

このBeanがクラスタ内の複数のサーバーからデプロイ可能かどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

homeCallRouterClassName

ホーム・メソッド呼出しのルーティングに使用するクラス名を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

createAsPrincipalName

ejbCreateが匿名プリンシパルで実行される場合に使用するプリンシパルの名前を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

networkAccessPoint

EJBでネットワーク通信に使用されるカスタム・ネットワーク・チャネルを割り当てます。ネットワーク・チャネルによって、一連の接続属性が定義されます。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

weblogic.ejbgen.SqlFinder

ターゲット:クラス

属性

表E-38 SqlFinder EJBGenアノテーションの属性

属性

説明

データ型

必須?

sql

デプロイメント記述子に含まれるものと同じWebLogic Server EJB QLリクエストを指定します。

注意: このリクエストが必要になる場合、EJB QLとWebLogic EJB QLを二重引用符で囲んでください。

String

はい

signature

ホーム・クラスで生成されるシグネチャを正確に指定します。EJBGenは適合例外を追加しますが、各パラメータ(java.langに属している場合でも)の完全修飾タイプを指定する必要があります。

String

はい

maxElements

多値問合せによって返される要素の最大数を指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

includeUpdates

現在のトランザクション中に実行された更新を問合せの結果に反映する必要があるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

isolationLevel

このメソッドのトランザクション・アイソレーションのタイプを指定します。

この属性の有効な値については、「Constants.IsolationLevel」を参照してください。デフォルト値はConstants.IsolationLevel.UNSPECIFIEDです。

Enum(Constants.IsolationLevel)

いいえ

dbSpecificSql

デプロイメント記述子に含まれるものと同じWebLogic Server EJB QLリクエストを指定します。このリクエストが必要になる場合、EJB QLとWebLogic EJB QLを二重引用符で囲んでください。

この属性の有効な値は、weblogic.ejbgen.DBSpecificSQLアノテーションの配列。デフォルト値は空の配列。

weblogic.ejbgen.DBSpecificSQLの配列

いいえ

sqlShapeName

デプロイメント記述子に含まれるものと同じEJB QLリクエストを指定します。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

transactionAttribute

ローカル・メソッドのトランザクション属性を指定します。指定されない場合、デフォルトのトランザクション属性が使用されます。このタグを付けたメソッドが、ローカル・クラス上に生成されます。

この属性の有効な値については、「Constants.TransactionAttribute」を参照してください。デフォルト値はConstants.TransactionAttribute.UNSPECIFIEDです。

Enum(Constants.TransactionAttribute)

いいえ

generateOn

このファインダの生成場所となるホームを指定します。指定しない場合、両方のホームで生成されます。

この属性の有効な値は次のとおりです:

- SqlFinder.GenerateOn.UNSPECIFIED

- SqlFinder.GenerateOn.LOCAL

- SqlFinder.GenerateOn.REMOTE

デフォルト値はSqlFinder.GenerateOn.UNSPECIFIEDです。

Enum

いいえ

sqlSelectDistinct

生成されたSQL SELECTにDISTINCT修飾子が含まれるかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

enableQueryCaching

読取り専用エンティティEJBを問合せレベルでキャッシュするかどうかを指定します。

この属性の有効な値については、「Constants.Bool」を参照してください。デフォルト値はConstants.Bool.UNSPECIFIEDです。

Enum(Constants.Bool)

いいえ

weblogic.ejbgen.SqlFinders

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.SqlFinderアノテーションの配列以外の属性はありません。

weblogic.ejbgen.SqlShape

ターゲット:クラス

属性

表E-39 SqlShape EJBGenアノテーションの属性

属性

説明

データ型

必須?

name

ホーム・クラスで生成されるシグネチャを正確に指定します。EJBGenは適合例外を追加しますが、各パラメータ(java.langに属している場合でも)の完全修飾タイプを指定する必要があります。

String

はい

relationNames

このファインダ問合せで使用するSQL形式の名前。この属性のデフォルト値は空の配列です。

文字列の配列

いいえ

tables

このファインダ問合せで使用するSQL形式の名前。この属性のデフォルト値は空の配列。

weblogic.ejbgen.SqlShapeTableの配列

いいえ

passThroughColumns

このファインダ問合せで使用するSQL形式の名前。この属性のデフォルト値は0です。

int

いいえ

weblogic.ejbgen.SqlShapeTable

ターゲット:クラス、メソッド、フィールド

属性

表E-40 SqlShapeTable EJBGenアノテーションの属性

属性

説明

データ型

必須?

name

SQL形式表の名前。

String

はい

ejbRelationshipRoleName

関係ロールの名前。この属性のデフォルト値はUNSPECIFIEDです。

String

いいえ

columns

データベース列。

文字列の配列

はい

weblogic.ejbgen.SqlShapes

ターゲット:クラス

このアノテーションには、weblogic.ejbgen.SqlShapeアノテーションの配列以外の属性はありません。

weblogic.ejbgen.ValueObject

ターゲット:クラス

属性

表E-41 ValueObject EJBGenアノテーションの属性

属性

説明

データ型

必須?

reference

他のEJBのクラスにアクセスするときに値オブジェクト・クラスが参照するオブジェクト指定します。

この属性の有効な値は次のとおりです:

- ValueObject.Reference.UNSPECIFIED

- ValueObject.Reference.UNSPECIFIED

- ValueObject.Reference.UNSPECIFIED

デフォルト値はValueObject.Reference.UNSPECIFIEDです。

Enum

いいえ

weblogic.ejbgen.ValueObjectField

ターゲット:クラス、メソッド、フィールド

属性

表E-42 ValueObjectField EJBGenアノテーションの属性

属性

説明

データ型

必須?

int

この属性のデフォルト値は0です。

int

いいえ

F EJB 1.1ユーザーへの重要な情報

新規ユーザーは、分散ビジネス・アプリケーションの実装にEJB 2.0 Beanを使用することを強くお薦めします。しかし、既存のアプリケーションがEJB 1.1を実装している場合は、以下の節をお読みください。EJB 1.1に固有の設計および実装上の重要な情報を提供しています。ここには、EJB 1.1デプロイメント記述子の詳細なリファレンスを記載しています。

- EJB 1.1 CMPのRDBMS永続性用の記述

- EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)の使用

- CMP 1.1ファインダ問合せとしてのSQLの使用

- WebLogic ServerでのEJB 1.1 CMPの調整更新

- is-modified-method-nameを使用したejbStore()の呼出しの制限

- 5.1のweblogic-ejb-jar.xmlデプロイメント記述子ファイルの構造

- 5.1のweblogic-ejb-jar.xmlデプロイメント記述子要素

- 1.1のweblogic-cmp-jar.xmlデプロイメント記述子ファイルの構造

- EJB 1.1ユーザーへの重要な情報

EJB 1.1 CMPのRDBMS永続性用の記述

クライアントはファインダ・メソッドを使用して、問合せを実行し、問合せ条件を満たすエンティティBeanの参照を受け取ることができます。この節では、RDBMS永続性を使用するWebLogic固有の1.1 EJB用のファインダを作成する方法について説明します。コンテナ管理による永続性を利用する2.0 EJBのファインダ問合せを定義するには、ポータブルな問合せ言語であるEJB QLを使用します。

WebLogic Serverでは、ファインダを簡単に作成できます。

1. EJBHomeインタフェースでファインダのメソッド・シグネチャを記述します。

2. ejb-jar.xmlデプロイメント・ファイルでファインダの問合せ式を定義します。

appcは、ejb-jar.xmlの問合せを使用して、デプロイメント時にファインダ・メソッドの実装を作成します。

RDBMS永続性用のファインダの主要コンポーネントは以下のとおりです。

- EJBHome内のファインダ・メソッド・シグネチャ

- ejb-jar.xml内で定義されるquery要素

- weblogic-cmp-jar.xml内の省略可能なfinder-query要素

以降の節では、WebLogic Serverデプロイメント・ファイルのXML要素を使用してEJBファインダを記述する方法について説明します。

ファインダ・シグネチャ

findMethodName()という形式で、ファインダ・メソッドのシグネチャを指定します。weblogic-cmp-jar.xmlに定義されるファインダ・メソッドは、EJBオブジェクトのJavaコレクションまたは単一オブジェクトを返す必要があります。

注意:

関連付けられているEJBクラスの単一オブジェクトを返すfindByPrimaryKey(primkey)メソッドを定義することもできます。

finder-list要素

finder-list要素は、EJBHome内の1つまたは複数のファインダ・メソッド・シグネチャをEJBオブジェクトを検索するための問合せに関連付けます。次に、WebLogic Server RDBMSベースの永続性を使用した単純なfinder-list要素の例を示します。

<finder-list>
<finder>
<method-name>findBigAccounts</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
<finder-query><![CDATA[(> balance $0)]]></finder-query>
</finder>
</finder-list>

注意:

method-param要素内に非プリミティブなデータ型を使用する場合には、完全修飾名を指定する必要があります。たとえば、Timestampではなくjava.sql.Timestampを使用します。完全修飾名を使用しないと、デプロイメント・ユニットのコンパイル時にappcでエラー・メッセージが生成されます。

finder-query要素

finder-query要素は、RDBMSからEJBオブジェクトを問合せするためのWebLogic問合せ言語(WLQL)式を定義します。WLQLは、ファインダ・パラメータ、EJB属性、およびJava言語の式に対して標準の演算子セットを使用します。WLQLの詳細については、「EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)の使用」を参照してください。

注意:

finder-query値のテキストは、常に、XML CDATA属性を使用して定義してください。CDATAを使用すると、WLQL文字列中に特殊文字が入っていても、ファインダをコンパイルしたときにエラーが発生しないようになります。

CMPファインダでは、1回のデータベース問合せですべてのBeanをロードできます。そのため、Beanが100あってもデータベースに一度アクセスするだけでロードできます。Bean管理による永続性(BMP)ファインダは、データベースに一度アクセスして、ファインダで選択したBeanの主キー値を取得する必要があります。各Beanにアクセスする場合、通常はBeanがキャッシュされていないとことを想定して、もう一度データベースにアクセスする必要があります。したがって、100のBeanにアクセスするために、BMPはデータベースに101回アクセスします。

EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)の使用

EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)を使用すると、コンテナ管理による永続性を利用する1.1エンティティEJBを問合せできます。weblogic-cmp-jar.xmlファイルでは、各finder-query要素に、EJBを返すための問合せを定義するWLQL文字列が指定されていなければなりません。EJB向けのWLQLとそれに対応するデプロイメント・ファイル(EJB 1.1仕様に基づいたもの)を使用します。

WLQL構文

WLQL文字列では、比較演算子用に次の接頭辞表記法を使用します。

(operator operand1 operand2)

追加のWLQL演算子は、単一のオペランド、テキスト文字列、またはキーワードを受け付けます。

WLQL演算子

次の表に、有効なWLQL演算子を示します。

表F-1 WLQL演算子

演算子

説明

サンプル構文

=

等しい

(= operand1 operand2)

<

より小さい

(< operand1 operand2)

>

より大きい

(> operand1 operand2)

<=

以下

(<= operand1 operand2)

>=

以上

(>= operand1 operand2)

!

ブール演算子NOT

(! operand)

&

ブール演算子AND

(& operand)

|

ブール演算子OR

(| operand)

like

指定されたtext_string、または入力パラメータ中の%記号に基づいたワイルドカード検索

(like text_string%)

isNull

単一オペランドの値がNULL

(isNull operand)

isNotNull

単一オペランドの値がNULL以外

(isNotNull operand)

orderBy

指定されたデータベース列を基準に結果を並び替える

注意 : orderBy句には永続フィールド名ではなく常にデータベース列名を指定します。WebLogic ServerはorderByに指定されたフィールド名を変換しません。

(orderBy 'column_name')

desc

結果を降順に並び替える(orderByと組み合わせた場合にのみ使用)

(orderBy 'column_name desc')

WLQLオペランド

有効なWLQLオペランドは以下のとおりです。

- 別のWLQL式

- weblogic-cmp-jar.xmlファイルの別の場所で定義されたコンテナ管理フィールド

注意:

RDBMS列名はWLQLのオペランドとして使用できません。代わりに、weblogic-cmp-jar.xmlのattribute-mapに定義されているとおり、RDBMS列にマップされるEJB属性(フィールド)を使用します。

- $nによって識別されるファインダ・パラメータまたはJava式。nはパラメータまたは式の数です。デフォルトでは、$nは、ファインダ・メソッド・シグネチャのn番目のパラメータにマップされます。Java式が組み込まれたより高度なWLQL式を記述するには、$nをJava式にマップします。

注意:

$nという表記法は、1ではなく0で始まる配列に基づいています。たとえば、ファインダの最初の3つのパラメータは、$0、$1、および$2に対応しています。式は個々のパラメータにマップされる必要はありません。高度なファインダは、パラメータより多くの式を定義できます。

WLQL式の例

次のサンプル・コードは、weblogic-cmp-jar.xmlファイルから基本的なWLQL式を使用する部分を抜粋したものです。

- この例では、ファインダに指定されたbalanceGreaterThanパラメータより大きいbalance属性を持つすべてのEJBが返されます。EJBHome内のファインダ・メソッド・シグネチャは次のとおりです。

public Enumeration findBigAccounts(double balanceGreaterThan)
throws FinderException, RemoteException;

<finder>要素の例は次のとおりです。

<finder>
<method-name>findBigAccounts</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
<finder-query><![CDATA[(> balance $0)]]></finder-query>
</finder>

balanceフィールドは、EJBの永続デプロイメント・ファイルの中の属性マップに定義する必要があります。

注意:

finder-query値のテキストは、常に、XML CDATA属性を使用して定義してください。CDATAを使用すると、WLQL文字列中に特殊文字が入っていても、ファインダをコンパイルしたときにエラーが発生しないようになります。

- 次に、複雑なWLQL式の使用例を示します。文字列を区切る引用符(')の使い方にも注意してください。

<finder-query><![CDATA[(& (> balance $0) (! (= accountType 'checking')))]]></finder-query>

- 次の例では、表内のすべてのEJBが検索されます。この例では、次のファインダ・メソッド・シグネチャを使用しています。

public Enumeration findAllAccounts()
throws FinderException, RemoteException

<finder>要素の例では、空のWLQL文字列が使用されています。

<finder>
<method-name>findAllAccounts</method-name>
<finder-query></finder-query>
</finder>

- 次の問合せでは、lastNameフィールドが「M」で始まるすべてのEJBが検索されます。

<finder-query><![CDATA[(like lastName M%)]]></finder-query>

- 次の問合せでは、nullのfirstNameフィールドを持つすべてのEJBが返されます。

<finder-query><![CDATA[(isNull firstName)]]></finder-query>

- 次の問合せでは、balanceフィールドが5000より大きいすべてのEJBが返され、それらのBeanがデータベース列idによってソートされます。

<finder-query><![CDATA[WHERE >5000 (orderBy 'id' (> balance 5000))]]></finder-query>

- 次の問合せは前の例とほぼ同じですが、EJBが降順で返されます。

<finder-query><![CDATA[(orderBy 'id desc' (> ))]]></finder-query>

CMP 1.1ファインダ問合せとしてのSQLの使用

WebLogic Serverでは、標準WLQL問合せの代わりにSQL文字列を使用し、CMP 1.1ファインダ問合せ用のSQLを記述することができます。SQL文がCMP 1.1ファインダ問合せとしてデータベースから値を取り出します。複雑なファインダ問合せが必要とされWLQLを使えない場合に、SQLを使ってCMP 1.1ファインダ問合せを記述します。

WLQLの詳細については、「EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)の使用」を参照してください。

SQLファインダ問合せを指定するには、次の手順に従います。

1. weblogic-cmp-jar.xmlファイルで、finder-sql要素を使って次のようにSQL問合せを記述します。
findBigAccounts(double cutoff)は次のようになります。

<finder-sql><![CDATA{balance >$0]]></finder-sql>

SQL文字列に含まれている「$0」や「$1」といった値は、ファインダ・メソッドへのパラメータを参照しています。WebLogic Server EJBコンテナは「$」をパラメータに置き換えますが、SQL問合せを解釈しようとはしません。

2. コンテナは次のようなSQLを発行します。

SELECT <columns> FROM table WHERE balance > ?

このSQLは、WHERE句のSQL文でなければなりません。コンテナがSELECT句とFROM句を付加します。WHERE句の中に任意のSQLが含まれます。

「より大きい(>)」や「より小さい(<)」のシンボルなど、SQL問合せ内でXMLパーサーを混乱させる可能性のある文字を使用する場合には、必ず、前述のSQL文の例のようにCDATA形式を使用してSQL問合せを宣言してください。

SQL問合せ内ではベンダー固有のSQLを際限なく使用できます。

WebLogic ServerでのEJB 1.1 CMPの調整更新

コンテナ管理EJBが読み書きされるときに、コンテナはgetおよびsetコールバックを受け取るので、EJBのコンテナ管理による永続性(CMP)は、自動的に調整更新をサポートします。EJB 1.1 CMP Beanを調整すると、パフォーマンスの向上に役立ちます。

WebLogic Serverは、EJB 1.1 CMPの調整更新をサポートするようになりました。ejbStoreが呼び出されると、EJBコンテナはコンテナ管理フィールドがトランザクションで変更されたかどうかを自動的に判定します。変更されたフィールドだけがデータベースに書き込まれます。変更されたフィールドがない場合、データベースは更新されません。

旧バージョンのWebLogic Serverでは、EJB 1.1 CMP Beanが変更されたかどうかをコンテナに通知するisModifiedメソッドを記述することができました。isModifiedは現在もWebLogic Serverでサポートされていますが、isModifiedメソッドを使用しないで、更新されたフィールドをコンテナに判定させることをお薦めします。

この機能はEJB 2.0 CMPに対してデフォルトで有効です。EJB 1.1 CMPの調整更新を有効にするには、weblogic-cmp-jar.xmlファイルの次のデプロイメント記述子要素をtrueに設定します。

<enable-tuned-updates>true</enable-tuned-updates>

CMPの調整更新を無効にするには、このデプロイメント記述子要素を次のように設定します。

<enable-tuned-updates>false</enable-tuned-updates>

この場合、ejbStoreは常にすべてのフィールドをデータベースに書き込みます。

is-modified-method-nameを使用したejbStore()の呼出しの制限

is-modified-method-nameデプロイメント記述子要素は、EJB 1.1のコンテナ管理永続性(CMP) Beanだけに適用されます。この要素は、weblogic-ejb-jar.xmlファイルに入っています。WebLogic ServerのCMP実装では、CMPフィールドの変更が自動的に検出され、それらの変更だけが基底のデータ・ストアに書き込まれます。Bean管理の永続性(BMP)ではis-modified-method-nameを使用しないことをお薦めします。is-modified-method-name要素とejbstoreメソッドの両方を作成する必要があるからです。

WebLogic Serverはデフォルトで、各トランザクションが正常に完了(コミット)したときにejbStore()メソッドを呼び出します。ejbStore()は、EJBの永続フィールドが実際に更新されたかどうかに関係なくコミット時に呼び出され、その結果としてDBMSが更新されます。WebLogic Serverは、ejbStore()が不必要に呼び出されてパフォーマンスが低下する場合に備えてis-modified-method-name要素を提供します。

is-modified-method-nameを使用するには、EJBプロバイダは最初に、永続データが更新されたときにWebLogic Serverに「合図」を送るEJBメソッドを開発する必要があります。このメソッドは、EJBフィールドが1つも更新されなかった場合は「false」を、フィールドが更新された場合は「true」を返さなければなりません。

EJBプロバイダまたはEJBデプロイメント記述子では、is-modified-method-name要素の値を使用してこのメソッドの名前を識別します。WebLogic Serverはトランザクションがコミットされたときに指定されたメソッドを呼び出し、そのメソッドが「true」を返す場合にのみejbStore()を呼び出します。この要素の詳細については、「is-modified-method-name」を参照してください。

5.1のweblogic-ejb-jar.xmlデプロイメント記述子ファイルの構造

WebLogic Server 5.1のweblogic-ejb-jar.xmlファイルは、EJB 1.1 Beanで使用するEJB文書型定義(DTD)を定義します。これらのデプロイメント記述子要素はWebLogic固有です。WebLogic Server 5.1のweblogic-ejb-jar.xmlの最上位要素は次のとおりです。

- description

- weblogic-version

- weblogic-enterprise-bean

- ejb-name

- caching-descriptor

- persistence-descriptor

- clustering-descriptor

- transaction-descriptor

- reference-descriptor

- jndi-name

- transaction-isolation

- security-role-assignment

5.1のweblogic-ejb-jar.xmlデプロイメント記述子要素

以下の節では、WebLogic Server 5.1のweblogic-ejb-jar.xmlデプロイメント記述子の要素について説明します。

caching-descriptor

caching-descriptor要素は、WebLogic Serverキャッシュ内のEJBの数、およびEJBに対してパッシブ化が行われるか、またはEJBがプールされるまでの時間の長さに影響します。この要素は子要素を含む全体が省略可能です。要素が定義されていない場合はデフォルト値が使用されます。

以下のcaching-descriptor要素の例は、この節で説明するキャッシング要素を示しています。

<caching-descriptor>
<max-beans-in-free-pool>500</max-beans-in-free-pool>
<initial-beans-in-free-pool>50</initial-beans-in-free-pool>
<max-beans-in-cache>1000</max-beans-in-cache>
<idle-timeout-seconds>20</idle-timeout-seconds>
<cache-strategy>Read-Write</cache-strategy>
<read-timeout-seconds>0</read-timeout-seconds>
</caching-descriptor>

max-beans-in-free-pool

注意:

この要素は、ステートレス・セッションEJBに対してのみ有効です。

WebLogic Serverでは、すべてのBeanクラスに対してEJBのフリー・プールが維持管理されています。この省略可能な要素では、フリー・プールのサイズを定義します。デフォルトでは、max-beans-in-free-poolは無制限です。フリー・プール内のBeanの最大数はメモリーによってのみ制限されます。

initial-beans-in-free-pool

注意:

この要素は、ステートレス・セッションEJBに対してのみ有効です。

initial-bean-in-free-poolの値を指定すると、WebLogic Serverでは、起動時に、指定した数のBeanインスタンスがフリー・プールに生成されます。この方法でBeanインスタンスをフリー・プールに格納しておくと、要求が来てから新しいインスタンスを生成せずにBeanに対する初期要求が可能になるため、EJBの初期応答時間が短縮されます。

initial-bean-in-free-poolが定義されていない場合のデフォルト値は0です。

max-beans-in-cache

注意:

この要素は、ステートフル・セッションEJBおよびエンティティEJBに対してのみ有効です。

この要素では、メモリーの許容範囲内で、このクラスのオブジェクトの最大数を指定します。max-beans-in-cacheの値に達すると、WebLogic Serverでは、最近クライアントに使用されていないEJBの一部に対してパッシブ化が行われます。また、max-beans-in-cacheの値は、EJBをWebLogic Serverのキャッシュからいつ削除するかにも影響を与えます。

max-beans-in-cacheのデフォルト値は100です。

idle-timeout-seconds

idle-timeout-secondsでは、ステートフルEJBがキャッシュに保持される最長時間を定義します。この時間を過ぎると、キャッシュ内のBeanの数がmax-beans-in-cacheで指定した値を超えている場合、WebLogic ServerではBeanインスタンスが削除されます。

定義されていない場合、idle-timeout-secondsのデフォルト値は600です。

cache-strategy

cache-strategy要素には、以下のいずれかを指定できます。

- Read-Write

- Read-Only

デフォルト値はRead-Writeです。

read-timeout-seconds

read-timeout-seconds要素では、Read-OnlyエンティティBeanでの各ejbLoad()呼出しの間隔を秒数で指定します。デフォルトでは、read-timeout-secondsは600秒に設定されています。この値を0に設定すると、WebLogic Serverでは、そのBeanがキャッシュされた場合にのみ、ejbLoadが呼び出されます。

persistence-descriptor

persistence-descriptor要素では、エンティティEJBに対する永続性オプションを指定します。以下に、persistence-descriptor要素に含まれるすべての要素を示します。

<persistence-descriptor>
<is-modified-method-name>. . .</is-modified-method-name>
<delay-updates-until-end-of-tx>. . .</delay-updates-until-end-of-tx>
<persistence-type>
<type-identifier>. . .</type-identifier>
<type-version>. . .</type-version>
<type-storage>. . .</type-storage>
</persistence-type>
<db-is-shared>. . .</db-is-shared>
<stateful-session-persistent-store-dir>
. . .
</stateful-session-persistent-store-dir>
<persistence-use>. . .</persistence-use>
</persistence-descriptor>

is-modified-method-name

is-modified-method-nameでは、EJBの保存時にWebLogic Serverによって呼び出されるメソッドを指定します。指定したメソッドはブール値を返す必要があります。メソッドを指定しない場合、WebLogic Serverでは、EJBは常に変更されていると見なされて保存されます。

メソッドを指定して適切な値を設定すると、パフォーマンスが向上する場合があります。ただし、メソッドの戻り値にエラーがあると、データに矛盾が発生する場合があります。

delay-updates-until-end-of-tx

トランザクションの完了時にトランザクションですべてのBeanの永続ストレージを更新するには、このプロパティをtrue (デフォルト)に設定します。通常、これによって不要な更新を防ぐことができるため、パフォーマンスが向上します。ただし、データベース・トランザクション内のデータベース更新の順序は保持されません。

データベースがアイソレーション・レベルとしてTransactionReadCommittedUncommittedを使用している場合は、進行中のトランザクションに関する中間結果を他のデータベースのユーザーに表示することもできます。この場合、delay-updates-until-end-of-txをfalseに設定して、各メソッド呼出しの完了時にBeanの永続ストレージを更新するように指定します。

注意:

delay-updates-until-end-of-txをfalseに設定しても、各メソッド呼出しの後にデータベース更新が「コミットされた」状態になるわけではありません。更新はデータベースに送信されるのみです。更新は、トランザクションの完了時にのみデータベースにコミットまたはロールバックされます。

persistence-type

persistence-typeでは、EJBで使用可能な永続性サービスを定義します。複数の永続性サービスを持つEJBをテストするために、weblogic-ejb-jar.xmlで複数のpersistence-typeエントリを定義できます。デプロイメントでは、persistence-useで定義した永続性タイプのみが実際に使用されます。

persistence-typeには、サービスのプロパティを定義する要素が含まれます。

- type-identifierでは、指定した永続性タイプを示すテキストが含まれます。たとえば、WebLogic Server RDBMSベースの永続性ではWebLogic_CMP_RDBMSという識別子が使用されます。

- type-versionでは、指定した永続性タイプのバージョンを指定します。

注意:

指定したバージョンは、WebLogic ServerのRDBMSの永続性のバージョンと正確に一致している必要があります。バージョンが一致していないと、次のエラーが発生します。

weblogic.ejb.persistence.PersistenceSetupException: Error initializing the CMP Persistence Type for your bean: No installed Persistence Type matches the signature of (identifier 'Weblogic_CMP_RDBMS', version 'version_number').

- type-storageでは、この永続性タイプのデータを格納するファイルの絶対パスを定義します。パスは、EJBのデプロイメントJARファイルまたはデプロイメント・ディレクトリの最上位を基準にしたファイルの場所を指定する必要があります。
WebLogic Server RDBMSベースの永続性では通常、Beanの永続性データを格納するのにweblogic-cmp-jar.xmlというXMLファイルを使用します。このファイルは、JARファイルのMETA-INFサブディレクトリにあります。

以下は、WebLogic Server RDBMSの永続性について適切な値が指定されているpersistence-type要素の例です。

<persistence-type>
<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
<type-version>5.1.0</type-version>
<type-storage>META-INF\weblogic-cmp-jar.xml</type-storage>
</persistence-type>

db-is-shared

db-is-shared要素はエンティティBeanに対してのみ有効です。true (デフォルト値)に設定すると、WebLogic Serverでは、EJBデータがトランザクション間で変更されると見なされ、各トランザクションの開始時にデータが再ロードされます。falseに設定すると、WebLogic Serverでは、永続ストレージのEJBデータに排他的にアクセスすると見なされます。

stateful-session-persistent-store-dir

stateful-session-persistent-store-dir要素では、WebLogic Serverで、パッシブ化が行われたステートフル・セッションBeanインスタンスの状態が格納されるファイル・システム・ディレクトリを指定します。

persistence-use

persistence-useプロパティはpersistence-typeとほぼ同じですが、このプロパティはデプロイ中に実際に使用される永続性サービスを定義します。persistence-useでは、persistence-typeで定義されているtype-identifier要素とtype-version要素を使用してサービスを指定します。

たとえば、persistence-typeで定義されているWebLogic Server RDBMSベースの永続性サービスを使用して実際にEJBをデプロイする場合、persistence-use要素は次のようになります。

<persistence-use>
<type-identifier>WebLogic_CMP_RDBMS</type-identifier>
<type-version>5.1.0</type-version>
</persistence-use>

clustering-descriptor

clustering-descriptor要素では、WebLogic ServerクラスタにデプロイされたEJBのレプリケーション・プロパティと動作を定義します。clustering-descriptor要素とその各子要素は省略可能であり、単一サーバー・システムには適用できません。

以下に、clustering-descriptor要素に含まれるすべての要素を示します。

<clustering-descriptor>
<home-is-clusterable>. . .</home-is-clusterable>
<home-load-algorithm>. . .</home-load-algorithm>
<home-call-router-class-name>. . .</home-call-router-class-name>
<stateless-bean-is-clusterable>. . .</stateless-bean-is-clusterable>
<stateless-bean-load-algorithm>. . .</stateless-bean-load-algorithm>
<stateless-bean-call-router-class-name>. . .
</stateless-bean-call-router-class-name>
<stateless-bean-methods-are-idempotent>. . .
</stateless-bean-methods-are-idempotent>
</clustering-descriptor>

home-is-clusterable

この要素は、trueまたはfalseに設定できます。home-is-clusterableが「true」の場合、クラスタ内の複数のWebLogic ServerからEJBをデプロイできます。ホーム・スタブの呼出しは、Beanがデプロイされるサーバー間で負荷が分散されます。Beanのホスト・サーバーにアクセスできなかった場合、呼出しは、Beanを提供する他のサーバーに自動的にフェイルオーバーします。

home-load-algorithm

home-load-algorithmでは、EJBホームのレプリカ間でのロード・バランシングに使用するアルゴリズムを指定します。このプロパティを定義しない場合、WebLogic Serverはサーバー・プロパティ、weblogic.cluster.defaultLoadAlgorithmで指定されたアルゴリズムを使用します。

home-load-algorithmは以下のいずれかの値に定義できます。

- round-robin - Beanのホスト・サーバー間で順番にロード・バランシングを実行します。

- random - Beanのホスト・サーバー間でEJBホームのレプリカがランダムにデプロイされます。

- weight-based - ホスト・サーバーの現在の負荷に従って、EJBホームのレプリカをデプロイするサーバーが決まります。

home-call-router-class-name

home-call-router-class-nameでは、Beanメソッド呼出しのルーティングに使用するカスタム・クラスを指定します。このクラスはweblogic.rmi.extensions.CallRouter()を実装する必要があります。指定すると、このクラスのインスタンスは各メソッド呼出しの前に呼び出されます。ルーター・クラスでは、メソッドのパラメータを基に、ルーティングするサーバーを選択できます。このクラスは、サーバー名を返すか、または現在のロード・アルゴリズムがサーバーを選択する必要があることを示すnullを返します。

stateless-bean-is-clusterable

このプロパティはhome-is-clusterableに似ていますが、ステートレス・セッションEJBにのみ適用できます。

stateless-bean-load-algorithm

このプロパティはhome-load-algorithmに似ていますが、ステートレス・セッションEJBにのみ適用できます。

stateless-bean-call-router-class-name

このプロパティはhome-call-router-class-nameに似ていますが、ステートレス・セッションEJBにのみ適用できます。

stateless-bean-methods-are-idempotent

この要素は、trueまたはfalseに設定できます。同一引数での同一メソッドの多重呼出しが1回だけの呼出しとまったく同じになるように設計されているBeanに対してのみ、stateless-bean-methods-are-idempotentをtrueに設定します。これによって、フェイルオーバー・ハンドラは、失敗した呼出しが失敗したサーバーで実際に完了していたかどうかがわからなくても失敗した呼出しを再試行できます。このプロパティをtrueに設定すると、Beanを提供する他のサーバーが使用できるようになっている限り、Beanスタブは障害から自動的に回復できます。

注意:

このプロパティは、ステートレス・セッションEJBにのみ適用できます。

transaction-descriptor

transaction-descriptor要素には、WebLogic Serverのトランザクション動作を定義する要素があります。現在、この要素の子要素は1つだけです。

<transaction-descriptor>
<trans-timeout-seconds>20</trans-timeout-seconds>
</transaction-descriptor>

trans-timeout-seconds

trans-timeout-seconds要素は、EJBのコンテナで初期化されたトランザクションの最長継続時間を指定します。トランザクションの継続時間がtrans-timeout-secondsの値を超えると、WebLogic Serverによってトランザクションがロールバックされます。

trans-timeout-secondsに値を指定しなかった場合、コンテナで初期化されたトランザクションはデフォルトで300秒後にタイムアウトになります。

reference-descriptor

reference-descriptor要素では、ejb-jar.xmlファイル内の参照が、WebLogic Serverで実際に使用可能なリソース・ファクトリとEJBのJNDI名にマップされます。

reference-descriptor要素には、リソース・ファクトリ参照およびEJB参照を定義するために1つまたは複数の要素が追加されます。次の例に、これらの要素の構造を示します。

<reference-descriptor>
<resource-description>
<res-ref-name>. . .</res-ref-name>
<jndi-name>. . .</jndi-name>
</resource-description>
<ejb-reference-description>
<ejb-ref-name>. . .</ejb-ref-name>
<jndi-name>. . .</jndi-name>
</ejb-reference-description>
</reference-descriptor>

resource-description

以下の要素で、各resource-descriptionを定義します。

- res-ref-nameではリソース参照名を指定します。これは、EJBプロバイダによってejb-jar.xmlデプロイメント記述子ファイル内に記載される参照です。

- jndi-nameでは、WebLogic Serverに用意されている実際のリソース・ファクトリのJNDI名を指定します。

ejb-reference-description

以下の要素で、各ejb-reference-descriptionを定義します。

- ejb-ref-nameはEJB参照名を指定します。これは、EJBプロバイダによってejb-jar.xmlデプロイメント記述子ファイル内に記載される参照です。

- jndi-nameでは、WebLogic Serverに用意されている実際のEJBのJNDI名を指定します。

enable-call-by-reference

デフォルトでは、同じEARから呼び出されたEJBメソッドは引数を参照で渡します。パラメータはコピーされないので、これによってメソッド呼出しのパフォーマンスが向上します。

enable-call-by-referenceをfalseに設定すると、EJB 1.1の仕様に従ってEJBメソッドへのパラメータがコピーされ(値で渡され)ます。EJBがリモートで(同じアプリケーション以外から)呼び出される場合は、常に値で渡す必要があります。

jndi-name

jndi-name要素は、Bean、リソース、または参照のJNDI名を指定します。

transaction-isolation

transaction-isolation要素では、EJBメソッドに対するトランザクションのアイソレーション・レベルを指定します。この要素は、EJBメソッドの範囲に適用される1つまたは複数のisolation-level要素で構成されます。例:

<transaction-isolation>
<isolation-level>Serializable</isolation-level>
<method>
<description>...</description>
<ejb-name>...</ejb-name>
<method-intf>...</method-intf>
<method-name>...</method-name>
<method-params>...</method-params>
</method>
</transaction-isolation>

以降の節では、transaction-isolation内の各要素について説明します。

isolation-level

transaction-isolationは、EJBのメソッド・レベルのトランザクション・アイソレーション設定を定義します。有効な値は以下のとおりです。

- TransactionSerializable - このトランザクションを同時に複数回実行すると、トランザクションを順番に複数回実行することと同じことになります。

注意:

Oracleデータベースの場合は、TransactionSerializableアイソレーション・レベルの代わりにTransactionReadCommittedForUpdateアイソレーション・レベルを使用することをお薦めします。Oracleデータベースは、TransactionSerializableアイソレーション・レベルではデータの読取りをロックしないためです。また、TransactionSerializableアイソレーション・レベルでは、Oracleデータベースに対する現在のトランザクションが、Oracle例外ORA-08177「このトランザクションのアクセスをシリアル化できません」を送出せずに続行することが可能です。TransactionReadCommittedForUpdateアイソレーション・レベルの詳細については、「Oracleのみのアイソレーション・レベル」を参照してください。

- TransactionReadCommitted - コミットした他のトランザクションの更新のみをトランザクションで表示できます。

- TransactionReadUncommitted - コミットしていない他のトランザクションの更新をトランザクションで表示できます。

- TransactionRepeatableRead - トランザクションでデータの一部を読み取ると、そのデータが他のトランザクションで変更されても、最初の読取り時と同じ値が返されます。

Oracleのみのアイソレーション・レベル

以下の追加の値は、Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされています。

- TransactionReadCommittedForUpdate - Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされます。この値を使用すると、アイソレーション・レベルはTransactionReadCommittedに設定され、トランザクションの間、メソッドで実行されるSQL SELECT文はすべてFOR UPDATEが付加されて実行されます。この結果、選択された行が更新用にロックされます。Oracleで問合せの影響を受ける行をすぐにロックできない場合は、それらの行が解放されるまで待ちます。この状況は、トランザクションでCOMMITまたはROLLBACKが実行されるまで続きます。
このアイソレーション・レベルを使用すると、次のエラーを防止できます。

java.sql.SQLException: ORA-08177: can't serialize access for this transaction

このエラーは、OracleデータベースでTransactionSerializableアイソレーション・レベルを使用したときに発生することがあります。

注意:

Oracleデータベースの場合は、TransactionSerializableアイソレーション・レベルの代わりにこのアイソレーション・レベル(TransactionReadCommittedForUpdate)を使用することをお薦めします。Oracleデータベースは、TransactionSerializableアイソレーション・レベルではデータの読取りをロックしないためです。

- TransactionReadCommittedNoWait - Oracleデータベース、およびコンテナ管理による永続性(CMP) EJBでのみサポートされます。
この値を使用すると、アイソレーション・レベルはTransactionReadCommittedに設定され、トランザクションの間、メソッドで実行されるSQL SELECT文はすべてFOR UPDATE NO WAITが付加されて実行されます。この結果、選択された行が更新用にロックされます。

TransactionReadCommittedForUpdate設定とは違って、必要なときロックがすぐに達成されない場合、TransactionReadCommittedForUpdateNoWaitではOracle DBMSが NOT WAITになります。このため、影響を受けるSELECT問合せは失敗し、コンテナから例外が送出されます。

異なるアイソレーション・レベルのサポートの詳細については、各データベースのマニュアルを参照してください。

method

method要素は、アイソレーション・レベルを適用するEJBメソッドを定義します。methodでは、以下の要素を使用してメソッドの範囲を定義します。

- descriptionは、メソッドを説明する省略可能な要素。

- ejb-nameでは、WebLogic Serverによってアイソレーション・レベル・プロパティが適用されるEJBを指定します。

- method-intfは、指定したメソッドがEJBのホームまたはリモートのいずれのインタフェースに存在するかを示す、省略可能な要素。この要素の値は、「Home」または「Remote」でなければなりません。method-intfを指定しない場合は、どちらのインタフェースにあるメソッドにもアイソレーションを適用できます。

- method-nameでは、EJBメソッドの名前、またはすべてのEJBメソッドを示すアスタリスク(*)を指定します。

- method-paramsは、各メソッドのパラメータのJavaクラスのタイプを示す、省略可能な要素。各パラメータのタイプは、method-params要素内のmethod-param要素を使用して順番に示す必要があります。

たとえば、次のmethod要素は、「AccountBean」EJB内のすべてのメソッドを示しています。

<method>
<ejb-name>AccountBean</ejb-name>
<method-name>*</method-name>
</method>

次のmethod要素は、「AccountBean」のリモート・インタフェース内のすべてのメソッドを示しています。

<method>
<ejb-name>AccountBean</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>

security-role-assignment

security-role-assignment要素は、ejb-jar.xmlファイル内のアプリケーション・ロールを、WebLogic Serverで使用可能なセキュリティ・プリンシパル名にマップします。

security-role-assignmentには、以下の要素を1つまたは複数、指定できます。

- role-nameは、EJBプロバイダがejb-jar.xmlデプロイメント・ファイルに指定したアプリケーションのロール名。

- principal-nameでは、実際のWebLogic Serverプリンシパルの名前を指定します。

1.1のweblogic-cmp-jar.xmlデプロイメント記述子ファイルの構造

weblogic-cmp-jar.xmlでは、WebLogic Server RDBMSベースの永続性サービスを使用するエンティティEJBのデプロイメント要素を定義します。

WebLogic Server 1.1のweblogic-cmp-jar.xmlの最上位要素は、weblogic-enterprise-bean要素で構成されます。

description
weblogic-version
<weblogic-enterprise-bean>
<pool-name>finance_pool</pool-name>
<schema-name>FINANCE_APP</schema-name>
<table-name>ACCOUNT</table-name>
<attribute-map>
<object-link>
<bean-field>accountID</bean-field>
<dbms-column>ACCOUNT_NUMBER</dbms-column>
</object-link>
<object-link>
<bean-field>balance</bean-field>
<dbms-column>BALANCE</dbms-column>
</object-link>
</attribute-map>
<finder-list>
<finder>
<method-name>findBigAccounts</method-name>
<method-params>
<method-param>double</method-param>
</method-params>
<finder-query><![CDATA[(> balance $0)]]></finder-query>
<finder-expression>. . .</finder-expression>
</finder>
</finder-list>
</weblogic-enterprise-bean>

1.1のweblogic-cmp-jar.xmlデプロイメント記述子要素

ここでは、weblogic-cmp-jar.xmlデプロイメント記述子の要素について説明します。

RDBMS定義要素

この節ではRDBMS定義要素について説明します。

enable-tuned-updates

enable-tuned-updatesは、ejbStoreが呼び出された場合に、EJBコンテナがコンテナ管理フィールドの変更の有無を自動的に判定し、変更されたフィールドだけをデータベースに書き込むように指定します。

pool-name

pool-nameでは、EJBのデータベース接続に使用するWebLogic Server接続プールの名前を指定します。

schema-name

schema-nameでは、データベースに置かれるソース表のスキーマを指定します。この要素は、EJBの接続プールで定義されたユーザーに対してデフォルト・スキーマではないスキーマを使用する場合にのみ必須です。

注意:

多くのSQL実装では大文字小文字が無視されますが、このフィールドは大文字小文字が区別されます。

table-name

table-nameでは、データベース内のソース表を指定します。この要素はすべての場合に必須です。

注意:

EJBの接続プールで定義されたユーザーには、指定された表に対する読み書き権限が必要です。ただし、スキーマ変更権限は必ずしも必要ありません。多くのSQL実装では大文字小文字が無視されますが、このフィールドは大文字小文字が区別されます。

EJBフィールド・マッピング要素

この節ではEJBフィールド・マッピング要素について説明します。

attribute-map

attribute-map要素では、EJBインスタンスの単一フィールドがデータベース表内の特定の列にリンクされます。attribute-mapには、WebLogic Server RDBMSベースの永続性を使用するEJBのフィールドごとに1つのエントリが必要です。

object-link

各attribute-mapエントリは、データベース内の列とEJBインスタンス内のフィールドとのリンクを表すobject-link要素から構成されます。

bean-field

bean-fieldでは、データベースからの移行が必要なEJBインスタンスのフィールドを指定します。この要素では大文字小文字が区別されます。この要素は、Beanインスタンスのフィールド名に正確に一致している必要があります。

また、このタグで参照されるフィールドは、Beanのejb-jar.xmlファイル内に定義されているcmp-field要素も持っている必要があります。

dbms-column

dbms-columnでは、EJBフィールドがマップされるデータベース列を指定します。多くのデータベースでは大文字小文字が無視されますが、このフィールドでは大文字小文字が区別されます。

注意:

WebLogic Serverでは、引用符で囲まれたRDBMSキーワードはdbms-columnのエントリとしてはサポートされていません。たとえば、基底のデータ・ストアで「create」や「select」が予約語になっている場合、それらを列名にして属性マップを作成することができません。

ファインダ要素

この節ではファインダ要素について説明します。

finder-list

finder-list要素では、Beanの集合を見つけるために生成されるすべてのファインダの集合を定義します。

findByPrimaryKeyの場合を除いて、finder-listには、ホーム・インタフェース内に定義されているファインダ・メソッドにごとに1つのエントリが必要です。findByPrimaryKeyにエントリが指定されなくても、コンパイル時に生成されます。

注意:

findByPrimaryKeyに対してエントリを指定すると、WebLogic Serverでは、正当性が検証されずにそのエントリが使用されます。ほとんどの場合では、findByPrimaryKeyに対するエントリを定義せずに、デフォルトで生成されるメソッドを受け入れることをお薦めします。

finder

finder要素では、ホーム・インタフェース内に定義されるファインダ・メソッドを記述します。finder要素に含まれる要素によって、WebLogic Serverでは、ホーム・インタフェース内に記述されているメソッドが識別され、必要なデータベース操作を実行できるようになります。

method-name

method-nameでは、ホーム・インタフェース内のファインダ・メソッドの名前を定義します。このタグには、メソッドの正確な名前を指定する必要があります。

method-params

method-params要素では、method-nameで指定されるファインダ・メソッドに対するパラメータのリストを定義します。

注意:

WebLogic Serverでは、このリストはEJBのホーム・インタフェース内のファインダ・メソッドのパラメータ・タイプと比較されます。パラメータ・リストの順序とパラメータ・タイプは、ホーム・インタフェースで定義されている順序とパラメータ・タイプに正確に一致している必要があります。

method-param

method-paramでは、パラメータ・タイプの完全修飾名を定義します。このタイプ名はjava.lang.Classオブジェクトで評価され、その結果のオブジェクトはEJBのファインダ・メソッド内の各パラメータに正確に一致している必要があります。

「double」や「int」のようなプリミティブ名を使用してプリミティブ・パラメータを指定できます。method-param要素内に非プリミティブなデータ型を使用する場合には、完全修飾名を指定する必要があります。たとえば、Timestampではなくjava.sql.Timestampを使用します。完全修飾名を使用しないと、デプロイメント・ユニットのコンパイル時にappcでエラー・メッセージが生成されます。

finder-query

finder-queryでは、このファインダ用にデータベースから値を取り出す場合に使用するWebLogic問合せ言語(WLQL)文字列を指定します。

注意:

finder-query値のテキストは、常に、XML CDATA属性を使用して定義してください。CDATAを使用すると、WLQL文字列中に特殊文字が入っていても、ファインダをコンパイルしたときにエラーが発生しないようになります。

finder-expression

finder-expressionでは、このファインダ用のデータベース問合せ中で変数として使用されるJava言語の式を指定します。

WebLogic Server EJBコンテナの今後のバージョンでは、EJB QL問合せ言語が使用される予定です。この問合せ言語はEJB 2.0仕様(http://java.sun.com/products/ejb/docs.html)では必須です。EJB QLでは、埋め込まれたJava式はサポートされていません。そのため、今後のEJBコンテナに簡単にアップグレードできるよう、WLQLでもJava式を埋め込まずにエンティティEJBファインダを作成してください。

G EJB問合せ言語(EJB-QL)とWebLogic Server

EJB問合せ言語(EJB QL)は、コンテナ管理による永続性を利用する2.0エンティティEJBのファインダ・メソッドを定義する移植可能な問合せ言語です。この問合せ言語はSQLに似ており、問合せ内の1つまたは複数のエンティティEJBオブジェクトまたはフィールドを選択する場合に使用します。findByPrimaryKey()以外のすべてのファインダ・メソッドの問合せをデプロイメント記述子で作成できます。findByPrimaryKeyは、EJBコンテナで自動的に処理されます。

以下の節では、EJB QLについて説明します。

- EJB 2.x BeanについてのEJB QLの要件

- EJB QLのEJB 2.x WebLogic QL拡張機能の使い方

- Queryインタフェースのプロパティ・ベースのメソッド

- WLQLからEJB QLへの移行

- 暗黙的クロス積に関して確認済みの問題

- EJB QLエラー報告機能

EJB 2.x BeanについてのEJB QLの要件

デプロイメント記述子では、EJB QL問合せ文字列を使用して、EJB 2.xのエンティティBeanの各ファインダ問合せを定義する必要があります。WebLogic Query Language (WLQL)をEJB 2.xエンティティBeanで使用することはできません。WLQLは、EJB 1.1のコンテナ管理による永続性で使用することを想定しています。WLQLおよびEJB 1.1のコンテナ管理による永続性の詳細については、「EJB 1.1 CMP用のWebLogic問合せ言語(WLQL)の使用」を参照してください。

EJB QLのEJB 2.x WebLogic QL拡張機能の使い方

WebLogic Serverには、標準のEJB QLの拡張であり、SQLに似たWebLogic QLという言語が用意されています。queryは、weblogic-ql要素を使用して、weblogic-cmp-jar.xmlデプロイメント記述子に定義します。

ejb-jar.xmlファイルには、weblogic-cmp-jar.xmlファイルのweblogic-ql要素に対応する問合せ要素が必要です。ただし、weblogic-cmp-jar.xmlの問合せ要素の値は、ejb-jar.xmlの問合せ要素の値をオーバーライドします。

以下のトピックでは、EJB 2.x QLのWebLogic QL拡張機能を使用する際のガイドラインを示します。

- upperおよびlower関数

- ORDER BYの使用

- サブ問合せの使用

- 算術関数の使用

- 集約関数の使用

- ResultSetを返す問合せの使用

- OracleのSELECT HINTの使用

- 問合せ内エラーのビジュアルなインジケータ

- 1回のコンパイル後に複数のエラー報告

upperおよびlower関数

EJB WebLogic QL upperおよびlower拡張機能は、大文字と小文字の違いがある以外は検索式の文字と一致する結果をファインダ・メソッドが返せるように、引数の大文字と小文字を変換します。大文字と小文字の変換は文字列を照合するための一時的なものなので、データベース内に永続しません。基底のデータベースも、upperおよびlower関数をサポートしている必要があります。

upper

upper関数は、文字列の照合の前に、引数内の文字をすべて大文字に変換します。問合せ内で大文字で表された式でupper関数を使用すると、大文字であるか小文字であるかに関係なく、式に一致するすべての項目が返されます。例:

select name from products where upper(name)='DETERGENT';

lower

lower関数は、文字列の照合の前に、引数内の文字をすべて小文字に変換します。問合せ内で小文字で表された式でlower関数を使用すると、大文字であるか小文字であるかに関係なく、式に一致するすべての項目が返されます。

select type from products where lower(name)='domestic';

ORDER BYの使用

EJB QLのORDER BY句は、Finderメソッドと連携して、選択におけるCMPフィールドの選択順序を指定するキーワードです。

例G-1 idによる順序付けを指定するORDER BY

ORDER BY
SELECT OBJECT(A) from A for Account.Bean
ORDER BY A.id

次のように、複数のフィールドに対してORDER BYに昇順[ASC]か降順[DESC]かを指定することもできます。順序を指定しない場合、ORDER BYはデフォルトとして昇順を使用します。

例G-2 idによる順序付けを指定するORDER BY (昇順/降順指定)

ORDER BY <field> [ASC|DESC], <field> [ASC|DESC]
SELECT OBJECT(A) from A for Account.Bean, OBJECT(B) from B for Account.Bean
ORDER BY A.id ASC; B.salary DESC

サブ問合せの使用

WebLogic Serverでは、EJB QLのサブ問合せの次のような機能をサポートしています。

- サブ問合せの戻り値の型

- 単一のcmp-field

- 集約関数

- 単純主キーを持つBean

- 比較オペランドとしてのサブ問合せ

- 相関サブ問合せ

- 非相関サブ問合せ

- サブ問合せでのDISTINCT句

WebLogic QLとサブ問合せの関係は、SQL問合せとサブ問合せの関係に似ています。WebLogic QLのサブ問合せは、外部WebLogic QL問合せのWHERE句内で使用してください。若干の例外はありますが、サブ問合せの構文はWebLogic QL問合せのものとほぼ同じです。

WebLogic QLを指定するには、「EJB QLのEJB 2.x WebLogic QL拡張機能の使い方」を参照してください。この手順に従って、SELECT文で次の例のようにサブ問合せを指定します。

次の問合せは、成績順位をもとに平均以上の生徒を選択しています。

SELECT OBJECT(s) FROM studentBean AS s WHERE s.grade > (SELECT AVG(s2.grade) FROM StudentBean AS s2)

注意:

上記問合せの例で、サブ問合せ「SELECT AVG(s2.grade) FROM StudentBean AS s2」の構文はEJB QL問合せと同じです。

サブ問合せをネストすることもできます。この深さは、基底のデータベースのネストの許容範囲によって制限されます。

WebLogic QL問合せでは、主問合せとそのすべてのサブ問合せのFROM句で宣言される識別子がユニークでなければなりません。これはつまり、サブ問合せの内側で前にローカルに宣言した識別子をそのサブ問合せで再び宣言することはできないということです。

たとえば、次の例は無効です。EmployeeBeanが問合せとサブ問合せの双方でempとして宣言されています。

SELECT OBJECT(emp)
FROM EmployeeBean As emp
WHERE emp.salary=(SELECT MAX(emp.salary) FROM
EmployeeBean AS emp WHERE employee.state=MA)

この問合せは次のように記述すべきです。

SELECT OBJECT(emp)
FROM EmployeeBean As emp
WHERE emp.salary=(SELECT MAX(emp2.salary) FROM
EmployeeBean AS emp2 WHERE emp2.state=MA)

この例では、サブ問合せのEmployee Beanが主問合せのEmployee Beanと異なる識別子になるように正しく宣言されています。

サブ問合せの戻り値の型

WebLogic QLサブ問合せの戻り値の型は、次のような各種の型のいずれかになります。

単一のcmp-field型のサブ問合せ

WebLogic Serverは、cmp-field.で構成されている戻り値型をサポートしています。サブ問合せから返される結果は、1つの値または値の集合から構成されている可能性があります。cmp-field型の値を返すサブ問合せの例を次に示します。

SELECT emp.salary FROM EmployeeBean AS emp WHERE emp.dept = 'finance'

このサブ問合せは、財務部門の従業員の給料すべてを選択しています。

集約関数

WebLogic Serverは、あるcmp-field に対する集約から構成されている戻り値型をサポートしています。集約は必ず1つの値から構成されるので、ここで返される値も常に1つの値になります。cmp-fieldの集約(MAX)の型の値を返すサブ問合せの例を次に示します。

SELECT MAX(emp.salary) FROM EmployeeBean AS emp WHERE emp.state=MA

このサブ問合せは、マサチューセッツで最高額の給料を1つだけ選択しています。

集約関数の詳細については、「集約関数の使用」を参照してください。

単純主キーを持つBean

WebLogic Serverは、単純主キーを持つ1つのcmp-beanで構成されている戻り値型をサポートしています。

単純主キーを持つBean型の値を返すサブ問合せの例を次に示します。

SELECT OBJECT(emp) FROM EMployeeBean As emp WHERE emp.department.budget>1,000,000

このサブ問合せは、$1,000,000以上の予算がある部門の全従業員のリストを返します。

注意:

複合主キーを持つBeanはサポートされていません。複合主キーを持つBeanをサブ問合せの戻り値の型として指定しようとしても、問合せをコンパイルする時点で失敗に終わります。

比較オペランドとしてのサブ問合せ

サブ問合せを比較演算子および算術演算子のオペランドとして使用します。WebLogic QLでは、以下の演算子のオペランドとしてサブ問合せをサポートしています。

- 比較演算子([NOT]IN, [NOT]EXISTS)

および

- 算術演算子(<、>、<=、>=、=、および該当部分すべてを表す<>)

[NOT]IN

[NOT]IN比較演算子は、左側のオペランドが右側のサブ問合せオペランドのメンバーかどうか検査します。

サブ問合せがNOT INオペレータの右側のオペランドとなっている例を次に示します。

SELECT OBJECT(item)
FROM ItemBean AS item
WHERE item.itemId NOT IN
(SELECT oItem2.item.itemID
FROM OrderBean AS orders2, IN(orders2.orderItems)oIttem2

サブ問合せは、すべての注文から品目すべてを選択しています。

主問合せのNOT IN演算子では、サブ問合せによって返された集合の中に含まれていない品目すべてを選択しています。したがって、最終的に、主問合せが未注文の品目すべてを選択します。

[NOT]EXISTS

[NOT]EXISTS比較演算子は、サブ問合せオペランドによって返された集合が空かどうか検査します。

サブ問合せがNOT EXISTSオペランドのオペランドとなっている例を次に示します。

SELECT (cust) FROM CustomerBean AS cust
WHERE NOT EXISTS
(SELECT order.cust_num FROM OrderBean AS order
WHERE cust.num=order_num)

これは、相関サブ問合せを用いた問合せの一例となっています。詳細については「相関サブ問合せと非相関サブ問合せ」を参照してください。次の問合せは、注文していない顧客をすべて返します。

SELECT (cust) FROM CustomerBean AS cust
WHERE cust.num NOT IN
(SELECT order.cust_num FROM OrderBean AS order
WHERE cust.num=order_num)

算術演算子

右側のサブ問合せオペランドが1つの値を返す場合、比較の算術演算子を使用できます。右側のサブ問合せが複数の値を返す場合には、サブ問合せの前にANYまたはALL修飾子が必要です。

「=」演算子を使用したサブ問合せの例を次に示します。

SELECT OBJECT (order)
FROM OrderBean AS order, IN(order.orderItems)oItem
WHERE oItem.quantityOrdered =
(SELECT MAX (subOItem.quantityOrdered)
FROM Order ItemBean AS subOItem
WHERE subOItem,item itemID = ?1)
AND oItem.item.itemId = ?1

特定のitemIdに対し、サブ問合せはその品目の注文の最高数を返します。サブ問合せが返している集合が、「=」演算子に必要な1つの値となっている点に注意してください。

メインの問合せの「=」演算子では、これと同じitemIdに対し、どの注文のOrderItem.quantityOrderedが副問合せから戻された注文の最高数に等しいかを調べています。最終的に、特定の品目について注文が最高数であるOrderBeanを問合せが返します。

右側のサブ問合せオペラントが複数の値を返す場合には、算術演算子とANYまたはALLと組み合わせて使用します。

ANYまたはALLを使用したサブ問合せの例を次に示します。

SELECT OBJECT (order)
FROM OrderBean AS order, IN(order.orderItems)oItem
WHERE oItem.quantityOrdered > ALL
(SELECT subOItem.quantityOrdered
FROM OrderBean AS suborder IN (subOrder.orderItems)subOItem
WHERE subOrder,orderId = ?1)

副問合は、特定のorderIdに対し、そのorderIdで注文された各品目のorderItem.quantityOrderedの集合を戻します。メインの問合せの「>」ALL演算子は、各品目のorderItem.quantityOrderedが副問合せから戻された集合内のすべての値を上回っている注文すべてを探しています。最終的にメイン問合せは、すべてのorderItem.quantityOrderedが入力された注文の各orderItem.quantityOrderedを上回るすべての注文を戻します。

注意:

副問合せが複数の値を持つ結果を返す可能性があるため、「>」演算子ではなく、「>」ALL演算子が使用されている点に注意してください。

相関サブ問合せと非相関サブ問合せ

WebLogic Serverは、相関サブ問合せと非相関サブ問合せの双方をサポートしています。

非相関サブ問合せ

非相関サブ問合せは、その外部問合せとは独立して評価されます。非相関サブ問合せの例を次に示します。

SELECT OBJECT(emp) FROM EmployeeBean AS emp
WHERE emp.salary>
(SELECT AVG(emp2.salary) FROM EmployeeBean AS emp2)

この非相関サブ問合せの例では、平均以上の給与の従業員を選択しています。この例では、算術演算子「>」を使用します。

相関サブ問合せ

相関サブ問合せは、その外部問合せの値がサブ問合せでの評価に関与するサブ問合せです。相関サブ問合せの例を次に示します。

SELECT OBJECT (mainOrder) FROM OrderBean AS mainOrder
WHERE 10>
(SELECT COUNT (DISTINCT subOrder.ship_date)
FROM OrderBean AS subOrder
WHERE subOrder.ship_date>mainOrder.ship_date
AND mainOrder.ship_date IS NOT NULL

この相関サブ問合せの例では、最後に出荷された10個の注文を選択しています。NOT IN演算子を使用しています。

注意:

相関問合せでは、非相関問合せより処理オーバーヘッドが大きくなる可能性があることに注意してください。

サブ問合せでのDISTINCT句

サブ問合せ内でDISTINCT句を使用すると、そのサブ問合せで生成されるSELECT DISTINCT内でSQL SELECT DISTINCTを使うことができます。サブ問合せでのDISTINCT句の使い方は、メイン問合せでの使い方とは異なります。メイン問合せ内のDISTINCT句はEJBコンテナによって施されますが、サブ問合せ内のDISTINCT句は生成されたSQLのSQL SELECT DISTINCTによって施されます。サブ問合せのDISTINCT句の例を示します。

SELECT OBJECT (mainOrder) FROM OrderBean AS mainOrder
WHERE 10>
(SELECT COUNT (DISTINCT subOrder.ship_date)
FROM OrderBean AS subOrder
WHERE subOrder.ship_date>mainOrder.ship_date
AND mainOrder.ship_date IS NOT NULL

算術関数の使用

WebLogic Serverでは、WebLogic QLの算術関数をサポートしています。WebLogic QLを指定するには、「EJB QLのEJB 2.x WebLogic QL拡張機能の使い方」を参照してください。この例に従って、算術関数を指定したSELECT文を記述します。

表G-1 算術関数

算術関数

説明

ABS(number)

数値(int、double、float)の絶対値を返します。

MOD(int, int)

xをyで割った剰余の値を返します。

SQRT(double)

平方根を返します。

注意:

EJB QL算術関数は、DB2では問合せパラメータと一緒に使用できません。

集約関数の使用

WebLogic Serverでは、WebLogic QLの集約関数をサポートしています。これらは、WHERE句のような問合せの一部ではなく、SELECT句のターゲットとして使われるのみです。集約関数の振る舞いはSQL関数と似ています。これらの関数は、問合せのWHERE条件によって返されるBeanの外側で評価されます。

WebLogic QLを指定するには、「EJB QLのEJB 2.x WebLogic QL拡張機能の使い方」を参照してください。これに従って、次の表のサンプルのように、集約関数を指定したSELECT文を記述します。

サポートされている関数とサンプル文のリストを次に示します。

表G-2 集約関数

集約関数

有効な引数データ型

説明

サンプル文

MIN(x)

- character

- date

- numeric

- string

このフィールドの最小値を返します。

SELECT MIN(t.price) FROM TireBean AS t WHERE t.size=?1

この文では、入力された特定のサイズの最安値を選択しています。

MAX(x)

- character

- date

- numeric

- string

このフィールドの最大値を返します。

SELECT MAX(s.customer_count) FROM SalesRepBean AS s WHERE s.city='Los Angeles'

この文では、ロサンゼルス市内の販売代理人それぞれが担当する顧客数の中の最大値を選択しています。

AVG( [DISTINCT] x)

numeric

このフィールドの平均値を返します。

SELECT AVG(b.price) FROM BookBean AS b WHERE b.category='computer_science'

この文では、コンピュータ科学分野の書籍の平均価格を選択しています。

SUM( [DISTINCT] x)

numeric

このフィールドの合計を返します。

SELECT SUM(s.customer_count) FROM SalesRepBean AS s WHERE s.city='Los Angeles'

この文では、ロサンゼルス市内の販売代理人が担当している顧客の合計数を取得しています。

COUNT( [DISTINCT] x)

numeric

フィールドの発生数を返します。

SELECT COUNT(s.deal.amount) FROM SalesRepBean AS s, IN(deal)s WHERE s.deal.status='closed' AND s.deal.amount>=1000000

この文では、100万ドル以上の非公開取引の数を取得しています。

注意:

このリリースのWebLogic Serverでは、以下の条件がすべて真の場合、ObjectNotFoundExceptionが返されます。

- 集約問合せでSUM、AVG、MAX、またはMIN演算子が使用されている

- 選択メソッドの結果タイプがプリミティブである

- 集約関数を適用できる値が存在しない
9.0より前のリリースのWebLogic Serverでは、上記の条件がすべて真の場合、0が返されました。

SQL仕様では、集約と共に個々のフィールドを選択する問合せにはGROUP BY句を指定する必要があります。

次の手順で、ResultSetとして集約関数を返すことができます。

ResultSetを返す問合せの使用

WebLogic Serverは、複数列問合せの結果をjava.sql.ResultSet の形式で返す、ejbSelect()問合せをサポートしています。この機能をサポートするために、WebLogic Serverでは、次のようにSELECT句のターゲット・フィールドをカンマで区切って指定できるようになりました。

SELECT emmp.name, emp.zip FROM EmployeeBean AS emp

この問合せは、従業員の名前と郵便番号の値を列としその数行を含んだjava.sqlResultSetを返します。

WebLogic QLを指定するには、「EJB QLのEJB 2.x WebLogic QL拡張機能の使い方」を参照してください。これに従って、上記の問合せに示すように、ResultSetを指定する問合せを記述します。また、同様にこれに従って、下記の表のサンプルで示すように、集約問合せを指定したSELECT文を記述します。

EJB QLで作成されるResultSetは、cmp-fieldの値、または、cmp-field値の集合だけを返します。Beanを返すことはできません。

さらに、cmp-fieldと集約関数を組み合わせた場合、下記のサンプルに示すような強力な問合せを作成できます。

次の行(Bean)は、各地区の従業員の給与を示しています。

表G-3 カリフォルニア州内の従業員の給与を示すCMPフィールド

名前

地区

給与

Matt

CA

110,000

Rob

CA

100,000

表G-4 アリゾナ州内の従業員の給与を示すCMPフィールド

名前

地区

給与

Dan

AZ

120,000

Dave

AZ

80,000

表G-5 テキサス州内の従業員の給与を示すCMPフィールド

名前

地区

給与

Curly

TX

70,000

Larry

TX

180,000

Moe

TX

80,00

注意:

各行が1つのBeanを表します。

次のSELECT文の問合せでは、ResultSet、集約関数(AVG)と共にGROUP BY文とORDER BY文を使用し、複数列問合せの結果を降順ソートを使って取り出します。

SELECT e.location, AVG(e.salary)
FROM Finder EmployeeBean AS e
GROUP BY e.location
ORDER BY 2 DESC

この問合せは、各地区の従業員の平均給与を降順で示します。2という数字は、ORDER BYソートをSELECT文の2番目の項目で実行することを意味しています。GROUP BY句は、e.location属性に一致する従業員の平均給与を指定しています。

ResultSetは、次のように降順で並んでいます。

地区

平均

AZ

100,000

CA

105,000

TX

110,000

注意:

ResultSetを返す問合せ内でORDER BYの引数として使用できるのは整数だけです。WebLogic Serverでは、Beanを返すファインダ、またはejbselect()内でORDER BYの引数として整数を使用することはできません。

OracleのSELECT HINTの使用

WebLogic Serverは、INDEXの使い方に関するヒントをOracle Queryオプティマイザに渡すことを可能にするEJB QL拡張機能をサポートしています。この拡張機能を使用すると、データベース・エンジンにヒントを提供できます。たとえば、検索先のデータベースがORACLE_SELECT_HINTによって恩恵を受けることがわかっている場合は、ANY文字列値を取り、その文字列値をデータベースに対するヒントとしてSQL SELECT文の後に挿入するORACLE_SELECT_HINT句を定義します。

このオプションを使用するには、この機能を使用する問合せをweblogic-cmp-jar.xmlのweblogic-ql要素で宣言します。weblogic-ql要素は、EJB-QLに対するWebLogic固有の拡張機能を含む問合せを指定します。

WebLogic QLのキーワードおよび使い方は次のとおりです。

SELECT OBJECT(a) FROM BeanA AS a WHERE a.field > 2 ORDER BY a.field SELECT_HINT '/*+ INDEX_ASC(myindex) */'

この文は、Oracleのオプティマイザ・ヒントを使用して次のSQLを生成します。

SELECT /*+ INDEX_ASC(myindex) */ column1 FROM ....

WebLogic QL ORACLE_SELECT_HINT句では、単一引用符で囲まれた部分(' ')がSQL SELECTの後に挿入されます。問合せ作成者は、引用符内のデータをOracleデータベースが確実に認識できるものにする必要があります。

getおよびsetメソッドの制約

WebLogic Serverでは、一連のアクセサ・メソッドを使用します。これらのメソッドの名前の先頭には、setとgetが付いています。WebLogic Serverでは、コンテナ管理によるフィールドの読出しおよび修正にこれらのメソッドを使用します。コンテナによって生成されるこれらのクラスは、「get」または「set」で始まり、ejb-jar.xmlで定義されている永続フィールドの実際の名前を使用する必要があります。また、これらのメソッドは、public、protected、およびabstractとして宣言します。

Queryインタフェースのプロパティ・ベースのメソッド

Queryインタフェースには、検索と実行の両方のメソッドがあります。検索メソッドは、EJBObjectsを返すという点で標準のEJBメソッドと同じように機能します。実行メソッドは、個々のフィールドを選択できるという点でさらにSelect文のように機能します。

Queryインタフェースの戻り値の型は切断されたResultSetです。つまり、返されたオブジェクトの情報には、ResultSetがデータベース接続の開いた状態を維持しないことを除いて、ResultSetの情報にアクセスするのと同じ方法でアクセスします。

Queryインタフェースのプロパティ・ベースのメソッドでは、問合せに固有の設定を指定することができます。QueryPropertiesインタフェースは標準のEJB問合せ設定を保持し、WLQueryPropertiesインタフェースはWebLogic固有の問合せ設定を保持します。

QueryインタフェースはQueryPropertiesの拡張版ですが、実際のQuery実装はWLQueryPropertiesを拡張したものなので、フィールド・グループ設定を設定する例G-3の例のように安全にキャストできます。

例G-3 WLQueryPropertiesでのフィールド・グループ設定の設定

Query query=qh.createQuery(); ((WLQueryProperties) query).setFieldGroupName("myGroup"); Collection results=query.find(ejbql);

または

Query query=qh.createQuery(); Properties props = new Properties(); props.setProperty(WLQueryProperties.GROUP_NAME, "myGroup"); Collection results=query.find(ejbql, props);

WLQLからEJB QLへの移行

EJB 1.1を使用する既存のアプリケーションがある場合、コンテナ管理によるエンティティEJBではファインダ・メソッド用にWLQLを使用できます。この節では、WLQLの一般的な処理についてのクイック・リファレンスを提供します。WLQLの構文とEJB QLの構文の対応については、次の表を参考にしてください。

表G-6 WLQLからEJB QLへの移行

WLQLのサンプル構文

対応するEJB QLの構文

(= operand1 operand2)

WHERE operand1 = operand2

(< operand1 operand2)

WHERE operand1 < operand2

(> operand1 operand2)

WHERE operand1 > operand2

(<= operand1 operand2)

WHERE operand1 <= operand2

(>= operand1 operand2)

WHERE operand1 >= operand2

(! operand)

WHERE NOT operand

(& expression1 expression2)

WHERE expression1 AND expression2

(| expression1 expression2)

WHERE expression1 OR expression2

(like text_string%)

WHERE operand LIKE 'text_string%'

(isNull operand)

WHERE operand IS NULL

(isNotNull operand)

WHERE operand IS NOT NULL

暗黙的クロス積に関して確認済みの問題

EJB QL問合せに、(明示的クロス積とは対照的な)暗黙的クロス積が含まれる場合、EJB QL問合せは結果として空の値を返す場合があります。

次のサンプル問合せを検討してください。

SELECT OBJECT(e) FROM EmployeeBean AS e WHERE e.name LIKE 'Joe' OR e.acct.balance < 100

この問合せはAccountEJBを参照していますが、AccountEJBはFROM句にリストされていません。この問合せの結果は、FROM句に明示的にリストされたAccountEJBのある問合せの場合と同じです。

EJB QLエラー報告機能

EJB QLのコンパイラ・エラー・メッセージでは、問合せのどの部分にエラーが生じているのかを特定できるビジュアルな表示が用意され、コンパイルごとに複数のエラーを報告できます。

問合せ内エラーのビジュアルなインジケータ

エラーが報告されると、EJB QLは問題のある場所を記号 =>> <<= で囲んで示します。これらの記号は、次に示すサンプルのコンパイラ・エラー報告では赤色で強調されています。

ERROR: Error from appc: Error while reading 'META-INF/FinderEmployeeBeanRDBMS.xml'. The error was:
Query:
EJB Name: FinderEmployeeEJB
Method Name: findThreeLowestSalaryEmployees
Parameter Types: (java.lang.String)
Input EJB Query: SELECT OBJECT(e) FROM FinderEmployeeBean e WHERE f.badField = '2' O
R (e.testId = ?1) ORDER BY e.salary
SELECT OBJECT(e ) FROM FinderEmployeeBean e
WHERE =>> f.badField <<= = '2' OR ( e.testId = ?1 ) ORDER BY e.salary
Invalid Identifier in EJB QL expression:
Problem, the path expression/Identifier 'f.badField' starts with an identifier: 'f'.
The identifier 'f', which can be either a range variable identifier or a collection member identifier,
is required to be declared in the FROM clause of its query or in the FROM clause of a parent query.
'f' is not defined in the FROM clause of either its query or in any parent query.
Action, rewrite the query paying attention to the usage of 'f.badField'.

1回のコンパイル後に複数のエラー報告

問合せに複数のエラーが含まれていた場合、EJB QLでは、1回のコンパイル後にこれらのエラーを複数個報告できるようになりました。これまでは、コンパイラが報告できるエラーはコンパイル1回につき1つだけでした。後続のエラーの報告には、再コンパイルが必要でした。

コンパイラが1回のコンパイル後にすべてのエラーを報告する保証はありません。

Copyright © 2007, 2012, Oracle and/or its affiliates. All rights reserved.