Oracle® Fusion Middleware

Oracle TopLinkの理解

12c (12.2.1.2.0)

E82674-01(原本部品番号:E79107-01)

2016年10月

このドキュメントでは、Oracle TopLinkを構成するコンポーネントおよびテクノロジに関する概念を説明します。

Oracle Fusion Middleware Oracle TopLinkの理解, 12c (12.2.1.2.0)

E82674-01

Copyright © 2013, 2016, Oracle and/or its affiliates. All rights reserved.

原本著者:  Oracle Corporation

原本協力者:

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

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

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

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

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

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 12c (12.2.1.2.0)での新機能と変更された機能

- このマニュアルに記載されているその他の重要な変更

1 Oracle TopLinkの概要

- 1.1 TopLinkの理解

- 1.1.1 オブジェクトと永続データのインピーダンス・ミスマッチとは

- 1.1.2 EclipseLinkのソリューション

- 1.2 主要機能

- 1.3 主要概念

- 1.3.1 EclipseLinkメタデータ

- 1.3.2 エンティティ

- 1.3.3 ディスクリプタ

- 1.3.4 マッピング

- 1.3.5 データ・アクセス

- 1.3.6 キャッシュ

- 1.3.7 問合せ

- 1.3.8 式フレームワーク

- 1.3.9 NoSQLデータベース

- 1.3.10 パフォーマンスのモニタリングおよびプロファイリング

- 1.4 主要コンポーネント

- 1.4.1 EclipseLink CoreおよびAPI

- 1.4.2 オブジェクト・リレーショナル(JPA 2.1)・コンポーネント

- 1.4.3 JAXBコンポーネント

- 1.4.4 MOXyコンポーネント

- 1.4.4.1 SDOコンポーネント

- 1.4.5 データベースWebサービス・コンポーネント

- 1.4.6 TopLink Grid

- 1.5 主要ツール

- 1.5.1 Oracle JDeveloper

- 1.5.2 Oracle Enterprise Pack for Eclipse

- 1.5.3 Eclipse

- 1.5.4 NetBeans

2 オブジェクト・リレーショナルおよびMOXyの内部の理解

- 2.1 メタデータについて

- 2.1.1 メタデータ・アーキテクチャの利点

- 2.1.2 プロジェクト・メタデータの作成

- 2.1.2.1 エンティティ・マッピング

- 2.1.2.2 データ・ソース・ログイン情報

- 2.1.3 セッション・メタデータの作成

- 2.2 オブジェクト・リレーショナル・ソリューションについて

- 2.2.1 オブジェクト・リレーショナル・エンティティ・アーキテクチャの理解

- 2.2.1.1 エンティティ

- 2.2.1.2 永続性と永続性ユニット

- 2.2.1.3 エンティティ・マネージャ

- 2.2.2 注釈を使用したメタデータの追加

- 2.2.2.1 注釈使用の長所と短所

- 2.2.3 構成の基本について

- 2.2.3.1 デフォルト注釈値

- 2.2.3.2 persistence.xmlを使用した永続性ユニットの構成

- 2.2.3.3 オブジェクト・リレーショナル・データ・タイプ・マッピング

- 2.2.4 データ・ソースについて

- 2.2.5 EclipseLinkキャッシュについて

- 2.2.5.1 キャッシュ動作の定義

- 2.2.5.2 クラスタ化環境でのキャッシング

- 2.2.6 データベース問合せについて

- 2.3 MOXyソリューションについて

- 2.3.1 JAXBプロバイダとしてのEclipseLink MOXyの使用

- 2.3.2 MOXyアーキテクチャの理解

- 2.3.2.1 JAXBコンテキストおよびJAXBコンテキスト・ファクトリ

- 2.3.3 MOXyに対するメタデータの提供

- 2.3.4 XMLバインディングについて

- 2.3.5 XPathによるオブジェクトの問合せ

3 永続性ユニットの理解

- 3.1 永続性ユニットについて

- 3.1.1 永続性ユニット名について

- 3.1.2 永続性プロバイダについて

- 3.1.3 トランザクション・タイプ・データ・ソースについて

- 3.1.4 ロギングについて

- 3.1.5 ベンダー・プロパティについて

- 3.1.6 マッピング・ファイルについて

- 3.1.7 管理対象クラスについて

- 3.1.8 デプロイメント・クラスパスについて

- 3.1.9 永続性ユニットのパッケージ・オプションについて

- 3.1.10 永続性ユニットの有効範囲について

- 3.1.11 コンポジット永続性ユニットについて

- 3.2 永続層の構築および使用

- 3.2.1 実装オプション

- 3.2.1.1 EclipseLink JPAメタデータ、注釈およびXMLの使用

- 3.2.1.2 EclipseLinkメタデータJava APIの使用

- 3.2.1.3 メソッドおよび直接フィールド・アクセスの使用

- 3.2.1.4 Javaバイト・コード・ウィービングの使用

- 3.2.2 永続クラス要件

- 3.2.3 永続層コンポーネント

- 3.2.3.1 マッピング・メタデータ

- 3.2.3.2 キャッシュ

- 3.2.3.3 問合せおよび式

- 3.3 オブジェクトの永続化について

- 3.3.1 アプリケーション・オブジェクト・モデル

- 3.3.2 データ・ストレージ・スキーマ

- 3.3.3 主キーおよびオブジェクト・アイデンティティ

- 3.3.4 マッピング

- 3.3.5 外部キーとオブジェクト・リレーションシップ

- 3.3.6 継承

- 3.3.7 同時実行性

- 3.3.8 キャッシュ

- 3.3.9 非介入型の永続性

- 3.3.10 インダイレクション

- 3.3.11 可変性

- 3.4 EclipseLink永続性マネージャへのアプリケーションの移行

- 3.5 ウィービングについて

- 3.5.1 動的ウィービングの使用

- 3.5.2 静的ウィービングの使用

- 3.5.3 POJOクラスのウィービング

- 3.5.4 ウィービングとJava EEアプリケーション・サーバー

- 3.5.5 永続性ユニット・プロパティを使用したウィービングの無効化

4 エンティティの理解

- 4.1 エンティティの識別

- 4.2 エンティティと永続識別子

- 4.3 エンティティとデータベース表

- 4.4 エンティティと継承

- 4.5 エンティティと埋込みオブジェクト

- 4.6 エンティティと順序生成

- 4.7 エンティティとロック

- 4.8 拡張可能なエンティティ

5 ディスクリプタの理解

- 5.1 共通のディスクリプタの概念

- 5.1.1 ディスクリプタのアーキテクチャ

- 5.1.2 ディスクリプタと継承

- 5.1.2.1 クラス・インジケータの指定

- 5.1.2.2 継承と主キー

- 5.1.2.3 単一表と複数表の継承

- 5.1.2.4 集約ディスクリプタ、コンポジット・ディスクリプタおよび継承

- 5.1.3 ディスクリプタと集約

- 5.1.4 ディスクリプタのカスタマイズ

- 5.1.5 修正メソッド

- 5.1.6 ディスクリプタ・イベント・マネージャ

- 5.2 オブジェクト・リレーショナル・ディスクリプタの概念

- 5.2.1 フェッチ・グループ

- 5.2.1.1 AttributeGroupタイプと操作

- 5.2.1.2 FetchGroup

- 5.2.1.3 デフォルトFetchGroup

- 5.2.1.4 名前付きFetchGroup

- 5.2.1.5 完全FetchGroup

- 5.2.1.6 Load/LoadAllとFetchGroup

- 5.2.1.7 LoadGroup

- 5.2.1.8 CopyGroup

- 5.2.1.9 マージ

- 5.2.2 ディスクリプタ問合せマネージャ

- 5.2.3 ディスクリプタと順序付け

- 5.2.4 ディスクリプタとロック

- 5.2.4.1 オプティミスティック・バージョン・ロック・ポリシー

- 5.2.4.2 ペシミスティック・ロック・ポリシー

- 5.2.4.3 アプリケーションでのロックの適用

- 5.3 ディスクリプタ・ファイル

- 5.3.1 オブジェクト・リレーショナル・マッピングへのorm.xmlの使用

- 5.3.2 EclipseLinkのオブジェクト・リレーショナル・マッピングへのeclipselink-orm.xmlの使用

- 5.3.2.1 マッピング情報のオーバーライドおよびマージ

- 5.3.2.2 XMLスキーマの検証

- 5.3.2.3 XML使用の長所と短所

- 5.3.3 EclipseLink MOXyマッピングへのeclipselink-oxm.xmlの使用

6 マッピングの理解

- 6.1 共通のマッピングの概念

- 6.1.1 マッピング・アーキテクチャ

- 6.1.2 マッピングの例

- 6.1.3 マッピング・コンバータ

- 6.1.3.1 シリアライズ・オブジェクト・コンバータ

- 6.1.3.2 タイプ変換コンバータ

- 6.1.3.3 オブジェクト・タイプ・コンバータ

- 6.1.4 トランスフォーメーション・マッピング

- 6.2 オブジェクト・リレーショナル・マッピングの概念

- 6.2.1 インダイレクション(遅延ロード)

- 6.2.2 インダイレクション、シリアライズおよびデタッチ

- 6.2.3 ValueHolderインダイレクション

- 6.2.4 透過インダイレクション

- 6.2.5 プロキシ・インダイレクション

- 6.2.5.1 プロキシ・インダイレクションの制限

- 6.2.6 ウィービング済インダイレクション

- 6.2.7 JPAマッピング・タイプについて

- 6.2.7.1 基本マッピング

- 6.2.7.2 デフォルトの変換およびコンバータ

- 6.2.7.3 コレクション・マッピング

- 6.2.7.4 オプティミスティック・ロックの使用

- 6.3 MOXyマッピングの概念

- 6.3.1 XMLデータ表現の理解

- 6.3.2 マッピング値

- 6.3.3 MOXyでの属性のサブセットのマーシャリングおよびアンマーシャリング

- 6.3.4 双方向に書込み可能な@XmlInverseReference

- 6.4 Object-JSONマッピングの概念

- 6.4.1 XMLおよびJSONへのコレクション・マッピング

- 6.5 パディング付きJSONについて

- 6.6 JAX-RS実装の拡張

7 データ・アクセスの理解

- 7.1 外部管理トランザクション・データ・ソースについて

- 7.2 データ・ソース・ログインのタイプについて

- 7.3 データ・ソース・プラットフォームのタイプについて

- 7.4 認証について

- 7.4.1 単純なJDBC認証

- 7.4.2 Oracleデータベースのプロキシ認証

- 7.4.3 監査

- 7.5 接続について

- 7.6 接続プールについて

- 7.6.1 内部接続プール

- 7.6.2 外部接続プール

- 7.6.3 デフォルト(書込み)および読取り接続プール

- 7.6.4 シーケンス接続プール

- 7.6.5 アプリケーション固有の接続プール

- 7.7 データ・パーティション化ポリシーについて

- 7.8 テナント分離について

- 7.8.1 単一表マルチテナント

- 7.8.2 テナントごとの表マルチテナント

- 7.8.3 VPDマルチテナント

- 7.9 異機種間バッチ書込みについて

- 7.10 シリアライズ・オブジェクト・ポリシーについて

- 7.11 自動チューニングについて

- 7.12 TopLink Data Servicesのライブ・データについて

- 7.12.1 通知配信のためのServer Sent EventおよびWebSocketのサポート

8 キャッシュの理解

- 8.1 キャッシュ・アーキテクチャについて

- 8.1.1 永続性ユニット・キャッシュ

- 8.1.2 永続性コンテキスト・キャッシュ

- 8.1.2.1 アプリケーション管理の永続性コンテキスト

- 8.1.2.2 コンテナ管理の永続性コンテキスト

- 8.1.3 共有、独立、保護、弱参照および読取り専用キャッシュ

- 8.1.3.1 独立キャッシュ

- 8.1.3.2 共有キャッシュ

- 8.1.3.3 保護キャッシュ

- 8.1.3.4 弱参照モード

- 8.1.3.5 読取り専用エンティティ

- 8.2 キャッシュのタイプとサイズについて

- 8.2.1 FULLキャッシュ・タイプ

- 8.2.2 WEAKキャッシュ・タイプ

- 8.2.3 SOFTキャッシュ・タイプ

- 8.2.4 SOFT_WEAKおよびHARD_WEAKキャッシュ・タイプ

- 8.2.5 NONEおよびCACHE

- 8.2.6 キャッシュおよびアイデンティティ・マップの構成のガイドライン

- 8.2.6.1 WEAK、SOFTおよびHARDキャッシュ・タイプの内部について

- 8.3 問合せおよびキャッシュについて

- 8.3.1 問合せキャッシュ・オプションおよびインメモリー問合せについて

- 8.4 失効したデータの処理について

- 8.4.1 ロック・ポリシーの構成

- 8.4.1.1 オプティミスティック・ロック

- 8.4.1.2 ペシミスティック・ロック

- 8.4.2 クラス単位でのキャッシュの構成

- 8.4.3 必要時の問合せ単位でのキャッシュ・リフレッシュの強制

- 8.4.4 キャッシュの無効化の構成

- 8.4.5 キャッシュ・コーディネーションの構成

- 8.5 明示的な問合せのリフレッシュについて

- 8.6 キャッシュ索引について

- 8.7 データベース・イベント通知およびOracle CQN

- 8.7.1 Oracle連続問合せ通知

- 8.8 問合せ結果キャッシュについて

- 8.9 キャッシュ・コーディネーションについて

- 8.9.1 キャッシュ・コーディネーションの使用が必要な場合

- 8.10 クラスタリングおよびキャッシュ・コーディネーション

- 8.10.1 JMSおよびRMIキャッシュのコーディネーション

- 8.10.2 カスタム・キャッシュのコーディネーション

- 8.11 クラスタリングおよびキャッシュの一貫性

- 8.12 キャッシュ・インターセプタ

- 8.13 Coherenceキャッシュの使用

9 問合せの理解

- 9.1 問合せの概念

- 9.1.1 Callオブジェクト

- 9.1.2 DatabaseQueryオブジェクト

- 9.1.3 データ・レベルとオブジェクト・レベルの問合せ

- 9.1.4 サマリー問合せ

- 9.1.5 ディスクリプタ問合せマネージャ

- 9.1.6 問合せキー

- 9.2 JPQL問合せについて

- 9.2.1 JPQLに対するEclipseLinkの拡張機能

- 9.2.2 JPQLでのEclipseLinkの特殊な演算子

- 9.3 SQL問合せ言語について

- 9.3.1 ストアド・プロシージャ

- 9.3.1.1 ストアド・プロシージャに対するEclipseLinkの拡張機能

- 9.4 Criteria APIについて

- 9.4.1 Criteria APIに対するEclipseLinkの拡張機能

- 9.5 ネイティブSQL問合せについて

- 9.5.1 ネイティブ問合せサポートに対するEclipseLinkの拡張機能

- 9.6 問合せヒントについて

- 9.6.1 JPAのキャッシュ問合せヒント

- 9.6.2 キャッシュ問合せヒントに対するEclipseLinkの拡張機能

- 9.7 問合せのキャストについて

- 9.7.1 ダウンキャスト用のEclipseLinkの式のサポート

- 9.8 問合せ用のOracle拡張機能について

- 9.8.1 問合せヒント

- 9.8.2 階層問合せ

- 9.8.3 フラッシュバック問合せ

- 9.8.4 ストアド・ファンクション

10 EclipseLinkの式の理解

- 10.1 式フレームワークについて

- 10.2 式の構成要素について

- 10.2.1 ブール・ロジック

- 10.2.2 データベース関数および演算子

- 10.2.2.1 Oracle XMLType関数

- 10.2.3 プラットフォーム関数とユーザー定義関数

- 10.2.4 1対1および集約オブジェクトのリレーションシップを表す式

- 10.2.5 結合リレーションシップと複雑なリレーションシップを表す式

- 10.2.5.1 結合について

- 10.2.5.2 結合でのEclipseLink Expression APIの使用

11 非リレーショナル・データ・ソースの理解

- 11.1 NoSQLプラットフォームの概念

- 11.2 NoSQL永続性ユニットについて

- 11.2.1 NoSQLプラットフォーム用の永続性ユニット・プロパティ

- 11.3 NoSQLプラットフォームのJPAアプリケーションについて

- 11.3.1 JPA注釈に対するマッピングの制限

- 11.4 NoSQLオブジェクトのマッピングについて

- 11.5 問合せおよびNoSQLプラットフォームについて

- 11.6 トランザクションおよびNoSQLプラットフォームについて

A データベースおよびアプリケーション・サーバーのサポート

- A.1 データベースのサポート

- A.2 アプリケーション・サーバーのサポート

- A.2.1 アプリケーション・サーバーのJAXBプロバイダとしてのEclipseLink MOXy

- A.3 非SQL標準データベースのサポート: NoSQL

はじめに

Oracle TopLinkでは、リレーショナル、XMLおよびJSONの永続化のすべてのニーズに応える、高いパフォーマンス、スケーラビリティ、開発者の生産性、アーキテクチャと設計の柔軟性に優れ、実績のある標準に基づいたエンタープライズJavaソリューションが提供されています。

対象読者

このドキュメントは、TopLinkおよびその機能の概念の詳細を理解する必要があるアプリケーション開発者および管理者向けに用意されています。

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

オラクル社のアクセシビリティへの取組みの詳細は、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 (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle TopLinkのドキュメント・セットに含まれる次のドキュメントを参照してください。

- Oracle TopLinkのソリューション・ガイド

- Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス

- Oracle TopLinkによるJAXBアプリケーションの開発

- Oracle TopLink Database Webサービスによる永続性アーキテクチャの開発

- Oracle TopLink Java APIリファレンス

- Oracle Coherenceの統合

- Java Persistence仕様(JPAの詳細情報)
http://jcp.org/en/jsr/detail?id=338

- Oracle TopLinkリリース・ノート

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

このガイドで説明する新機能

次のトピックでは、Oracle Toplinkの新機能と変更された機能およびこのガイドで説明する主な変更について紹介し、その他の参考資料へのリンクを示します。このドキュメントは、旧名『Oracle TopLinkの理解』の新版です。

12c (12.2.1.2.0)での新機能と変更された機能

Oracle TopLink 12c (12.2.1.2.0)には、このドキュメントで説明する次の新機能と変更された機能が含まれています。

MOXyの拡張機能

- XMLおよびJSONへのコレクション・マッピングの改善: @XmlElementWrapper注釈をJSONキーとして使用し、コレクションをXMLおよびJSONの両方にマップできるようになりました。詳細は、6.4.1項「XMLおよびJSONへのコレクション・マッピング」を参照してください。

- 属性のサブセットのマーシャリングおよびアンマーシャリング: ディスクリプタに属性グループを設定することにより、マーシャリングおよびアンマーシャリングするオブジェクト属性のサブセットを構成できるようになりました。詳細は、6.3.3項「MOXyでの属性のサブセットのマーシャリングとアンマーシャリング」を参照してください。

- 双方向に書込み可能な@XmlInverseReference: MOXyの@XmlInverseReference注釈により、アンマーシャル操作の間、バック・ポインタをマップできます。マーシャル操作の間にポインタをマップするには、@XmlInverseReference注釈を@XmlElement注釈と組み合せます。詳細は、6.3.4項「双方向に書込み可能な@XmlInverseReference」を参照してください。

JAX-RS (REST)の拡張機能

- パディング付きJSON: パディング付きJSONは、一般的なWebブラウザでは同一生成元ポリシーにより禁止されている、異なるドメインのサーバーからデータを要求する方法を提供します。詳細は、6.5項「パディング付きJSONについて」を参照してください。

- JAX-RS実装に対するサポートの改善: MOXyJsonProviderクラスはEclipseLink JAXB (MOXy)をJSONプロバイダとして使用できます。JAX-RS統合をより容易にするため、このクラスは拡張可能になりました。詳細は、6.6項「JAX-RS実装の拡張」を参照してください。

TopLinkの最適化

- 異機種間バッチ書込み: 複数書込みのあるトランザクションを最適化するため、新しい永続性ユニット・プロパティが追加されました。詳細は、7.9項「異機種間バッチ書込みについて」を参照してください。

- バイナリ形式オブジェクトの永続性: 7.10項「シリアライズ・オブジェクト・ポリシーについて」

- 自動チューニング: テンプレートのチューニング構成を容易にするため、SessionTunerインタフェースが強化されました。アプリケーションを本番および開発用に、または様々なデプロイメント構成に対して簡単に調整できるようになりました。詳細は7.11項「自動チューニングについて」を参照してください。

TopLinkのデータ・サービス

- TopLink Data Servicesのライブ・データ: TopLink Data Services (TLDS)では、エンタープライズJava Persistenceへのアクセスを提供するリッチなRESTインタフェースを公開することにより、モダンHTML5, JavaScript、およびモバイル・クライアント・アプリケーションにおけるデータ・アクセスを容易にします。TLDSにより、サーバー側キャッシング、検証およびセキュリティを使用して、拡張可能な永続性を持つデータ・ストア、リレーショナルまたはNoSQLを公開できます。詳細は、7.12項「TopLink Data Servicesのライブ・データについて」を参照してください。

このマニュアルに記載されているその他の重要な変更

このガイドは12c (12.2.1.2.0)でいくつかの点が更新されました。次の表に、追加または変更された項を示します。

- 新機能に関する説明を第1章からこの章に移動しました。

- アプリケーション開発に関する章を削除しました。

- アプリケーション・サーバーとの統合に関する項を削除しました。

- 第2章「マッピングの理解」の章タイトルを第2章「オブジェクト・リレーショナルおよびMOXyの理解」に変更しました。

- 永続性ユニットの詳細を、第5章から独自の章、第3章「永続性ユニットの理解」に移動しました。

- 4.8項「拡張可能なエンティティ」を追加し、外部からマッピングを追加または変更することにより、JPAエンティティおよびJAXB Beanを拡張可能にできることを記載しました。

- ディスクリプタの詳細を、第5章「ディスクリプタの理解」に記載しました。

- マッピングの詳細を第6章「マッピングの理解」に記載しました。

- 7.8項「テナント分離について」を追加し、EclipseLinkがテナントを分離する機能の設計および実装を柔軟に行えることを記載しました。

- 8.7項「データベース・イベント通知およびOracle CQN」を追加し、データベースがデータベースの変更をEclipseLinkに通知できるAPIについて記載しました。

- 8.10項「クラスタリングおよびキャッシュ・コーディネーション」のキャッシュ・クラスタリングの情報を統合しました。

- 問合せの詳細を第9章「問合せの理解」に移動しました。標準JPAの一部である、JPQL問合せ句に関する詳細は削除しました。

- 式フレームワークの詳細を第10章「EclipseLinkの式の理解」に移動しました。標準JPAの一部である、データベース関数および演算子に関する詳細は削除しました。

- NoSQLの詳細を、第11章「非リレーショナル・データ・ソースの理解」に記載しました。

- 「パフォーマンスのモニタリングおよびプロファイリングの理解」の章を削除しました。

1 Oracle TopLinkの概要

この章では、Oracle TopLinkとその主要機能(TopLinkに含まれるコンポーネント、メタデータ、アプリケーション・アーキテクチャ、マッピングおよびAPI)について説明します。

この章の内容は次のとおりです。

- TopLinkの理解

- 主要機能

- 主要概念

- 主要コンポーネント

- 主要ツール

1.1 TopLinkの理解

Oracle TopLinkは、Java Platform, Standard Edition (Java SE)やJava Platform, Enterprise Edition (Java EE)などのJava環境で使用するためのマッピングおよび永続性フレームワークです。TopLinkの中核となる機能は、オープン・ソースのマッピングおよび永続性フレームワークであるEclipseLinkによって提供されます。EclipseLinkプロジェクトは、オラクル社に主導され、Eclipse Foundationの管理下にあります。TopLinkには、このドキュメントの後の部分で説明するとおり、EclipseLinkを超える追加機能が含まれます。

EclipseLink
EclipseLinkは、次の各仕様と、それらの仕様の拡張をすべて実装しています。

- Java Persistence API (JPA)
JPAは、オブジェクト/リレーショナル・マッピング(ORM)用のJava APIであり、Javaオブジェクトは、Javaアプリケーションでリレーショナル・データを管理する目的でデータベース・アーティファクトにマップされます。JPAには、Java Persistence Query Language (JPQL)、Java Persistence Criteria API、およびオブジェクト/リレーショナル・マッピング・メタデータを定義するためのJava APIおよびXMLスキーマが含まれます。

最新バージョンの仕様は、JSR 338: Java Persistence 2.1です。http://jcp.org/en/jsr/detail?id=338を参照してください。

標準のJPAに対するEclipseLinkの拡張は次のとおりです。

- 非リレーショナル(NoSQL)・データベースに対するマッピングのサポート。

- テナント分離、拡張可能なエンティティ、外部メタデータ・ソースなど、Software as a Service (SaaS)環境で役立つ機能。

- Java API for RESTful Web Services (JAX-RS、JSR 311として定義)。

- その他多くの追加の注釈、注釈の拡張、Java Persistence Query Language (JPQL)の拡張、JPA問合せカスタマイズの拡張、および永続性プロパティの拡張。

- Java Architecture for XML Binding (JAXB)
JAXBは、オブジェクト/XMLマッピング(OXM)のためのJava APIであり、XML文書は、そのXML文書のXSDスキーマに基づいてJavaオブジェクトにバインドされます。JAXBによって、XMLインスタンス文書をJavaコンテンツ・ツリーにアンマーシャリングし(読み取り)、次にJavaコンテンツ・ツリーをXMLインスタンス文書にマーシャリングする(書き込む)方法が提供されます。JAXBでは、JavaオブジェクトからXMLスキーマを生成する方法も提供されます。

最新バージョンの仕様は、JSR 222: Java Architecture for XML Binding (JAXB) 2.0です。http://jcp.org/en/jsr/detail?id=222を参照してください。

EclipseLinkによって、JAXBは、JavaScript Object Notation (JSON)ドキュメントをサポートするように拡張されます。EclipseLinkは、JSONの読取り時と書込み時のすべてのオブジェクト/XMLオプションに対応しています。

注意:
EclipseLinkプロジェクトでは、EclipseLink MOXyという用語を使用して、EclipseLinkの完全なJAXBサポートとそのJSONサポートを説明し、さらにより古いネイティブのTopLinkオブジェクト/XML APIに対するサポートを説明します(これらはJAXB仕様では定義されていません)。TopLinkには、すべてのMOXy機能が含まれますが、この用語はOracleドキュメントでは正式に使用されていません。

前述の標準仕様の実装に加え、EclipseLinkには次の機能が含まれます。

- EclipseLink Database Web Services (DBWS)
DBWSは、Webサービスを介してリレーショナル・データベース・アーティファクトにJava EE準拠のクライアント非依存アクセスを行うための開発ツールおよびランタイムです。開発ツールのDBWSビルダーは、必要なデプロイメント・アーティファクトを生成するコマンド行ユーティリティです。(DBWSビルダーは、Eclipse Dali Java PersistenceツールセットおよびOracle JDeveloperに統合されています。)ランタイム・プロバイダは、サービス・ディスクリプタ(および関連するデプロイメント・アーティファクト)を使用して、それをJAX-WS 2.0 Webサービスとして実現します。ランタイムは、EclipseLinkを使用して、Webサービス・クライアントが使用するXML SOAPメッセージとデータベース間の橋渡しをします。

- EclipseLink Enterprise Information Services (EIS)
EISは、Java Connector Architecture (JCA)リソース・アダプタを通じてデータ・ストアの使用を有効化するための機能です。XMLメタデータの使用によって、相互作用および交換データが構成され、ドメイン・モデルにマップされます。相互作用のデータは、Common Client interface (CCI)またはXMLスキーマを使用してマップできます。この使用方法は、JDBCまたはSQLアクセスが提供されない非リレーショナル・データ・ストアを対象としています。

EclipseLinkは、広範囲のJava Enterprise Edition (Java EE)およびJavaアプリケーション・アーキテクチャとともに使用できます。EclipseLinkを使用して、リレーショナル・データベース、非リレーショナル(NoSQL)・データベース、XML、JSON、Webサービスを含む様々なデータ・ソースおよび形式をサポートする高度なオブジェクト永続性およびオブジェクト・トランスフォーメーション・レイヤーを設計、実装、デプロイおよび最適化できます。

EclipseLinkは、Java EE、Java SEおよびWebコンテナでJava永続性をサポートしますが、これには次のような様々なアプリケーション・サーバーとの統合が含まれます。

- Oracle WebLogic Server

- Oracle Glassfish Server

- JBoss Web Server

- IBM WebSphereアプリケーション・サーバー

- SAP NetWeaver

- Oracle Containers for Java EE (OC4J)

- 他の様々なWebコンテナ(Apache Tomcat、Eclipse Gemini、IBM WebSphere CE、SpringSource Serverなど)

EclipseLinkによって、オブジェクトとデータ・ソースおよびオブジェクトとデータ表現のマッピングを、柔軟で効率的なメタデータ形式で迅速に取得および定義できます。

ランタイムでは、このマッピング・メタデータを自分のアプリケーションに活用できますが、この場合、データ・アクセス、問合せ、トランザクション(外部トランザクション・コントローラの使用の有無を問わない)、およびキャッシングを詳細にサポートできる、シンプルなセッション・ファサードを使用できます。

TopLinkの詳細は、「主要機能」を参照してください。

1.1.1 オブジェクトと永続データのインピーダンス・ミスマッチとは

Javaとデータ・ソースの統合は、エンタープライズJavaアプリケーションの作成時には非常に軽視されている問題です。この複雑な問題は、単なるデータ・ソースに対する読取りおよび書込みにとどまりません。データ・ソースの要素には表、行、列、主キー、外部キーがあります。JavaおよびJava EEプログラミング言語には、エンティティ・クラス(標準Javaクラス)、ビジネス・ルール、複雑なリレーションシップおよび継承があります。非リレーショナル・データ・ソースでは、JavaエンティティをXML要素とスキーマに一致させる必要があります。

解決を成功させるには、これらの異なるテクノロジ間の橋渡し、およびオブジェクトと永続データのインピーダンス・ミスマッチの解決が必要ですが、これは多くのリソースを要する難しい課題です。この課題を解決するには、Java EEとデータ・ソース要素の間に横たわる次の問題を解決する必要があります。

- 根本的に異なるテクノロジ

- 異なるスキル群

- テクノロジごとに異なるスタッフおよび所有物

- 異なるモデリングおよび設計の原理

アプリケーション開発者には、アプリケーション設計またはデータの整合性を損わずに、Javaアプリケーションとすべてのデータ・ソースを統合できる製品が必要です。また、Java開発者には、リレーショナル・データベースまたは非リレーショナル・データ・ソースをリポジトリとして使用して、ビジネス・ドメイン・オブジェクトを格納(永続化)および取得する機能が必要です。

1.1.2 EclipseLinkのソリューション

EclipseLinkは、Javaオブジェクトとデータ・ソースの不一致を解決します。これには、オブジェクト・テクノロジの最適な機能と特定のデータ・ソースを結合するアプリケーションを作成できる永続性フレームワークが含まれます。次の内容を実行できます。

- Javaオブジェクトを事実上すべてのリレーショナル・データベースに永続化できます。

- JavaオブジェクトとXMLおよびJSON文書間でインメモリー変換を実行できます。

- 任意のオブジェクト・モデルを任意のリレーショナルまたは非リレーショナル・スキーマにマップできます。

- EclipseLinkには、データ・ソースの見やすいオブジェクト指向ビューが用意されているため、SQLまたはJDBCに詳しくない場合でもEclipseLinkを正しく使用できます。

1.2 主要機能

広範な機能セットが用意されています。これらの機能を使用して、スケーラブルでメンテナンス性の高い、高パフォーマンスのエンタープライズ・アプリケーションを短期間で作成できます。

主な機能には、次のものがあります。

- 非侵入的で柔軟なメタデータベース・アーキテクチャ

- 高度なマッピング・サポートと柔軟性: リレーショナル、オブジェクト・リレーショナル・データ型、およびXML

- 幅広いパフォーマンス・チューニング・オプションによる、スケーラビリティに優れたパフォーマンスおよび同時実行性を実現する最適化

- Oracle Fusion Middleware Serverなどの一部のアプリケーション・サーバーのクラスタの統合を含む、包括的なオブジェクト・キャッシングのサポート

- 広範な問合せ機能: Java Persistence Query Language (JPQL)、ネイティブSQL、EclipseLink式フレームワークなど

- ジャストインタイム方式の読取り

- オブジェクトレベルのトランザクション・サポートと広く使用されているサーバーおよびデータベースとの統合

- オプティミスティック/ペシミスティック・ロック・オプションおよびロック・ポリシー

詳細およびダウンロードは、TopLinkのホーム・ページを参照してください。

http://www.oracle.com/technology/products/ias/toplink/index.html

1.3 主要概念

この項では、このドキュメントに記載されているいくつかの主要概念の概要について説明します。この項で説明する主要概念は、次のとおりです。

- EclipseLinkメタデータ

- エンティティ

- ディスクリプタ

- マッピング

- データ・アクセス

- キャッシュ

- 問合せ

- 式フレームワーク

- NoSQLデータベース

- パフォーマンスのモニタリングおよびプロファイリング

1.3.1 EclipseLinkメタデータ

EclipseLinkのメタデータは、アプリケーションの開発とデプロイされたランタイム環境の間の橋渡しをします。次のものを使用して、メタデータを取得できます。

- JavaファイルのJPA注釈、およびpersistence.xmlおよびeclipselink-orm.xmlファイルのJPA定義プロパティ
メタデータは、persistence.xmlファイルのEclipseLink JPA注釈およびプロパティ拡張機能によっても取得されます。eclipselink-orm.xmlファイルは、JPA仕様には定義されていないプロパティ拡張機能を定義するためにも使用できます。

- JavaファイルのJAXB注釈およびeclipselink-oxm.xmlファイルのJAXB定義のプロパティ
eclipselink-oxm.xmlファイルは、JAXB仕様には定義されていないプロパティ拡張機能を定義するためにも使用できます。

- JavaおよびEclipseLinkのAPI

メタデータを通じて、構成情報をランタイム環境に渡すことができます。ランタイム環境では、Javaオブジェクト、JPAエンティティ、およびEclipseLink APIを使用して記述されたコードなどの永続クラスとともにこの情報を使用して、アプリケーションが完成します。詳細は、「注釈を使用したメタデータの追加」を参照してください。『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』も参照してください。

マッピングは、アプリケーションの外部に保存できます。これは、追加マッピング情報が指定されたeclipselink-orm.xmlまたはeclipselink-oxm.xmlファイルを、ファイルとしてWebサーバーで使用できるようにすれば簡単に行えます。マッピング情報を保存して、動的に情報を更新できるようにするサーバー・プロセスが関係するような複雑なものにすることもできます。詳細は、EclipseLinkドキュメントの『EclipseLink/Examples/JPA/MetadataSource』を参照してください。

http://wiki.eclipse.org/EclipseLink/Examples/JPA/MetadataSource

1.3.2 エンティティ

エンティティは、永続性ドメイン・オブジェクトです。一般的に、エンティティはリレーショナル・データベースの表を表現し、各エンティティ・インスタンスはその表の行に相当します。エンティティの主なプログラミング・アーティファクトはエンティティ・クラスですが、各エンティティはヘルパー・クラスを使用できます。

エンティティの永続状態は、永続フィールドまたは永続プロパティを通じて表現されます。これらのフィールドまたはプロパティでは、オブジェクト/リレーショナル・マッピングの注釈を使用して、エンティティおよびエンティティ関係を、基礎となるデータ・ストアのリレーショナル・データにマップします。

第4章「エンティティの理解」を参照してください。

1.3.3 ディスクリプタ

ディスクリプタは、Javaクラスをデータ・ソース表現に関連付ける方法を記述したものです。ディスクリプタは、オブジェクト・クラスをデータ・ソースに、データ・モデル・レベルで関連付けます。たとえば、永続クラス属性はデータベース列にマップされます。

EclipseLinkでは、ディスクリプタを使用して、あるデータ・ソースで特定クラスのインスタンスがどのように表現されるかを定義した情報を格納します。ディスクリプタは、EclipseLinkによって内部的に使用され、注釈、XMLまたはIDE (JDeveloperやEclipseなど)を通じて定義され、実行時に読み取られます。

第5章「ディスクリプタの理解」を参照してください。

1.3.4 マッピング

マッピングは、個々のオブジェクト属性をデータ・ソース表現と関連付ける方法を記述したものです。マッピングには、複雑なトランスフォーメーションまたは直接エントリを指定することができます。

EclipseLinkでは、マッピングを使用して、オブジェクトとデータ・ソース表現の間でデータをどのように変換するかを決定します。マッピングは、EclipseLinkによって内部的に使用され、注釈、XMLまたはIDE (JDeveloperなど)を通じて定義され、実行時にプロジェクトXMLファイルから読み取られます。

第6章「マッピングの理解」を参照してください。

1.3.5 データ・アクセス

データ・ソース・プラットフォームには、バインディング、ネイティブSQLの使用、バッチ書込みの使用、順序付けなどの特定のデータ・ソースに固有のオプションが含まれます。

EclipseLinkでは、OracleおよびOracle以外の多くのデータ・ソース・プラットフォームがサポートされます。

第7章「データ・アクセスの理解」を参照してください。

1.3.6 キャッシュ

EclipseLinkキャッシュは、クラスと主キーの値に基づいて最近読み取られたり書き込まれたオブジェクトが格納される、インメモリー・リポジトリです。キャッシュは、データベースとの不要な通信を回避し、ロックおよびキャッシュの分離レベルを制御し、オブジェクト・アイデンティティを管理することでパフォーマンスを向上するために使用します。

第8章「キャッシュの理解」を参照してください。

1.3.7 問合せ

リレーショナルや非リレーショナルのデータ・ソースに対して、Java EEおよびJava EE以外のアプリケーションの両方で問合せを使用して、永続オブジェクトまたはデータを作成、読取り、更新および削除できます。問合せは、オブジェクト・レベルまたはデータ・レベルで作成できます。

Java Persistence Query Language (JPQL)、SQL、式フレームワークなどの複数の問合せ言語がサポートされます。また、Java Persistence Criteria APIを使用すると、JPQLの文字列ベースのアプローチを使用せずに、オブジェクトベースの問合せ定義オブジェクトを構成して動的問合せを定義できます。

第9章「問合せの理解」を参照してください。

1.3.8 式フレームワーク

EclipseLinkの式フレームワークを使用すると、ドメイン・オブジェクト・モデルに基づいて問合せの検索基準を指定できます。式には、SQLより優れた点が多くあります。たとえば、式は管理が簡単で、ディスクリプタやデータベース表を変更してもアプリケーションの問合せ構造に影響せず、Queryインタフェースの標準化によって可読性が向上し、複雑な操作が簡略化されます。

第10章「EclipseLinkの式の理解」を参照してください。

1.3.9 NoSQLデータベース

NoSQLは、SQL標準をサポートしないデータベース・システムの類型です。これには、ドキュメント・データベース、キー/値ストア、および他の様々な非標準データベースが含まれます。Java Persistence API (JPA)を通じて、NoSQLデータベースに対するJavaオブジェクトの永続化がサポートされます。EclipseLinkのネイティブAPIも、NoSQLデータベースでサポートされます。

第11章「非リレーショナル・データ・ソースの理解」を参照してください。

1.3.10 パフォーマンスのモニタリングおよびプロファイリング

アプリケーションのパフォーマンスを測定し、最適化するための様々な機能が用意されています。ほとんどの機能はディスクリプタまたはセッションで有効/無効を切り替えることができるため、グローバルなパフォーマンスの向上が可能になります。パフォーマンスのプロファイリングとパフォーマンス、フェッチ・グループおよび問合せのモニタリングのためのツールが提供されています。

Oracle TopLinkのソリューション・ガイドのパフォーマンスの拡張に関する項を参照してください。

1.4 主要コンポーネント

図1-1に、TopLinkに含まれているコンポーネントを示します。次の項ではコンポーネントについて説明します。

図1-1 TopLinkのコンポーネント

「図1-1 TopLinkのコンポーネント」の説明

1.4.1 EclipseLink CoreおよびAPI

EclipseLink Coreは、ランタイム・コンポーネントを提供します。ランタイムには、EclipseLink API経由で直接アクセスできます。ランタイム環境は、独立プロセスまたは外部プロセスではなく、アプリケーション内に埋め込まれています。EclipseLinkは、アプリケーション・コールによって起動され、永続データを操作できるようにします。この機能により、共有データベース接続およびキャッシュされたオブジェクトへのスレッド・セーフなトランザクション・アクセスが可能になります。

EclipseLink APIには、JPA 2.0 (JSR-338)のリファレンス実装が用意されています。org.eclipse.persistence.*クラスは、EclipseLinkのAPIをカプセル化して、仕様には定義されていない拡張機能を提供します。これらの拡張機能には、EclipseLink固有のプロパティと注釈が含まれています。API、プロパティおよび拡張機能の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

JAXB APIは、Java SE 6に含まれます。eclipselink.jarファイルで、org.eclipse.persistence.jaxb.*クラスは、JAXBに対するEclipseLinkのサポートをカプセル化します。

TopLink Grid APIは、toplink-grid.jarファイルに含まれます。oracle.eclipselink.coherence.*クラスは、TopLink Gridに対するEclipseLinkのサポートをカプセル化します。

oracle.toplink.*クラスによって表現されていたTopLink Essentialsの古い永続性API (JPA 1の実装)は、TopLinkから削除され、EclipseLinkに置き換えられました。同様にoracle.toplink.*クラスによって表現されていた古いネイティブTopLink API (JPA以前のマッピングおよび永続性API)は、EclipseLinkのパッケージ名を使用してEclipseLinkに再実装されています。

1.4.2 オブジェクト・リレーショナル(JPA 2.1)・コンポーネント

JPAは、Java永続性を簡略化します。これには、Javaオブジェクトをリレーショナル・データベース表に標準的で移植性の高い方法でマップする方法を宣言で定義できるようにするオブジェクト・リレーショナル・マッピングのアプローチが用意されています。JPAは、Java EEアプリケーション・サーバーの内部およびJava Standard Edition (Java SE)アプリケーションのEJBコンテナの外部の両方で動作します。2.1 JPAの更新に含まれている主な機能は、次のとおりです。

- オブジェクト/リレーショナル・マッピング機能の拡張

- 埋込みオブジェクト・コレクションのサポート

- 複数レベルの埋込みオブジェクト

- 順序付けられたリスト

- アクセス・タイプの組合せ

- 基準問合せAPI

- 問合せ「ヒント」の標準化

- DDL生成をサポートするための追加メタデータの標準化

- 検証のサポート

1.4.3 JAXBコンポーネント

JAXBは、XML文書をJava形式でJavaプログラムに提示することにより、JavaプログラムがXML文書にアクセスできようにするJava APIです。このプロセスはバインディングと呼ばれ、コンピュータ・メモリー内のオブジェクトとして、XML文書内に情報が表現されます。これにより、Domain Object Model (DOM)またはStreaming API for XML (SAX)を使用してXML自身の直接表現からデータを取得しなくても、オブジェクトからXML内のデータにアクセスできるようになります。通常、XMLバインディングをJPAエンティティとともに使用し、JAX-WSまたはJAX-RSの実装を利用して、データ・アクセス・サービスを作成します。これら両方のWebサービス標準では、JAXBがデフォルトのバインディング・レイヤーとして使用されています。このサービスにより、クライアント・コンピュータでJavaが使用されている場合とそうでない場合がある複数のコンピュータ間で、JPAによって公開されたデータにアクセスできるようになります。

JAXBでは、注釈の拡張セットを使用して、JavaからXMLへのマッピングのバインディング・ルールを定義します。これらの注釈は、EclipseLink APIのjavax.xml.bind.*パッケージのサブクラスになっています。これらの注釈の詳細は、Oracle TopLink Java APIリファレンスを参照してください。

JAXBの詳細は、次の『Java Architecture for XML Binding (JAXB)』を参照してください。

http://www.eclipse.org/eclipselink/moxy.php

1.4.4 MOXyコンポーネント

MOXy (Object-XMLとも呼ばれます)は、EclipseLink JAXBの実装です。このコンポーネントにより、JavaクラスをXMLスキーマにバインドできます。MOXyは、注釈を通じてマッピング情報を提供できるJAXBを実装しています。XML形式でマッピングを格納する方法のサポートは、MOXyによって提供されます。提供されている多数の高度なマッピングによって、Javaクラス・モデルでスキーマをミラーリングしなくても、複雑なXML構造を処理できます。

EclipseLink JAXBコンパイラで生成されるオブジェクトは、Java POJOモデルです。これらは、JAXB仕様で要求されている必要な注釈を使用して生成されます。JAXBランタイムAPIを使用すれば、オブジェクトをマーシャリングおよびアンマーシャリングできます。

MOXyをJAXBプロバイダとして使用する際には、既存のオブジェクト・モデルをXMLに変換するためのメタデータは不要です。モデルのXML表記を微調整する必要がある場合にのみ、(注釈またはXMLを使用して)メタデータを指定できます。

EclipseLink MOXyを使用して、次の方法でXMLを操作できます。

- XMLスキーマからのJavaモデルの生成

- EclipseLink MOXy JAXBランタイムの指定

- JAXBを使用したXMLの操作

- JavaモデルからのXMLスキーマの生成

MOXyおよびそれらの使用例の詳細は、『Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

EclipseLinkでは、オブジェクト・モデルがXMLスキーマにマップされる方法を制御できるようにしながら、最大限の柔軟性を実現しています。自分のオブジェクト・モデルを制御できることには、多くの利点があります。

- 適切なパターンおよびプラクティスを使用して、ドメイン・クラスを自分のアプリケーション専用に設計できます。

- XPathベースのマッピングを使用できます。これにより、クラスとXMLスキーマ・タイプの間に1対1の関係が必要なくなります。詳細は、『Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

- アプリケーションに適切な方法でオブジェクトをインスタンス化できます。

- 自分のクラスパスの依存性を制御できます。ほとんどのJAXB実装では、クラス・パスの依存性をアプリケーションに追加するために生成されるクラスに、ベンダー固有コードを配置します。

EclipseLinkの主な利点の1つは、マッピング情報を外部に保存できるので、JavaクラスやXMLスキーマを変更する必要がないことです。つまり、ドメイン・オブジェクトを複数のスキーマにマップできます(または、スキーマが変更された場合には、ドメイン・クラスを変更するかわりに、マッピング・メタデータを更新できます)。サード・パーティのクラスをマッピングする際には、ソースにアクセスして注釈を追加できないこともあるため、その場合にも便利です。

1.4.4.1 SDOコンポーネント

Service Data Objects (SDO)コンポーネントには、Service Data Objectsバージョン2.1.1のリファレンス実装が用意されています。リファレンス実装は、JSR-235に記載されています。SDOの実装には、リファレンス実装が組み込まれており、JavaオブジェクトからXMLへの変換、およびサービス・アーキテクチャに組み込めるデータ・オブジェクト・モデルの作成や使用に主に使用する追加機能が提供されています。

SDOでは、次の機能が提供されます。

- SDO APIの使用

- XMLスキーマの変換

- SDOで使用するためのXSDのカスタマイズ

- 動的データ・オブジェクトを使用したXMLの操作

- 静的データ・オブジェクトの使用

- SDOコンパイラの実行: タイプ・セーフなデータ・オブジェクトの生成

- タイプ・セーフなデータ・オブジェクトを使用したXMLの操作

詳細は、EclipseLinkドキュメントの「Getting Started with EclipseLink SDO」を参照してください:

http://www.eclipse.org/eclipselink/moxy.php

1.4.5 データベースWebサービス・コンポーネント

データベースWebサービス(DBWS)では、Webサービスを使用して、リレーショナル・データベース・アーティファクトに簡単かつ効率的にアクセスできます。Javaコードを記述しなくても、データベースに対して、クライアントに中立なJava EE準拠のアクセスが可能になります。DBWSでは、既存のORMおよびOXMコンポーネントを使用しながら、EclipseLinkのコア機能を拡張します。

DBWSには、サービス・ディスクリプタ(および関連するデプロイメント・アーティファクト)を使用して、それをJAX-WS 2.0 Webサービスとして実現するランタイム・プロバイダ・コンポーネントがあります。ランタイム・プロバイダは、EclipseLinkを使用して、Webサービス・クライアントが使用するXML SOAPメッセージとデータベース間の橋渡しをします。DBWSアーキテクチャの詳細は、Oracle TopLink Database Webサービスによる永続性アーキテクチャの開発の開発者ガイドを参照してください。

1.4.6 TopLink Grid

Oracle Coherence (Coherence)を使用してJPAアプリケーションをスケール・アウトし、グリッドに書き込み、グリッドをデータ・ソースとして扱えます。TopLink Gridは、Coherenceを分散共有(L2)キャッシュとして使用することから、JPQL問合せをCoherenceに送ってグリッド全体でパラレル実行してデータベース負荷を削減することまで、スケール・アウトに関する多数のオプションをアプリケーションに提供します。TopLink Gridでは、スケール・アウトするアプリケーションをリライトする必要はありません。

TopLink Gridは、EclipseLink JPA実装とOracle Coherenceとを統合するもので、次の開発アプローチを提供します。

- Coherence APIをTopLink Gridによって支援されたキャッシュとともに使用して、JPAに対して実装された特殊なキャッシュ・ローダーおよびキャッシュ・ストア・インタフェースでリレーショナル・データにアクセスできます。

- JPAを使用してアプリケーションを構築し、データ・グリッドの機能を透過的に使用してスケーラビリティとパフォーマンスを向上させることができます。このような「グリッド基盤のJPA」アプローチにおいては、TopLink Gridが、キャッシュのセットと、EclipseLinkのJPA実装でのCoherenceの使用方法を制御できる問合せ構成オプションを提供します。

注意:
TopLink Gridの機能は、toplink-grid.jarファイルによって提供されています。このファイルを使用できるのは、Oracle Coherenceのライセンスを保持している場合のみです。

1.5 主要ツール

この項では、Oracle JDeveloper、Oracle Enterprise Pack for Eclipse、EclipseおよびNetBeans開発環境によって提供されるTopLinkのサポートについて説明します。どのツールもTopLinkと互換性がありますが、それぞれ特定の統合方法があります。

この項の内容は次のとおりです。

- Oracle JDeveloper

- Oracle Enterprise Pack for Eclipse

- Eclipse

- NetBeans

1.5.1 Oracle JDeveloper

Oracle JDeveloperは、E-BusinessアプリケーションとWebサービスの開発、デバッグおよびデプロイをエンドツーエンドでサポートするJava EE開発環境です。

JDeveloperの詳細およびダウンロードは、次を参照してください。

http://www.oracle.com/us/products/tools/019657.htm

JDeveloperには、EclipseLinkを使用するアプリケーションの開発を支援する多くの機能が含まれています。これらの機能には、データベース表からJPAエンティティをリバース・エンジニアリングし、EntityManagerが挿入されたEJB 3.0セッションBeanを生成するウィザードが含まれています。これには、JPAエンティティを問い合せるメソッドも含まれ、クライアントの生成をテストできます。

JDeveloperのツールを使用すると、JavaクラスおよびJPAエンティティを迅速かつ容易に構成し、コードを使用せずに、リレーショナル・データベースやXMLスキーマなどの様々なデータ・ソースにマップできます。

EclipseLinkインストールに含まれているDBWSBuilderスクリプトを使用すると、DBWSBuilderユーティリティを実行してWebサービスを生成できます。JDeveloperは、付属のAPIを使用しますが、DBWSBuilderスクリプトは直接使用しません。

Oracle JDeveloperのTopLinkサポートの詳細は、JDeveloperのオンライン・ヘルプを参照してください。

1.5.2 Oracle Enterprise Pack for Eclipse

Oracle Enterprise Pack for Eclipse (OEPE)は、Eclipseが優先IDEである場合に、Java EEの開発をサポートするように設計された一連のプラグインです。

OEPEの詳細およびダウンロードは、次を参照してください。

http://www.oracle.com/technetwork/developer-tools/eclipse/overview/index.html

OEPEは、EclipseLinkのJPA実装を使用する永続層を作成するために、次のタスクを完了できるように支援します。

- JPAプロジェクトに対する永続性プロバイダの構成。
OEPEには、Eclipse JPAプロジェクトで使用できるEclipseLinkプロジェクト・ファセットが用意されています。EclipseLinkプロジェクト・ファセットを選択すると、プロジェクトが次のように変更されます。

- Oracle WebLogic Server 11gリリース1に同梱されているEclipseLink永続性プロバイダのJARファイルが含まれるようにプロジェクト・ビルド・パスが自動的に構成されます。Oracle WebLogic Serverの初期のバージョンにはライブラリ・ファイルが同梱されていませんが、ファセット構成ウィザードを使用してダウンロードできます。

- Eclipse JPAプロジェクトのpersistence.xmlファイルに、EclipseLink固有のデータベース接続プロパティを自動的に構成できます。

- JPAエンティティの生成。
OEPEでは、OEPE JPAエンティティ生成ウィザードを使用してJPAエンティティを生成できます。

- JavaクラスのXMLスキーマへのマップ。
OEPEでは、JAXBプロバイダとしてMOXyを使用し、JavaクラスをXMLスキーマにマップできます。

- Javaクラスの注釈指定。
OEPEを使用すれば、データベース・スキーマに基づくJPA注釈を既存のJavaクラス(POJO)に指定できます。そうする際にEclipseでは、適切なアクセッサにJPA注釈が追加されます。

- JPAエンティティ・ダイアグラム・エディタの使用。
OEPEには、JPAプロジェクト内のエンティティ関係を表示するためのグラフィカル・ユーザー・インタフェースが用意されています。エンティティ・ダイアグラム・エディタを使用すれば、エンティティ間の関係の表示および変更、エンティティ・ソース・コードへの容易なアクセス、追加のオブジェクト・リレーショナル・マッピングの作成を行えます。このエディタでは、エンティティとエンティティのフィールドの両方のプロパティを編集できます。また、永続性コンテキストを記述するpersistence.xmlファイルも編集できます。

- SQLスキーマ・ビューアの使用。
OEPEでは、データベース・スキーマ間の表および関係を表示するSQLスキーマ・ビューアを使用して、データベース・スキーマを調べることができます。このビューアでは、表ノードとして表が表示されます。各ノードには、表のすべての列が一覧表示され、列のデータ型が表示されます。また、ノードには、アイコンの形で、主キーと外部キーのインジケータも表示されます。表の間の外部キーの関係は、矢印の形で、リンクによって表されます。

1.5.3 Eclipse

Eclipse IDEには、JPAを使用するアプリケーションの作成、実行および保守を支援する多くの機能とユーティリティが用意されています。OEPEをインストールすると、これらの機能が拡張されます。

Eclipse IDEの詳細およびダウンロードは、次を参照してください。

http://www.oracle.com/technetwork/developer-tools/eclipse/overview/index.html

Dali Java永続性ツール・プロジェクトには、JPAエンティティのオブジェクト・リレーショナル・マッピングの定義および編集用の拡張可能なフレームワークとツールが用意されています。JPAマッピングのサポートは、エンティティ生成ウィザード、デザインタイム検証、エンティティと永続性ユニット構成用の高機能UIを提供することにより、マッピングの複雑さを最小限に抑えることを目的としています。

Daliの詳細およびダウンロードは、次を参照してください。

http://www.eclipse.org/webtools/dali

オラクル社、オープン・ソースおよびサード・パーティ・ベンダー・コミュニティが提供するその他のツールおよびユーティリティは、Eclipse Marketplaceで入手できます。

http://marketplace.eclipse.org/

1.5.4 NetBeans

NetBeans IDEには、TopLinkを含むOracle GlassFish Serverがバンドルされています。このIDEでは、JPAベースのコード環境が完全にサポートされています。このサポートには、エンティティを作成するためのエンティティ・クラス・ウィザード、およびエンティティがJPA仕様に準拠していることを確認するためのエディタ・ヒントが含まれています。NetBeansには、persistence.xmlファイルを作成するための永続性ユニット・エディタも用意されています。

NetBeansの詳細およびダウンロードは、次を参照してください。

http://netbeans.org/index.html

2 オブジェクト・リレーショナルおよびMOXyの内部の理解

この章では、オブジェクト・リレーショナルおよびMOXyアーキテクチャの機能について説明します。

この章の内容は次のとおりです。

- メタデータについて

- オブジェクト・リレーショナル・ソリューションについて

- MOXyソリューションについて

2.1 メタデータについて

EclipseLinkのメタデータは、アプリケーションの開発とデプロイされたランタイム環境の間の橋渡しをします。メタデータは次のものを使用して取得します。

- 注釈およびpersistence.xmlファイルの要素プロパティ拡張機能永続性プロバイダでは、これらすべてのメタデータのソースを解釈して、実行時にインメモリー・セッションおよびプロジェクトが作成されます。

- JavaおよびEclipseLink API (この方法は最も労力が必要とされます)。

メタデータを通じて、構成情報をランタイム環境に渡すことができます。ランタイム環境では、永続クラス(Javaオブジェクトまたはエンティティ)およびEclipseLink APIを使用して記述されたコードとともにこの情報を使用して、アプリケーションが完成します。

詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオーバーライドおよびマージに関する項を参照してください。

図2-1 EclipseLinkのメタデータ

「図2-1 EclipseLinkのメタデータ」の説明

この項の内容は次のとおりです。

- メタデータ・アーキテクチャの利点

- プロジェクト・メタデータの作成

- セッション・メタデータの作成

2.1.1 メタデータ・アーキテクチャの利点

EclipseLinkメタデータ・アーキテクチャによって、次のような多くの重要な利点が提供されます。

- ドメイン・モデル・オブジェクト内ではなく、XML内にマッピング情報を格納します。

- メタデータを使用することにより、EclipseLinkはオブジェクト・モデルまたはデータベース・スキーマに介入しません。

- 開発者は、特定の設計を強引に通すことなく、必要に応じてオブジェクト・モデルを設計できるようになります。

- DBAは、特定の設計を強引に通すことなく、必要に応じてデータベースを設計できるようになります。

- コード生成(設計、実装、メンテナンスなどの重大な問題の原因になる可能性がある)に依存しません。

- 非介入型です。EclipseLinkに適合するようにオブジェクト・モデルまたはデータベース・スキーマを設計することを開発者に要求するのではなく、メタデータ自らがオブジェクト・モデルおよびデータベース・スキーマに適応します。

EclipseLink JPAを使用すると、標準のJPAの注釈、デプロイXMLまたはその両方を使用して永続性メタデータを柔軟に表現でき、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能もオプションで利用できます。

2.1.2 プロジェクト・メタデータの作成

プロジェクトには、EclipseLinkランタイムがオブジェクトをデータ・ソースへマップするために使用するマッピング・メタデータが含まれています。プロジェクトは、EclipseLinkランタイムが使用するプライマリ・オブジェクトです。

この項では、プロジェクト・メタデータの最も重要な、次のような内容について説明します。

- エンティティ・マッピング

- データ・ソース・ログイン情報

オブジェクト・リレーショナル・マッピングでは、EclipseLinkランタイムは、JPAの注釈、persistence.xml、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能の任意の組合せに基づき、インメモリー・プロジェクトを構成します。

MOXyマッピングでは、EclipseLinkランタイムは、JAXBの注釈とeclipselink-oxmバインディングの組合せを使用します。『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオーバーライドおよびマージに関する項を参照してください。

2.1.2.1 エンティティ・マッピング

EclipseLinkは、永続性エンティティをアプリケーションのデータベースにマップします。次のようないくつかのプロジェクト開発へのアプローチがあります。

- マッピング用のクラスと表のインポート

- クラスのインポート、および表とマッピングの生成

- 表のインポート、およびクラスとマッピングの生成

- クラス定義と表定義の作成

最も一般的なソリューションは、モデリング・ツールやJDeveloperのような統合開発環境(IDE)などの開発ツールを使用して永続エンティティを開発すること、および適切なリレーショナル設計ツールを使用してリレーショナル・モデルを開発することです。その後、開発者はJDeveloperを使用して、これら2つのモデルを関連付けるマッピングを作成します。

JDeveloperには、アプリケーションの永続エンティティまたはリレーショナル・モデル・コンポーネントを生成するための機能がいくつか用意されていますが、これらのユーティリティの目的はアプリケーションのラウンドトリップ開発を完了することではなく、迅速な初期開発戦略を支援することのみです。

詳細は、第5章「ディスクリプタの理解」および第6章「マッピングの理解」を参照してください。

2.1.2.2 データ・ソース・ログイン情報

POJOプロジェクトの場合、データ・ソースへのアクセスに必要な情報を指定するセッション・メタデータでセッション・ログインを構成します。

詳細は、2.1.3項「セッション・メタデータの作成」を参照してください。

2.1.3 セッション・メタデータの作成

EclipseLinkセッションには、データ・ソースにアクセスするために必要な情報が含まれます。セッションは、EclipseLinkランタイムの機能にアクセスするためにアプリケーションが使用するプライマリ・オブジェクトです。

EclipseLinkランタイムは、EclipseLink JPAを使用して、JPAおよびEclipseLinkの注釈、JPAの永続性プロパティ(persistence.xmlファイル内)およびEclipseLinkのプロパティの拡張機能の任意の組合せに基づき、インメモリー・セッションを構成します。『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオーバーライドおよびマージに関する項を参照してください。

2.2 オブジェクト・リレーショナル・ソリューションについて

EclipseLinkでは、完全なJPA準拠のJPA実装が提供されます。これは、すべての必須機能および多くのオプション機能に完全に準拠しています。これは、JPA仕様に記載されていないEclipseLink機能(オブジェクトレベル・キャッシュ、分散キャッシュ調整、広範なパフォーマンス・チューニング・オプション、Oracle Databaseサポートの拡張機能、高度なマッピング、オプティミスティック・ロック・オプションとペシミスティック・ロック・オプション、広範な注釈と問合せのヒントなど)もサポートしています。

詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

次の各項で、これらの機能の多くについて説明します。

- オブジェクト・リレーショナル・エンティティ・アーキテクチャの理解

- 注釈を使用したメタデータの追加

- 構成の基本について

- データ・ソースについて

- EclipseLinkキャッシュについて

- データベース問合せについて

2.2.1 オブジェクト・リレーショナル・エンティティ・アーキテクチャの理解

このエンティティ・アーキテクチャは、エンティティ、永続性ユニット、永続性コンテキスト、エンティティ・マネージャ・ファクトリおよびエンティティ・マネージャで構成されています。図2-2に、これらの要素の関係を示します。

- 永続性は、1つ以上のEntityManagerFactoryオブジェクトを作成します。

- 各EntityManagerFactoryは、1つの永続性ユニットによって構成されます。

- EntityManagerFactoryは、1つ以上のEntityManagerオブジェクトを作成します。

- 1つ以上のEntityManagerは、1つのPersistenceContextを管理します。

図2-2 エンティティ・アーキテクチャの要素間の関係

「図2-2 エンティティ・アーキテクチャの要素間の関係」の説明

2.2.1.1 エンティティ

エンティティは、アプリケーションで定義されたオブジェクトで、次の特性があります。

- 永続化することが可能です。

- 永続識別子を持ちます(永続識別子とは、エンティティ・インスタンスを一意に識別し、そのインスタンスを同じエンティティ・タイプの他のインスタンスから区別するキーです。エンティティは、データ・ストアにそのエンティティを表現するオブジェクトが存在する場合、永続識別子を持ちます)。

- エンティティの永続性ビューに関してトランザクション的であるという点で、トランザクション的です(エンティティは、トランザクション内で作成、更新および削除され、変更のデータベースへのコミット時にはトランザクションが必要です)。ただし、メモリー内エンティティは、変更を永続化することなく更新できます。

- プリミティブ・オブジェクト、プリミティブ・ラッパー・オブジェクトまたは組込みオブジェクトではありません。エンティティは、単一の場所(表の行など)に通常格納される集約された状態のセットを保持する粒度の細かいオブジェクトであり、他のエンティティに対するリレーションシップを持ちます。

エンティティには、エンティティを記述するエンティティ・メタデータも含まれています。エンティティ・メタデータは、データベースに対して永続化されません。これは、エンティティがロードされてから実行時に起動されるまでの間、永続性レイヤーがエンティティを管理するために使用されます。メタデータは、Javaプログラミング要素またはXMLファイル(ディスクリプタ)の注釈として表現できます。詳細は、第4章「エンティティの理解」を参照してください。

現在のリリース以降では、マッピングを自動的に追加できる拡張可能なエンティティを定義および使用できます。この場合、エンティティには、静的属性ではなく、マップ内に拡張された属性が保存されます。次に、エンティティは、eclipselink-orm.xmlマッピング・ファイルを使用して、このマップの値をデータベースにマップする方法を定義します。EclipseLinkでは、動的にマッピングを定義できることに加えて、これらの拡張されたマッピングを保存して外部から管理することもできます。この外部保存によって、アプリケーションの実行中に、拡張されたマッピングを定義できるようになりました。エンティティを拡張可能にする方法の詳細は、Oracle TopLinkのソリューション・ガイドのSoftware as a Serviceの提供に関する項を参照してください。

2.2.1.2 永続性と永続性ユニット

永続性は、エンティティの特性です。つまり、エンティティはデータ・ストアで表すことができ、後でアクセスできます。

永続性ユニットは、永続化可能なユニットを識別し、それに関連するプロパティを定義します。また、永続化する必要があるオブジェクトも定義します。オブジェクトは、エンティティ・クラス、埋込み可能クラス、マップされたスーパークラスのいずれかです。永続性ユニットでは、エンティティ・マネージャ・ファクトリの構成が提供されます。エンティティ・マネージャ・ファクトリによって作成されたエンティティ・マネージャは、永続性ユニットに定義されたプロパティを継承します。

2.2.1.3 エンティティ・マネージャ

エンティティ・マネージャは、エンティティに対して操作を実行するAPIコールを有効にします。エンティティ・マネージャを使用してエンティティの作成、読取り、書込みのいずれかを行うまで、エンティティは、非永続性Javaオブジェクトです。エンティティ・マネージャがエンティティへの参照を取得すると、そのエンティティはエンティティ・マネージャによって管理されるようになります。特定の時点でのエンティティ・マネージャ内の管理対象エンティティ・インスタンスのセットは、永続性コンテキストと呼ばれ、同じ永続性IDのJavaインスタンスは、永続性コンテキスト内に特定の時点で1つのみ存在できます。

特定のデータベースを対象とする読取りまたは書込み、特定タイプのオブジェクトの永続化または管理、および特定の永続性プロバイダによる実装を行うようエンティティ・マネージャを構成できます。永続性プロバイダにより、EntityManagerインタフェース実装、Query実装、SQL生成などのJPAの実装が提供されます。エンティティ・マネージャはEntityManagerFactoryによって提供されます。エンティティ・マネージャの構成は、EntityManagerFactoryに依存しますが、永続性ユニットとして個別に定義されます。永続性ユニットに名前を付けることで、各EntityManagerFactoryオブジェクトを区別できます。この方法により、特定のエンティティの操作にどの構成を使用するかをアプリケーションで制御できます。永続性ユニットを記述する構成は、persistence.xmlファイルで定義します。特定の構成をEntityManagerFactoryにバインドするようにリクエストできるようにするために、永続性ユニットに名前を付けます。

2.2.2 注釈を使用したメタデータの追加

注釈は、JPA永続性プロバイダが永続動作を管理するために実行時に解釈できるように、対応するJavaクラス・ファイルにコンパイルされるメタデータを使用してJavaソース・コードを修飾するための簡単な表現手段です。

メタデータ注釈は、構造化メタデータおよび型指定メタデータをソース・コードに添付するJava言語の機能を表します。メタデータ指定には注釈のみで十分であり、XMLを使用する必要はありません。標準のJPA注釈は、javax.persistenceパッケージにあります。

詳細は、JPA仕様(http://jcp.org/en/jsr/detail?id=338)の第10章「Metadata Annotations」を参照してください。

EclipseLinkには、Javaソース・コードに簡単にメタデータを追加できるように、一連の独自仕様の注釈が用意されています。メタデータは、対応するJavaクラス・ファイルにコンパイルされ、実行時にJPA永続性プロバイダによって解釈されて、永続性動作が管理されます。注釈は、クラス、メソッドおよびフィールドのレベルに適用できます。

EclipseLinkの注釈では、JPAメタデータの使用を介して現在入手できない一部の機能が公開されています。

- 基本プロパティ: デフォルトでは、EclipseLinkの永続性プロバイダは、シンプル・タイプに対する基本マッピングを自動的に構成します。これらの注釈を使用して、フィールドまたはプロパティのエンティティの即時の状態を微調整します。

- 関係: EclipseLinkには、1対1や1対多などの一部の関係がデフォルトで含まれます。他の関係は、明示的にマップする必要があります。注釈を使用して、エンティティ関係のタイプおよび特性を指定して、これらの関係をデータベースでどのように実装するかを微調整します。

- 埋込みオブジェクト: 埋込みオブジェクトには、それ自体の永続識別子は存在せず、識別子に関しては、エンティティに依存しています。デフォルトで、永続性プロバイダでは、すべてのエンティティがそれ自体の表にマップされることが想定されます。注釈を使用して、他のエンティティが所有するエンティティに対して、この動作をオーバーライドします。

2.2.2.1 注釈使用の長所と短所

注釈を使用する場合の利点は、次のとおりです。

- 比較的簡単に使用および理解できます。

- 記述しているコード内にインラインのメタデータとして提供されるため、メタデータの適用先となるソース・コードのコンテキストをレプリケートする必要がありません。

注釈の主な短所は、メタデータが不必要にコードに結合されるため、メタデータを変更する場合にソース・コードを変更して再コンパイルする必要があることです。

2.2.3 構成の基本について

次の項では、オブジェクト・リレーショナル・マッピング・プロジェクトの主な構成ファイルのいくつかについて説明します。

2.2.3.1 デフォルト注釈値

各注釈には、デフォルト値があります(詳細はJPA仕様を参照)。永続性エンジンにより、アプリケーションの大半に適用されるデフォルトが定義されます。デフォルト値をオーバーライドするには、単に値を指定します。したがって、必ずしも構成値を指定する必要はなく、指定はこの原則の例外となります。これは、例外による構成と呼ばれます。

注意:
必要時に動作を変更できるように、ユーザーはデフォルト値を把握しておく必要があります。

デフォルト値の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。JPA仕様の第10章「Metadata Annotations」も参照してください。

http://jcp.org/en/jsr/detail?id=338

この構成は例外処理として行われます。つまり、構成ファイルのいずれかに値が指定されていない場合は、デフォルト値が使用されます。

2.2.3.2 persistence.xmlを使用した永続性ユニットの構成

永続性ユニットでは、エンティティ・マネージャを取得する際に必要な詳細を定義します。エンティティ・マネージャ・ファクトリを取得する場合、永続性ユニットを名前で指定します。永続性ユニットを構成するには、JPA永続性ファイルpersistence.xmlを使用します。ベンダー固有の拡張機能は、<properties>要素を使用して、このファイルに指定できます。

このファイルは、永続性ユニットのJARファイルのMETA-INF/ディレクトリまたはクラスパスにあります。

詳細は、3.1項「永続性ユニットについて」を参照してください。『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の永続性プロパティの拡張機能リファレンスに関する項も参照してください。

2.2.3.3 オブジェクト・リレーショナル・データ・タイプ・マッピング

オブジェクト・リレーショナル・データ・タイプ・マッピングは、特定オブジェクトのデータ・メンバー・タイプを、Oracle Databaseのような特別なオブジェクト・リレーショナル・データベースでの格納に最適化された構造化データ・ソース表現に変換します。オブジェクト・リレーショナル・データ・タイプ・マッピングを使用すると、オブジェクト・モデルをオブジェクト・リレーショナル・モデルにマップできます。オブジェクト・リレーショナル・データ・タイプ・マッピングは、オブジェクト・リレーショナル・データ・タイプ・データ・ソース表現をサポートするために最適化された特別のオブジェクト・リレーショナル・データベースにのみ使用できます。

詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

2.2.4 データ・ソースについて

永続性ユニットの定義で重要なのは、プロバイダが読み書きするデータを検出可能な場所です。これを、データ・ソースと呼びます。データ・ソースは、通常はデータベースです。データベースの場所は、サーバーのJNDIネームスペースのJDBCデータ・ソースの形式で指定します。

通常、EclipseLinkを使用するアプリケーションは、JTAトランザクションのコンテキストで実行します。データ・ソースの名前は、persistence.xmlファイルのjta-data-source要素に指定します。アプリケーションがトランザクションのコンテキストで実行されない場合は、resource-localと見なされます。この場合は、non-jta-data-source要素に、データ・ソースの名前を指定します。

XMLスキーマなどのリレーショナル・データベース以外のデータ・ソースも指定できます。

詳細は、第7章「データ・アクセスの理解」を参照してください。

アプリケーションは、スタンドアロン(Java SE)・モードで実行できます。このモードでは、非JTA準拠のデータ・ソースとともに、非Oracleスタックにおいて、サーバーの外部でアプリケーションが実行されます。この場合、JDBCドライバ・クラス、データベースに接続するためにクライアントが使用するURL、データベースにアクセスするためのユーザー名とパスワードなどのドライバ固有の情報を指定する必要があります。アプリケーションをスタンドアロン・モードで実行する方法の詳細および例は、Oracle TopLinkのソリューション・ガイドのコンテナ外部でのTopLink JPAのテストに関する項を参照してください。

2.2.5 EclipseLinkキャッシュについて

EclipseLinkのデフォルトでは、読み取られて永続性ユニットに対して永続化されたすべてのオブジェクトのサブセットがキャッシュされる、共有オブジェクト・キャッシュが使用されます。共有キャッシュは、ローカルのEntityManagerキャッシュとは異なります。共有キャッシュは、永続性ユニット(EntityManagerFactoryまたはサーバー)の期間存在し、永続性ユニットのすべてのEntityManagerおよびユーザーによって共有されます。ローカルのEntityManagerキャッシュは共有されず、EntityManagerまたはトランザクションの期間のみ存在します。

共有キャッシュの利点は、オブジェクトを読み取ると、同じオブジェクトを再度読み取る際にデータベースにアクセスする必要がないことです。また、問合せを使用してオブジェクトを読み取る場合は、オブジェクトを再作成する必要はなく、オブジェクトの関係も再度フェッチする必要がありません。

共有キャッシュの制限は、JDBC経由または別のアプリケーションやサーバーによってデータベースが直接変更されると、共有キャッシュのオブジェクトが失効することです。

EclipseLinkには、失効データを扱うために、次のようなメカニズムが用意されています。

- リフレッシュ

- 無効化

- オプティミスティック・ロック

- キャッシュ・コーディネーション

- データベース変更通知(DCN)

共有キャッシュは無効にしたり、@Cacheまたは@Cacheable注釈を使用して、選択的に有効化または無効化することもできます。EclipseLinkには、キャッシュするオブジェクト数および使用するメモリー量を構成するためのキャッシュ戦略もいくつか用意されています。

キャッシュが最新でないことをアプリケーションが検出した場合、アプリケーションはプログラムでキャッシュをクリア、リフレッシュまたは無効化できます。キャッシュされているオブジェクトのいずれかが使用中の場合にキャッシュをクリアすると、オブジェクト・アイデンティティの問題が発生する場合があるので、無効化する方が安全です。キャッシュされているオブジェクトのいずれも使用中でないことがわかっている場合は、キャッシュをクリアできます。

詳細は、第8章「キャッシュの理解」を参照してください。

2.2.5.1 キャッシュ動作の定義

EclipseLinkには、キャッシュ・プロパティを定義できる@Cache注釈が用意されています。プロパティには、キャッシュのタイプ、サイズ、リフレッシュ・ルールなどが含まれます。『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

2.2.5.2 クラスタ化環境でのキャッシング

あるサーバーでの変更は他のサーバーにキャッシュされているオブジェクトには反映されないため、クラスタ化環境でのキャッシングでは問題が発生する場合があります。これは、読取り専用オブジェクトでは問題になりませんが、頻繁に更新されるオブジェクトでは問題になります。

EclipseLinkには、この問題に対する解決策がいくつか用意されています。

- 頻繁に変更されるクラスに対してはキャッシュを無効にできます。

- キャッシュ・コーディネーションを使用して、クラスタ内のサーバー間で変更をブロードキャストして、変更されたオブジェクトを更新または無効化できます。

- 存続時間または時刻に基づいてキャッシュを無効化できます。

- オプティミスティック・ロックを使用して、無効なオブジェクトへの更新を防ぎ、キャッシュ内でオブジェクトが無効化されるようにトリガーすることができます。

詳細は、8.10項「クラスタリングおよびキャッシュ・コーディネーション」を参照してください。

2.2.6 データベース問合せについて

EclipseLinkのオブジェクト・リレーショナル・コンポーネントは、様々な問合せをサポートしています。

- JPQL問合せ

- SQL問合せ

- Criteria API問合せ

- ネイティブSQL問合せ

- EclipseLink JPA問合せヒント

- 問合せのキャスト

- 問合せ用のOracle拡張機能

- 拡張EclipseLinkネイティブ問合せ

これらの問合せの詳細は、第9章「問合せの理解」を参照してください。

2.3 MOXyソリューションについて

EclipseLinkによって提供されるMOXyコンポーネントでは、JavaクラスをXMLスキーマに効率的にバインドできます。MOXyではJAXBが実装されるので、注釈でマッピング情報を提供でき、マッピングをXML形式で保存できます。

JAXB (Java Architecture for XML Binding—JSR 222)は、JavaのXMLバインディングの標準です。JAXBでは、XMLスキーマの概念が100%カバーされています。EclipseLinkでは、JAXBの実装が多くの拡張機能とともに提供されています。

EclipseLink MOXyをJAXBプロバイダとして使用する際には、既存のオブジェクト・モデルをXMLに変換するためのメタデータは不要です。XML表記を微調整する必要がある場合は、(注釈またはXMLを使用して)メタデータを指定できます。

MOXyには、Javaクラス・モデルでスキーマをミラーリングしなくても、複雑なXML構造を処理できる高度なマッピングが多数含まれています。

詳細は、『Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

次の各項で、これらの機能の多くについて説明します。

- JAXBプロバイダとしてのEclipseLink MOXyの使用

- MOXyアーキテクチャの理解

- MOXyに対するメタデータの提供

- XMLバインディングについて

- XPathによるオブジェクトの問合せ

2.3.1 JAXBプロバイダとしてのEclipseLink MOXyの使用

MOXyをJAXBプロバイダとして使用するには、JAXBランタイムへのエントリ・ポイントを指定する必要があります。このエントリ・ポイントは、EclipseLink JAXBContextFactoryクラスです。

エントリ・ポイントを識別するには、jaxb.propertiesというテキスト・ファイルを作成して、JAXBContextFactoryクラスへのパスをjavax.xml.bind.context.factoryコンテキスト・パラメータの値として、次のように入力します。

javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory

jaxb.propertiesファイルは、ドメイン・クラスと同じパッケージに存在する必要があります。

2.3.2 MOXyアーキテクチャの理解

図2-3に示されているMOXyのサンプル・アーキテクチャでは、開始点はXMLスキーマになっています。バインディング・コンパイラは、スキーマから導出されたプログラム・クラスおよびインタフェースのセットにソース・スキーマをバインドします。アプリケーション内のJAXBの注釈が付いたクラスは、スキーマ・コンパイラで生成されるか、開発者がJAXB注釈を既存のJavaクラスに追加した結果によって生成されます。アプリケーションは、データをXML文書にマーシャリングするか、データをコンテンツ・オブジェクトのツリーにアンマーシャリングできます。各コンテンツ・オブジェクトは、導出されたスキーマ、またはスキーマ・ジェネレータによってマップされた既存のプログラム要素のどちらかのインスタンスで、XML内のインスタンスに対応しています。

図2-3 MOXyのサンプル・アーキテクチャ

「図2-3 MOXyのサンプル・アーキテクチャ」の説明

2.3.2.1 JAXBコンテキストおよびJAXBコンテキスト・ファクトリ

JAXBContextFactoryクラスは、EclipseLink JAXBランタイムへのエントリ・ポイントです。これは、必須のファクトリ・メソッドを提供し、JAXBContextオブジェクトの新しいインスタンスを作成できます。

JAXBContextFactoryクラスでは、次のことが可能です。

- クラスの配列およびプロパティ・オブジェクトからのJAXBContextオブジェクトの作成

- コンテキスト・パスおよびクラスローダーからのJAXBContextオブジェクトの作成

JAXBContextクラスは、JAXB APIに対するクライアントのエントリ・ポイントを提供します。JAXBContextクラスは、メタデータの解釈、スキーマ・ファイルの生成、およびJAXBオブジェクト(Marshaller、Unmarshaller、Binder、IntrospectorおよびValidator)のインスタンスの作成を行います。

MOXyには、JAXBContextオブジェクトを作成する際にいくつかのオプションが用意されています。次のいずれかから開始できます。

- JAXBの注釈の付いた1つ以上のクラスのリスト

- Javaクラスのマッピングが定義された1つ以上のEclipseLink XMLバインディング・ドキュメントのリスト

- クラスとXMLバインディングの組合せ

- コンテキスト・パスのリスト

2.3.3 MOXyに対するメタデータの提供

2.3.2.1項「JAXBコンテキストおよびJAXBコンテキスト・ファクトリ」に説明されている入力オプションに加えて、MOXyには、MetadataSourceオブジェクトの概念が用意されています。このオブジェクトによって、マッピング情報をアプリケーションの外部に保存して、アプリケーションのJAXBContextオブジェクトが作成またはリフレッシュされるときにそれを取得できるようになります。MetadataSourceの実装の詳細は、『Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

2.3.4 XMLバインディングについて

XMLバインディングとは、コンピュータのメモリーのオブジェクトとして、XML文書内に情報を表現する方法です。これにより、Domain Object Model (DOM)、Simple API for XML (SAX)またはStreaming API for XML (StAX)を使用してXML自身の直接表現からデータを取得しなくても、オブジェクトからXML内のデータにアクセスできるようになります。バインディングする際に、JAXBでは、JPAエンティティのグラフにツリー構造が適用されます。グラフの複数ツリー表現は可能で、選択されたルート・オブジェクトおよびリレーションシップがトラバースする方向に依存します。

EclipseLinkでは、すべての標準JAXB注釈を使用できます。EclipseLinkには、標準注釈に加えて、EclipseLink XMLバインディング・ドキュメントという、メタデータを表現する別の方法も用意されています。XMLバインディングは、マッピング情報を実際のJavaクラスから分離できるだけでなく、次のような高度なメタデータ・タスクにも使用できます。

- 追加のマッピング情報で、既存の注釈を拡張またはオーバーライドできます。

- Java注釈を使用せずに、すべてのマッピング情報を外部指定できます。

- 複数のバインディング文書にまたがるマッピングを定義できます。

- 具体的なJavaフィールドに対応しない仮想マッピングを指定できます。

詳細は、『Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

2.3.5 XPathによるオブジェクトの問合せ

EclipseLink MOXyでは、従来のJavaのアクセス・メソッドを使用してオブジェクトの値を取得および設定する方法に加えて、XPath文を使用して値にアクセスすることもできます。EclipseLinkのJAXBContextオブジェクトには、XPathで値を取得および設定できる特別なAPIがあります。詳細は、『Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

3 永続性ユニットの理解

この章では、永続性ユニットおよび永続層について詳細に説明します。

この章の内容は次のとおりです。

- 永続性ユニットについて

- 永続層の構築および使用

- オブジェクトの永続化について

- EclipseLink永続性マネージャへのアプリケーションの移行

- ウィービングについて

3.1 永続性ユニットについて

永続性ユニットでは、エンティティ・マネージャを取得する際に必要な詳細を定義します。EclipseLink JPAアプリケーションをパッケージ化するには、persistence.xmlファイルの作成時に永続性ユニットを構成する必要があります。各永続性ユニットは、persistence.xmlファイルのpersistence-unit要素で定義します。

persistence.xmlファイルを使用して、エンティティをパッケージ化します。パッケージ化戦略を選択したら、任意のアーカイブのMETA-INFディレクトリにpersistence.xmlファイルを配置します。次の項では、永続性ユニットの指定方法の詳細について説明します。詳細および例は、JPA仕様の「persistence.xml file」を参照してください。persistence.xmlファイルに対するEclipseLinkの拡張機能の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の永続性プロパティの拡張機能リファレンスに関する項を参照してください。

- 永続性ユニット名について

- トランザクション・タイプ・データ・ソースについて

- マッピング・ファイルについて

- 管理対象クラスについて

- ベンダー・プロパティについて

- デプロイメント・クラスパスについて

- 永続性ユニットのパッケージ・オプションについて

- 永続性ユニットの有効範囲について

- コンポジット永続性ユニットについて

3.1.1 永続性ユニット名について

Java EE環境でアプリケーションを開発する場合、永続性ユニット名が各モジュール内で一意であることを確認してください。たとえば、emp_ejb.jarファイル内で定義できるEmployeeServiceという名前の永続性ユニットは、1つのみです。

詳細は、JPA仕様の「name」を参照してください。

3.1.2 永続性プロバイダについて

永続性プロバイダでは、JPAの実装を定義します。これは、persistence.xmlファイルのprovider要素に定義されています。永続性プロバイダはベンダー固有のものです。EclipseLinkの永続性プロバイダはorg.eclipse.persistence.jpa.PersistenceProviderです。

3.1.3 トランザクション・タイプ・データ・ソースについて

Java EE環境でアプリケーションを開発する場合、デフォルトのトランザクション・タイプであるJTA (Java Transaction API用)を使用し、jta-data-source要素にデータ・ソースを指定します。

JTAに適合しないデータ・ソースを使用する場合は、transaction-type要素にRESOURCE_LOCALを設定して、non-jta-data-source要素に値を指定します。

デフォルトの永続性プロバイダorg.eclipse.persistence.jpa.PersistenceProviderを使用している場合は、接続メタデータに基づいて、プロバイダがデータベース・タイプの自動検出を試みます。このデータベース・タイプを使用して、検出されたデータベース・タイプに固有のSQL文が発行されます。オプションのeclipselink.target-databaseプロパティを指定すれば、データベース・タイプが正しいことを保証できます。

詳細は、JPA仕様の「transaction-type」および「provider」を参照してください。

3.1.4 ロギングについて

ロギングはJPA仕様の一部ではありませんが、EclipseLinkにはロギング・ユーティリティが用意されています。そのため、ログで提供される情報はEclipseLink JPA固有のものです。EclipseLinkでロギングを有効にすれば、次の情報を確認できます。

- 構成の詳細

- デバッグを容易にするための情報

- データベースに送信されるSQL

ロギングはpersistence.xmlファイルに指定できます。EclipseLinkのロギング・プロパティでは、ロギングのレベル、およびログの出力をファイルまたは標準出力のどちらにするかを指定できます。ロギング・ユーティリティはjava.util.loggingに基づいているので、使用するロギング・レベルを指定できます。

ロギング・ユーティリティには、ログ出力の量および詳細度を制御するロギング・レベルが9種類用意されています。ロギング・レベルは、次のようにeclipselink.logging.levelを使用して設定します。

<property name="eclipselink.logging.level" value="FINE"/>

デフォルトでは、System.outまたはコンソールにログが出力されます。出力がファイルにロギングされるように構成するには、eclipselink.logging.fileプロパティを次のように設定します。

<property name="eclipselink.logging.file" value="output.log"/>

EclipseLinkのロギング・ユーティリティはプラガブルで、java.util.loggingなどの数種類のロギング統合がサポートされています。java.util.loggingを有効にするには、eclipselink.logging.loggerプロパティを次のように設定します。

<property name="eclipselink.logging.logger" value="JavaLogger"/>

EclipseLinkでのロギングおよびロギング・ユーティリティで利用可能なロギング・レベルの詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の永続性プロパティの拡張のリファレンスに関する項を参照してください。

3.1.5 ベンダー・プロパティについて

persistence.xmlファイルの最後のセクションは、propertiesセクションです。properties要素によって、永続性ユニットに対してEclipseLink永続性プロバイダ固有の設定を指定できます。JPA仕様の「properties」を参照してください。『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の永続性プロパティの拡張機能リファレンスに関する項も参照してください。

3.1.6 マッピング・ファイルについて

永続性ユニットにメタデータを適用します。このメタデータは、すべてのマッピング・ファイルと注釈の集合です(xml-mapping-metadata-complete要素が存在しない場合)。メタデータに対して1つのマッピングorm.xmlファイルを使用し、そのファイルをクラスパスのMETA-INFディレクトリに配置する場合、それを明示的にリストする必要はありません。このファイルは、EclipseLink永続性プロバイダによって自動的に検索され、使用されます。マッピング・ファイルを別の方法で指定する場合、または別の場所に配置する場合、それらをpersistence.xmlファイルのmapping-file要素にリストする必要があります。

詳細は、JPA仕様の「mapping-file, jar-file, class, exclude-unlisted-classes」を参照してください。

3.1.7 管理対象クラスについて

通常、すべてのエンティティおよび他の管理対象クラスは、単一のJARファイルと、META-INFディレクトリのpersistence.xmlファイルおよび1つ以上のマッピング・ファイルに配置します(XMLにメタデータを格納する場合)。

EclipseLink永続性プロバイダは、永続性ユニットを処理するときに、特定の各永続性ユニットで管理するエンティティ、マップ済スーパークラスおよび埋込みオブジェクトのセットを特定します。

EclipseLink永続性プロバイダは、デプロイ時に、次のいずれかのソースから管理対象クラスを取得できます。管理対象クラスは、次のいずれかである場合に含まれます。

- ローカル・クラス: persistence.xmlファイルがパッケージ化されているデプロイメント・ユニットの@Entity、@MappedSuperclassまたは@Embeddable注釈付きのクラス。詳細は、JPA仕様の「Entity」を参照してください。

注意:
アプリケーションをJava EE環境にデプロイする場合、EclipseLink永続性プロバイダではなくアプリケーション・サーバー自体によってローカル・クラスが検出されます。Java SE環境で、exclude-unlisted-classes要素をfalseに設定すると、この機能を有効化できます(この要素をfalseに設定すると、EclipseLink永続性プロバイダによってローカル・クラスの検出が試行されます)。JPA仕様の「mapping-file, jar-file, class, exclude-unlisted-classes」を参照してください。

- マッピング・ファイルのクラス: XMLマッピング・ファイルのentity (JPA仕様の「entity」を参照)、mapped-superclass、embeddableなどのマッピング・エントリを持つクラス。詳細は、JPA仕様の「mapped-superclass」および「embeddable」を参照してください。
デプロイされたコンポーネント・アーカイブにこれらのクラスが含まれる場合、それらはすでにクラスパスに存在します。存在しない場合、それらを明示的にクラスパスに含める必要があります。

- 明示的にリストされたクラス: persistence.xmlファイルにclass要素としてリストされているクラス。
次のいずれかの場合、クラスを明示的にリストすることを検討してください。

- デプロイメント・ユニットのJARにローカルではない追加クラスが存在する場合。たとえば、永続性ユニットのエンティティで使用する異なるJARに埋込みオブジェクト・クラスが存在する場合です。この場合、persitence.xmlファイルのclass要素に完全修飾されたクラスをリストします。また、クラスを含むJARまたはディレクトリが、デプロイ済のコンポーネントのクラスパスに含まれることを確認する必要があります(たとえば、デプロイメントJARのマニフェスト・クラスパスにそれを追加します)。

- エンティティとして注釈を付けることのできる1つ以上のクラスを除外する場合。クラスに@Entity注釈を付けることができても、デプロイされた特定のコンテキストでそれをエンティティとして扱いません。たとえば、特定のエンティティを転送オブジェクトとして使用し、デプロイメント・ユニットの一部にする必要がある場合です。この場合、Java EE環境で、persistence.xmlファイルのexclude-unlisted-classes要素を使用する必要があります(この要素のデフォルト設定の使用によって、ローカル・クラスが永続性ユニットに追加されなくなります)。詳細は、JPA仕様の「mapping-file, jar-file, class, exclude-unlisted-classes」を参照してください。

- アプリケーションをJava SE環境で実行する予定で、Java SEでそれ以外に移植可能な方法がないため、クラスを明示的にリストする場合。

- 管理対象クラスの追加のJARファイル: persistence.xmlファイルのjar-file要素にリストされている名前付きJARファイルの注釈付きクラス。詳細は、JPA仕様の「mapping-file, jar-file, class, exclude-unlisted-classes」を参照してください。
jar-file要素にリストされているJARファイルが、デプロイメント・ユニットのクラスパスに含まれることを確認する必要があります。これを行うには、デプロイメント・ユニットのマニフェスト・クラスパスに手動でJARファイルを追加します。

jar-file要素のJARファイルは、persistence.xmlファイルが存在しているJARファイルの親を基準としてリストする必要があることに注意してください。これは、マニフェスト・ファイルのクラスパス・エントリに指定する内容と一致します。

3.1.8 デプロイメント・クラスパスについて

EJB JAR、WARまたはEARファイルにアクセスできるようにするには、クラスまたはJARファイルがデプロイメント・クラスパスに含まれる必要があります。これは次のいずれかの方法で可能になります。

- JARファイルをEJB JARまたはWARファイルのマニフェスト・クラスパスに配置します。
これを行うには、JARまたはWARファイルのMETA-INF/MANIFEST.MFファイルにクラスパス・エントリを追加します。空白で区切ることで、1つ以上のディレクトリまたはJARファイルを指定できます。

- EARファイルのライブラリ・ディレクトリにJARファイルを配置します。
これによって、アプリケーション・クラスパスでJARファイルを使用できるようになり、EARファイル内にデプロイされたすべてのモジュールからアクセス可能になります。デフォルトでは、これはEARファイルのlibディレクトリになりますが、application.xmlデプロイメント・ディスクリプタのlibrary-directory要素を使用して、EARファイルの任意のディレクトリとなるように構成できます。

3.1.9 永続性ユニットのパッケージ・オプションについて

Java EEでは、様々なパッケージ構成で永続性がサポートされます。アプリケーションは、次のモジュール・タイプにデプロイできます。

- EJBモジュール: エンティティをEJB JARにパッケージ化できます。EJB JARで永続性ユニットを定義する場合、persistence.xmlファイルはオプションではなく、それを作成してデプロイメント・ディスクリプタ(存在する場合)とともにJARのMETA-INFディレクトリに配置する必要があります。

- Webモジュール: WARファイルを使用してエンティティをパッケージ化できます。この場合、WEB-INF/classes/META-INFディレクトリにpersistence.xmlファイルを配置します。WARのクラスパスにWEB-INF/classesディレクトリが自動的に含まれるため、そのディレクトリを基準としてマッピング・ファイルを指定します。

- 永続性アーカイブ: 永続性アーカイブは、META-INFディレクトリにpersistence.xmlファイルを含み、そのpersistence.xmlで定義された永続性ユニットの管理対象クラスを含むJARです。異なるJava EEモジュールの複数のコンポーネントで永続性ユニットを共有するか、それにアクセスする場合、永続性アーカイブを使用します。
永続性アーカイブを作成したら、それをEARのルートまたはアプリケーション・ライブラリ・ディレクトリに配置できます。または、永続性アーカイブをWARのWEB-INF/libディレクトリに配置することもできます。この場合、永続性ユニットにアクセスできるのは、WAR内のクラスのみになりますが、永続性ユニットの定義とWebアーカイブ自体を分離することができます。

詳細は、JPA仕様の「Persistence Unit Packaging」を参照してください。

3.1.10 永続性ユニットの有効範囲について

1つのpersistence.xmlファイルに任意の数の永続性ユニットを定義できます。次に、定義済およびパッケージ化済の永続性ユニットを使用するためのルールを示します。

- 永続性ユニットには、その定義の有効範囲内でのみアクセス可能です。

- 永続性ユニット名は、その有効範囲内で一意である必要があります。

詳細は、JPA仕様の「Persistence Unit Scope」を参照してください。

3.1.11 コンポジット永続性ユニットについて

コンポジット永続性ユニットを使用すると、(エンティティ・タイプの独自のセットがそれぞれに設定された)複数の永続性ユニットを単一の永続性コンテキストとして公開できます。このコンポジット永続性ユニットの一部である個々の永続性ユニットを、コンポジット・メンバー永続性ユニットと呼びます。

コンポジット永続性ユニットでは、次のことを行えます。

- 複数の永続性ユニット内の任意のエンティティ間のリレーションシップのマッピング

- 複数のデータベースおよび様々なデータ・ソースにストアされているエンティティへのアクセス

- エンティティの完全なセット全体に対する問合せおよびトランザクションの容易な実行

図3-1は、単純なコンポジット永続性ユニットを示しています。EclipseLinkではpersistence.xmlファイルを処理し、2つのコンポジット・メンバー永続性ユニットを含むコンポジット永続性ユニットを検出します。

- クラスAは、member1.jarファイルにあるmemberPu1という名前の永続性ユニットによってマップされています。

- クラスBは、member2.jarファイルにあるmemberPu2という名前の永続性ユニットによってマップされています。

図3-1 単純なコンポジット永続性ユニット

図3-1「単純なコンポジット永続性ユニット」の説明

詳細は、Oracle TopLinkのソリューション・ガイドのコンポジット永続性ユニットによる複数のデータベースの使用に関する項を参照してください。

3.2 永続層の構築および使用

EclipseLinkでは、クラスが永続クラスになるには特定の最低要件を満たしている必要があります。EclipseLinkでは、大部分の要件を満たすための代替方法も用意しています。EclipseLinkは、オブジェクト・モデルへの介入を最小限にできるメタデータ・アーキテクチャを使用した、非介入型アプローチを使用します。

この項では、次の内容について説明します。

- 実装オプション

- 永続クラス要件

- 永続層コンポーネント

3.2.1 実装オプション

EclipseLinkを使用して永続層を実装する際は、次のオプションを検討してください。

- EclipseLink JPAメタデータ、注釈およびXMLの使用

- EclipseLinkメタデータJava APIの使用

- メソッドおよび直接フィールド・アクセスの使用

- Javaバイト・コード・ウィービングの使用

3.2.1.1 EclipseLink JPAメタデータ、注釈およびXMLの使用

JPAを使用している場合は、標準のJPAの注釈およびpersistence.xml、EclipseLink JPAの注釈の拡張機能およびEclipseLink JPAのpersistence.xmlの拡張機能を任意に組み合せて永続層コンポーネントを指定できます。

詳細は、2.2.3項「構成の基本について」を参照してください。

3.2.1.2 EclipseLinkメタデータJava APIの使用

永続層コンポーネントは、Javaでコーディングまたは生成できます。Javaコードを使用するには、project、login、platform、descriptorsおよびmappingsなど、プロジェクトの各要素に関して、コードを手動で記述する必要があります。アプリケーションがモデルベースであり、コード生成に強く依存する場合は、このほうが効率的です。

3.2.1.3 メソッドおよび直接フィールド・アクセスの使用

クラスのフィールド(データ・メンバー)にアクセスする際は、getter/setterメソッドを使用してアクセスするか(プロパティ・アクセスとも呼ばれる)、フィールド自体に直接アクセスできます。

メソッド・アクセスと直接フィールド・アクセスのどちらを使用するかは、アプリケーション設計によって決まります。次のガイドラインを考慮してください。

- クラス外ではメソッド・アクセスを使用します。
これは、クラスの本来のパブリックAPIです。getter/setterメソッドは、必要なすべての副次的な処理を行うため、クライアントはその詳細を認識する必要がありません。

- クラス内では、パフォーマンス向上のため直接フィールド・アクセスを使用します。
この場合は、getter/setterメソッドを使用しないために起動されない副次的な処理を考慮に入れる必要があります。

メソッド・アクセスと直接フィールド・アクセスのどちらを使用するかを検討する際は、次の制限を考慮してください。

getter/setterメソッドで変更追跡を有効にした場合(たとえば、メソッドsetPhoneを@ChangeTrackingで修飾した場合)は、クライアントでgetter/setterメソッドを使用してフィールド(phone)を変更すると、EclipseLinkではその変更を追跡します。

同様に、フィールドで変更追跡を有効にした場合(たとえば、フィールドphoneを@ChangeTrackingで修飾した場合)は、クライアントでフィールド(phone)を直接変更すると、EclipseLinkではその変更を追跡します。

ただし、getter/setterメソッドで変更追跡を有効にした場合(たとえば、メソッドsetPhoneを@ChangeTrackingで修飾した場合)でも、クライアントがフィールド(phone)に直接アクセスする場合は、EclipseLinkでは変更を検出しません。クラス内ではパフォーマンス向上のためフィールド・アクセスを、クラス外ではメソッド・アクセスを使用する形式でのコーディングを選択する場合は、この制限に注意してください。

詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@ChangeTracking注釈の説明を参照してください。

3.2.1.4 Javaバイト・コード・ウィービングの使用

ウィービングは、コンパイル済のJavaクラスのバイトコードを操作する方法です。

JPAエンティティとPlain Old Java Object (POJO)クラスの両方のパフォーマンスを向上するために、遅延ロード、変更追跡、フェッチ・グループ、内部最適化などの操作にウィービングを使用します。

詳細は、3.5項「ウィービングについて」を参照してください。

3.2.2 永続クラス要件

永続Javaオブジェクトを作成する場合、privateまたはprotected属性で直接アクセスを使用します。

ウィービングを使用している場合、ValueHolderInterfaceは必要ありません。詳細は、3.5項「ウィービングについて」を参照してください。インダイレクションおよび透過インダイレクションの詳細は、6.2.1項「インダイレクション(遅延ロード)」を参照してください。

3.2.3 永続層コンポーネント

アプリケーションの永続層の目的は、実行時にセッションを使用してマッピング・メタデータとデータ・ソースを関連付け(第7章「データ・アクセスの理解」を参照)、EclipseLinkのキャッシュ、問合せと式、およびトランザクションを使用して永続オブジェクトの作成、読取り、更新および削除を行うことです。

通常、EclipseLink永続層には次のコンポーネントが含まれます。

- マッピング・メタデータ

- キャッシュ

- 問合せおよび式

3.2.3.1 マッピング・メタデータ

EclipseLinkアプリケーションのメタデータ・モデルは、プロジェクトに基づいています。プロジェクトは、ディスクリプタ、マッピングおよびランタイム機能をカスタマイズする各種ポリシーで構成されています。セッションからプロジェクトを参照することにより、このマッピングと構成情報を特定のデータ・ソースとアプリケーションに関連付けます。

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

- 2.1.2項「プロジェクト・メタデータの作成」

- 第5章「ディスクリプタの理解」

- 第6章「マッピングの理解」

3.2.3.2 キャッシュ

デフォルトでは、EclipseLinkセッションはオブジェクト・アイデンティティを保証するオブジェクトレベルのキャッシュを提供し、アプリケーションがデータ・ソースにアクセスする回数を減らしてパフォーマンスを向上します。EclipseLinkは、ロック、リフレッシュ、無効化、分離およびコーディネーションなどの、様々なキャッシュ・オプションを提供します。キャッシュ・コーディネーションを使用して、デプロイされたアプリケーションの他のインスタンスと変更を同期化するようにEclipseLinkを構成できます。永続性ユニットまたはエンティティ・レベルでほとんどのキャッシュ・オプションを構成できます。また、問合せ単位またはディスクリプタでキャッシュ・オプションを構成して、参照クラスのすべての問合せに適用されるようにできます。

詳細は、第8章「キャッシュの理解」を参照してください。

3.2.3.3 問合せおよび式

オブジェクト・リレーショナル・アーキテクチャでは、EclipseLinkによって、複数のオブジェクトおよびデータ問合せタイプが提供され、次のように問合せ選択基準の柔軟なオプションを使用できます。

- EclipseLink式

- JPQL (Java Persistence Query Language)

- SQL

- ストアド・プロシージャ

- 例による問合せ

これらのオプションを使用して、あらゆるタイプの問合せを作成できます。名前付き問合せを使用してアプリケーション問合せを定義することをお薦めします。名前付き問合せは、プロジェクトのメタデータ内に保持され、名前で参照されます。これにより、アプリケーション開発は簡単になり、問合せはカプセル化されてメンテナンス・コストが軽減します。

オブジェクト・リレーショナル・アーキテクチャでは、永続エンティティ・タイプとは無関係に任意の問合せオプションを自由に使用できます。また、EclipseLink APIを使用してコードで問合せを作成することもできます。

注意:
これらの問合せ方法は、MOXy (OXM、JAXB)マッピングでは使用できません。ただし、レガシーEIS XMLプロジェクトを使用する場合は、問合せを実行できます。

詳細は、第9章「問合せの理解」および第10章「EclipseLinkの式の理解」を参照してください。

3.3 オブジェクトの永続化について

この項では、リレーショナル・マッピングについて簡単に説明し、オブジェクト・モデリングとリレーショナル・モデリングへの手引きとなる情報および制限が提供されます。この情報は、アプリケーションを作成するときに役立ちます。

この項では、次の内容について説明します。

- アプリケーション・オブジェクト・モデル

- データ・ストレージ・スキーマ

- 主キーおよびオブジェクト・アイデンティティ

- マッピング

- 外部キーとオブジェクト・リレーションシップ

- 継承

- 並行性

- キャッシュ

- 非介入型の永続性

- インダイレクション

- 可変性

3.3.1 アプリケーション・オブジェクト・モデル

オブジェクト・モデリングとは、アプリケーション・オブジェクトを表現するJavaクラスを設計することです。自分で選んだ統合開発環境(IDE)またはUnified Modeling Language (UML)モデリング・ツールを使用して、アプリケーション・オブジェクト・モデルを定義および作成できます。

EclipseLinkデータベース・セッションにディスクリプタを登録するクラスは、すべて永続クラスと呼ばれます。EclipseLinkでは、永続クラスは、データベースに格納されるあらゆるprivateまたはprotected属性に対してpublicアクセッサ・メソッドを提供する必要はありません。詳細は、3.2.2項「永続クラス要件」を参照してください。

3.3.2 データ・ストレージ・スキーマ

データ・ストレージ・スキーマとは、アプリケーションの永続データを編成するために実装する設計のことです。このスキーマは、永続データ自体を参照するのであって、実際のデータ・ソースを参照するのではありません(例、リレーショナル・データベースや非リレーショナル・レガシー・システム)。

アプリケーション開発プロセスの設計フェーズで、データ・ソースのクラスの実装方法を決定する必要があります。既存のデータ・ソース情報を統合する場合、クラスと既存データの関係を確認する必要があります。統合するレガシー情報がない場合は、各クラスを格納する方法を決定してから必要なスキーマを作成します。

3.3.3 主キーおよびオブジェクト・アイデンティティ

オブジェクトを永続化する場合、各オブジェクトには、格納および取得時にそれを一意に識別するためのアイデンティティが必要です。オブジェクト・アイデンティティは、一般に一意の主キーを使用して実装されます。このキーは、各オブジェクトを識別し、参照を作成および管理するために、EclipseLinkによって内部的に使用されます。オブジェクト・アイデンティティが損われると、オブジェクト・モデルが破損することがあります。

Javaアプリケーションでは、メモリー内の各オブジェクトが1つのみのオブジェクト・インスタンスによって表される場合にオブジェクト・アイデンティティが維持されます。同じオブジェクトの複数取得は、同一オブジェクトの複数コピーを返すのではなく、同一オブジェクト・インスタンスへの参照を返します。

EclipseLinkは、複数アイデンティティ・マップをサポートして、オブジェクト・アイデンティティを保持します(コンポジット主キーを含む)。詳細は、8.2項「キャッシュのタイプとサイズについて」を参照してください。

3.3.4 マッピング

EclipseLinkでは、メタデータを使用して、オブジェクトおよびBeanのデータ・ソースへのマップ方法を記述します。このアプローチによって、永続性情報とオブジェクト・モデルが分離されるため、開発者は自由に理想的なオブジェクト・モデルを設計し、DBAは自由に理想的なスキーマを設計できます。詳細は、2.1項「メタデータについて」を参照してください。

実行時に、EclipseLinkはメタデータを使用して、アプリケーションが必要とするたびにシームレスおよび動的にデータ・ソースと対話します。

EclipseLinkは、オブジェクト・モデルに含まれる可能性のある様々なデータ・タイプと参照をサポートする、広範なマッピング階層を提供します。詳細は、第6章「マッピングの理解」を参照してください。

3.3.5 外部キーとオブジェクト・リレーションシップ

外部キーは、別の表の一意キー(通常は主キー)を参照する1つ以上の列です。主キーと同様、外部キーは任意の数のフィールドで、これらすべてが1つの単位として扱われます。外部キーと参照先の親である主キーは、フィールドの数およびタイプが同じである必要があります。

外部キーは、1つの表の1つ以上の列から別の表の1つ以上の列へのリレーションシップを表します。たとえば、すべてのEmployeeに属性addressがあり、この属性にAddress(独自のディスクリプタおよび表を所有)のインスタンスが含まれている場合、address属性に対する1対1マッピングにより、特定のEmployeeの住所を見つけるための外部キー情報が指定されます。

3.3.6 継承

オブジェクト指向システムでは、クラスを、他のクラスに基づいて定義できます。たとえば、オートバイ、セダンおよびバンは、すべて乗り物の種類です。それぞれの乗り物タイプは、Vehicleクラスのサブクラスです。同様に、Vehicleクラスは、特定の各乗り物タイプのスーパークラスです。各サブクラスはそのスーパークラスから属性およびメソッドを継承します(これらにそのクラス独自の属性とメソッドを追加します)。

継承により、次のようなアプリケーションの利点が提供されます。

- サブクラスを使用することにより、スーパークラスから提供された共通の要素をベースとして特殊化した動作を提供できます。継承を使用することで、スーパークラスのコードが何度も再利用できます。

- 一般的な動作を定義する抽象スーパークラスを実装できます。この抽象スーパークラスは、動作を定義し一部実装できます。詳細については、特殊化したサブクラスを使用して完成します。

3.3.7 同時実行性

同時クライアントを同時にログインさせるには、サーバーが各クライアント用に実行の専用スレッドを生成する必要があります。これは、Java EEアプリケーション・サーバーによって自動的に行われます。専用スレッドにより、各クライアントは他のクライアントの完了を待たずに作業できるようになります。EclipseLinkは、これらのスレッドがアイデンティティ・マップを変更するときやデータベース・トランザクションを実行する際、互いに干渉しないように保証します。クライアントは、独立したスレッド・セーフな方法でトランザクションを変更できます。EclipseLinkは、変更するオブジェクトのクローンを管理することで、各クライアントの作業を他の同時クライアントおよびスレッドから分離します。これは、本質的に、データベース・トランザクションとしてACID (Atomicity、Consistency、Isolation、Durability)トランザクション方針のすべてを維持する、オブジェクトレベルのトランザクション・メカニズムです。

EclipseLinkでは、オプティミスティックおよびペシミスティック・ロック戦略が構成できるようにサポートされていて、EclipseLink並行性マネージャが使用するロックのタイプをカスタマイズできます。詳細は、5.2.4項「ディスクリプタとロック」を参照してください。

3.3.8 キャッシュ

EclipseLinkキャッシュは、データベースからオブジェクトとして返されたデータを将来の使用のために自動的に保存しておくことにより、アプリケーションのパフォーマンスを向上させます。このキャッシュにはいくつかの利点があります。

- データベースから以前に読み取られたJavaオブジェクトを再利用することで、データベース・アクセスが最小限に抑えられます。

- オブジェクトがキャッシュにすでに存在している場合、データベースへのSQLコールが最小限に抑えられます。

- データベースへのネットワーク・アクセスが最小限に抑えられます。

- キャッシュ・ポリシーはクラス単位またはBean単位に設定できます。

- キャッシュのオプションおよび動作のベースを、Javaガベージ・コレクションにすることができます。

EclipseLinkには、複数のキャッシュ・ポリシーがサポートされているという高い柔軟性があります。開発者は、個々のアプリケーション・パフォーマンスに基づいて、パフォーマンスを最大限にするためにキャッシュを微調整できます。詳細は、第8章「キャッシュの理解」を参照してください。

3.3.9 非介入型の永続性

EclipseLinkの非介入型のアプローチでは、メタデータ・アーキテクチャを通じて永続性を実現するため、オブジェクト・モデルへの介入がほとんどありません。

Javaオブジェクトを永続化する際、EclipseLinkでは次のいずれも不要です。

- 永続スーパークラスまたは永続インタフェースの実装

- オブジェクト・モデルにおける必要なメソッドの保存、削除またはロード

- 特別な永続メソッド

- オブジェクト・モデルへのソース・コードの生成またはラップ

この非介入型アプローチの詳細は、3.2項「永続層の構築および使用」を参照してください。2.1項「メタデータについて」も参照してください。

3.3.10 インダイレクション

インダイレクション・オブジェクトは、アプリケーション・オブジェクトのかわりとなるため、アプリケーション・オブジェクトは必要とされるまでデータベースから読み取られません。インダイレクション(JPAでの遅延ロード)を使用すると、EclipseLinkで関連オブジェクトのスタンドインを作成できます。これにより、特にアプリケーションが取得したオブジェクトのみのコンテンツを必要とし、そのオブジェクトに関連するすべてのオブジェクトのコンテンツは必要としない場合に、パフォーマンスの大幅な向上が見られます。

インダイレクションがない場合、アプリケーションが永続オブジェクトを取得するたびに、そのオブジェクトで参照されるオブジェクトもすべて取得されます。これは、アプリケーションによってはパフォーマンスの低下につながります。

注意:
常にインダイレクションを使用することをお薦めします。

EclipseLinkは、プロキシ・インダイレクション、透過インダイレクションおよびValueHolderインダイレクションなど、いくつかのインダイレクション・モデルを提供します。

詳細は、6.2.7.3.5項「コレクションを使用したインダイレクション」および6.2.1項「インダイレクション(遅延ロード)」を参照してください。

3.3.11 可変性

可変性とは、複雑なフィールドのプロパティの1つであり、フィールド値を(置換ではなく)変更できるかどうかを指定します。

不変マッピングでは、オブジェクトのオブジェクトIDが変更されないかぎり、つまり、オブジェクト値が別のオブジェクト値と完全に置換されないかぎり、マップされたオブジェクト値は変更できません。

可変マッピングでは、オブジェクトのオブジェクトIDを変更しなくても、マップされたオブジェクト値を変更できます。

デフォルトでは、EclipseLinkは次のように想定します。

- すべてのTransformationMappingインスタンスは可変

- すべてのJPA @Basicマッピング・タイプ(Serializableタイプは除く)は不変(DateおよびCalendarタイプを含む)

- すべてのJPA @BasicマッピングのSerializableタイプは可変

値が不変か可変かは、アプリケーションによる永続クラスの使用方法に大きく依存します。たとえば、EclipseLinkは、デフォルトでDateタイプの永続フィールドを不変であると想定するため、フィールドの値が同じオブジェクトIDを持つかぎり、その値は変更されていないものとみなされます。アプリケーションでDateクラスのsetメソッドを使用する場合、そのオブジェクトIDを変更せずにDateオブジェクトの値の状態を変更できます。この場合、EclipseLinkでは変更が検出されません。これを回避するには、マッピングを可変として構成し、EclipseLinkに対して、オブジェクトIDのみではなく永続値の状態を調査するように指示します。

可変性を構成できる対象は次のとおりです。

- TransformationMappingインスタンス;

- 各JPA @Basicマッピング・タイプ(DateおよびCalendarタイプを含む)

- すべてのDateおよびCalendarタイプ

可変性は、変更追跡のパフォーマンスに影響を与える場合があります。たとえば、トランスフォーメーション・マッピングが可変値をマップする場合、EclipseLinkは値をクローニングし、比較する必要があります。マッピングで単純な不変の値をマップする場合は、マッピングを不変として構成すると、パフォーマンスを向上できます。

可変性は、ウィービングにも影響を与えます。EclipseLinkがウィービングを実行できるのは、不変マッピングの属性変更追跡ポリシーのみです。

詳細は、3.5項「ウィービングについて」を参照してください。『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@Mutable注釈の説明も参照してください。

3.4 EclipseLink永続性マネージャへのアプリケーションの移行

EclipseLinkを永続性マネージャとして使用するように、アプリケーション・サーバーを構成できます。JARファイルに含まれるコンテナ管理の永続性を備えたすべてのエンティティに対して、ただ1つの永続性マネージャのみを使用できます。

EclipseLinkは、EclipseLinkを永続性マネージャとして使用するように既存のJava EEアプリケーションを移行するための自動サポートを提供します。詳細は、Oracle TopLinkのソリューション・ガイドのApache OpenJPAからTopLinkへの移行に関する項を参照してください。

3.5 ウィービングについて

ウィービングは、コンパイル済のJavaクラスのバイトコードを操作する方法です。EclipseLinkのJPA永続性プロバイダでは、ウィービングを使用してJPAエンティティとPlain Old Java Object (POJO)クラスの両方を拡張し、遅延ロード、変更追跡、フェッチ・グループ、内部最適化などの操作に対応します。

ウィービングは、実行時(エンティティのロード時)に動的に実行するか、エンティティの.classファイルを後処理してコンパイル時に静的に実行できます。デフォルトでは、EclipseLinkは、Java EEアプリケーション・サーバーの内部やJava SE内(EclipseLinkエージェントが構成されている場合)などで、可能なかぎり動的ウィービングを使用します。動的ウィービングは構成しやすく、プロジェクトのビルド・プロセスを変更する必要がないので、動的ウィービングをお薦めします。

この項の内容は次のとおりです。

- 動的ウィービングの使用

- 静的ウィービングの使用

- POJOクラスのウィービング

- ウィービングとJava EEアプリケーション・サーバー

- 永続性ユニット・プロパティを使用したウィービングの無効化

3.5.1 動的ウィービングの使用

動的ウィービングを使用すると、アプリケーション・クラス・ファイルを実行時にロードする際に、1つずつウィービングできます。ウィービングするクラスの数がごく少ないか、クラスのウィービング時間が短い場合、このオプションを検討してください。

ウィービングするクラスの数が多いか、クラスのウィービング時間が長い場合は、静的ウィービングの使用を検討します。

3.5.2 静的ウィービングの使用

静的ウィービングを使用すると、すべてのアプリケーション・クラス・ファイルをビルド時にウィービングして、事前ウィービング済のクラス・ファイルを配信できます。該当するすべてのクラス・ファイルのウィービングをビルド時に実行し、事前ウィービング済のクラス・ファイルを配信する場合に、このオプションの使用を検討してください。これを実行することで、動的ウィービングで必要とされる実行時のウィービング手順を省略して、アプリケーション・パフォーマンスを向上できます。

また、エージェントを構成できないJava環境でウィービングを実行する場合も、静的ウィービングの使用を検討してください。

3.5.3 POJOクラスのウィービング

EclipseLinkでは、POJOクラスで次の機能を有効にするためにウィービングを使用します。

- 遅延ロード

- 変更追跡

- フェッチ・グループ

EclipseLinkでは、ウィービングを実行するPOJOアプリケーションをパッケージ化する際に、作成したJAR内のすべてのPOJOクラスのウィービングを実行します。

EclipseLinkでは、persistence.xmlファイルに定義されている次のすべてのクラスのウィービングを実行します。

- persistence.xmlファイルにリストしたすべてのクラス

- persistence.xmlファイルを含むJARに関連するすべてのクラス(要素<exclude-unlisted-classes>がfalseの場合)

3.5.4 ウィービングとJava EEアプリケーション・サーバー

デフォルトのEclipseLinkのウィービング動作は、EclipseLink JPA永続性プロバイダを使用する、Java EE JPA準拠のアプリケーション・サーバーで適用されます。この動作を変更するには、persistence.xmlファイル(JPAエンティティまたはPOJOクラス用)を変更して、EclipseLink JPAプロパティ、EclipseLink JPA注釈、またはその両方を使用します。

3.5.5 永続性ユニット・プロパティを使用したウィービングの無効化

EclipseLinkの永続性ユニット・プロパティを使用してウィービングを無効化するには、次の1つ以上のプロパティをfalseに設定してpersistence.xmlを構成します。

- eclipse.weaving: すべてのウィービングを無効化します。

- eclipselink.weaving.lazy: 遅延ロード(インダイレクション)のウィービングを無効化します。

- eclipselink.weaving.changetracking: 変更追跡のウィービングを無効化します。

- eclipselink.weaving.fetchgroups: フェッチ・グループのウィービングを無効化します。

- eclipselink.weaving.internal: 内部最適化のウィービングを無効化します。

- eclipselink.weaving.eager: 即時リレーションシップのインダイレクションのウィービングを無効化します。

参照先

4 エンティティの理解

この章では、エンティティについて紹介および説明します。エンティティは、軽量な永続性ドメイン・オブジェクトです。一般的に、エンティティはリレーショナル・データベースの表を表現し、各エンティティ・インスタンスはその表の行に相当します。エンティティの主なプログラミング・アーティファクトはエンティティ・クラスですが、各エンティティはヘルパー・クラスを使用できます。

エンティティの永続状態は、永続フィールドまたは永続プロパティを通じて表現されます。これらのフィールドまたはプロパティでは、オブジェクト/リレーショナル・マッピングの注釈を使用して、エンティティおよびエンティティ関係を、基礎となるデータ・ストアのリレーショナル・データにマップします。

エンティティのアイデンティティ、およびエンティティのロック技術や順序生成のオプションを構成できます。

この章の内容は次のとおりです。

- エンティティの識別

- エンティティと永続識別子

- エンティティとデータベース表

- エンティティと継承

- エンティティと埋込みオブジェクト

- エンティティと順序生成

- エンティティとロック

- 拡張可能なエンティティ

4.1 エンティティの識別

@Entity注釈を使用して、クラスがエンティティであることを指定します。

注意:
エンティティ・クラスは、<exclude-unlisted-classes>タグをfalseに設定しないかぎり、persistence.xmlファイルにもリストする必要があります。

詳細は、JPA仕様の第2章「Entities」を参照してください。

http://jcp.org/en/jsr/detail?id=338

4.2 エンティティと永続識別子

すべてのエンティティは、エンティティ状態を格納するデータベース表の主キーに相当する永続識別子を持つ必要があります。

デフォルトで、EclipseLinkの永続性プロバイダは、主キーとして機能する1つ以上のフィールドまたはプロパティが各エンティティに含まれるものと想定します。

次の注釈を使用して、エンティティの識別子を生成または構成できます。

- @Id

- @IdClass

- @EmbeddedId

- @GeneratedValue

- @TableGenerator

- @SequenceGenerator

- @UuidGenerator

これらの注釈を使用して、エンティティの識別子をデータベースで管理する方法を調整することもできます。これらの注釈の詳細は、JPA仕様の「Metadata for Object/Relational Mapping」を参照してください。

http://jcp.org/en/jsr/detail?id=338

4.3 エンティティとデータベース表

すべてのエンティティ・クラスは、データベースの特定の表または表のセットにマップされます。デフォルトで、エンティティの表名は大文字でそのエンティティ名に設定されます(これは、デフォルトでエンティティの短縮クラス名に設定されます)。エンティティは、通常、単一の表にマップされますが、複数の表やビューにもマップできます。

エンティティの表は、次の注釈を使用してカスタマイズできます。

- @Table

- @SecondaryTable

4.4 エンティティと継承

JPAは、継承でオブジェクトを永続化するための様々な方法を定義しています。@Inheritance注釈は、SINGLE_TABLE, JOINEDおよびTABLE_PER_CLASSの継承を定義するためにルート・クラスで使用します。一般的な状態または永続性の動作を定義するが、データベース上に関係が存在しない抽象クラスでは、@MappedSuperclass注釈を使用できます。

- @Inheritance

- @MappedSuperclass

4.5 エンティティと埋込みオブジェクト

@Embeddable注釈を使用して埋込みクラスをマップできます。埋込み可能クラスは、直接永続化されず、親エンティティでのみ永続化される特別なタイプのクラスです。埋込み可能クラスは、単一の参照の場合には@Embedded注釈を、埋込みIDの場合には@EmbeddedIdを、CollectionまたはMap参照の場合には@ElementCollection注釈を使用して、エンティティまたは別の埋込み可能クラスから参照できます。埋込み可能クラスは、@MapKeyClass注釈を使用して任意のMapキーで使用することもできます。

- @Embeddable

- @EmbeddedId

- @Embedded

- @ElementCollection

4.6 エンティティと順序生成

多くのデータベースでは、順序と呼ばれるID生成の内部メカニズムがサポートされます。基礎となるデータベースがサポートしている場合、データベースの順序を使用して識別子を生成できます。

- @SequenceGenerator: @GeneratedValue注釈を使用してSEQUENCEタイプの主キー・ジェネレータを指定する場合、@SequenceGenerator注釈を使用してこの主キー・ジェネレータを調整し、次のことを実行できます。

- アプリケーション要件またはデータベースのパフォーマンス・パラメータに一致するように、割当てサイズを変更できます。

- 既存のデータ・モデルに一致するように、初期値を変更できます(たとえば、主キーの値の範囲がすでに割当て済または予約済である既存のデータ・セットに基づいて作成する場合)。

- 既存のデータ・モデルで事前定義されている順序を使用できます。

- @TableGenerator: @GeneratedValue注釈を使用してTABLEタイプの主キー・ジェネレータを指定する場合、@TableGenerator注釈を使用してこの主キー・ジェネレータを調整し、次のことを実行できます。

- 主キー・ジェネレータの表の名前が不適切な場合、予約語の場合、既存のデータ・モデルと互換性がない場合、またはデータベースの表名として無効な場合、その名前を変更できます。

- アプリケーション要件またはデータベースのパフォーマンス・パラメータに一致するように、割当てサイズを変更できます。

- 既存のデータ・モデルに一致するように、初期値を変更できます(たとえば、主キーの値の範囲がすでに割当て済または予約済である既存のデータ・セットに基づいて作成する場合)。

- 特定のカタログまたはスキーマで主キー・ジェネレータの表を構成できます。

- 主キー・ジェネレータの表に含まれる1つ以上の列に対して一意制約を構成できます。

これらの注釈の詳細および例は、JPA仕様の「Metadata for Object/Relational Mapping」を参照してください。

4.7 エンティティとロック

オプティミスティック・ロックとペシミスティック・ロックを選択できます。オプティミスティック・ロックの使用をお薦めします。詳細は、5.2.4項「ディスクリプタとロック」を参照してください。

デフォルトで、EclipseLinkの永続性プロバイダでは、アプリケーションがデータ整合性を管理するものと想定されます。

@Version注釈を使用して、オプティミスティック・ロックの値として機能するエンティティ・クラスのバージョン・フィールドまたはプロパティを指定することで、JPA管理のオプティミスティック・ロックを有効化することをお薦めします。バージョン・フィールドまたはプロパティを選択する場合、次の条件を満たす必要があります。

- 1つのエンティティに対してただ1つのバージョン・フィールドまたはプロパティがあること

- プライマリ表に永続化されているプロパティまたはフィールドを選択すること(JPA仕様の「Table Annotation」を参照)

- アプリケーションでバージョン・プロパティまたはフィールドを変更しないこと

注意:
フィールドまたはプロパティ・タイプは、数値型(Number、long、int、BigDecimalなど)またはjava.sql.Timestampである必要があります。数値型の使用をお薦めします。

@Version注釈には属性はありません。

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

- JPA仕様(http://jcp.org/en/jsr/detail?id=338)の「Optimistic Locking and Concurrency」

- JPA仕様(http://jcp.org/en/jsr/detail?id=338)の「Version Annotation」

- 『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオプティミスティック・ロックのEclipseLink JPA拡張機能の説明

JPAメタデータによって構成されるEclipseLinkアーティファクトの詳細は、5.2.4項「ディスクリプタとロック」を参照してください。

4.8 拡張可能なエンティティ

JPAエンティティおよびJAXB Beanは、外部でマッピングを追加または変更して、拡張可能にすることができます。エンティティまたはBeanのソース・ファイルの変更やBeanの永続性ユニットの再デプロイは必要ありません。

拡張可能なエンティティは、複数のクライアント(テナント)が共有の汎用アプリケーションを使用できるマルチテナント(またはSaaS)・アーキテクチャで役立ちます。テナントは、自分のデータにプライベートにアクセスでき、他のテナントと共有するデータにもアクセスできます。

拡張可能なエンティティを使用すれば、次のことを行えます。

- 一部のマッピングがすべてのユーザーに共通で、一部のマッピングはユーザー固有であるようなアプリケーションを作成できます。

- 顧客に提供された後のアプリケーションにマッピングを追加できます(デプロイメント後でも可能)。

- マッピング変更後も、同じEntityManagerFactoryインタフェースを使用してデータを操作できます。

- アプリケーションで使用されるメタデータのソースを追加提供できます。

@VirtualAccessMethods注釈を使用してJPAエンティティを拡張可能に指定し、@XmlVirtualAccessMethods注釈を使用してJAXB Beanを拡張可能に指定します。いずれの場合も、仮想プロパティを使用して外部でマッピングを指定します。これにより、ソース・ファイルの変更および永続性ユニットの再デプロイをしなくても、マッピングを変更できるようになります。

JPAエンティティおよびJAXB Beanを拡張可能にする方法の詳細は、Oracle TopLinkのソリューション・ガイドのJPAエンティティとJAXB Beanを拡張可能にする方法に関する項を参照してください。

5 ディスクリプタの理解

この章では、ディスクリプタについて紹介および説明します。EclipseLinkでは、ディスクリプタを使用して、あるデータ・ソースによって特定クラスのインスタンスがどのように表現されるかを定義した情報を格納します。ディスクリプタには、クラスのインスタンス変数を、データ・ソースおよび、値の格納と取得に使用されるトランスフォーメーション・ルーチンに関連付けるマッピングを含めます。それによって、ディスクリプタは、Javaオブジェクトとそのデータ・ソース表現を接続する役目を果します。

この章の内容は次のとおりです。

- 共通のディスクリプタの概念

- オブジェクト・リレーショナル・ディスクリプタの概念

5.1 共通のディスクリプタの概念

次の項では、オブジェクト・リレーショナルとMOXyのディスクリプタに共通の概念について説明します。

- ディスクリプタのアーキテクチャ

- ディスクリプタと継承

- ディスクリプタと集約

- ディスクリプタのカスタマイズ

- 修正メソッド

- ディスクリプタ・イベント・マネージャ

5.1.1 ディスクリプタのアーキテクチャ

ディスクリプタには、あるデータ・ソースによって特定オブジェクト・クラスのインスタンスがどのように表現されるかを定義したすべての情報を格納します。ディスクリプタAPIを使用すると、Javaコードを介してEclipseLinkディスクリプタを定義または修正できます。ディスクリプタAPIのクラスは、主としてorg.eclipse.persistence.descriptorsパッケージに含まれています。

EclipseLinkディスクリプタには次の情報を格納できます。

- ディスクリプタ自体の中で記述する永続Javaクラス、および対応するデータ・ソース(データベース表またはXMLの複合型インタラクション)。

- そのクラスの属性とリレーションシップをデータ・ソースでどのように表現するかを記述したマッピングのコレクション。

- データ・ソースの主キー情報(またはそれに相当する情報)。

- フィールド名の問合せキー(または別名)のリスト。

- 順序番号の情報。

- ディスクリプタの動作を調整するためのオプション・プロパティのセット。リフレッシュ・オプションのキャッシング、アイデンティティ・マップ、オプティミスティック・ロック、イベント・マネージャおよび問合せマネージャに関するサポートが含まれます。

EclipseLinkがサポートするデータ・ソース・タイプごとに、対応するディスクリプタ・タイプがあります。同一のデータ・ソース・タイプに対して有効なディスクリプタ・タイプが複数ある場合もあります。使用するディスクリプタのタイプにより、定義できるマッピングのタイプが決まります。

5.1.2 ディスクリプタと継承

継承とは、導出されたクラス(子)にそのスーパークラス(親)の特性をどのように受け継がせるかを意味します。ディスクリプタを使用すると、リレーショナル・プロジェクトおよびXMLプロジェクトにおいてクラス間の継承リレーションシップを定義できます。

子クラスのディスクリプタでは、親クラスのディスクリプタに指定されているマッピングをオーバーライドしたり、親クラスのディスクリプタにマップされていない属性をマップできます。

図5-1は、Java継承階層の代表例としてVehicleというオブジェクト・モデルを示します。ルート・クラスのVehicleには、2つブランチ・クラスFueledVehicleおよびNonFueledVehicleが含まれています。各ブランチ・クラスには、それぞれCarおよびBicycleというリーフ・クラスが含まれます。

図5-1 継承階層の例

「図5-1 継承階層の例」の説明

EclipseLinkが継承階層で認識するクラスは、次の3つの種類です。

- ルート・クラスは、サブクラス階層内のすべてのインスタンス化可能クラスの情報を格納します。デフォルトでは、ルート・クラスに対して実行された問合せにより、ルート・クラスおよびインスタンス化可能なサブクラスのインスタンスが返されます。ただし、ルート・クラスの構成方法によっては、ルート・クラスに対する問合せ時にサブクラスのインスタンスを省いて、ルート・クラス自体のインスタンスのみを返すこともできます。
たとえば、図5-1のVehicleクラスが、ルート・クラスです。

- ブランチ・クラスは、永続スーパークラスの他にサブクラスを持つものです。デフォルトでは、ブランチ・クラスに対して実行された問合せにより、ブランチ・クラスおよびそのサブクラスのインスタンスが返されます。ただし、ルート・クラスの場合と同様に、ブランチ・クラスの構成方法によっては、ブランチ・クラスに対する問合せ時にサブクラスのインスタンスを省いて、ブランチ・クラス自体のインスタンスのみを返すこともできます。
たとえば、図5-1のFueledVehicleクラスが、ブランチ・クラスです。

- リーフ・クラスには、階層内の永続スーパークラスがありますが、サブクラスはありません。リーフ・クラスに対して実行された問合せにより、リーフ・クラスのインスタンスのみが返されます。
たとえば、図5-1のCarクラスが、リーフ・クラスです。

子クラスのディスクリプタでは、親クラスのディスクリプタに指定されているマッピングをオーバーライドしたり、親クラスのディスクリプタにマップされていない属性をマップできます。

この項では、次の内容について説明します。

- クラス・インジケータの指定

- 継承と主キー

- 単一表と複数表の継承

- 集約ディスクリプタ、コンポジット・ディスクリプタおよび継承

5.1.2.1 クラス・インジケータの指定

継承を構成する場合は、ルート・クラス・ディスクリプタに、インスタンス化先のサブクラスの選択の方法を構成します。

これを行うには、次のいずれかの方法を実行します。

- クラス・インジケータ・フィールドの使用

- クラス抽出メソッドの使用

注意:
継承階層内のすべてのリーフ・クラスにはクラス・インジケータが必須で、かつこれらのリーフ・クラスは同じタイプのクラス・インジケータ(フィールドまたはクラス抽出メソッド)を持つ必要があります。

5.1.2.1.1 クラス・インジケータ・フィールドの使用

クラスの永続属性を使用すると、インスタンス化先のサブクラスを指定できます。たとえば、リレーショナル・ディスクリプタでは、ルート・クラス表のクラス・インジケータ・フィールドを使用できます。ただし、クラス・インジケータ・フィールドには、読取り専用に設定されていないダイレクト・マッピングを関連付けないでください。

注意:
インジケータ・フィールドが主キーの一部である場合は、インジケータ・フィールドに対する書込み専用トランスフォーメーション・マッピングを定義します。

クラス・インジケータ・フィールドでは、値として文字列または数値を使用できます。

ルート・クラス・ディスクリプタによって、クラス・インジケータ・フィールドの値をインスタンス化されるクラスに変換する方法を指定する必要があります。

5.1.2.1.2 クラス抽出メソッドの使用

オブジェクトのデータ・ソース・レコード内で利用可能なすべての情報に基づいて、クラス・インジケータを計算するJavaメソッドを定義することができます。このようなメソッドをクラス抽出メソッドといいます。

クラス抽出メソッドを使用すると、データ・モデルに明示的なクラス・インジケータ・フィールドを含める必要がなくなり、また、複雑すぎてクラス・インジケータ・フィールドには定義できないリレーションシップを処理できます。

クラス抽出メソッドには次の特性が必要です。

- ルート・ディスクリプタのクラスをベースにして定義されていること

- 静的であること

- 引数としてRecordをとること

- 入出力引数であるRecordにjava.lang.Classオブジェクトを出力すること

状況に応じて、only-instancesおよびwith-all-subclasses式も定義する必要があります。クラス抽出メソッドを使用する場合は、共通の表を使用するすべてのクラスの兄弟インスタンスを正しくフィルタ処理するための式を、EclipseLinkに指定する必要があります。

クラス抽出メソッドを使用して継承を構成した場合、EclipseLinkではルート・クラスに関する問合せのためのSQLは生成されません。

5.1.2.2 継承と主キー

リレーショナル・プロジェクトの場合、EclipseLinkでは、継承階層内のすべてのクラスが、ルート・ディスクリプタに設定されているのと同じ主キーを持っていることが前提とされます。

5.1.2.3 単一表と複数表の継承

リレーショナル・プロジェクトでは、継承階層を単一の表または複数の表にマップできます。

5.1.2.4 集約ディスクリプタ、コンポジット・ディスクリプタおよび継承

リレーショナル・ディスクリプタを集約ディスクリプタとして指定できます。XMLディスクリプタは常にコンポジット・ディスクリプタです(5.1.3項「ディスクリプタと集約」を参照)。

リレーショナル集約ディスクリプタで継承を構成する場合は、継承ツリー内のすべてのディスクリプタが集約である必要があります。つまり、集約クラスと非集約クラスのディスクリプタを同じ継承ツリーに置くことはできません。

XMLディスクリプタで継承を構成する場合は、すべてのXMLディスクリプタがコンポジットであるため、継承はディスクリプタ・タイプによる制限を受けません。

5.1.3 ディスクリプタと集約

2つのオブジェクト、つまり、ソース(親、すなわち所有)オブジェクトとターゲット(子、すなわち被所有)オブジェクトは、両者間に厳密な1対1の関係がある場合、集約によって関連付けられ、ターゲット・オブジェクトのすべての属性は、ソース・オブジェクトと同じデータ・ソース表現から取得できます。つまり、ソース・オブジェクトが存在すればターゲット・オブジェクトも存在する必要があり、ソース・オブジェクトが破棄されればターゲット・オブジェクトも破棄されるということです。

この場合、ソースおよびターゲット・オブジェクトのディスクリプタは、この関係を反映するよう定義する必要があります。

EJB 3.0仕様はネストされた集合をサポートしていません。

5.1.4 ディスクリプタのカスタマイズ

ディスクリプタ・カスタマイザを指定すると、実行時にディスクリプタをカスタマイズできます。ディスクリプタ・カスタマイザはJavaクラスの1つで、org.eclipse.persistence.config.DescriptorCustomizerインタフェースを実装し、デフォルト(ゼロ引数)・コンストラクタを備えています。

ディスクリプタ・カスタマイザを使用することで、コードAPIを介して実行時にディスクリプタがカスタマイズされますが、その方法は、修正メソッドを使用してディスクリプタをカスタマイズする方法と類似しています。5.1.5項「修正メソッド」を参照してください。

5.1.5 修正メソッド

実行時にディスクリプタがロードされるときにコールするstatic Javaメソッドを関連付けることができます。このメソッドは、ディスクリプタのJavaコードAPIを介して実行時のディスクリプタ・インスタンスを修正できます。このメソッドは、public staticであり、タイプorg.persistence.descriptors.structures.ClassDescriptorの属性を1つとるものである必要があります。このメソッドの実装では、publicの任意のディスクリプタとマッピングAPIを使用して、ディスクリプタの高度な機能を構成できます。

ただし、ディスクリプタはセッションが接続される前にのみ修正できます。これは、セッションの接続後にディスクリプタを修正するのは望ましくないためです。

修正メソッドは、有理数型ディスクリプタ、オブジェクト・リレーショナル・データ・タイプのディスクリプタ、およびXMLディスクリプタとともに使用できます。

5.1.6 ディスクリプタ・イベント・マネージャ

リレーショナル・プロジェクトでは、EclipseLinkによって、永続性のライフ・サイクル中にDescriptorEventの様々なインスタンスが起動されます。各ディスクリプタは、これらのイベントを受信してそれを登録済のディスクリプタ・イベント・ハンドラにディスパッチする役割を持つDescriptorEventManagerのインスタンスを所有します。

ディスクリプタ・イベント・ハンドラを使用すると、構築したアプリケーション固有のロジックをディスクリプタ・イベントの発生時に実行でき、永続データのライフ・サイクルの様々な時点において実行可能なカスタマイズ・アクションをとれるようになります。たとえば、ディスクリプタ・イベント・ハンドラを使用して次の動作を実行できます。

- 永続オブジェクトと他のシステム、サービスおよびフレームワークとの同期化

- EclipseLinkで対応していない非永続属性の管理

- オブジェクトの永続状態が変化したときにアプリケーションの他のオブジェクトに通知すること

- EclipseLinkのマッピングで直接サポートされていない複雑なマッピングまたは最適化を実装すること

5.2 オブジェクト・リレーショナル・ディスクリプタの概念

次の項では、オブジェクト・リレーショナル・ディスクリプタに固有の概念について説明します。

- フェッチ・グループ

- ディスクリプタ問合せマネージャ

- ディスクリプタと順序付け

- ディスクリプタとロック

5.2.1 フェッチ・グループ

デフォルトでは、特定のオブジェクト・クラスに対してオブジェクト・レベルの読取り問合せを実行すると、そのオブジェクトのディスクリプタにマップされているすべての永続属性がEclipseLinkによって返されます。この1回の問合せを実行するだけで、対象オブジェクトのすべての永続属性が定義され、さらに、各属性のgetメソッドをコールすることで、属性値をオブジェクトから直接取得できます。

オブジェクトの属性の一部のみが必要な場合は、フェッチ・グループを使用して、そのオブジェクトの属性のサブセットのみが返されるようにした方が効率的です。

フェッチ・グループを使用して、オブジェクトの属性のサブセットを定義し、そのフェッチ・グループをReadObjectQueryまたはReadAllQuery問合せと関連付けることができます。問合せを実行すると、EclipseLinkによりフェッチ・グループ内の属性のみが取得されます。除外された属性のいずれかに関するgetメソッドをコールすると、EclipseLinkでは、このサブセットから除外されたすべての属性をフェッチする問合せが自動的に実行されます。

1つのクラスに対して複数のフェッチ・グループを定義できます。オプションで、デフォルトのフェッチ・グループとして最大1つのフェッチ・グループを指定できます。フェッチ・グループを指定しないでReadObjectQueryまたはReadAllQuery問合せを実行する場合、問合せを別の方法で構成しないかぎり、EclipseLinkではデフォルトのフェッチ・グループが使用されます。

フェッチ・グループを使用する前に、システムの使用状況を綿密に分析しておくことをお薦めします。多くの事例では、フェッチ・グループに含まれない属性をロードするために必要な追加の問合せにより、部分的な属性のロードによって得られるメリットがかなり相殺されているためです。

フェッチ・グループは、FetchType.LAZY (partial object queries)で構成された基本マッピングとのみ組み合せて使用できます。

EclipseLinkでは、フェッチ、ロード、コピーおよびマージ操作で部分的エンティティの使用を構成するために使用できるAttributeGroupを使用します。

- フェッチ: データベースから取得される属性とその関連列を制御します。

- ロード: 問合せから返されたエンティティで移入されるリレーションシップを制御します。

- コピー: 新しいエンティティ・インスタンスにコピーされる属性を制御します。

- マージ: エンティティにフェッチ、ロードまたはコピーされた属性のみをマージします。

5.2.1.1 AttributeGroupタイプと操作

次の項では、使用可能なAttributeGroupタイプおよび操作について説明します。

- FetchGroup

- デフォルトFetchGroup

- 名前付きFetchGroup

- 完全FetchGroup

- Load/LoadAllとFetchGroup

- LoadGroup

- CopyGroup

- マージ

5.2.1.2 FetchGroup

FetchGroupは、問合せ実行の結果としてエンティティが取得されるときにフェッチする(データベースから選択する)必要のある属性を定義します。FetchGroupにリレーションシップ属性を含めることで決定されるのは、属性の必須列をフェッチして移入するかどうかのみです。遅延フェッチ・タイプの場合、属性を含めることで、そのプロキシが作成されてアクセス時に遅延ロードが有効になります。問合せでのFetchGroupの使用時にリレーションシップ・マッピングの移入を強制するには、属性をグループに含め、FetchType.EAGERに設定するか、問合せで関連するLoadGroupに含める必要があります。

5.2.1.3 デフォルトFetchGroup

FetchGroupには、FetchGroupManagerによって管理される名前付きのデフォルトFetchGroupの概念も含まれます。デフォルトFetchGroupは、1つ以上の基本マッピングが遅延するように構成され、エンティティ・クラスがFetchGroupTrackerを実装している場合に、メタデータ処理中に定義されます(通常はウィービングを通じて導入されます)。デフォルトFetchGroupは、明示的FetchGroupや名前付きFetchGroupが構成されていないこのエンティティ・タイプのすべての問合せで使用されます。

5.2.1.4 名前付きFetchGroup

名前付きFetchGroupは、@FetchGroup注釈を使用して、またはeclipselink-orm.xmlファイル内で、エンティティに対して定義できます。

5.2.1.5 完全FetchGroup

FetchGroupは、最初に作成されたときは空であると想定されます。ユーザーは、FetchGroupに属性を追加する必要があります。すべての属性を含むFetchGroupが必要な場合、FetchGroupManager.createFullFetchGroup()を使用する必要があります。

5.2.1.6 Load/LoadAllとFetchGroup

FetchGroupは、リレーションシップ・マッピングやネストしたリレーションシップ・マッピングのロード操作を実行するように構成することもできます。

5.2.1.7 LoadGroup

LoadGroupを使用して、リレーションシップ属性の指定したセットに問合せ結果での移入を強制します。

5.2.1.8 CopyGroup

CopyGroupによって、エンティティのコピー方法を定義するために使用される、非推奨のObjectCopyPolicyが置換されます。ソース・エンティティ・グラフからターゲット・コピーにコピーする内容を定義する属性を指定することに加え、CopyGroupでは次の定義も可能です。

- shouldResetPrimaryKey: 識別子属性をデフォルト値にリセットします。これは、コピー操作でソースと同様の状態の新しいエンティティを作成するためにエンティティをクローニングする場合に使用されます。デフォルトはfalseです。

- shouldResetVersion: オプティミスティック・バージョンのロック属性をコピーでデフォルト値にリセットします。デフォルトはfalseです。

- depth: リレーションシップを処理するためのカスケード・モードを定義します。デフォルトでは、CASCADE_PRIVATE_PARTSが使用されますが、NO_CASCADEやCASCADE_ALL_PARTSにも構成できます。

5.2.1.9 マージ

使用可能な属性を定義して、部分エンティティをAttributeGroupが関連付けられた永続性コンテキストにマージすると、それらの属性のみがマージされます。エンティティ内のリレーションシップ・マッピングも、それらのカスケード・マージ設定に従ってマージされます。

5.2.2 ディスクリプタ問合せマネージャ

各リレーショナル・ディスクリプタには、次の構成に使用できるDescriptorQueryManagerのインスタンスが用意されています。

- 名前付き問合せ

- 基本的な永続性操作用のカスタムのデフォルト問合せ

- 追加の結合式

5.2.3 ディスクリプタと順序付け

オブジェクト・アイデンティティを保持するうえで重要なのは、各オブジェクト・インスタンスを区別するために一意の値(特定の順序)の割当てを管理することです。

順序付けオプションにプロジェクト・レベルとセッション・レベルのいずれを構成するかにより、EclipseLinkで使用される順序付けのタイプが決まります。POJOプロジェクトの場合、セッション・レベルの順序構成を使用して、プロジェクト・レベルの順序構成をセッション単位でオーバーライドすることもできます。

順序タイプの構成後、ディスクリプタの参照クラスごとに、1つの属性(通常は主キーとして使用する属性)を独自の順序に関連付ける必要があります。

5.2.4 ディスクリプタとロック

オブジェクト・リレーショナル・マッピングでは、次に示すロック・ポリシーのいずれかを使用してディスクリプタを構成し、ドメイン・オブジェクトへの同時アクセスを制御できます。

- オプティミスティック: すべてのユーザーにデータへの読取りアクセス権限があります。ユーザーが変更を加えようとした場合、そのユーザーがデータを読み取った後にデータが変更されていないか、アプリケーションによってチェックされます。

- ペシミスティック: 更新目的でデータにアクセスした最初のユーザーによって、更新処理が完了するまでデータがロックされます。

- ロックなし: 複数のユーザーが互いの変更内容を上書きする操作は阻止されません。

ほとんどのタイプのアプリケーションでは、ユーザー同士が互いの変更内容を上書きできないようにするために、オプティミスティック・ロックを使用することをお薦めします。

この項では、EclipseLinkでサポートされている次のような様々なタイプのロック・ポリシーについて説明します。

- オプティミスティック・バージョン・ロック・ポリシー

- ペシミスティック・ロック・ポリシー

- アプリケーションでのロックの適用

5.2.4.1 オプティミスティック・バージョン・ロック・ポリシー

オプティミスティック・ロックを使用した場合、すべてのユーザーにデータへの読取りアクセス権限があります。ユーザーが変更を加えようとした場合、そのユーザーがデータを読み取った後にデータが変更されていないか、アプリケーションによってチェックされます。

オプティミスティック・バージョン・ロック・ポリシーでは、バージョン・フィールド(書込みロック・フィールド)を使用して、オプティミスティック・ロックが実行されます(バージョン・フィールドは、参照クラス内に作成し、オブジェクト変更がコミットされるたびにEclipseLinkによって更新されます)。

EclipseLinkは、データ・ソースからオブジェクトを読み取るときにこのバージョン・フィールドの値をキャッシュします。クライアントがオブジェクトに書き込もうとすると、EclipseLinkはキャッシュしたバージョン値とデータ・ソース内の最新のバージョン値を次のように比較します。

- 2つの値が一致した場合は、EclipseLinkはオブジェクト内のバージョン・フィールドを更新し、データ・ソースに対する変更内容をコミットします。

- 2つの値が一致しなかった場合は、そのクライアントが最初にオブジェクトを読み取った後に別のクライアントがそのオブジェクトを更新したことを意味するため、書込み操作を却下します。

EclipseLinkには、次のようなバージョン・ベースのオプティミスティック・ロック・ポリシーが用意されています。

- VersionLockingPolicy

- TimestampLockingPolicy

これらのロック・ポリシーの詳細は、Oracle TopLinkのソリューション・ガイドのオプティミスティック・ロックの設定に関する項を参照してください。

注意:
次の理由から、通常はnumericタイプのバージョンのロックをお薦めします。

- データ・ソースからのタイムスタンプ取得により、パフォーマンスが低下する場合があること

- timestampタイプのバージョンのロックでは、データベースが格納するタイムスタンプによって精度に限界があること

オプティミスティック・ロック違反により更新が失敗すると、EclipseLinkではOptimisticLockExceptionがスローされます。この例外は、データベースの変更を行っているアプリケーションで処理する必要があります。アプリケーションは、ロックの競合をクライアントに通知し、オブジェクトをリフレッシュして、クライアントに変更内容の再適用を依頼する必要があります。

バージョン値は、オブジェクト内にマップ済属性として格納するか、キャッシュに格納するかを選択できます。3層アプリケーションでは、オブジェクトの更新時にバージョン値が確実にクライアントに渡されるようにするため、オブジェクト内にバージョン値を格納しておく方法が一般的です(5.2.4.3項「アプリケーションでのロックの適用」を参照)。

バージョン値をキャッシュに格納する場合、バージョン値のマッピングは必要ありません。バージョン・フィールドをマップする場合、マッピングを読取り専用として構成する必要があります。

私有の子オブジェクトの変更時にその親オブジェクトのバージョン・フィールドが確実に更新されるようにするには、5.2.4.1.1項「オプティミスティック・バージョン・ロック・ポリシーとカスケード」を使用することを検討します。

ストアド・プロシージャを使用してオブジェクトを更新または削除する場合、オプティミスティック・ロックの障害を検出するために必要な行数をデータベースが返さないことがあるため、ストアド・プロシージャでオプティミスティック・ロックのバージョンを確認し、一致しない場合はエラーをスローする必要があります。StoredProcedureCallでは、バージョン・ロックのみが直接サポートされます。タイムスタンプおよびフィールド・ロックでは、同じフィールドの2つのバージョンをコールに渡す必要があるため、##パラメータを使用してトランザクション行にアクセスするSQLコールは、他のロック・ポリシーに使用できます。

5.2.4.1.1 オプティミスティック・バージョン・ロック・ポリシーとカスケード

使用するデータベース・スキーマが、親オブジェクトおよびその私有の子オブジェクトの両方を同じ表内に格納する設計になっている場合には、その子オブジェクトを更新すると、親オブジェクトのバージョン・フィールドが更新されます。

一方、親オブジェクトおよびその私有の子オブジェクトを異なる表に格納する場合は、デフォルトでは、子を変更しても、親のバージョン・フィールドは更新されません。

この場合に親オブジェクトのバージョン・フィールドを確実に更新するには、親オブジェクトのバージョン・フィールドを手動で更新するか、またはVersionLockingPolicyを使用している場合は、子オブジェクトのバージョン・フィールドの更新が親に自動的にカスケードされるようにEclipseLinkを構成することができます。

オプティミスティック・バージョン・ロックのカスケード機能を有効化した場合に、私有の子オブジェクトを変更すると、EclipseLinkはその私有されている外部参照マッピングを走査し、ルートに向かってすべての親オブジェクトを更新します。

EclipseLinkでは、次の場合にオプティミスティック・バージョン・ロックのカスケードがサポートされます。

- 私有の1対1および1対多マッピングでのオブジェクト変更

- 次のコレクション・マッピング(私有かどうかは問わない)でのリレーションシップ変更(追加または削除)

- ダイレクト・コレクション

- 1対多

- 多対多

- 集約コレクション

図5-2に例示したオブジェクトの図について考えてみます。

図5-2 オプティミスティック・バージョン・ロック・ポリシーとカスケードの例

「図5-2 オプティミスティック・バージョン・ロック・ポリシーとカスケードの例」の説明

この例では、ObjectAがObjectBを私有し、ObjectBはObjectCを私有し、ObjectCはObjectDを私有します。

ObjectBを作業ユニットに登録し、ObjectBを変更して、作業ユニットをコミットしたとします。この場合、ObjectBはObjectAのキャッシュをチェックし、値が存在しない場合にはデータベースに対してObjectAを問い合せます。次に、ObjectBは自身の変更をObjectAに通知します。ObjectAは、自身に対応する表に変更がない場合でも、自身のバージョン・オプティミスティック・ロック・フィールドを更新します。

ObjectAを作業ユニットに登録し、そのObjectB、ObjectC、ObjectDにこの順序でアクセスして、ObjectDのフィールドを変更し、作業ユニットをコミットするとします。この場合は、ObjectDが自身の変更をObjectCに通知します。ObjectCは、自身に対応する表に変更がない場合でも、自身のバージョン・オプティミスティック・ロック・フィールドを更新します。次に、ObjectCはObjectDの変更をObjectBに通知します。次に、ObjectBがObjectDの変更をObjectAに通知します。ObjectAは、自身に対応する表に変更がない場合でも、自身のバージョン・オプティミスティック・ロック・フィールドを更新します。

5.2.4.1.2 オプティミスティック・ロックとロールバック

オプティミスティック・ロックで、オプティミスティック・ロックのバージョンをキャッシュに格納する場合、ロックされたオブジェクトの値をロールバックするにはUnitOfWorkメソッドcommitAndResumeOnFailureを使用します。

ロックされた複数のバージョンを1つのオブジェクトに格納する場合は、更新失敗時に各オブジェクト(すなわち、オブジェクトのバージョン)をリフレッシュする必要があります。あるいは、失敗時に新しい作業ユニットを取得して、そのユニットに変更を再適用することもできます。

5.2.4.1.3 オプティミスティック・フィールド・ロック・ポリシー

オプティミスティック・フィールド・ロック・ポリシーでは、表内に現存する1つ以上のフィールドを使用して、クライアントが対象オブジェクトを読み取った以後にそのオブジェクトが変更されたかどうかを判別することによって、オプティミスティック・ロックが実行されます。

ユーザーがオブジェクトを最初に読み取ったとき、またはオブジェクトを作業ユニットに登録したときに、作業ユニットにより、そのオブジェクトの元の状態がキャッシュされます。コミット時には、ロック・フィールドの元の値と更新中のデータ・ソースの現在の値が、作業ユニットにより比較されます。ロック・フィールドのいずれかの値が変更されていた場合には、オプティミスティック・ロック例外がスローされます。

EclipseLinkには、次のようなオプティミスティック・フィールド・ロック・ポリシーが用意されています。

- AllFieldsLockingPolicy

- ChangedFieldsLockingPolicy

- SelectedFieldsLockingPolicy

- VersionLockingPolicy

- TimestampLockingPolicy

これらのロック・ポリシーの詳細は、Oracle TopLinkのソリューション・ガイドのオプティミスティック・ロックの設定に関する項を参照してください。

5.2.4.2 ペシミスティック・ロック・ポリシー

ペシミスティック・ロックを使用した場合は、データを更新する目的でそのデータにアクセスする最初のユーザーが、更新を完了するまでデータをロックします。

ペシミスティック・ロック・ポリシーを使用する場合は、更新をただちに失敗させるか、読取りロックが取得されるまで待機させるようにポリシーを構成できます。

ペシミスティック・ロック・ポリシーは、コンテナ管理の永続性タイプと、EJB情報を含むディスクリプタを保持するプロジェクトでのみ使用できます。

(ペシミスティック・ロック・ポリシーではなく)ペシミスティック・ロックは、問合せレベルでも使用できます。

EclipseLinkでは、ペシミスティック・ロックをコンテナ管理の永続性を持つエンティティとともに使用する場合にこのロックの最適化が行われ、問合せをペシミスティック・ロックに設定し、(ファインダの実行後に終了する)独自の新しいトランザクションで問合せを実行すると、EclipseLinkによってそのロック設定はオーバーライドされ、SQLにFOR UPDATEは追加されません。ただし、ユーザーがFOR UPDATEを含むSQL文字列でペシミスティック・ロック問合をカスタマイズしている場合、この最適化の使用によって不都合な結果が発生する可能性があります。この場合、最適化が必要な状況が存在すると、問合せは非ペシミスティック・ロックにリセットされますが、SQLは同じままのため、問合せのロック設定が問合せのSQL文字列と競合します。この問題を回避するには、次の2つのアプローチのいずれかを使用します。

- 選択基準として式を使用します(第10章「EclipseLinkの式の理解」)。これによって、EclipseLinkでSQLの生成を制御します。

- 最適化の条件をなくすため、ファインダをトランザクション内に配置します。

5.2.4.3 アプリケーションでのロックの適用

アプリケーションで適切にオブジェクトをロックするには、オブジェクトが編集のためにクライアントに送信される前に、ロックを取得する必要があります。

5.2.4.3.1 アプリケーションでのオプティミスティック・ロックの適用

オプティミスティック・ロックを使用する場合、オブジェクトを正しくロックするには次の2つの選択肢があります。

- オブジェクト内のオプティミスティック・ロック・フィールドを読取り専用以外にマップし、読取り時にバージョンをクライアントに渡し、更新時にサーバーに戻します。
更新のためにオブジェクトが読み取られるときに、元のバージョン値がクライアントに送信されることを確認します。クライアントは、その元のバージョン値を更新情報とともに戻す必要がありますが、このバージョンは、サーバー上の新しい作業ユニットで登録または読取りが行われた後に、更新対象のオブジェクトに設定される必要があります。

- クライアントとの対話が完了するまで作業ユニットを保持します。
ステートフル・セッションBeanを介して、またはHTTPセッションにおいて、更新対象オブジェクトの読取りに使用する作業ユニットを、クライアントとの対話が完了するまで保管します。

オブジェクトをクライアントに更新用に渡す前に、この作業ユニットからオブジェクトを読み取っておく必要があります。これにより、作業ユニットのキャッシュまたは作業ユニットのクローンに元のバージョン値を保管しておけます。

この同じ作業ユニットを更新でも必ず使用します。

1番目の選択肢の方が一般的に使用され、ステートレス・アプリケーションを開発する場合には必須となります。

5.2.4.3.2 アプリケーションでのペシミスティック・ロックの適用

ペシミスティック・ロックを使用する場合は、作業ユニットを使用して、オブジェクトが読み取られる前にデータベース・トランザクションを開始する必要があります。この作業ユニットとデータベース・トランザクションは、クライアントがオブジェクトを編集して更新するまでの間、保持する必要があります。この同じ作業ユニットをオブジェクトの更新でも必ず使用します。

5.3 ディスクリプタ・ファイル

次の項では、オブジェクト・リレーショナルおよびMOXyマッピングに使用できるディスクリプタ・ファイルについて説明します。

- オブジェクト・リレーショナル・マッピングへのorm.xmlの使用

- EclipseLinkのオブジェクト・リレーショナル・マッピングへのeclipselink-orm.xmlの使用

- EclipseLink MOXyマッピングへのeclipselink-oxm.xmlの使用

5.3.1 オブジェクト・リレーショナル・マッピングへのorm.xmlの使用

orm.xmlファイルを使用して、メタデータを永続性ユニットに適用します。このメタデータは、すべてのマッピング・ファイルと注釈の集合です(xml-mapping-metadata-complete要素が存在しない場合)。メタデータに対して1つのマッピングorm.xmlファイルを使用し、そのファイルをクラスパスのMETA-INFディレクトリに配置する場合、それを明示的にリストする必要はありません。このファイル(orm.xml)は、永続性プロバイダによって自動的に検索され、使用されます。

JPA 2.0 orm.xmlのスキーマは、orm_2_0.xsdです。(http://java.sun.com/xml/ns/persistence/orm_2_0.xsd)

マッピング・ファイルを異なる名前で使用するか、異なる場所に配置する場合、それらをpersistence.xmlファイルのmapping-file要素にリストする必要があります。

5.3.2 EclipseLinkのオブジェクト・リレーショナル・マッピングへのeclipselink-orm.xmlの使用

EclipseLinkは、eclipselink-orm.xmlという拡張JPA orm.xmlマッピング構成ファイルをサポートしています。このマッピング・ファイルは、JPAの標準マッピング・ファイルのかわりとして、またJPAのマッピング・ファイルをオーバーライドするためにも使用できます。すべての標準JPAマッピング機能を使用できるだけでなく、高度なマッピング・タイプとオプションも使用できます。

eclipselink-orm.xmlファイルの詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のeclipselink-orm.xmlのスキーマ参照に関する項を参照してください。

注意:
このマッピング・ファイルを使用すると、EclipseLinkの多くの高度な機能が有効になりますが、他のJPA実装に対する永続性ユニットの移植性がなくなる場合があります。

オーバーライド値の詳細は、次を参照してください。

- JPA仕様の「XML Overriding Rules」
http://jcp.org/en/jsr/detail?id=338

- eclipselink-orm.xmlのスキーマはeclipselink_orm_2_2.xsdです。
http://www.eclipse.org/eclipselink/xsds/eclipselink_orm_2_2.xsd

5.3.2.1 マッピング情報のオーバーライドおよびマージ

orm.xmlファイルのマッピングをオーバーライドするには、プロジェクトでMETA-INF/eclipselink-orm.xmlファイルを定義する必要があります。eclipselink-orm.xmlの内容が、orm.xmlおよび永続性ユニットで指定されたその他のJPAマッピング・ファイルをオーバーライドします。複数のORMファイルの指定が重複している場合、競合エンティティが存在しなければそれらのファイルはマージされます。

詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオーバーライドおよびマージに関する項を参照してください。

5.3.2.2 XMLスキーマの検証

デフォルトでは、.orm XMLファイルの内容は、JPAの.orm XMLスキーマに対して検証されません。

開発時に、.orm XMLファイルをスキーマに対して検証し、その妥当性を確認することをお薦めします。EclipseLinkで.orm XMLスキーマの検証を有効にするには、persistence.xmlファイルの永続性ユニット・プロパティeclipselink.orm.validate.schemaを使用します。

5.3.2.3 XML使用の長所と短所

注釈のかわりにXMLを使用する場合の利点は、次のとおりです。

- メタデータとソース・コード間の結合がありません。

- 既存のEJB 3.0以前の開発プロセスに準拠しています。

- IDEおよびソース・コントロール・システムでサポートされます。

XMLによるマッピングの主な短所は、次のとおりです。

- 注釈と比較して、本質的に複雑です。

- コード・コンテキストのレプリケーションが必要です(XMLとソース・コードの両方で構造を定義する必要があります)。

詳細は、JPA仕様の第10章「Metadata Annotations」を参照してください。

http://jcp.org/en/jsr/detail?id=338

5.3.3 EclipseLink MOXyマッピングへのeclipselink-oxm.xmlの使用

Java注釈を使用して、プロジェクトにJAXBの機能を指定できます。EclipseLinkには、Java注釈に加えて、eclipselink-oxm.xmlというXMLマッピング構成ファイルが用意されています。このマッピング・ファイルには、標準のJAXBマッピングと、高度なマッピング・タイプ用の構成オプションが含まれています。eclipselink-oxm.xmlファイルを、ソース・コードのJAXB注釈のかわりに使用するか、JAXB注釈をオーバーライドするために使用できます。

注意:
このマッピング・ファイルを使用すると、多くの高度な機能が有効になりますが、他のJAXB実装に対するモデルの移植性がなくなる場合があります。

6 マッピングの理解

この章では、マッピングについて紹介および説明します。EclipseLinkでは、オブジェクト表現とデータ・ソース固有の表現との間でデータのトランスフォーメーションを実行できます。このトランスフォーメーションをマッピングと呼びますが、マッピングは、EclipseLinkプロジェクトの中核をなしています。

マッピングはそれぞれ、ドメイン・オブジェクトの単一データ・メンバーに対応しています。マッピングによって、オブジェクト・データ・メンバーをそのデータ・ソース表現と関連付け、オブジェクトとデータ・ソースの間の双方向変換を実行する手段を定義します。

この章の内容は次のとおりです。

- 共通のマッピングの概念

- オブジェクト・リレーショナル・マッピングの概念

- MOXyマッピングの概念

- Object-JSONマッピングの概念

- パディング付きJSONについて

- JAX-RS実装の拡張

6.1 共通のマッピングの概念

この項では、EclipseLinkに固有のリレーショナル・マッピングと非リレーショナル・マッピングの概念について説明します。

- マッピング・アーキテクチャ

- マッピングの例

- マッピング・コンバータ

- シリアライズ・オブジェクト・コンバータ

- タイプ変換コンバータ

- オブジェクト・タイプ・コンバータ

6.1.1 マッピング・アーキテクチャ

マッピングを定義するには、次のコンポーネントを利用します。

- オブジェクトのデータを格納するデータ・ソース(リレーショナル・データベース表またはスキーマ定義のXML要素など)に固有のデータ表現

- 特定オブジェクト・クラスのディスクリプタ

- マップするオブジェクト・クラス

注意:
マッピングは、プロジェクトの永続性の有無にかかわりなく同じです。

標準的なEclipseLinkマッピングの例については、6.1.2項「マッピングの例」を参照してください。

プロジェクトで定義するデータ・ソースのタイプによって、使用できるマッピングのタイプおよびその構成方法が決まります。永続プロジェクトでは、マッピングを使用してデータ・ソースを永続させます。永続ではないプロジェクトでは、オブジェクト形式とその他の一部のデータ表現(XMLなど)の間で単に変換を行うためにマッピングを使用します。

ディスクリプタは、特定のドメイン・オブジェクトを表し、オブジェクトのクラスを記述します。ディスクリプタは、マッピングも所有します(メモリー内で永続化または変換するクラス・データ・メンバーごとに1つのマッピング)。ディスクリプタの詳細は、第5章「ディスクリプタの理解」を参照してください。

6.1.2 マッピングの例

EclipseLinkでは、より複雑なマッピングをサポートしますが、ほとんどのEclipseLinkのクラスは、クラスで使用可能な情報のタイプを定義する1つのデータベース表またはXML要素にマップされます。特定のクラスからインスタンス化された各オブジェクトは、一意にオブジェクトを識別する識別子(主キー)を付加して、オブジェクトの属性を構成する1つの行にマップされます。

図6-1は、最も単純なデータベース・マッピングの例を示します。

- データベースのTable_Xは、Class_Xを表します。

- Object_X1およびObject_X2は、Class_Xのインスタンスです。

- Table_Xの各行は、Object_X1およびObject_X2に加えて、Class_Xのその他のインスタンスも表します。

図6-1 データベース表へのクラスおよびオブジェクトのマップ方法

「図6-1 データベース表へのクラスおよびオブジェクトのマップ方法」の説明

EclipseLinkには、図6-1に示した単純なマッピングから複雑なマッピングまで、これらのマッピングを作成するためのツールが用意されています。

リレーショナル・マッピングのその他の例は、図6-2「シリアライズ・オブジェクト・コンバータ(リレーショナル)」を参照してください。

6.1.3 マッピング・コンバータ

既存のEclipseLinkマッピングがニーズを満たしていない場合、マッピングの拡張機能を使用してカスタムのマッピングを作成できます。これらの拡張機能は、次のとおりです。

- シリアライズ・オブジェクト・コンバータ

- タイプ変換コンバータ

- オブジェクト・タイプ・コンバータ

注意:
シンプル・タイプ変換以外では、データ・ソースがリレーショナルかリレーショナルでないかにかかわらず、マッピング・コンバータおよびトランスフォーマを使用できます。シンプル・タイプ変換は、XMLプロジェクトにのみ適用されます。

6.1.3.1 シリアライズ・オブジェクト・コンバータ

シリアライズ・オブジェクト・コンバータは、Javaオブジェクト・シリアライズを介して複雑なオブジェクトをバイナリ・フィールドにマップできるダイレクト・マッピングおよびダイレクト・コレクション・マッピングで使用できます。シリアライズされたオブジェクトは、通常、データベースのRAWまたはバイナリ・ラージ・オブジェクト(BLOB)フィールド、またはXML文書のHEXまたはBASE64要素に格納されます。

図6-2は、シリアライズ・オブジェクト・コンバータを使用したフィールドへ直接マッピングの例を示しています。属性jobDescriptionには、データベースのJOB_DESCフィールドに格納される、書式設定されたテキスト文書が含まれています。

図6-2 シリアライズ・オブジェクト・コンバータ(リレーショナル)

「図6-2 シリアライズ・オブジェクト・コンバータ(リレーショナル)」の説明

図6-3に、シリアライズ・オブジェクト・コンバータを使用する非リレーショナル・マッピングの例を示します。属性jobDescriptionには、EclipseLinkによってXMLスキーマのJOB DESCRIPTION要素に格納される、書式設定されたテキスト文書が含まれています。

図6-3 シリアライズ・オブジェクト・コンバータ(非リレーショナル)

「図6-3 シリアライズ・オブジェクト・コンバータ(非リレーショナル)」の説明

シリアライズ・オブジェクト・コンバータは、Javaシリアライザを利用します。ドメイン・オブジェクトをシリアライズ・オブジェクト・コンバータでマップする前に、ドメイン・オブジェクトにjava.io.Serializableインタフェースが実装され(または実装が継承され)、シリアライズされていないすべてのフィールドにtransientがマークされていることを確認してください。

6.1.3.2 タイプ変換コンバータ

タイプ変換コンバータは、複雑なオブジェクトをバイナリ・フィールドにマップできるダイレクト・マッピングおよびダイレクト・コレクション・マッピングで使用できます。たとえば、データ・ソースのNumberをJavaのStringにマップすることや、Javaのjava.util.Dateをデータ・ソースのjava.sql.Dateにマップすることができます。

図6-4に、タイプ変換マッピング(リレーショナル)の例を示します。java.util.Dateクラスは、デフォルトではTimestampとしてデータベースに格納されるため、そのクラスは、まず、java.sql.Dateのような明示的なデータベース・タイプに変換する必要があります(これはDB2に対してのみ必須であり、その他の大部分のデータベースには、任意の日付または時間を格納できる単一日付のデータ・タイプがあります)。

図6-4 タイプ変換マッピング(リレーショナル)

「図6-4 タイプ変換マッピング(リレーショナル)」の説明

図6-5は、タイプ変換マッピング(非リレーショナル)を示しています。java.util.DateオブジェクトがXMLスキーマのStringにマップされています。

図6-5 タイプ変換マッピング(非リレーショナル)

「図6-5 タイプ変換マッピング(非リレーショナル)」の説明

データベース用に特別にタイプ処理が必要な場合、タイプ変換コンバータを使用してその特定のデータベースを指定できます。コンバータには、5Kを超えるBLOBおよびCLOBフィールドの処理に必要なOracle Thin JDBCの特別な挿入および更新と同様に、NCHAR、NVARCHAR2およびNCLOBフィールドに必要な特別なOracle JDBCの特別なバインド・オプションのためのサポートが含まれています。

EclipseLinkは、org.eclipse.persistence.platform.database.oracleパッケージのNCharacter、NClobおよびNStringタイプをコンバータのデータ・タイプとして使用し、NCHAR、NCLOBおよびNVARCHAR2タイプをサポートしています。EclipseLinkは、java.sql.BlobおよびClobタイプをコンバータのデータ・タイプとして使用して、5Kを超えるBLOBおよびCLOBの値をサポートしています。

データ・ソースの時間タイプ(TIMESTAMPなど)をjava.lang.Stringにマップするためにタイプ変換コンバータを構成できます。ただし、String値が次の書式に一致していることが条件です。

- YYYY/MM/DD HH:MM:SS

- YY/MM/DD HH:MM:SS

- YYYY-MM-DD HH:MM:SS

- YY-MM-DD HH:MM:SS

より複雑なStringをTIMESTAMPタイプに変換する場合は、トランスフォーメーション・マッピングを検討してください(6.1.4項「トランスフォーメーション・マッピング」を参照)。

@TypeConverter注釈を使用して、マップ済属性の読取りおよび書込み中にデータ値を変更することもできます。各TypeConverterは、一意の名前を付ける必要があり、クラス、フィールドおよびプロパティ・レベルで定義でき、Entity、MappedSuperclassおよびEmbeddableクラス内で指定できます。TypeConverterは、常に@Convert注釈を使用して指定されます。

@TypeConverterをBasic、BasicMapまたはBasicCollectionマッピングに配置できます。これらの注釈の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

6.1.3.3 オブジェクト・タイプ・コンバータ

オブジェクト・タイプ・コンバータは、一定数の値をJavaオブジェクトに対応させることができるダイレクト・マッピングおよびダイレクト・コレクション・マッピングで使用できます。このコンバータは、スキーマにある値がJavaにある値と異なる場合に使用します。

図6-6は、Employee属性のgenderとXML要素のgenderとの間のオブジェクト・タイプの変換を示しています。Javaのオブジェクト属性の値がFemaleの場合、EclipseLinkではその値がFとしてXML要素に格納されます。

図6-6 オブジェクト・タイプXMLコンバータ

「図6-6 オブジェクト・タイプXMLコンバータ」の説明

@ObjectTypeConverter注釈を使用した、オブジェクト・タイプの変換の実行もできます。この注釈は、マップ済属性の読取りおよび書込み中にデータベース・データ値の固定数をJavaオブジェクト値に変換するorg.eclipse.persistence.mappings.converters.ObjectTypeConverterを指定します。この注釈には、@ConversionValue注釈を使用して、変換値の配列に対する値を提供する必要があります。詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@ObjectTypeConverterおよび@ConversionValueの説明を参照してください。

6.1.4 トランスフォーメーション・マッピング

ある種の特殊な状況においては、データ・ソースの処理に関して、既存のマッピング・タイプおよびそのデフォルトのJavaでは、不十分な場合が考えられます。このような特殊なケースでは、Javaでの値の表現とデータ・ソースでの値の表現の間で、特殊な変換を実行するためのトランスフォーメーション・マッピングの使用を検討できます。

ヒント:
トランスフォーメーション・マッピングは複雑なため、多くの場合、コンバータまたはフィールドへ直接マッピングのgetterおよびsetterメソッドを使用する方が簡単に変換を実行できます。

図6-7は、トランスフォーメーション・マッピングを示しています。B_DATEおよびB_TIMEフィールドからの値は、birthDate属性に格納されるjava.util.Dateの作成に使用されます。

図6-7 トランスフォーメーション・マッピング

「図6-7 トランスフォーメーション・マッピング」の説明

トランスフォーメーション・マッピングは、次の2つのコンポーネントで構成されています。

- 属性トランスフォーマ: 読取り時にオブジェクト属性トランスフォーメーションを実行します。

- フィールド・トランスフォーマ: 書込み時にオブジェクト属性からフィールドへのトランスフォーメーションを実行します。

トランスフォーマは、別個のクラスまたはドメイン・オブジェクトでのメソッドのいずれかとして実装できます。

多くの場合、トランスフォーメーション・マッピングは、複数のフィールドの値を使用して1つのオブジェクトを作成する場合に適しています。このタイプのマッピングでは、データベースからオブジェクトを読み取る際に起動される、属性トランスフォーメーションが必要です。これには、Recordのインスタンスであるパラメータを1つ以上持たせる必要があります。属性トランスフォーメーションでは、特定の列の値の取得にRecordメソッドgetを使用できます。属性トランスフォーメーションは、オプションで2番目のパラメータ(Sessionのインスタンス)を指定できます。Sessionは、トランスフォーメーションで必要な追加の値を取得するために、データベースで問合せを実行します。トランスフォーメーションにより、属性に格納される値が返されます。

トランスフォーメーション・マッピングでは、オブジェクトが保存される際にデータベースに書き込まれる、各フィールドに対するフィールド・トランスフォーメーションも必要です。トランスフォーメーションは、そのフィールドに格納される値を返します。

属性およびフィールド・トランスフォーメーションの実装時には、アプリケーション・データをデータ・ソースに、またはその逆に適合させるための変換に必要な、どのような処置も講じることができます。

@Transformation属性を使用して、データベース列値と属性値のトランスフォーメーション・マッピングを実行できます。@WriteTransformerおよび@ReadTransformer注釈とともにこの注釈を使用します。@WriteTransformer注釈は、単一の属性値を単一のデータベース列値に変換するために使用します。この注釈については、FieldTransformerインタフェースの実装を提供することもできます。@ReadTransformer注釈については、org.eclipse.persistence.mappings.transformers.AttributeTransformerインタフェースの実装を提供する必要があります。これらの注釈の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の @Transformation、@ReadTransformerおよび@WriteTransformerに関する説明を参照してください。

6.2 オブジェクト・リレーショナル・マッピングの概念

この項では、EclipseLinkに固有のリレーショナル・マッピングの概念について説明します。

- インダイレクション(遅延ロード)

- インダイレクション、シリアライズおよびデタッチ

- ValueHolderインダイレクション

- 透過インダイレクション

- プロキシ・インダイレクション

- ウィービング済インダイレクション

- JPAマッピング・タイプについて

6.2.1 インダイレクション(遅延ロード)

デフォルトでは、EclipseLinkは永続オブジェクトを取得する際に、そのオブジェクトが参照する依存オブジェクトをすべて取得します。リレーションシップ・マッピングによってマップされた属性に対してインダイレクション(遅延読取り、遅延ロードおよびジャストインタイム読取りとも呼びます)を構成すると、参照オブジェクトのプレースホルダとしてインダイレクション・オブジェクトが使用されます(EclipseLinkは、その特定の属性がアクセスされるまで、依存オブジェクトの読取りを遅延します)。その結果、アプリケーションにとって重要なのは取得されたオブジェクトの内容のみであり、関連オブジェクトの内容は重要でないという場合は特に、パフォーマンスが大幅に向上します。

すべての関連マッピングに対してインダイレクションを使用することをお薦めします。これにより、データ・ソースへのアクセスを最適化できるだけでなく、永続性ユニット処理、キャッシュ・アクセスおよび同時実行性のEclipseLinkによる最適化が可能になります。

注意:

- インダイレクションの使用は、双方向リレーションシップの適切なメンテナンスのために特に重要です。この場合、インダイレクションを使用する必要があります。コレクションを操作する場合は、透過インダイレクションを使用する必要があります(6.2.4項「透過インダイレクション」を参照)。

- インダイレクション(遅延ロード)の実装はベンダー固有です。LAZY属性またはフィールドやリレーションシップが使用されている場合、エンティティのシリアライズおよび永続性コンテキストへのマージが、ベンダー間で相互運用できない場合があります。

図6-8に、インダイレクションの例を示します。インダイレクションを使用しない場合、Orderオブジェクトを読み取ると、LineItemオブジェクトの依存コレクションも読み取られます。インダイレクションを使用する場合、Orderオブジェクトを読み取っても、LineItemオブジェクトの依存コレクションは読み取られません(lineItems属性は、インダイレクション・オブジェクトを参照します)。customerIdなどの他の属性にはアクセスできますが、EclipseLinkが依存LineItemオブジェクトを読み取るのは、lineItems属性にアクセスがあった場合のみです。

図6-8 EclipseLinkインダイレクション

「図6-8 EclipseLinkインダイレクション」の説明

EclipseLinkでは、次のインダイレクション・タイプをサポートします。

- ValueHolderインダイレクション

- 透過インダイレクション

- プロキシ・インダイレクション

アプリケーションのシリアライズ対象となるオブジェクトにインダイレクションを使用する場合、デシリアライズ時にトリガーされないインダイレクション・オブジェクトの影響を検討する必要があります。6.2.2項「インダイレクション、シリアライズおよびデタッチ」を参照してください。

6.2.2 インダイレクション、シリアライズおよびデタッチ

インダイレクション(遅延ロード)を使用している場合、永続オブジェクトのグラフにトリガーされていないインダイレクション・オブジェクトが含まれる可能性があります。インダイレクション・オブジェクトは一時オブジェクトで、1つのJVMと別のJVMの間でシリアライズが存続することはないため、トリガーされていないインダイレクション・オブジェクトでは、デシリアライズ後にリレーションシップへのアクセスが行われるとエラーがトリガーされます。

アプリケーションでは、デシリアライズ後に必要なインダイレクト・リレーションシップがシリアライズ前にインスタンス化されていることを確認する必要があります。これを行うには、ValueHolderまたはウィービング済インダイレクションを使用して任意のリレーションシップのgetメソッドにアクセスし、透過インダイレクションを使用して任意のリレーションシップのsizeメソッドをコールします。アプリケーションで、シリアライズ時にリレーションシップを常にインスタンス化する場合、永続クラスのシリアライズwriteObjectメソッドを上書きして、最初に目的のリレーションシップをインスタンス化できます。多数のリレーションシップや階層の深いリレーションシップを持つオブジェクトでは、ラージ・オブジェクト・グラフをシリアライズしないように注意してください(クライアントで必要とされるリレーションシップのみがインスタンス化されるのが理想的です)。

JPAエンティティをシリアライズする場合、シリアライズの前にインスタンス化されていないLAZYリレーションシップは、アクセスされるとエラーの原因となります。ウィービングをサーバーで使用し、エンティティをクライアントにシリアライズする場合、jarの静的ウィービングを通じて、またはEclipseLinkエージェントを使用したクライアントJVMの起動を通じて、同じウィービング・クラスがクライアントに存在している必要があります。

詳細は、3.2.1.4項「Javaバイト・コード・ウィービングの使用」を参照してください。

6.2.3 ValueHolderインダイレクション

インダイレクションを使用する永続クラスは、リレーションシップ属性を値ホルダー属性に置き換える必要があります。ValueHolderは、ValueHolderなど、ValueHolderInterfaceインタフェースを実装するクラスのインスタンスです。このオブジェクトには、置き換えられるオブジェクトをデータベースから取得するために必要な情報が格納されます。アプリケーションがValueHolderにアクセスしないと、置き換えられたオブジェクトはデータベースから読み取られません。

ValueHolderが置き換えるオブジェクトを取得するには、ValueHolderInterfaceのgetValueおよびsetValueメソッドを使用します。これらのメソッドを使用する便利な方法としては、次の例で示すように、ValueHolderInterfaceのgetValueおよびsetValueメソッドを、getおよびsetメソッド内で非表示にする方法があります。

図6-9に、データベースから読み取られるEmployeeオブジェクトを示します。Addressオブジェクトは読み取られず、アクセスするまで作成されません。

図6-9 読み取られないアドレス・オブジェクト

「図6-9 読み取られないアドレス・オブジェクト」の説明

図6-10に示すとおり、最初のアドレスへのアクセス時に、ValueHolderはAddressオブジェクトを読み取り、それを返します。

図6-10 最初のリクエスト

「図6-10 最初のリクエスト」の説明

図6-11で示すように、アドレスに対する後続のリクエストではデータベースにアクセスしません。

図6-11 後続のリクエスト

「図6-11 後続のリクエスト」の説明

メソッド・アクセスを使用している場合、マッピングで指定されたgetおよびsetメソッドは、ValueHolderが参照しているオブジェクトではなく、ValueHolderInterfaceのインスタンスにアクセスする必要があります。アプリケーションがこれらのgetterおよびsetterを使用することはありませんが、ValueHolderの使用を隠すgetterおよびsetterを使用します。

6.2.4 透過インダイレクション

透過インダイレクションでは、次のいずれかのJavaオブジェクトとして関連オブジェクトのコレクションを保持する永続クラスの任意のリレーションシップ属性を宣言します。

- java.util.Collection

- java.util.Hastable

- java.util.List

- java.util.Map

- java.util.Set

- java.util.Vector

EclipseLinkでは、適切なインタフェースを実装し、関連オブジェクトのJust-in-Time方式による読取りも実行するインダイレクション・オブジェクトが使用されます。透過インダイレクションを使用する場合、属性をValueHolderInterfaceとして宣言する必要はありません。

新たに作成されたコレクション・マッピングは、属性がValueHolderInterfaceではない場合、デフォルトで透過的なインダイレクションを使用します。

JPAエンティティおよびPlain Old Java Object (POJO)クラスに対しては、透過インダイレクト・コンテナ・インダイレクションのウィービングが自動的に実行されるようEclipseLinkを構成できます。詳細は、3.2.1.4項「Javaバイト・コード・ウィービングの使用」および3.5項「ウィービングについて」を参照してください。

6.2.5 プロキシ・インダイレクション

JavaクラスのProxyを使用して、定義済インタフェースのプレースホルダとして動的プロキシ・オブジェクトを使用できます。特定のEclipseLinkマッピングを構成してプロキシ・インダイレクションを使用し、EclipseLinkクラスをドメイン・モデルに含めることなく、インダイレクションの利点を得ることができます。プロキシ・インダイレクションは1対1リレーションシップ・マッピングに対応し、インダイレクション・コンテナはコレクション・マッピングに対応します。

プロキシ・インダイレクションを使用するには、ドメイン・モデルが次の条件をすべて満たしている必要があります。

- 1対1リレーションシップのターゲット・クラスがパブリック・インタフェースを実装していること

- ソース・クラスの1対1属性が、interfaceタイプである必要があります。

- メソッド・アクセスを使用する場合、getterメソッドおよびsetterメソッドはインタフェースを使用する必要があります。

プロキシ・インダイレクションを使用する前に、永続性ユニットの使用方法で設定されている制限に注意してください(6.2.5.1項「プロキシ・インダイレクションの制限」を参照)。

プロキシ・インダイレクションを構成するため、修正メソッドでJDeveloperまたはJavaを使用できます。

6.2.5.1 プロキシ・インダイレクションの制限

Javaのプロキシ・オブジェクトは、送信されるメッセージの遮断にのみ使用できます。==、instanceofまたはgetClassなどのプリミティブ操作がプロキシで使用されている場合は、メッセージは遮断されません。プロキシ・オブジェクトの使用に関しては、アプリケーションでこの制限に多少注意することが必要です。

プロキシ・インダイレクションの実装のターゲットは永続性ユニットに登録できません。かわりに、先にソース・オブジェクトを永続性ユニットに登録します。これにより、ソース・オブジェクト・クローンでgetterコールを使用し、ターゲット・オブジェクト・クローンを取得できます。

6.2.6 ウィービング済インダイレクション

ウィービング用に構成したJPAエンティティまたはPOJOクラスの場合、EclipseLinkでは、1対1マッピングのValueHolderインダイレクションのウィービングが実行されます。アプリケーションにコレクション・マッピング(1対多または多対多)が含まれている場合にEclipseLinkで変更追跡に対するウィービングが実行されるようにするには、すべてのコレクション・マッピングに対し、透過インダイレクト・コンテナ・インダイレクションのみが使用されるように構成する必要があります(コレクション・マッピングは、即時ロードやValueHolderインダイレクションが使用されるようには構成できません)。

詳細は、3.2.1.4項「Javaバイト・コード・ウィービングの使用」を参照してください。

6.2.7 JPAマッピング・タイプについて

リレーショナル表にエンティティ・クラスをマップするには、永続フィールドごとにマッピングを構成する必要があります。次の項では、EclipeLinkのJPAマッピング・タイプについて説明します。

- 基本マッピング

- デフォルトの変換およびコンバータ

- コレクション・マッピング

- オプティミスティック・ロックの使用

6.2.7.1 基本マッピング

シンプルJavaタイプは、エンティティの即時状態の一部としてそのフィールドまたはプロパティにマップされます。シンプルJavaタイプのマッピングは、基本マッピングと呼ばれます。

デフォルトでは、EclipseLink永続性プロバイダによって、シンプル・タイプの基本マッピングが自動的に構成されます。

次の注釈を使用して、アプリケーションでこれらのマッピングを実装する方法を調整します。

- @Basic

- @Enumerated

- @Temporal

- @Lob

- @Transient

- @Column

- 遅延の基本(6.2.7.3.5項「コレクションを使用したインダイレクションの使用」を参照してください)

すべてのマッピング・タイプに、オプションの共通セットがあります。

- 読取り専用: 読取りおよびコピー時にマッピングで値の移入を行うように指定します。複数のマッピングで同じデータベース列を共有する場合には必須です。

- コンバータ: ほとんどのマッピング・タイプでカスタム・データ・タイプおよびデータの変換を使用できます。

- 注釈: @Converter、@TypeConverter、@ObjectTypeConverter、@StructConverter、@Convert

- 外部メタデータ: <converter>、<type-converter>、<object-type-converter>、<struct-converter>、<convert>

これらの注釈の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

6.2.7.2 デフォルトの変換およびコンバータ

『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のコンバータ注釈に関する項には、EclipseLinkが定義するコンバータ注釈の拡張のリストおよび説明へのリンクが記載されています。

次の説明については、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の個々のコンバータ注釈を参照してください。

- EclipseLink永続性プロバイダがコンバータ注釈を検索する順序

- コンバータを指定するクラスのタイプ(クラス、フィールドおよびプロパティ・レベルでコンバータを定義できます)

- コンバータを使用できるマッピング

6.2.7.3 コレクション・マッピング

DescriptorCustomizerクラスを使用して、EclipseLinkディスクリプタおよびマッピングAPIを通じて追加の拡張マッピングおよびマッピング・オプションにアクセスできます。

- 1対多マッピング

- 多対多マッピング

- コレクションを使用したインダイレクションの使用

6.2.7.3.1 1対多マッピング

1対多マッピングは、1つのソース・オブジェクトとターゲット・オブジェクトのコレクションの間の関連を表すために使用されます。それらは、ターゲット・オブジェクトのCollection(または他のコレクション・タイプ)によるJavaでの実装が簡単だが、リレーショナル・データベースによる実装が難しいもののよい例です。

Javaコレクションでは、所有者がその一部を参照します。リレーショナル・データベースでは、その一部がその所有者を参照します。リレーショナル・データベースでは、この実装を使用して問合せをより効率的にします。

図6-12 1対多リレーションシップ

「図6-12 1対多リレーションシップ」の説明

注意:
1対多リレーションシップに示されているphone属性のタイプは、Vectorです。コレクション属性の宣言にはCollectionインタフェース(またはCollectionインタフェースを実装する任意のクラス)を使用できます。

6.2.7.3.2 JPAマッピング

デフォルトで、JPAでは、1対多の多重度を持つ多値のアソシエーションに対してOneToManyマッピングを自動的に定義します。

@OneToMany注釈を使用して次の操作を行います。

- フェッチ・タイプをEAGERに構成します。

- 関連するターゲット・エンティティを構成します(使用されるコレクションは汎用を使用して定義されないため)。

- アソシエーションのターゲットにカスケードする必要のある操作を構成します(たとえば、所有側エンティティが削除されると、アソシエーションのターゲットも削除されます)。

- 単方向の1対多リレーションシップのために永続性プロバイダによって使用される結合表の詳細を構成します。mappedByまたはJoinColumnを使用する1対多では、関連オブジェクトの削除がデータベース上でカスケードされます。JoinTableを使用する1対多では、結合表の削除がデータベース上でカスケードされます(ターゲット・オブジェクトは、制約方向のためにプライベートであってもカスケードされません)。

詳細は、JPA仕様の11.1.23項「JoinTable Annotation」を参照してください。

http://jcp.org/en/jsr/detail?id=338

6.2.7.3.3 多対多マッピング

多対多マッピングは、ソース・オブジェクトのコレクションとターゲット・オブジェクトのコレクションの間のリレーションシップを表します。この場合、ソースとターゲットのレコード間の関連を管理するための中間表の作成が必要です。

図6-13は、Javaの多対多マッピングおよびリレーショナル・データベース表の多対多マッピングを示しています。

図6-13 多対多リレーションシップ

「図6-13 多対多リレーションシップ」の説明

注意:
多対多リレーションシップに示されているプロジェクト属性では、コレクション属性を宣言するためにCollectionインタフェース(またはCollectionインタフェースを実装する任意のクラス)を使用できます。

6.2.7.3.4 JPAマッピング

デフォルトで、JPAでは、多対多の多重度を持つ多値のアソシエーションに対して多対多マッピングを自動的に定義します。

@ManyToMany注釈を使用して次の操作を行います。

- FetchTypeをEAGERに構成します。

- NULL値がアプリケーションにとって不適切である場合、NULL値を禁止するようにマッピングを構成します(非プリミティブ・タイプの場合)。

- 関連するターゲット・エンティティを構成します(使用されるコレクションは汎用を使用して定義されないため)。

- アソシエーションのターゲットにカスケードする必要のある操作を構成します(たとえば、所有側エンティティが削除されると、アソシエーションのターゲットも削除されます)。

@ManyToMany注釈でサポートされる属性のリストは、Java Persistence仕様を参照してください。

http://jcp.org/en/jsr/detail?id=338

6.2.7.3.5 コレクションを使用したインダイレクションの使用

JPAでは、遅延ロードを、データが最初にアクセスされたときに可能であれば遅延してフェッチするという永続性プロバイダに対するヒントとして規定しています。Java EE環境でアプリケーションを開発する場合、fetchをjavax.persistence.FetchType.LAZYに設定し、必要なすべての機能を永続性プロバイダで提供します。

Java SE環境で1対1または多対1のマッピングを使用する場合、fetch属性をFetchType.LAZYに設定することで、動的ウィービングまたは静的ウィービングを使用して遅延ロードを実行します。また、Java SE環境では、1対多リレーションシップおよび多対多リレーションシップはデフォルトではLAZYで、透過インダイレクションが使用されます。一方、1対1リレーションシップおよび多対1リレーションシップはLAZYではありません。

Java SE環境や、JVMコマンド行で-javaagentの使用が許可されない環境で1対1または多対1のマッピングを使用する場合、fetch属性をFetchType.LAZYに設定することで、静的ウィービングを使用して遅延ロードを実行します。

1対1リレーションシップおよび多対1リレーションシップをLAZYに設定してウィービングを有効にすると、EclipseLink JPA永続性プロバイダでは、ウィービングを介して、これらのリレーションシップに対するValueHolderインダイレクションが有効になります。

コレクション注釈@OneToOne、@OneToMany、@ManyToManyおよび@ManyToOneには、lazyまたはeagerに設定できるfetchマッピング属性が用意されています。属性をlazyに設定すると、EclipseLink JPA永続性プロバイダでインダイレクションが使用されます。

表6-1は、マッピング・タイプ別の遅延ロードのサポートを示しています。

表6-1 マッピング・タイプ別の遅延ロードのサポート

マッピング

Java EE

Java SE

多対多

fetch属性がjavax.persistence.FetchType.LAZYに設定されている場合に遅延ロードが実行されます(デフォルト)。

fetch属性がjavax.persistence.FetchType.LAZYに設定されている場合に遅延ロードが実行されます(デフォルト)。

1対多

fetch属性がjavax.persistence.FetchType.LAZYに設定されている場合に遅延ロードが実行されます(デフォルト)。

fetch属性がjavax.persistence.FetchType.LAZYに設定されている場合に遅延ロードが実行されます(デフォルト)。

1対1

fetch属性がjavax.persistence.FetchType.LAZYに設定されている場合に遅延ロードが実行されます。

fetch属性は無視され、デフォルトのjavax.persistence.FetchType.EAGERが適用されます。

多対1

fetch属性がjavax.persistence.FetchType.LAZYに設定されている場合に遅延ロードが実行されます。

fetch属性は無視され、デフォルトのjavax.persistence.FetchType.EAGERが適用されます。

基本

fetch属性がjavax.persistence.FetchType.LAZYに設定されている場合に遅延ロードが実行されます。

fetch属性は無視され、デフォルトのjavax.persistence.FetchType.EAGERが適用されます。

6.2.7.4 オプティミスティック・ロックの使用

オプティミスティック・ロックの使用をお薦めします。オプティミスティック・ロックを使用した場合、すべてのユーザーにデータへの読取りアクセス権限があります。ユーザーが変更を書き込もうとすると、アプリケーションにより、ユーザーがデータを読み取ってから、そのデータが変更されていないかが確認されます。

6.2.7.4.1 ステートレス環境でのオプティミスティック・ロック

ステートレス環境では、期限切れの(失効した)データを処理しないよう、特に注意する必要があります。失効したデータを処理しないための一般的な戦略は、オプティミスティック・ロックを実装し、オプティミスティック・ロックの値をオブジェクトに格納することです。この方法は、ステートレス・アプリケーションがオブジェクトをシリアライズする場合、またはオブジェクトの内容を代替形式でクライアントに送信する場合には、十分注意して行う必要があります。これらの場合、オプティミスティック・ロックの値を編集ページのHTTPコンテンツとしてクライアントに転送します。次に、任意の書込みトランザクションの戻り値を使用して、クライアントが処理を実行しているときに、データが変更されていないことを確認する必要があります。

オプティミスティック・バージョン・ロック・ポリシーまたはオプティミスティック・フィールド・ロック・ポリシーを使用できます。バージョン・ロック・ポリシーの使用をお薦めします。

6.2.7.4.2 オプティミスティック・バージョン・ロック

@Version注釈を使用して、オプティミスティック・ロックの値として機能するエンティティ・クラスのバージョン・フィールドまたはプロパティを指定することで、JPA管理のオプティミスティック・ロックを有効化できます(推奨)。

バージョン・フィールドまたはプロパティを選択する場合、次の条件を満たす必要があります。

- 1つのエンティティに対してただ1つのバージョン・フィールドまたはプロパティがあること

- プライマリ表に永続化されたプロパティまたはフィールドを選択すること

- アプリケーションでバージョン・プロパティまたはフィールドを変更しないこと

詳細は、JPA仕様の11.1.45項「Table Annotation」を参照してください。

http://jcp.org/en/jsr/detail?id=338

注意:
フィールドまたはプロパティ・タイプは、数値型(Number、long、int、BigDecimalなど)またはjava.sql.Timestampである必要があります。EclipseLinkでは数値型の使用をお薦めします。

@Version注釈には属性はありません。@Version注釈では、EclipseLinkコンバータを使用することができます。6.2.7.2項「デフォルトの変換およびコンバータ」を参照してください。

詳細は、JPA仕様の11.1.9項「Column Annotation」を参照してください。

http://jcp.org/en/jsr/detail?id=338

6.3 MOXyマッピングの概念

XMLマッピングは、オブジェクトのデータ・メンバーを、構造がXMLスキーマ・ドキュメント(XSD)により定義されているXML文書のXML要素に変換します。様々なXMLマッピング・タイプを使用して、XMLの単純および複合型の組合せにJavaオブジェクトの属性をマップできます。

クラスは複合型にマップされ、オブジェクトの関係はXML要素にマップされ、単純属性はテキスト・ノードとXML属性にマップされます。MOXyを使用する場合の真価は、オブジェクト属性をXML文書にマッピングする際に、XPath文を使用してXMLデータの場所を指定できることにあります。

EclipseLinkでは、クラスのディスクリプタに各クラスのXMLマッピングを格納します。EclipseLinkでは、ディスクリプタを使用してXML文書からマップされたオブジェクトをインスタンス化し、新規または変更済のオブジェクトをXML文書として格納します。

EclipseLinkには、JAXB仕様には定義されていないXMLマッピングが用意されています。MOXyの拡張機能には、EclipseLinkの注釈を介して使用できるものと、基礎となるメタデータに対するプログラムの変更が必要なものがあります。

MOXyに対するマッピングの概念については、『Oracle TopLinkによるJAXBアプリケーションの開発』に記載されています。次の章を参照してください。

EclipseLink MOXyランタイムに関する章の内容は次のとおりです。

- JAXB注釈に代わる、EclipseLink XMLバインディング・ドキュメント。XMLバインディングは、マッピング情報を実際のJavaクラスから分離できるだけでなく、高度なメタデータにも使用できます。

- JAXBContextの作成時に使用できる、何種類かのブートストラップ・オプション。

- EclipseLinkメタデータの提供を担当する、MetadataSourceインタフェース。このインタフェースの実装の指定により、マッピング情報をアプリケーションの外部に保存して、アプリケーションのJAXBContextが作成またはリフレッシュされるときにマッピング情報を取得できるようになります。

- スキーマの生成および検証。

- マーシャリング・プロセス中およびアンマーシャリング・プロセス中に、イベント・コールバックを取得する何種類かのメカニズム。マップされたオブジェクトにコールバック・メソッドを直接指定するか、または別のListenerクラスを定義し、JAXBランタイムに登録できます。

- XPathによるオブジェクトの問合せ。これは、従来のJavaアクセス・メソッドに代わる、オブジェクトの値の取得および設定方法です。EclipseLink MOXyでは、XPath文を使用して値にアクセスすることができます。EclipseLinkのJAXBContextには、XPathで値を取得および設定できるようにするための特殊なAPIがあります。

- アイテムの一部のみがマップされている場合でもXML文書全体を保持できる、JAXB Binderインタフェースの使用。

単純な値のマッピングに関する章では、MOXyでマッピングを設定する初期タスクについて説明しています。

- XML文書の最上位レベルのルートが何になるかをEclipseLinkに通知する、デフォルトのルート要素。

- Javaクラスの名前空間の情報、およびすべての要素が名前空間に対して修飾されている必要があること。パッケージ、タイプまたはフィールド/プロパティ・レベルの要素を名前空間に対して修飾できます。

- xsi:type属性、代替グループまたはMOXY固有の@XmlDiscriminatorNodeおよび@XmlDiscriminatorValue注釈を使用して、XMLで継承階層を指定する方法

単純な値のマッピングに関する章および特殊なスキーマ・タイプのマッピングに関する章は、Java値をXMLにマップする様々な方法を説明しています。

- Java値はXML属性、テキスト・ノード、スキーマ・タイプまたはシンプル・タイプ・トランスレータにマップできます。

- 単純なJava値のコレクションは、テキスト・ノード、グループ化要素内のテキスト・ノード、リスト要素またはXmlAttributesまたはXmlValuesのコレクションにマップできます。

- OXMメタデータを使用して1つのプロパティに複数のJavaマッピングを作成できます。ただし、読取り可能なマッピングはせいぜい1つです(それ以外は「書込み専用」です)。

- Javaenumsは、@XmlEnum注釈と@XmlEnumValue注釈を使用してXMLにマップできます。

- 日付と時間: また、EclipseLink MOXyは、JAXB仕様で扱われていない次の型をサポートしています。java.sql.Date、java.sql.Timeおよびjava.sql.Timestamp。

- unionファイル: EclipseLinkでXMLスキーマ・ユニオンなどのXML文書をアンマーシャリングする場合、正常な変換が行われるまで、union型のそれぞれが試行されます。現時点では、EclipseLinkは、注釈またはOXMメタデータを使用したunionのマッピングをサポートしていません。ただし、EclipseLinkのXMLカスタマイザを使用してマッピングを作成することはできます。

- バイナリ形式: EclipseLinkでは、base64Binary(デフォルト)とhexBinaryという、2つの表現形式でのバイナリ・データのマーシャリングおよびアンマーシャリングをサポートしています。EclipseLink OXMで@XmlSchemaType注釈または<xml-schema-type>要素を使用して、目的のバイナリ形式を指定できます。

6.3.1 XMLデータ表現の理解

JPAからXMLへのマッピングに注釈を使用することは、常に最も効果的とはかぎりません。たとえば、次の場合にはJAXBを使用しません。

- サード・パーティのクラスにメタデータを指定する必要があるが、ソースにアクセスできない場合。

- 複数のXMLスキーマにオブジェクト・モデルをマップする必要がある場合。JAXBのルールでは、注釈を使用して複数のマッピングを適用することはできません。

- オブジェクト・モデルにすでに多くの注釈(たとえば、JPA、Spring、JSR-303などのサービスから)が含まれていて、他の場所でメタデータを指定する必要がある場合。

これらの状況および類似の状況では、eclipselink_oxm.xmlファイルを公開して、XMLデータ表現を使用できます。

XMLメタデータは、次の2つのモードで動作します。

- 注釈で指定されたメタデータに追加します。これは、次の場合に便利です。

- XML表現のバージョンのひとつが注釈に定義されており、XMLメタデータを使用して将来のバージョンのメタデータを微調整する場合。

- 標準のJAXB注釈を使用し、かつMOXy拡張機能用のXMLメタデータを使用する場合。このようにすると、コンパイル時の依存関係がオブジェクト・モデルに新たに生じることはありません。

- 注釈メタデータを完全に置換します。これは、様々なXML表現にマップする必要がある場合に便利です。

6.3.2 マッピング値

単純なJava値および単純な値のコレクションを、XMLテキスト・ノードに直接マップする方法がいくつかあります。属性、テキスト・ノードまたはスキーマ・タイプにマップできます。シンプル・タイプ・トランスレータを使用して、XMLスキーマで定義されていないタイプのノードにマップすることもできます。これらの方法は『Oracle TopLinkによるJAXBアプリケーションの開発』の単純な値のマッピングに関する項に記載されています。

6.3.3 MOXyでの属性のサブセットのマーシャリングおよびアンマーシャリング

オブジェクト・リレーショナル・マッピングでは、EclipseLinkはFetchGroupsおよびAttributeGroupsを定義して、特定のオブジェクトのどの属性を書き出し、どの属性を読み込むかを制御します。

現在のMOXy/JAXBリリースでは、マーシャリングおよびアンマーシャリングするオブジェクト属性のサブセットを構成できるようになりました。これを行うには、注釈のセットを使用して、ディスクリプタに属性グループを設定します。注釈は、XmlNamedObjectGraphs、XmlNamedObjectGraph、XmlNamedAttributeNodeおよびXmlNamedSubGraphです。Xml接頭辞により同等のJPA注釈と区別されることに注意してください。

@XmlNamedObjectGraph拡張機能は、マーシャリングまたはアンマーシャリングするモデルのサブセットの指定に使用します。1つ以上の@XmlNamedAttributeNode注釈を指定することにより指定します。プロパティに適用されるオブジェクト・グラフが必要な場合、サブグラフを指定できます。サブグラフはターゲット・クラスの@XmlNamedSubgraphまたは@XmlNamedObjectGraph注釈のいずれかで指定できます。

インタフェースのセットも定義されているため、ObjectGraphsを実行時に動的に作成できます。これらのObjectGraphsは、事前定義済のObjectGraphの名前のかわりにマーシャラまたはアンマーシャラに設定できます。インタフェースはObjectGraph、SubgraphおよびAttributeNodeです。ObjectGraphの新しいインスタンスを作成するため、メソッドがJAXBContextクラスに含まれています。

6.3.4 双方向に書込み可能な@XmlInverseReference

MOXyの@XmlInverseReference注釈により、アンマーシャル操作の間、バック・ポインタをマップできます(JPAエンティティをマッピングする場合に便利です)。ただし、マーシャル操作の間は@XmlTransientのように動作します。これは、以前のリリースでは、マッピングは一方向のみにしか使用できなかったことを意味します。現在のリリースでは、@XmlInverseReference注釈を@XmlElement注釈と組み合せて、マーシャリング操作の間、プロパティを書込み可能にできるようになりました。これにより、マッピングを双方向に使用できるようになりました。

6.4 Object-JSONマッピングの概念

EclipseLink MOXyでは、JSON (JavaScript Object Notation)を対象とするオブジェクトの変換機能がサポートされます。この機能は、RESTfulサービスを作成する場合に便利です(JAX-RSサービスはXMLとJSON両方のメッセージを受け取ることができます)。

EclipseLinkは、次のようなJSONの読取り時と書込み時のすべてのMOXyオブジェクト/XMLオプションに対応しています。

- EclipseLinkの高度な拡張マッピング機能(JAXB仕様に対する追加)

- 外部バインディング・ファイルへのマッピングの格納

- 動的JAXBによる動的モデルの作成

- マルチテナント・アプリケーションをサポートする拡張可能モデルの作成

EclipseLinkでは、JSON文書のマッピングに次のサポートが提供されます。

- 通常のJAXBでの使用に必要とされるもの以外は、JSONバインディングでコンパイル時の依存性は必要ありません。JSON文書としてMOXy外部バインディング・ファイルを書き込むこともできます。

- XMLは単一のデータ型を保持しますが、JSONは文字列、数値、ブール値を区別します。EclipseLinkでは、これらのデータ型が自動的にサポートされます。

- JSONでは属性は使用されず、@XmlAttribute注釈を使用してマップされたものはすべて要素としてマーシャリングされます。デフォルトでは、EclipseLinkによって属性および要素のイベントが両方ともトリガーされるため、マップされた属性または要素で値を処理できます。

- EclipseLinkでは、ルート要素のないJSON文書がサポートされます。デフォルトで、@XmlRootElement注釈が存在しない場合、マーシャリングされたJSON文書にルート要素は含まれません。EclipseLinkでは、この動作をオーバーライドできます(JSON出力からルート要素を省略できます)。

- JSONではネームスペースを使用しないため、すべてのネームスペースおよび接頭辞は、マーシャリングおよびアンマーシャリング時にデフォルトで無視されます。EclipseLinkでは、マーシャラおよびアンマーシャラに、ネームスペースと接頭辞のMap (またはNamespacePrefixMapperのインスタンス)を提供できます。ネームスペース接頭辞は、要素名の先頭に追加されて、マーシャリングされた文書に出現します。

- デフォルトでは、JSONへのマーシャリング時に、EclipseLinkは空のコレクションを[ ]としてマーシャリングしますが、この動作をオーバーライドして、空のコレクションをまったくマーシャリングしないようにできます。

- ルート・レベルのコレクションをマーシャリングおよびアンマーシャリングできます。

JSON文書に対するEclipseLinkサポートの詳細は、『Oracle TopLinkによるJAXBアプリケーションの開発』のJSON文書の使用に関する項を参照してください。

6.4.1 XMLおよびJSONへのコレクション・マッピング

デフォルトでは、JAXB実装はコレクション・データに関するグループ化要素を出力しません。しかし、@XmlElementWrapper注釈をJSONキーとして使用することにより出力できます。このグループ化要素は複数形の名前を持つことも多く、@XmlElement注釈で定義された繰返し要素よりは、JSON配列のキーにより良く適合します。

6.5 パディング付きJSONについて

JSONPつまり「パディング付きJSON」は、Webブラウザで動作するJavaScriptが使用する通信技術です。一般的なWebブラウザでは同一生成元ポリシーにより禁止されている、異なるドメインのサーバーからデータを要求する方法を提供します。

JSONPと呼ばれる使用パターンは、<script>要素のオープン・ポリシーを使用して、動的に生成されたJSON形式のデータで動作するJavaScriptコードを他の生成元から取得します。JSONPに対するリクエストはJSONを取得するかわりに、任意のJavaScriptコードを取得します。JavaScriptインタプリタが評価を行い、JSONパーサーによる解析は行われません。

6.6 JAX-RS実装の拡張

MOXyには、MOXyJsonProviderと呼ばれるMessageBodyReaderおよびMessageBodyWriterクラスの実装が用意されています。MOXyJsonProviderクラスは、EclipseLink JAXB (MOXy)をJSONプロバイダとして有効化するために使用できます。このクラスを直接使用または拡張して、JAX-RS統合を容易にすることができます。次の拡張機能がMOXyJsonProviderクラスに追加されています。

- readFromおよびwriteToメソッドのgenericTypeパラメータで、NULL値を使用できるようになりました。

- 最終キーワードはreadFromおよびwriteToメソッドから削除されました。

- WILD_CARDだけでなく、APPLICATION_JSONの値がサポートされるメディア・タイプとして追加されました。

7 データ・アクセスの理解

この章では、セッションの最も重要な機能の1つ、データ・ソースへのアクセスの提供について説明します。この章では、セッション内のデータ・アクセスの背後にある、EclipseLinkに特有の概念について説明します。

この章の内容は次のとおりです。

- 外部管理トランザクション・データ・ソースについて

- データ・ソース・ログインのタイプについて

- データ・ソース・プラットフォームのタイプについて

- 認証について

- 接続について

- 接続プールについて

- データ・パーティション化ポリシーについて

- テナント分離について

- 異機種間バッチ書込みについて

- シリアライズ・オブジェクト・ポリシーについて

- 自動チューニングについて

- TopLink Data Servicesのライブ・データについて

7.1 外部管理トランザクション・データ・ソースについて

EclipseLinkのトランザクション・データ・ソースは、接続プールがトランザクション・サービス(アプリケーション・サーバー制御トランザクションやJTAトランザクションなど)によって管理される場合、外部管理されます。JTA管理のデータ・ソースまたは接続プールは、一般的にJava EEアプリケーションで使用され、通常はEJBアプリケーションで必要になります。外部管理の接続プールは、次のように使用します。

- ExternalTransactionControllerを使用するようにセッションを構成し、EclipseLinkの永続性ユニットを外部トランザクション・サービスに統合します。eclipselink.target-server persistenceユニット・プロパティを使用して、ExternalTransactionControllerインタフェースを実装するクラスの名前を構成します。

- 永続性ユニットのブール型オプションexternal-transaction-controllerを使用して、トランザクションがトランザクション・マネージャーにより管理されており、EclipseLinkが管理できないことを示します。また、データ・ソースがトランザクションをサポートしていない場合、接続のログインを指定し、接続が外部コントローラによって保持されていることをEclipseLinkに通知するために使用します。

- 状況によっては、トランザクションのオーバーヘッドを回避するために、JTA以外の接続プールを使用するようにEclipseLinkの読取り接続プールまたはシーケンス接続プールを構成する必要があります。詳細は、「デフォルト(書込み)および読取り接続プール」および「シーケンス接続プール」を参照してください。

7.2 データ・ソース・ログインのタイプについて

セッションに関連付けられたログイン(存在する場合)によって、EclipseLinkランタイムがプロジェクトのデータ・ソースに接続する方法が決まります。データ・ソースに永続化しないプロジェクトの場合、ログインは必要ありません。データ・ソースに永続化するプロジェクトの場合、ログインは常に必要です。ログインには、認証、接続プールの使用、および外部トランザクション・コントローラの使用などのデータ・ソース・アクセスの詳細が含まれます。Loginは、データ・ソース・プラットフォームを所有します。

データ・ソース・プラットフォームには、バインディング、ネイティブSQLの使用、バッチ書込みの使用、順序付けなどの特定のデータ・ソースに固有のオプションが含まれます。

ログインは様々なロールで使用できます。ログインのロールにより、ログインを作成する場所と方法が決まります。選択するログインのロールは、作成対象のプロジェクトのタイプやログインの使用目的によって異なります。

データ・ソースに永続化するプロジェクト・タイプごとに、独立したセッション・ログイン・タイプがあります。

XMLログインは存在しません。EclipseLink XMLプロジェクトはXMLデータ・トランスフォーメーションに対する非永続的なインメモリー・オブジェクト用として使用されるため、ログインするデータ・ソースは存在しません。

リレーショナル・データベースにアクセスするプロジェクトを作成する場合、DatabaseLoginを使用してプロジェクトを構成する必要があります。DatabasePlatformでの選択により、プロジェクトを特定のタイプのデータベース向けにさらにカスタマイズすることができます。永続性ユニット・オプションdatasource-loginを通じて構成できます。このオプションには、ユーザー名、パスワード、データ・ソース・プラットフォームを実装しているクラスの名前などを構成するための属性が含まれます。

7.3 データ・ソース・プラットフォームのタイプについて

EclipseLinkは、データ・ソース・プラットフォームのクラスを使用して基礎となるデータ・ソースの詳細を抽出します。データ・ソース・プラットフォームは、プロジェクトのLoginによって所有されます。データベース・プラットフォームは、すべてのセッションに対してプロジェクト・レベルで指定するか、このプロジェクト・レベルの構成をセッション・レベルでオーバーライドします。

ほとんどのプラットフォーム・オプションを構成するには、修正メソッドまたはpreLoginイベント・リスナーを使用する必要があります。

EclipseLinkでは、Structured Query Language (SQL)を使用してデータベースと対話します。各データベース・プラットフォームでは、基本SQL言語の独自のバリエーションが使用されるため、EclipseLinkでは、データベースとの通信に使用するSQLを調整し、アプリケーションが円滑に実行されるようにする必要があります。

選択するデータベース・プラットフォームのタイプによって、使用されるJava Database Connectivity (JDBC)ドライバのタイプなど、EclipseLinkランタイムがデータベースにアクセスする場合の特定の手段が決定されます。JDBCは、Javaアプリケーションによるデータベースへのアクセスを可能にするアプリケーション・プログラミング・インタフェース(API)です。EclipseLinkリレーショナル・プロジェクトは、データベースを対象にオブジェクトの読取りや書込みを行うために、JDBC接続に依存します。EclipseLinkアプリケーションでは、アプリケーション・アーキテクチャに応じて個別のJDBC接続を使用するか、JDBC接続プールを使用します。

DatabasePlatformクラスはデータベース・プラットフォーム(Oracle、Sybase、DBaseなど)固有の動作をカプセル化し、この動作にEclipseLinkがアクセスするためのプロトコルを提供します。

EclipseLinkには、ターゲット・データベースに応じてプロジェクトをカスタマイズするために様々なデータベース固有のプラットフォームが用意されています。サポートされているデータベース・プラットフォームのリストについては、org.eclipse.persistence.config.TargetDatabaseクラスおよびA.1項「データベースのサポート」を参照してください。

サポートされているアプリケーション・サーバーのリストについては、org.eclipse.persistence.config.TargetServerおよびA.2項「アプリケーション・サーバーのサポート」を参照してください。使用するアプリケーション・サーバーの名前は、eclipselink.target-server.persistenceユニット・プロパティで指定できます。

datasource-login永続性ユニット・オプションには、ユーザー名、パスワード、接続プーリングなどの構成可能なその他のデータ・ソース・プロパティが含まれます。Loginクラスを実装し、データベースに固有のプロパティを設定できます。

7.4 認証について

認証は、データ・ソースがユーザーのアイデンティティを検証し、そのユーザーに特定のアクションを実行するために十分な権限があるかどうかを確認するための手段です。認証は、データ・セキュリティ、ユーザーのアカウンタビリティおよび監査において中心的な役割を果たします。

2層アプリケーションの場合、通常は単純なJDBC認証で十分です。

次の項では、異なる認証戦略について説明します。

- 単純なJDBC認証

- Oracleデータベースのプロキシ認証

- 監査

7.4.1 単純なJDBC認証

ユーザー名とパスワードを使用してEclipseLinkデータベース・ログインを構成すると、EclipseLinkでは、アプリケーションで使用するように構成されているJDBCドライバにこれらの資格証明が提供されます。

デフォルトでは、EclipseLinkではpersistence.xmlファイルからパスワードが読み取られます。

7.4.2 Oracleデータベースのプロキシ認証

EclipseLinkでは、Oracle JDBCドライバおよび外部接続プールのみを使用した、Java SEアプリケーションおよびJava EEアプリケーションのOracle Databaseでのプロキシ認証がサポートされます。

注意:
EclipseLinkでは、JTAによるOracle Databaseのプロキシ認証はサポートしていません。

Oracleデータベースのプロキシ認証には、次のようなセキュリティ上の利点があります。

- 中間層が代理として接続可能なユーザーや、中間層がユーザーから引き受けるロールの制御による、制限付きの信頼モデル

- Oracle Call Interface (OCI)およびシックJDBCを介したユーザー・セッションのサポートや、クライアント再認証のオーバーヘッドの解消による、スケーラビリティ

- データベースを介した実際のユーザーのアイデンティティの保持や、実際のユーザーのかわりに実行されるアクションの監査の有効化による、アカウンタビリティ

- ユーザーがデータベースに把握される環境や、ユーザーがデータベースに認識されない単なるアプリケーション・ユーザーにすぎない環境のサポートによる、柔軟性

注意:
Oracleデータベースは、3層でのプロキシ認証のみをサポートしています。複数の中間層間におけるプロキシ認証はサポートしていません。

Oracleデータベースでの認証の詳細は、『Oracle Databaseセキュリティ・ガイド』の多層環境でのユーザー・アイデンティティの保持に関する項を参照してください。

プロキシ認証を使用するようにEclipseLinkデータベース・ログインを構成し、次の操作を実行します。

- 3層アーキテクチャでの複雑な認証に対応する(クライアント対中間層および中間層対データベースの認証、中間層を介したデータベースへのクライアントの再認証など)。

- 汎用プール・ユーザーではなくデータベース操作用の特定のユーザーを使用して、データベースの(トリガーおよびストアド・プロシージャに関するものを含む)監査情報を向上させる。

- ストアド・プロシージャでセッション・コンテキストに直接ユーザー情報を設定するのではなく、プロキシ・ユーザーを使用してVPD/OLS構成を簡略化する。

7.4.3 監査

選択する認証のタイプとは関係なく、EclipseLinkは、すべてのデータベース操作に関連するユーザーの名前をログに記録します。例7-1は、CONFIGレベルのEclipseLinkログを示し、ServerSessionがサンプル・ユーザーscottのメイン接続を介して接続し、ClientSessionがプロキシ接続jeffを使用しています。

例7-1 Oracle Databaseのプロキシ認証のログ

[TopLink Config]--ServerSession(13)--Connection(14)--Thread(Thread[main,5,main])--connecting(DatabaseLogin( platform=>Oracle9Platform   user name=> "scott" connector=>OracleJDBC10_1_0_2ProxyConnector datasource name=>DS))
[TopLink Config]--ServerSession(13)--Connection(34)--Thread(Thread[main,5,main])--Connected: jdbc:oracle:thin:@localhost:1521:orcl
User: SCOTT
[TopLink Config]--ClientSession(53)--Connection(54)--Thread(Thread[main,5,main])--connecting(DatabaseLogin(platform=>Oracle9Platform user name=> "scott" connector=>OracleJDBC10_1_0_2ProxyConnector datasource name=>DS))
[TopLink Config]--ClientSession(53)--Connection(56)--Thread(Thread[main,5,main])--Connected: jdbc:oracle:thin:@localhost:1521:orcl
User: jeff

データベース・サーバーによっては、別のユーザー監査オプションが用意されている場合があります。詳細は、データベース・サーバーのドキュメントを参照してください。

または、監査目的でデータベース・スキーマと組み合せてEclipseLink永続性ユニットを使用することも検討してください。

7.5 接続について

接続は、アプリケーションで使用するように構成されたドライバを介してデータ・ソースにアクセスする方法を提供するオブジェクトです。リレーショナル・プロジェクトでは、JDBCを使用してデータ・ソースに接続し、EISプロジェクトではJCAを使用します。EclipseLinkでは、インタフェースorg.eclipse.persistence.internal.databaseaccess.Accessorを使用してデータ・ソース接続をラップします。このインタフェースは、特定のイベントからアクセス可能です。

通常、サーバー・セッションを使用する場合、EclipseLinkは、読取りと書込みの両方に対して異なる接続を使用します。このため、読取りには非トランザクション接続を使用し、必要ない場合は接続を維持しないようにできます。

デフォルトでは、EclipseLinkサーバー・セッションは、接続を遅延して(永続性ユニットのコミット操作時にのみ)取得します。または、クライアント・セッションの取得時に書込み接続を取得するようにEclipseLinkを構成できます。

接続は、内部または外部の接続プールから割り当てることができます。

7.6 接続プールについて

接続プールは、1つ以上のクライアントのかわりにデータ・ソース接続の共有コレクション(プール)を作成および保持するサービスです。接続プールは、リクエストに基づいてプロセスに接続を提供し、プロセスが接続の使用を終了すると、接続をプールに返します。接続は、プールに返されると、他のプロセスで使用できます。データ・ソースへの接続の確立には時間がかかるため、接続プールのこのような接続を再使用してパフォーマンスを向上できます。

EclipseLinkは、接続プールを使用して、サーバーおよびクライアント・セッションで使用される接続を管理および共有します。この機能により、必要な接続数が減り、アプリケーションで多くのクライアントをサポートできるようになります。

EclipseLinkで提供される内部接続プール、またはJDBCドライバまたはJava EEコンテナで提供される外部接続プールを使用するようにセッションを構成できます。

EclipseLinkアプリケーションの接続プールは、読取り、書込み、順序付け、およびその他のアプリケーション固有の機能などの様々な目的に使用できます。

この項では、次の接続プールのタイプについて説明します。

- 内部接続プール

- 外部接続プール

- デフォルト(書込み)および読取り接続プール

- シーケンス接続プール

- アプリケーション固有の接続プール

7.6.1 内部接続プール

Java EE以外のアプリケーションでは、通常、内部接続プールを使用します。デフォルトでは、EclipseLinkセッションは内部接続プールを使用します。

内部接続プールを使用して、デフォルト(書込み)および読取り接続プールを構成できます。オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。

内部接続プールでは、表示専用でデータの変更が頻繁ではないデータを読み取るアプリケーション用の読取り接続の作成を最適化できます。また、ワークベンチを使用して、デフォルト(書込み)および読取りの接続プールを構成したり、オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。

7.6.2 外部接続プール

Java EEアプリケーションでは、通常、外部接続プールを使用します。外部接続プールとは、JDBCドライバまたはJava EEコンテナによって提供される、単一データ・ソースへの再利用可能な接続の集合です。

外部トランザクション・コントローラ(JTA)を使用する場合、外部接続プールを使用してJTAと統合する必要があります。

外部接続プールを使用して、Javaを通じてデフォルト(書込み)および読取りの接続プールを構成したり、オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。

外部接続プールを使用すると、EclipseLinkアプリケーションで次のことが可能になります。

- Java EE対応システムへの統合

- JTAトランザクションとの統合(JTAトランザクションはJTA対応のデータ・ソースを必要とします)

- 複数のアプリケーションが同じデータ・ソースを使用する、共有接続プールの活用

- 構成と管理が直接サーバーで行われるデータ・ソースの使用

7.6.3 デフォルト(書込み)および読取り接続プール

サーバー・セッションでは、読取り接続プールと書込み接続プールが提供されます。これらは異なるプールとするか、または(外部接続プーリングを使用する場合は)同じ接続プールとすることが可能です。

すべての読取り問合せは読取り接続プールからの接続を使用し、データ・ソースに変更を書き込むすべての問合せは書込み接続プールからの接続を使用します。デフォルト(書込み)および読取り接続プールの属性を構成できます。

新規接続が確立されるたびに、セッションのDatasourceLoginに指定した接続構成がEclipseLinkにより使用されます。また、外部トランザクション・コントローラを使用する場合、必要に応じて読取り接続プールごとに個別の接続構成を定義することにより、余計なオーバーヘッドが発生しないようにできます。

connection-pool.readプロパティを使用して、非トランザクション読取り問合せ用の読取り接続プールを構成します。デフォルトで、EclipseLinkでは、読取り問合せにデフォルト・プールが使用され、独立した読取り接続プールは使用されません。詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のconnection-pool.readを参照してください。

7.6.4 シーケンス接続プール

オブジェクト・アイデンティティを保持するうえで重要なのは、各インスタンスを区別するために一意の値の割当ての順序付け管理をすることです。詳細は、8.2項「キャッシュのタイプとサイズについて」を参照してください。

順序付けには、データ・ソースによって管理される特別な順序リソースの読取りと書込みが含まれます。

デフォルトで、EclipseLinkには個別トランザクションの順序操作が含まれます。これによって、順序リソースのデッドロックを発生させる可能性のある書込みトランザクション中の複雑な操作を回避します。ただし、外部トランザクション・コントローラ(JTAデータ・ソースや接続プールなど)を使用する場合、EclipseLinkでは、順序付けで異なるトランザクションを使用できません。シーケンス接続プールを使用して、順序付け用に非JTAトランザクション・プールを構成します。これは、(ネイティブ順序付けではなく)表の順序付けの場合にのみ必要です。

各サーバー・セッションで、EclipseLinkが順序付け用に排他的に使用する、シーケンス接続プールと呼ばれる1つの接続プールを作成できます。シーケンス接続プールによって、EclipseLinkは、リクエストの取得元であるトランザクションの外部にある新しいオブジェクト識別子に対するリクエストに対応できます。これによって、EclipseLinkは、順序リソースに対する更新を即座にコミットし、デッドロックを回避できます。

注意:
シーケンス接続プールの使用時に元のトランザクションが失敗しても、順序操作はロールバックされません。

次のような場合は、シーケンス接続プールを使用する必要があります。

- 表の順序付け(非ネイティブ順序付け)を使用する場合。

- 外部トランザクション・コントローラ(JTA)を使用する場合。

次のような場合は、シーケンス接続プールを使用しないようにする必要があります。

- 順序付けを使用しないか、データ・ソースのネイティブ順序付けを使用する場合。

- デッドロックを回避するために順序表を構成した場合。

- 非JTAデータ・ソースを使用する場合。

永続性ユニット・プロパティeclipselink.connection-pool.sequenceを使用して、シーケンス接続プールを構成できます。このプロパティにより、接続プールは生成されたIDを割り当てることができ、また、このプロパティはTABLEの順序付けのためにのみ必要になります。デフォルトで、TopLinkでは、順序付けにはデフォルト・プールが使用され、独立したシーケンス接続プールは使用されません。詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のconnection-pool.sequenceを参照してください。

7.6.5 アプリケーション固有の接続プール

セッションでEclipseLinkの内部接続プールを使用する場合、アプリケーションの任意の目的のために使用できる1つ以上の接続プールを作成できます。これらは名前付き接続プールと呼ばれ、名前を自由に付け、任意の目的のために使用できます。

通常、これらの名前付き接続プールを使用して、様々なセキュリティ・レベルのプールを提供します。たとえば、デフォルト接続プールの場合は特定の表にのみアクセスできますが、管理接続プールの場合はすべての表にアクセスできます。

7.7 データ・パーティション化ポリシーについて

データ・パーティション化によって、アプリケーションはそのデータを複数のデータベース・マシンにスケーリングできます。データ・パーティション化の詳細は、Oracle TopLinkのソリューション・ガイドのデータのスケールのためのデータ・パーティション化に関する項を参照してください

一部のデータベースでは、複数のマシン全体にわたるデータベースのクラスタリングがサポートされます。Oracle RACでは、単一のデータベースを複数の異なるサーバー・ノードに拡張できます。Oracle RACでは、表およびノードでデータのパーティション化もサポートされます。データベース・クラスタでは、クラスタ内の任意のノードからどのデータにもアクセスできます。ただし、特定のノードへのデータ・アクセスをパーティション化する方が、ノード間通信が減少するため、通常はより効率的です。詳細は、Oracle TopLinkのソリューション・ガイドのクラスタ化データベースおよびOracle RACに関する項を参照してください。

7.8 テナント分離について

Oracle TopLinkでは、アプリケーションを1つ開発し、それを別の複数のクライアント(つまりテナント)に、アプリケーションの割合、データの分離度およびテナントに固有の機能を変えてデプロイできます。たとえば、規模の大きな企業が1つの給与アプリケーションを、複数の部門で使用するよう開発したとします。各部門は、独自のデータと共有データにアクセスできますが、他の部門のデータはまったく参照することができません。

EclipseLinkでは、テナントを分離する機能の設計および実装をかなり柔軟にできます。次などが可能です。

アプリケーションの分離オプション

- コンテナ/サーバーの分離

- 同じコンテナ/サーバー内でアプリケーションを分離

- 同じアプリケーション内でエンティティ・マネージャ・ファクトリおよび共有キャッシュを分離

- エンティティ・マネージャごとにテナントは分離し、エンティティ・マネージャ・ファクトリは共有

データの分離オプション

- データベースの分離

- スキーマ/表領域の分離

- 表の分離

- 表は共有し列を分離

- 問合せのフィルタリング

- Oracle Virtual Private Database (VPD)

EclipseLinkには、データ・ソースでマルチテナンシを提供する次のオプションがあります。

- 単一表マルチテナントでは、テナントは表を共有できます。各テナントには、識別子列によって識別される独自の行があり、それらの行は他のテナントからは認識できません。7.8.1項「単一表マルチテナント」を参照してください。

- テナントごとの表マルチテナントでは、各テナントは表テナント識別子で識別される独自の表を持ち、それらの表は他のユーザーは参照できません。7.8.2項「テナントごとの表マルチテナントの使用」を参照してください。

- (VDP)マルチテナントでは、テナントは同じ表を共有する複数のテナントをサポートする機能を持つVDPデータベースを使用します。7.8.3項「VPDマルチテナント」を参照してください。

7.8.1 単一表マルチテナント

単一表マルチテナントでは、エンティティまたはマップ済のスーパークラスがマップされるすべての表(TableまたはSecondaryTable)に、複数のテナント用の行を含めることができます。テナントに固有の行へのアクセスは、指定のテナントに制限されています。

テナント固有の行は、1つ以上のテナント識別子列を使用してテナントに関連付られています。識別子列には、どのような永続性コンテンツがアクセスできるか制限するアプリケーション・コンテキスト値が使用されています。

マップされた表での問合せの結果は、プロパティ値として提供されるテナント識別子値に制限されます。これは、表のすべての挿入、更新および削除操作に適用されます。マルチテナントのメタデータがマップ済のスーパークラス・レベルで適用されると、独自のマルチテナント・メタデータを指定しないかぎり、すべてのサブエンティティに適用されます。

7.8.2 テナントごとの表マルチテナント

テナントごとの表マルチテナントでは、テナント独自の1つ以上の表に、アプリケーションの複数のテナントはデータを分離できます。複数のテナントの表は、名前に接頭辞または接尾辞が使用して区別して共有スキーマに含めるか、テナント固有の別のスキーマに含めることができます。テナントごとの表エンティティは、同じ永続性ユニットに他のタイプのマルチテナント・エンティティと混在させることができます。

テナントごとの表マルチテナント・タイプは次とともに使用します。

- 識別子の種類を指定するテナント表識別子(接頭辞または接尾辞付きのスキーマまたは名前)

- ユーザーを識別するテナントID(永続性ユニットごとにテナントごとの表を分離する場合、エンティティ・マネージャごとに構成するか、エンティティ・マネージャ・ファクトリで構成)

単一のアプリケーション・インスタンスで永続性ユニットのEntityManagerFactoryが共有されている場合、複数のテナントのリクエストを処理できます。

またはテナントごとに、別のEntityManagerFactoryインスタンスを使用することも可能です。(これはテナントごとに拡張を使用する場合に必要です。)この場合、テナント固有のスキーマおよび表明は、eclipselink-orm.xml構成ファイルに定義します。永続性ユニットにMetadataSourceを登録する必要があります。MetadataSourceは、アプリケーション外から提供されるその他の永続性ユニット・メタデータをサポートするために使用します。『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のmetadata-sourceも参照してください。

テナントごとの表マルチテナント・タイプでは、個々のテナント表をエンティティ・レベルで使用することができます。トランザクションの開始後、各エンティティ・マネージャでテナントのコンテキスト・プロパティを提供する必要があります。

- エンティティの表(TableおよびSecondaryTable)は、テナントのコンテキストに基づく、テナントの個別の表です。結合またはコレクション表を使用するエンティティ内のリーションシップも、テナントごとの表のコンテキスト内に存在することが前提となっています。

- マルチテナントのメタデータは、SINGLE_TABLEまたはJOINED継承戦略の使用時には、継承階層のルート・レベルでしか適用できません。マルチテナント・メタデータは、TABLE_PER_CLASS継承階層内に指定できます。

テナントごとの表マルチテナントの構築の詳細は、Oracle TopLinkのソリューション・ガイドのテナントごとの表マルチテナントの使用に関する項を参照してください。

7.8.3 VPDマルチテナント

仮想プライベート・データベース(VPD)では、様々なパラメータに基づくセキュリティ・コントロールを使用して、データベース・オブジェクトへのアクセスを制限します。

たとえば、Oracle仮想プライベート・データベースでは、行および列レベルでデータベースへのアクセスを制限するセキュリティ・ポリシーをサポートしています。セキュリティ・ポリシーが適用された表、ビュー、シノニムに対して発行されたSQL文に対し、Oracle VPDでは、動的なWHERE句を追加します。

Oracle仮想プライベート・データベースでは、データベース表、ビューまたはシノニムに対し、セキュリティが直接強制されます。セキュリティ・ポリシーはこれらのデータベース・オブジェクトに直接付加され、ユーザーがデータにアクセスするたびにポリシーは自動的に適用されるため、セキュリティは回避できません。

ユーザーがOracle Virtual Private Databaseポリシーで保護されている表、ビューまたはシノニムに直接的または間接的にアクセスすると、Oracle DatabaseはユーザーのSQL文を動的に変更します。この変更は、セキュリティ・ポリシーを実装する関数によって戻されたWHERE条件(述語)に基づいて行われます。Oracle仮想プライベート・データベースでは、関数内に記述された条件、または関数が戻す条件を使用して、動的に、またユーザーに対して透過的に文を変更します。Oracle仮想プライベート・データベースのポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に適用できます。

EclipseLink VPDマルチテナントを使用する場合、データベースでは、SELECT、INSERT、UPDATE、INDEXおよびDELETEのすべての問合せでテナント・フィルタリングを行います。

EclipseLink VPDマルチテナントを使用するには、@Multitenantおよび@TenantDiscriminatorColumn注釈を使用して、まずデータベースでVPDを構成し、その後エンティティまたはマップ済のスーパークラスでマルチテナントを指定する必要があります。

VPDマルチテナントの構築の詳細は、Oracle TopLinkのソリューション・ガイドのVPDマルチテナントの使用に関する項を参照してください。

7.9 異機種間バッチ書込みについて

現在のリリースでは、複数の書込みのあるトランザクションを最適化するための永続性ユニット・プロパティが用意されています。eclipselink.jdbc.batch-writingプロパティは、バッチ書込みの使用を構成して、複数の書込みのあるトランザクションを最適化します。バッチ書込みを使用すると、複数の異機種間の動的SQL文を、1つの実行としてデータベースに送信することや、複数の異機種間のパラメータ化されたSQL文を、1つのバッチ実行として実行することができます。バッチ書込みをサポートしていないJDBCドライバやデータベースがあることに注意してください。

eclipselink.jdbc.batch-writing.sizeプロパティは、バッチ書込みに使用するバッチ・サイズを構成します。パラメータ化されたバッチ書込みの場合、この値にはバッチにする文の数を指定します(デフォルト: 100)。動的バッチ書込みの場合、この値はバッチの対象となるSQLバッファのサイズで、デフォルトは32kです。

バッチ書込みによる修正問合せのバッチ処理が可能な場合、eclipselink.jdbc.batch-writing永続性プロパティを問合せヒントとともに使用して構成することができます。一部のデータベースのDDLなど、問合せのタイプによってはバッチ処理ができない場合があります。バッチ書込みを無効にすると、行カウントを戻すこともできます。

7.10 シリアライズ・オブジェクト・ポリシーについて

シリアライズ(またはバイナリ形式)・オブジェクト・ポリシーによって、EclipseLinkは私有の(およびネストされた私有の)エンティティおよび要素コレクションとともに、データベースの追加フィールドにエンティティ・オブジェクト全体を書き出すことができます。シリアライズ・オブジェクト・ポリシーは、データベースからのフェッチを最適化し、データベース読取りを高速化し、CPUおよびネットワーク・アクセスの中間層を削減します。

シリアライズ・オブジェクト・ポリシーは、読取り専用またはほぼ読取り専用のアプリケーションに最適で、すべての依存エンティティおよび要素コレクションをロードするエンティティにのみ使用します。シリアライズ・オブジェクト・ポリシーを使用する場合、データベース書込み操作(挿入および更新)の速度は遅くなり、私有データを含まないオブジェクトに対する問合せの速度も遅くなります。

シリアライズ・オブジェクト・ポリシーは、エンティティまたはマップされたスーパークラスで@SerializedObject注釈を使用するか、SerializedObjectPolicyインタフェースの実装を渡すことにより有効化されます。このインタフェースの実装を提供する必要があります。デフォルトの実装はありません。注釈には、データベースのオブジェクトに対する列名を定義するフィールドも含まれます。

シリアライズ・オブジェクト・ポリシーが有効な場合、読取り問合せ(検索、リフレッシュなど)は、自動的にシリアライズ・オブジェクトを使用します。シリアライズ・オブジェクトにNULLまたは廃止されたバージョンのオブジェクトが含まれる場合、シリアライズ・オブジェクト・ポリシーを使用している問合せは例外をスローするか、他のフィールドすべてが同様に読み込まれている場合は、これらのフィールドを使用してオブジェクトを構築します(シリアライズ・オブジェクト・ポリシーが使用されていない場合も同様)。

シリアライズ・オブジェクト・ポリシーの詳細は、Oracle TopLinkのソリューション・ガイドのシリアライズ・オブジェクト・ポリシーに関する項を参照してください。@SerializedObject注釈の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@SerializedObjectに関する項を参照してください。

7.11 自動チューニングについて

自動チューニングは、特定の目的に対するJPAおよびセッション構成をアプリケーションが自動的にチューニングできるようにする最適化です。複数の構成オプションを単一のチューナで構成し、アプリケーション・デプロイメントの前後で、またセッションへの接続前にアプリケーションのメタデータが処理された後で、異なる構成を指定できます。自動チューニングにより、構成が簡単になり、動的な単一チューニング・オプションが使用可能になります。

SessionTunerインタフェースにより、テンプレートのチューニング構成が容易になります。これにより、アプリケーションを本番および開発用に、または様々なデプロイメント構成に対して簡単に調整できます。

デプロイメントの間、チューナはコールバックを受信してJPA構成をチューニングします。tunePreDeployメソッドを使用して、永続性ユニット・プロパティをチューニングでき、tuneDeployメソッドを使用して、セッションに接続する前にSessionをチューニングでき、tunePostDeployメソッドを使用して、Sessionオブジェクトが初期化され、データベースに接続された後にチューニングできます。

チューナを構成するために、eclipselink.tuning persistenceプロパティが追加されています。SafeModeTunerはデバッグ用のチューニングのために用意されており、またデフォルトのStandardTunerも用意されています。

Oracle TopLinkのソリューション・ガイドの自動チューニングに関する項を参照してください。

7.12 TopLink Data Servicesのライブ・データについて

TopLink Data Services (TLDS)では、エンタープライズJava Persistenceへのアクセスを提供するリッチなRESTインタフェースを公開することにより、モダンHTML5, JavaScript、およびモバイル・クライアント・アプリケーションにおけるデータ・アクセスを容易にします。TLDSにより、サーバー側キャッシング、検証およびセキュリティを使用して、拡張可能な永続性を持つデータ・ストア、リレーショナルまたはNoSQLを公開できます。TLDSの目標は、既存のエンタープライズJava顧客向けにOracle Middlewareを使用したThin Server Architecture (TSA)クライアントの開発を可能にし、クライアント・アプリケーションを主に扱う開発者の新規市場を誘致することです。

TLDSの主なメリットは、次のとおりです。

- クライアント開発者は、サーバー側コンポーネントをコーディングする必要なしにサービスを定義およびカスタマイズでき、また、既存のJava EEアプリケーション・コンポーネントを修正せずに使用できます。

- 永続性エンティティ・モデルは、カスタマイズ可能なJSONおよびXMLに対する暗黙的バインディングを備えた、使いやすいRESTインタフェースを使用して、自動的に公開されます。

- 非同期の「ライブ・データ」通知を使用する対話式アプリケーションを開発できます。

- RESTをサポートしているクライアント・テクノロジーを使用してアプリケーションを開発できます。このサービスとクライアントの間には結合はありません。

7.12.1 通知配信のためのServer Sent EventおよびWebSocketのサポート

Server Sent Events (SSE)は、HTTPを使用してComet形式でサーバーからクライアントにデータ(イベント)を送信するための、単一二重プロトコルです。

8 キャッシュの理解

この章では、キャッシュについて紹介および説明します。EclipseLinkキャッシュは、クラスと主キーの値に基づいて最近読み取られたり書き込まれたオブジェクトが格納される、インメモリー・リポジトリです。キャッシュによって、最近読み取られたり書き込まれたオブジェクトを保持してメモリー内でアクセスすることで、データベース・アクセスを最小限に抑え、ロック・レベルと分離レベルを制御し、オブジェクト・アイデンティティを管理してパフォーマンスを向上できます。

EclipseLinkにより定義されているエンティティ・キャッシュ注釈は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のキャッシュ注釈に関する項に記載されています。

EclipseLinkには、EclipseLinkキャッシュを構成するために指定できる多くの永続性ユニット・プロパティも用意されています。これらのプロパティによって、注釈を補完したり、注釈のかわりを提供できます。これらのプロパティのリストについては、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のキャッシュに関する項を参照してください。

この章の内容は次のとおりです。

- キャッシュ・アーキテクチャについて

- キャッシュのタイプとサイズについて

- 問合せおよびキャッシュについて

- 失効したデータの処理について

- 明示的な問合せのリフレッシュについて

- キャッシュ索引について

- データベース・イベント通知およびOracle CQN

- 問合せ結果キャッシュについて

- キャッシュ・コーディネーションについて

- クラスタリングおよびキャッシュ・コーディネーション

- クラスタリングおよびキャッシュの一貫性

- キャッシュ・インターセプタ

- Coherenceキャッシュの使用

8.1 キャッシュ・アーキテクチャについて

EclipseLinkは、2つのタイプのキャッシュを使用します(共有型の永続性ユニット・キャッシュ(L2)は、データ・ソースから取得されたオブジェクトまたはそれに書き込まれたオブジェクトを保持し、独立型の永続性コンテキスト・キャッシュ(L1)は、トランザクションに参加中のオブジェクトを保持します)。永続性コンテキスト(エンティティ・マネージャ)が正常にデータ・ソースにコミットされると、EclipseLinkではそれに応じて永続性ユニット・キャッシュが更新されます。概念的には、永続性コンテキスト・キャッシュはEntityManagerによって表され、永続性ユニット・キャッシュはEntityManagerFactoryによって表されます。

内部的に、EclipseLinkは、永続性ユニット・キャッシュをEclipseLinkセッションに、永続性コンテキスト・キャッシュをEclipseLink永続性ユニットに格納します。図8-1に示すとおり、永続性ユニット(セッション)と永続性コンテキスト(作業ユニット)は、データ・ソース接続と連携して、EclipseLinkアプリケーションのオブジェクトを管理します。

データベースからの読取りリクエストは、EclipseLinkセッションの永続性ユニット(セッション)・キャッシュに送信されます。データベースからの書込みリクエストは、EclipseLinkの永続性コンテキスト(作業ユニット)・キャッシュに送信されます。永続性(セッション)・キャッシュにより、オブジェクトが永続性コンテキストに登録されます。コミットまたはマージ・トランザクション中に、永続性コンテキスト・キャッシュにより永続性ユニット・キャッシュがリフレッシュされます。オブジェクトのライフ・サイクルは、これらのメカニズムに依存しています。

図8-1 オブジェクトのライフ・サイクルとEclipseLinkのキャッシュ

「図8-1 オブジェクトのライフ・サイクルとEclipseLinkのキャッシュ」の説明

8.1.1 永続性ユニット・キャッシュ

永続性ユニット・キャッシュは、特定の永続性ユニットに接続されたクライアントにサービスを提供する共有キャッシュ(L2)です。EntityManagerオブジェクトを使用してデータ・ソースを対象にブジェクトの読取りまたは書込みを行うと、EclipseLinkは、オブジェクトのコピーを永続性ユニットのキャッシュに保存し、同じ永続性ユニットにアクセスする他のすべてのプロセスがそれらにアクセスできるようにします。

EclipseLinkは、次から永続性ユニット・キャッシュにオブジェクトを追加します。

- データ・ストア: EclipseLinkが読取り操作を実行した場合

- 永続性コンテキスト・キャッシュ: 永続性コンテキストが正常にトランザクションをコミットした場合

EclipseLinkでは、独立、共有、保護という3つのキャッシュ分離レベルが定義されています。これらのレベルの詳細は、8.1.3項「共有、独立、保護、弱参照および読取り専用キャッシュ」を参照してください。

一意の永続性ユニット名ごとに、個別の永続性ユニット・キャッシュがあります。このキャッシュは概念的にはEntityManagerFactoryを使用して格納されますが、同じ永続性ユニット名を持つ2つのファクトリは、同じキャッシュを共有し、効果的に同じ永続性ユニット・インスタンスになります。同じ永続性ユニットがJava EEの2つの個別のアプリケーションにデプロイされても、それらの永続性ユニットの完全名は、通常、一意のままであるため、個別のキャッシュが使用されます。データ・ソース、データベースURL、ユーザー、テナントIDなどの特定の永続性ユニット・プロパティは、永続性ユニットの一意名に影響を与えることがあり、結果として個別の永続性ユニット・インスタンスと個別のキャッシュが使用されます。eclipselink.session.name永続性ユニット・プロパティを使用して、2つの永続性ユニットを強制的に同じインスタンスに解決し、キャッシュを共有できます。

8.1.2 永続性コンテキスト・キャッシュ

永続性コンテキスト・キャッシュは、EntityManager内で操作を提供する独立キャッシュ(L1)です。これは、永続性ユニット・キャッシュのオブジェクトを管理して分離し、永続性コンテキストがデータ・ソースに変更をコミットした後に、変更済または新規のオブジェクトを永続性ユニット・キャッシュに書き込みます。

注意:
コミット済の変更のみが共有永続性ユニット・キャッシュにマージされ、フラッシュなどの操作は、トランザクションがコミットされるまで永続性ユニット・キャッシュに影響しません。

永続性コンテキスト・キャッシュのライフ・サイクルは、アプリケーション管理とコンテナ管理の永続性コンテキスト間で異なります。永続性コンテキスト(作業ユニット)・キャッシュは、永続性ユニット内の操作にサービスを提供します。これは、永続性コンテキスト(セッション)・キャッシュのオブジェクトを管理して分離し、永続性ユニットがデータ・ソースに変更をコミットした後に、変更済または新規のオブジェクトを永続性コンテキスト・キャッシュに書き込みます。

8.1.2.1 アプリケーション管理の永続性コンテキスト

アプリケーション管理の永続性コンテキストは、EntityManagerFactoryからのアプリケーションによって作成されます。アプリケーション管理の永続性コンテキストのキャッシュは、EntityManagerがクローズされるか、clear()がコールされるまで変更されません。この場合、アプリケーション管理の永続性ユニットの存続期間を短く維持するか、clear()を使用して永続性コンテキスト・キャッシュが大きくなりすぎないように、または永続性ユニット・キャッシュおよびデータベースとの同期を失わないようにすることが重要です。通常、トランザクションまたはリクエストごとに個別のEntityManagerを作成する必要があります。

拡張永続性コンテキストは、それがコンテナによって管理されていても、アプリケーション管理の永続性コンテキストと同じキャッシュ動作になります。

EclipseLinkでは、存続期間の長い永続性コンテキスト(2層アプリケーションなど)用にWEAK参照モード・オプションもサポートされます。8.1.3.4項「弱参照モード」を参照してください。

8.1.2.2 コンテナ管理の永続性コンテキスト

コンテナ管理の永続性コンテキストは、通常、SessionBeanか、Java EEコンテナまたはフレームワーク(Springなど)によって管理される他のオブジェクトにインジェクションされます。コンテナ管理の永続性コンテキストのキャッシュは、トランザクションの継続期間中のみ維持されます。トランザクションで読み取られたエンティティは、トランザクションの完了後にデタッチされ、後続のトランザクションでマージまたは編集する必要があります。

注意:
EclipseLinkでは、永続性コンテキストがクローズされた後に、エンティティのLAZYリレーションシップにアクセスすることが可能です。

8.1.3 共有、独立、保護、弱参照および読取り専用キャッシュ

EclipseLinkでは、3つのキャッシュ分離レベルが定義されています。キャッシュ分離レベルでは、永続性ユニットおよび永続性コンテキストによってエンティティのキャッシュを実行する方法が定義されます。キャッシュ分離レベルは@Cache注釈のisolation属性で設定できます。分離属性に使用できる値は次のとおりです。

- isolated: エンティティは、永続性ユニットではなく、永続性コンテキストにのみキャッシュされます。8.1.3.1項「独立キャッシュ」を参照してください。

- shared: エンティティは、永続性コンテキストと永続性ユニットの両方にキャッシュされ、読取り専用エンティティは共有されて永続性ユニットにのみキャッシュされます。8.1.3.2項「共有キャッシュ」を参照してください。

- protected: エンティティは、永続性コンテキストと永続性ユニットの両方にキャッシュされ、読取り専用エンティティは分離されて永続性ユニットおよび永続性コンテキストにキャッシュされます。8.1.3.3項「保護キャッシュ」を参照してください。

8.1.3.1 独立キャッシュ

独立キャッシュ(L1)は、永続性コンテキストに格納されるキャッシュです。これは、トランザクションまたはユーザー・セッション・ベースのキャッシュです。エンティティでキャッシュ分離をisolatedに設定すると、その共有キャッシュが無効になります。独立キャッシュでは、オブジェクトが永続性コンテキストに読み取られてリフレッシュが使用されない場合を除き、すべての問合せおよび検索操作はデータベースにアクセスします。

独立キャッシュを使用して次の操作を実行できます。

- 共有キャッシュで高揮発性データのキャッシュを回避します。

- シリアライズ可能トランザクションの分離を実現します。

各永続性コンテキストは、初期状態で空の独立キャッシュを所有します。永続性コンテキストの独立キャッシュは、永続性コンテキストがクローズされるか、EntityManager.clear()操作が使用されると破棄されます。

EntityManagerを使用して独立エンティティを読み取ると、EntityManagerによって、データベースから直接エンティティが読み取られ、永続性コンテキストの独立キャッシュに格納されます。読取り専用エンティティを読み取っても、それは独立キャッシュに格納されたままですが、変更追跡は行われません。

永続性コンテキストは、接続プールまたは排他接続を使用してデータベースにアクセスできます。永続性ユニット・プロパティのeclipselink.jdbc.exclusive-connection.modeを使用して、排他接続を使用できます。排他接続を使用すると、ユーザーごとの読取りおよび書込みのセキュリティが強化されます。特定の問合せを構成して、永続性コンテキストの排他接続を使用することもできます。

注意:
EntityManagerに排他接続が含まれる場合、その使用が終了したらEntityManagerをクローズする必要があります。EntityManagerのガベージ・コレクションが行われるときに、ファイナライザに依存して接続を解放することはお薦めしません。管理永続性コンテキストを使用する場合、これをクローズする必要はありません。

8.1.3.2 共有キャッシュ

共有キャッシュ(L2)は、永続性ユニットに格納されるキャッシュです。これは、永続性ユニット全体に対応する共有オブジェクト・キャッシュです。エンティティでキャッシュ分離をsharedに設定すると、その共有キャッシュが有効になります。共有キャッシュでは、リフレッシュが使用される場合を除き、問合せおよび検索操作は共有キャッシュに対して解決されます。

共有キャッシュを使用して次の操作を実行できます。

- IDまたは索引でエンティティを検索または問い合せるときに、データベース・アクセスを回避することでパフォーマンスを向上します。

- エンティティのリレーションシップにアクセスするときに、データベース・アクセスを回避することでパフォーマンスを向上します。

- 読取り専用エンティティの永続性コンテキスト全体でオブジェクト・アイデンティティを維持します。

EntityManagerを使用して共有エンティティを検索すると、最初にEntityManagerによって永続性ユニットの共有キャッシュが確認されます。エンティティは、永続性ユニットの共有キャッシュに存在しない場合、データベースから読み取られて永続性ユニットの共有キャッシュに格納され、コピーも永続性コンテキストの独立キャッシュに格納されます。IDや索引付き属性を基準としない問合せは、すべて最初にデータベースにアクセスします。問合せの各結果行について、オブジェクトがすでに共有キャッシュに存在する場合、共有オブジェクト(とそのリレーションシップ)が使用され、それ以外の場合、新しいオブジェクトが行から作成されて共有キャッシュに配置され、コピーが独立キャッシュに配置されます。独立コピーは、読取り専用が使用されないかぎり常に返されます。読取り専用の場合、独立コピーは必要ないため、共有オブジェクトが返されます。

共有キャッシュのサイズおよびメモリー使用量は、エンティティのキャッシュ・タイプにより異なります。@Cache注釈の属性は、キャッシュの無効化およびクリアに使用することもできます。

8.1.3.3 保護キャッシュ

保護キャッシュ・オプションでは、共有オブジェクトで独立オブジェクトを参照できます。エンティティでキャッシュ分離をprotectedに設定すると、その共有キャッシュが有効になります。保護オプションは、共有オプションとほぼ同じですが、保護エンティティは共有とは異なり、独立エンティティに対するリレーションシップを持つことができます。

保護キャッシュを使用して次の操作を実行できます。

- IDまたは索引でエンティティを検索または問い合せるときに、データベース・アクセスを回避することでパフォーマンスを向上します。

- 共有エンティティに対するエンティティのリレーションシップにアクセスするときに、データベース・アクセスを回避することでパフォーマンスを向上します。

- 読取り専用エンティティの永続性コンテキストに対する独立を保証します。

- 独立エンティティに対するリレーションシップを可能にします。

保護エンティティは、共有エンティティと同じライフ・サイクルを持ちます(リレーションシップと読取り専用を除く)。保護エンティティの共有エンティティに対するリレーションシップは、共有キャッシュにキャッシュされますが、独立エンティティに対するリレーションシップは隔離され、共有キャッシュにキャッシュされません。@Noncacheable注釈を使用して、共有エンティティに対するリレーションシップのキャッシュを無効化することもできます。読取り専用の保護エンティティは、常に独立キャッシュにコピーされますが、変更追跡は行われません。

8.1.3.4 弱参照モード

EclipseLinkでは、存続期間の長い永続性コンテキストに対して専用の永続性コンテキスト・キャッシュが提供されます。通常、永続性コンテキストの存続期間は短く維持するのが最適です(リクエストごと、またはトランザクションごとに新しいEntityManagerを作成するなど)。これは、ステートレス・モデルと呼ばれます。これによって、永続性コンテキストが大きくなりすぎ、メモリーやパフォーマンスの問題が発生することを防ぎます。また、永続性コンテキストにキャッシュされたオブジェクトが失効したり、コミット済の状態との同期を失わないようにします。

一部の2層アプリケーションまたはステートフル・モデルでは、存続期間の長い永続性コンテキストが必要です。EclipseLinkでは、これらのタイプのアプリケーションに対して特殊な弱参照モードのオプションが提供されます。弱参照モードでは、永続性コンテキストのオブジェクトに対して弱い参照が維持されます。これによって、アプリケーションによる参照がない場合に、オブジェクトのガベージ・コレクションを行うことができます。これによって、永続性コンテキストが大きくなりすぎることを防ぎ、メモリー使用量を削減してパフォーマンスを向上します。新規、削除済または変更済のオブジェクトは、すべてコミットが発生するまで強い参照を使用して保持されます。

弱参照モードは、eclipselink.persistence-context.reference-mode永続性ユニット・プロパティを通じて構成できます。次のオプションを使用できます。

- HARD: これはデフォルトで、弱参照は使用されません。永続性コンテキストは、クリアまたはクローズされるまで増大します。

- WEAK: 弱参照が使用されます。参照されていない未変更オブジェクトは、ガベージ・コレクションの対象になります。遅延変更追跡を使用しているオブジェクトは、ガベージ・コレクションの対象になりません。

- FORCE_WEAK: 弱参照が使用されます。参照されていない未変更オブジェクトは、ガベージ・コレクションの対象になります。遅延変更追跡を使用している変更済の(ただし参照されていない)オブジェクトも、ガベージ・コレクションの対象になり、すべての変更が失われます。

8.1.3.5 読取り専用エンティティ

エンティティは、@ReadOnly注釈またはread-only XML属性を使用して読取り専用として構成できます。読取り専用エンティティは、変更を追跡されず、更新はすべて無視されます。読取り専用エンティティは、永続化または削除できません。読取り専用エンティティは、変更が禁止されていますが、EclipseLinkでは現在これが強制されません。読取り専用オブジェクトを変更すると、永続性ユニット・キャッシュが破損する可能性があります。

eclipselink.read-only問合せヒントを使用して、読取り専用オブジェクトを返すように問合せを構成することもできます。

読取り専用のsharedエンティティでは、問合せから共有インスタンスが返されます。すべての永続性コンテキストのすべての問合せから、同じエンティティが返されます。共有読取り専用エンティティは、永続性コンテキストにコピーまたは隔離されません。これによって、オブジェクトのコピーおよびオブジェクトの変更追跡のコストを回避することで、パフォーマンスを向上できます。この場合、メモリーが削減され、ヒープ使用量が減少し、パフォーマンスが向上します。オブジェクト・アイデンティティも読取り専用エンティティの永続性ユニット全体で維持され、アプリケーションではこれらの共有オブジェクトに対する参照を保持できます。

読取り専用のisolatedまたはprotectedエンティティは、永続性コンテキストから返された独立コピーを保持しています。これによって、オブジェクトの変更追跡が行われなくなるため、パフォーマンスとメモリー使用量が多少改善しますが、sharedエンティティほどではありません。

8.2 キャッシュのタイプとサイズについて

EclipseLinkには、異なるメモリー要件を持つ複数の異なるキャッシュ・タイプがあります。キャッシュのサイズ(キャッシュされたオブジェクトの数)も構成可能です。使用するキャッシュのタイプおよびサイズは、アプリケーション、失効データの可能性、JVMおよびマシンで使用可能なメモリー量、ガベージ・コレクションのコスト、およびデータベースのデータ量によって異なります。

共有オブジェクト・キャッシュのキャッシュ・タイプおよびサイズは、@Cache注釈のtypeおよびsize属性で構成することができます。また、問合せ結果キャッシュのキャッシュ・タイプは、eclipselink.query-results-cache.type永続性ユニット・プロパティで構成することができます。詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@Cache注釈およびeclipselink.query-results-cache.type永続性ユニット・プロパティに関する説明を参照してください。

デフォルトでは、EclipseLinkは、100個のオブジェクトの初期サイズでSOFT_WEAKを使用します。キャッシュ・サイズは固定されませんが、初期サイズは固定で、EclipseLinkはメモリーのオブジェクトがガベージ・コレクションの対象になるまで、キャッシュからオブジェクトを排除しません。CACHEタイプが使用されるとオブジェクトは排除されますが、これは推奨されません。また、SOFT_WEAKおよびHARD_WEAKのキャッシュ・サイズは、メモリーに保持するオブジェクトの最小数を決定できるソフトまたはハード・サブキャッシュのサイズです。

オブジェクト・アイデンティティをクラス単位でどのように管理するかを構成することができます。ClassDescriptorオブジェクトでは、表8-1で説明するキャッシュおよびアイデンティティ・マップのオプションが使用できます。

表8-1 キャッシュおよびアイデンティティ・マップのオプション

オプション

キャッシング

アイデンティティの保証

メモリー使用量

FULLキャッシュ・タイプ

はい

はい

非常に多い

WEAKキャッシュ・タイプ

はい

はい

少ない

SOFTキャッシュ・タイプ

はい

はい

多い

SOFT_WEAKおよびHARD_WEAKキャッシュ・タイプ

はい

はい

中程度

他にNONEおよびCACHEという2つのオプションがあります。これらのオプションはお薦めしません。

type属性の値はeclipselink.cache.type.<ENTITY>およびeclipselink.cache.type.default永続性ユニット・プロパティでオーバーライドできます。

8.2.1 FULLキャッシュ・タイプ

このオプションでは、完全なキャッシュとアイデンティティの保証を行います。オブジェクトは、実際に削除されるまでメモリーからフラッシュされません。

すべてのオブジェクトがキャッシュされ、キャッシュから削除されることはありません。キャッシュ・サイズは、最大サイズに達すると2倍まで許容されます。この方法を使用すると、多くのオブジェクトが読み取られる場合、メモリーの負荷が高くなることがあります。このオプションはバッチ操作には使用しないでください。

このアイデンティティ・マップは、データ・セットのサイズが小さく、メモリーの容量が大きい場合に使用することをお薦めします。

8.2.2 WEAKキャッシュ・タイプ

このオプションでは、ガベージ・コレクションが行われていないオブジェクトのみがキャッシュされます。アプリケーションによって参照されているオブジェクトは、キャッシュされます。

WEAKキャッシュ・タイプでは、使用するメモリーが完全アイデンティティ・マップより少ないかわりに、クライアント/サーバー・トランザクション全体にわたる永続キャッシュ戦略も使用しません。オブジェクトは、サーバー側(つまり、サーバーJVM内)でアプリケーションによって参照されなくなると、ガベージ・コレクションの対象になります。

8.2.3 SOFTキャッシュ・タイプ

このオプションは、WEAKキャッシュ・タイプとほぼ同じですが、キャッシュで弱参照のかわりにソフト参照を使用するところが異なります。アプリケーションによって参照されているオブジェクトはキャッシュされ、オブジェクトがキャッシュから削除されるのは、メモリーが少ない場合のみです。

ソフト・アイデンティティ・マップではオブジェクトのキャッシュを最適化でき、メモリー残量が少ない場合はJVMでオブジェクトのガベージ・コレクションを行うことも可能です。

8.2.4 SOFT_WEAKおよびHARD_WEAKキャッシュ・タイプ

これらのオプションは、弱いキャッシュとほぼ同じですが、最も使用頻度の高いサブキャッシュが維持されるところが異なります。サブキャッシュでは、ソフトまたはハード参照を使用して、これらのオブジェクトがガベージ・コレクションの対象とならないように、またはメモリー上でJVMが少ない場合にのみガベージ・コレクションの対象となるようにします。

ソフト・キャッシュとハード・キャッシュでは、より効率的にメモリーを使用できます。これらのマップでは、ガベージ・コレクションされたオブジェクトを解放します(最近使用された一定数のオブジェクトは除く)。弱参照でキャッシュされたオブジェクトは、トランザクションが複数のクライアント/サーバー起動にわたって使用される場合、フラッシュされる可能性があることに注意してください。サブキャッシュのサイズは、@Cache size属性で指定されたキャッシュのサイズに比例します。キャッシュ・サイズは、トランザクションで保持するオブジェクトの数に設定する必要があります。

このキャッシュは、キャッシュで使用されるメモリーを制御する手段として、ほとんどの場合に使用をお薦めします。

8.2.5 NONEおよびCACHE

NONEおよびCACHEオプションでは、オブジェクト・アイデンティティが維持されないため、これらは非常に限定的な状況でのみ使用する必要があります。NONEではどのオブジェクトもキャッシュされません。CACHEでは、LRU方式で一定数のオブジェクトのみがキャッシュされます。これらのキャッシュ・タイプは、オブジェクトに対するリレーションシップが存在しない場合にのみ使用する必要があります。これらのオプションの使用はお薦めしません。キャッシュを無効にするには、かわりにキャッシュ分離をISOLATEDに設定してください。

8.2.6 キャッシュおよびアイデンティティ・マップの構成のガイドライン

キャッシュ・タイプの構成時には、次のガイドラインに従ってください。

- 存続期間の長いオブジェクトでは、SOFT、SOFT_WEAKまたはHARD_WEAKキャッシュ・タイプを使用します。どのような場合にどちらを選択するかについては、8.2.6.1項「WEAK、SOFTおよびHARDキャッシュ・タイプの内部について」を参照してください。

- 存続期間の短いオブジェクトでは、WEAKキャッシュ・タイプを使用します。

- インスタンスがほとんど存在しない存続期間の長いオブジェクト(参照データなど)では、FULLキャッシュ・タイプを使用します。

注意:
FULLキャッシュ・タイプは、クラスに少数の限られたインスタンスが存在する場合にのみ使用してください。それ以外の場合に使用すると、メモリー・リークが発生します。

- キャッシュが不要であるか、使用しない場合、キャッシュ分離をISOLATEDに設定して共有キャッシュを無効にします。

注意:
CACHEおよびNONEキャッシュ・タイプの使用はお薦めしません。

8.2.6.1項「WEAK、SOFTおよびHARDキャッシュ・タイプの内部について」を参照してください。

8.2.6.1 WEAK、SOFTおよびHARDキャッシュ・タイプの内部について

WEAKおよびSOFTキャッシュ・タイプでは、JVM弱参照およびソフト参照を使用して、アプリケーションによって参照されるオブジェクトがキャッシュ内に保持されるようにします。アプリケーションでオブジェクト参照を解除すると、JVMでは自由にオブジェクトのガベージ・コレクションを実行します。弱参照またはソフト参照がガベージ・コレクションされる時期は、JVMによって決定されます。一般的に、弱参照は、それぞれのJVMガベージ・コレクション操作でガベージ・コレクションされると想定されます。

SOFT_WEAKおよびHARD_WEAKキャッシュ・タイプには、次の2つのキャッシュが含まれます。

- 参照キャッシュ: それぞれソフトまたはハード参照を含めたLinkedListとして実装されるキャッシュ

- 弱キャッシュ: 弱参照を含めたMapとして実装されるキャッシュ

指定したサイズでSOFT_WEAKまたはHARD_WEAKキャッシュを作成すると、参照キャッシュのLinkedListは正確にそのサイズになります。弱キャッシュのMapのサイズは、その初期サイズと同じです(指定したサイズより多くのオブジェクトが読み取られると、弱キャッシュは増大します)。EclipseLinkはガベージ・コレクションを制御しないため、弱く保持されたオブジェクトは適切なときにJVMが削除します。

参照キャッシュはLinkedListとして実装されるため、リストの最後に新しいオブジェクトが追加されます。そのため、これは本質的に最低使用頻度(LRU)キャッシュです(固定サイズで、最大サイズに到達するとリストの先頭のオブジェクトが削除されます)。

SOFT_WEAKおよびHARD_WEAKは、基本的に同じタイプのキャッシュです。HARD_WEAKは、一部のJVMでの問題を回避するために構成されました。

アプリケーションを実行しているシステムでメモリー不足の状態が頻繁に発生する場合や、プラットフォームのJVMで弱い参照とソフト参照が同様に扱われる場合には、参照キャッシュ内のオブジェクトのガベージ・コレクションが頻繁に行われるため、参照キャッシュによるパフォーマンス向上の利点は得られません。この場合、HARD_WEAKの使用をお薦めします。これはSOFT_WEAKと同じですが、参照キャッシュでハード参照を使用する点が異なります。そうすることで、アプリケーションは参照キャッシュによるパフォーマンス向上の利点を確実に得ることができます。

HARD_WEAKまたはSOFT_WEAK内のオブジェクトは、参照キャッシュから削除されると、弱キャッシュに格納されます。このオブジェクトは引き続きキャッシュされていますが、JVMは弱参照をガベージ・コレクションすることを随時決定できるため、どれくらいの間キャッシュに保持されるかはEclipseLinkでは保証できません。

8.3 問合せおよびキャッシュについて

共有永続性ユニット(セッション)・キャッシュに対して実行される問合せは、インメモリー問合せと呼ばれます。インメモリー問合せを慎重に構成することで、パフォーマンスを向上できます。

デフォルトでは、主キーに基づいてシングル・オブジェクトを検索する問合せは、必要なオブジェクトをまずキャッシュから取得し、オブジェクトがキャッシュに存在しない場合にのみ、データ・ソースで検索を行います。その他すべての問合せタイプの場合は、デフォルトでデータベースを最初に検索します。特定の問合せを、インメモリー・キャッシュ、データベース、その両方のうち、いずれに対して実行するかを指定できます。

8.3.1 問合せキャッシュ・オプションおよびインメモリー問合せについて

JPAは、問合せの共有永続性ユニット・キャッシュ(L2)との対話方法を構成するため、基本的な問合せヒントを定義しています。EclipseLinkでは、キャッシュの使用を構成するための、追加の問合せヒントも用意されています。JPAおよびEclipseLinkの問合せヒントの詳細は、9.6項「問合せヒントについて」を参照してください。

エンティティにはfind()メソッドまたは問合せのいずれかを使用して、JPAを通じてアクセスできます。The find()メソッドは、最初にIdに対する永続性コンテキスト・キャッシュ(L1)をチェックし、オブジェクトが見つからない場合は共有コンテキスト・ユニット・キャッシュ(L2)をチェックし、それでもオブジェクトが見つからない場合はデータベースにアクセスします。デフォルトでは、IDまたはキャッシュの索引付けされたフィールドを使用する場合を除き、すべての問合せでデータベースにアクセスします。問合せがデータベースから行を取得すると、各行をキャッシュにより解決します。オブジェクトがキャッシュ内に存在する場合は、行は廃棄され、オブジェクトが使用されます。オブジェクトが共有キャッシュ内に存在しない場合は、オブジェクトは行から構築され、共有キャッシュに格納されます。コピーも永続性コンテキストのキャッシュに格納され、問合せ結果として戻されます。

これが一般的なプロセスですが、トランザクションが使用済の場合は異なります。トランザクションが使用済の場合、共有の永続性ユニット・キャッシュは無視され、オブジェクトは永続性コンテキスト・キャッシュに直接格納されます。

次の状況では、トランザクションは使用済とみなされます。

- flush()がデータベースに変更を書き込んだ場合。

- ペシミスティック・ロック問合せが実行された場合。

- 更新または削除問合せが実行された場合。

- ネイティブSQL問合せが実行された場合。

- この永続性ユニット・プロパティeclipselink.transaction.join-existingが使用されます。

- JDBC接続がEntityManagerからアンラップされた場合。

- UnitOfWork API beginEarlyTransactionが呼び出された場合。

エンティティを構成して独立させたり、キャッシュ不能とすることもでき、このような場合は決して共有キャッシュに格納されません(「共有、独立、保護、弱参照および読取り専用キャッシュ」を参照してください)。

8.4 失効したデータの処理について

失効したデータは、データ・ソースにコミットされた最新バージョンでないオブジェクトをキャッシュした結果として発生します。失効したデータの発生を防止するには、適切なキャッシュ・ロック戦略を実装します。

EclipseLinkでは、デフォルトで、読取りまたは書込み操作中のキャッシュ・ロックを最小限に抑えるために同時実行性が最適化されます。非常に明確な理由があって変更する場合を除き、EclipseLinkの分離レベルはデフォルトのまま使用してください。EclipseLinkでの分離レベルの詳細は、8.1.3項「共有、独立、保護、弱参照および読取り専用キャッシュ」を参照してください。

キャッシュ・ロックにより、プロセスがオブジェクトを読み取る、または書き込むタイミングを制御します。キャッシュ・ロックの構成に応じて、別のプロセス内で使用されているオブジェクトの読取りまたは書込みが可能かどうかが決まります。

キャッシュを適切に管理すると、アプリケーションの効率が高まります。キャッシュはデータベース・アクセスを減少させ、オブジェクト・アイデンティティの管理の重要な部分を占めるため、キャッシュを完全にオフにすることはほとんどありません。

キャッシュ戦略を最大限に活用し、失効したデータがアプリケーションに使用されることを最小限に抑えるために、次のことをお薦めします。

- ロック・ポリシーの構成

- クラス単位でのキャッシュの構成

- 必要時の問合せ単位でのキャッシュ・リフレッシュの強制

- キャッシュの無効化の構成

- キャッシュ・コーディネーションの構成

8.4.1 ロック・ポリシーの構成

ロック・ポリシーを構成しておくことで、変更中のオブジェクトの値が変更されるのを防止するか、または少なくとも変更された時間を識別することができます。これは通常、オプティミスティック・ロックを使用して行います。EclipseLinkでは、数値バージョン・フィールド、タイムスタンプ・バージョン・フィールド、一部のフィールド、すべてのフィールドなど、複数のロック・ポリシーでロックできます。オプティミスティック・ロックとペシミスティック・ロックについては、次の項で説明します。

8.4.1.1 オプティミスティック・ロック

EclipseLinkオプティミスティック・ロックの使用をお薦めします。オプティミスティック・ロックを使用した場合、すべてのユーザーにデータへの読取りアクセス権限があります。ユーザーが変更を書き込もうとすると、アプリケーションにより、ユーザーがデータを読み取ってから、そのデータが変更されていないかが確認されます。@OptimisticLockingを使用して、エンティティを更新または削除する際にEclipseLinkが使用するオプティミスティック・ロックのタイプを指定します。

バージョン・ロック・ポリシーまたはフィールド・ロック・ポリシーを使用できます。バージョン・ロック・ポリシーの使用をお薦めします。標準のJPA @Versionの注釈は、単一値の値およびタイムスタンプ・ベースのロックで使用されます。ただし、高度なロッキング機能には、@OptimisticLocking注釈を使用します。@OptimisticLocking注釈には、エンティティを更新または削除する際に使用するオプティミスティック・ロックのタイプを指定します。オプティミスティック・ロックは、@Entityまたは@MappedSuperclass注釈でサポートされています。

OptimisticLocking注釈および使用可能なロックのタイプの詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@OptimisticLockingに関する項を参照してください。

詳細は、5.2.4.1項「オプティミスティック・バージョン・ロック・ポリシー」および5.2.4.1.3項「オプティミスティック・フィールド・ロック・ポリシー」を参照してください。

8.4.1.2 ペシミスティック・ロック

ペシミスティック・ロックを使用した場合は、データを更新する目的でそのデータにアクセスする最初のユーザーが、更新を完了するまでデータをロックします。このアプローチの短所は、並行性が損われること、デッドロックになる可能性があることです。eclipselink.pessimistic-lockプロパティを使用して、TopLinkでペシミスティック・ロックを使用するかどうかを指定します。詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のeclipselink.pessimistic-lockに関する項を参照してください。

問合せレベルでペシミスティック・ロックのサポートを使用することを検討してください。5.2.4.2項「ペシミスティック・ロック・ポリシー」を参照してください。

8.4.2 クラス単位でのキャッシュの構成

特定のクラスで使用するデータを他のアプリケーションが変更できる場合、そのクラスには弱いスタイルのキャッシュを使用します。たとえば、@Cache typeの属性値WEAKおよびSOFT_WEAKを指定すると、参照対象として削除されたオブジェクトをキャッシュが保持する期間は最も短くなります。キャッシュ・タイプの詳細は、8.2項「キャッシュのタイプとサイズについて」を参照してください。

8.4.3 必要時の問合せ単位でのキャッシュ・リフレッシュの強制

すべての問合せには、選択したオブジェクトの最新バージョンをデータ・ソースで検索し、その情報でキャッシュを更新することをEclipseLinkに強制するフラグを含めることができます。詳細は、8.5項「明示的な問合せのリフレッシュについて」を参照してください。Oracle TopLinkのソリューション・ガイドのキャッシュのリフレッシュに関する項も参照してください。

8.4.4 キャッシュの無効化の構成

expiryを使用すると、エンティティ・インスタンスをキャッシュで失効させるまでのミリ秒数や、エンティティ・クラスのすべてのインスタンスをキャッシュで失効させる時刻を指定してエンティティを構成できます。有効期限は、@Cache注釈または<cache XML要素で設定し、expiryまたはexpiryTimOfDay属性で構成できます。詳細は、Oracle TopLinkのソリューション・ガイドのエンティティ・キャッシュの有効期限の設定に関する項を参照してください。

8.4.5 キャッシュ・コーディネーションの構成

アプリケーションが読取り中心で、変更がすべて、複数の分散セッションで実行されている同一Javaアプリケーションによって行われる場合は、EclipseLinkのキャッシュ・コーディネーション機能の使用が有効なことがあります。これは、データの失効は防止しませんが、できるかぎり最小限に抑えます。詳細は、8.9項「キャッシュ・コーディネーションについて」および8.10項「クラスタリングおよびキャッシュ・コーディネーション」を参照してください。

8.5 明示的な問合せのリフレッシュについて

分散システムの中には、システム内のサーバー全体で少数のオブジェクトのみが一貫していればよいものがあります。逆に、いくつかの特定のオブジェクトが、負荷に関係なく、常に最新の状態であることを求めるシステムもあります。そのようなシステムを構築する場合は、分散キャッシュ・コーディネーションを行うほどの負荷をかけずに、データベースから選択したオブジェクトを適切な間隔で明示的にリフレッシュすることができます。

このタイプの戦略を実装するには、次の手順を実行します。

1. 必要なオブジェクトをリフレッシュする一連の問合せを構成します。

2. 適切なリフレッシュ・ポリシーを設定します。

3. 必要に応じて問合せを起動し、オブジェクトをリフレッシュします。

@Cache注釈には、データベースに対するすべての問合せで強制的にキャッシュをリフレッシュさせるalwaysRefresh属性とrefreshOnlyIfNewer属性が用意されています。キャッシュは、データベース内のオプティミスティック・ロック値がキャッシュ内のものよりも実際に新しい場合にのみリフレッシュされます。詳細は、Oracle TopLinkのソリューション・ガイドのキャッシュのリフレッシュに関する項を参照してください。

問合せを実行すると、必要なオブジェクトがキャッシュ内に存在する場合、EclipseLinkは、より新しいバージョンがないかどうかデータベースをチェックすることなく、キャッシュされたオブジェクトを返します。これにより、EclipseLinkがデータベースの結果から作成する必要のあるオブジェクトの数が減るため、この方法はコーディネートされていないキャッシュ環境に最適です。ただし、コーディネートされたキャッシュ環境では必ずしも最善の戦略ではありません。

この動作をオーバーライドするには、alwaysRefresh属性を設定し、データベースのオブジェクトがキャッシュ内のオブジェクトよりも常に優先されるよう指定します。この場合、キャッシュされたオブジェクトがデータベースのデータで更新されます。

このタイプのリフレッシュ・ポリシーは、アプリケーションの特性に応じて、EclipseLinkの各エンティティに実装することも、特定の問合せのみに実装することもできます。

8.6 キャッシュ索引について

EclipseLinkキャッシュは、エンティティのIDで索引付けされます。これによって、ID別のfind()操作、リレーションシップおよび問合せが可能になり、キャッシュ・ヒットを取得してデータベース・アクセスを回避できます。キャッシュは、非ID問合せではデフォルトで使用されません。すべての非ID問合せは、データベースにアクセスし、結果セットで返される行ごとにキャッシュによって解決されます。

アプリケーションは、そのID以外に他の一意キーを各モデルに持つことが多くあります。生成されたIDが使用される場合、これはごく普通です。アプリケーションは、頻繁にこれらの一意キーに基づいて問合せを行うため、これらの問合せ時のデータベース・アクセスを回避するため、キャッシュ・ヒットを取得できる方が便利です。

キャッシュ索引では、EclipseLinkキャッシュ内にインメモリー索引を作成することで、非IDフィールドでキャッシュ・ヒットが可能になります。キャッシュ索引は、単一のフィールドまたはフィールドのセットに配置できます。索引付けされたフィールドは、更新可能です(通常は一意となりますが、これは要件ではありません)。索引付けされたフィールドを含む問合せでは、キャッシュ・ヒットを取得できます。索引付けされた問合せから取得できるのは、単一の結果のみです。

キャッシュ索引は、@CacheIndexおよび@CacheIndexes注釈と、<cache-index> XML要素を使用して構成できます。@CacheIndexは、エンティティに定義するか、属性に定義して属性に索引付けすることができます。エンティティに定義する索引では、索引に使用するcolumnNamesを定義する必要があります。索引は、オブジェクトが更新可能な属性を使用して更新されたときに、再度索引付けするように構成できます。

問合せ結果キャッシュを使用して、索引付けされていない問合せの問合せ結果をキャッシュすることも可能です。詳細は、8.8項「問合せ結果キャッシュについて」を参照してください。

8.7 データベース・イベント通知およびOracle CQN

一部のデータベースおよびデータベース製品では、行が更新または削除された場合、データベースからイベントを発生させることができます。

データベースがデータベースの変更をEclipseLinkに通知できるように、EclipseLinkはAPIをサポートしているため、変更されたオブジェクトはEclipseLinkの共有キャッシュで無効化できます。これにより、他のアプリケーションがデータベース内の同じデータにアクセスする場合でも、共有キャッシュが使用され、失効したデータは回避されます。EclipseLinkは、Database Change Notification CQNに対するOracle Databaseの機能との統合をサポートしています。データベース・イベントをサポートする他のデータベースおよび製品に対して、カスタムのDatabaseEventListenerが提供される場合もあります。

共有環境でのキャッシュについては、次のように他の解決策があります。

- 共有キャッシュを無効化します(@Cacheable(false)または@Cache(isolation=ISOLATED)の設定を使用)。

- 読取り専用オブジェクトのみをキャッシュします。

- 失効したデータを減らすためにキャッシュ無効化タイムアウトを設定します。

- フレッシュ・データが必要な場合にオブジェクトまたは問合せに対してリフレッシュを使用します。

- 書込み整合性を保証するためにオプティミスティック・ロックを使用します(失効したデータに対する書込みは失敗し、キャッシュは自動的に無効化されます)。

JPA Cache APIおよびEclipseLinkのJpaCache APIを直接使用して、共有キャッシュ内のオブジェクトをアプリケーションによって無効化することもできます。EclipseLinkのキャッシュ・コーディネーションは、EclipseLinkの永続化ユニットのクラスタへの無効化メッセージの送信に使用することもできます。

データベース・イベントは、アプリケーションが失効データを取得する可能性を低減できますが、その可能性が排除されることはありません。オプティミスティック・ロックは、引き続きデータの整合性を保証するために使用する必要があります。単一のサーバー・アプリケーションでも、ペシミスティック・ロックが使用される場合を除き、失効データは永続性コンテキスト内で発生する可能性があります。オプティミスティック(またはペシミスティック)・ロックは、任意のマルチユーザー・システムでデータの整合性を保証するために常に必要です。

8.7.1 Oracle連続問合せ通知

Oracle Databaseの10.2リリースでは、連続問合せ通知(CQN)機能がリリースされました。CQNでは、表の列が変更された場合、データベース・イベントを発生させることができます。CQN用のJDBC APIは11.2まで完成しないため、EclipseLinkの統合には11.2が必要です。

EclipseLink CQNのサポートは、Oracle JDBCを受信したデータベース変更イベントと統合するOracleChangeNotificationListenerリスナーによって有効化されます。eclipselink.cache.database-event-listenerプロパティを使用して、リスナーの完全クラス名を構成します。

デフォルトでは、永続性ユニットのすべての表が変更通知のために登録されますが、@Cache注釈のdatabaseChangeNotificationType属性を使用して、変更通知を特定のクラスに対して選択的に無効にするよう構成できます。

Oracle CQNはROWIDを使用し、列レベルの変更を通知します。このためEclipseLinkでは、CQNが有効なクラスのすべての問合せにROWIDを含める必要があります。挿入操作の後、EclipseLinkでは、オブジェクトのROWIDも選択する必要があります。EclipseLinkでは、オブジェクトのIdのみでなく、ROWIDのキャッシュ索引も維持します。EclipseLinkは、トランザクションを処理しているサーバーでキャッシュが無効にされないよう、トランザクションごとに1回データベースのトランザクションIdも選択します。

EclipseLinkのCQN統合には次の制限があります。

- プライマリ表でバージョンが使用され更新されないかぎり、セカンダリ表のオブジェクトが変更されてもその無効化はトリガーされません。

- プライマリ表でバージョンが使用され更新されないかぎり、オブジェクトのOneToMany、ManyToManyおよびElementCollectionのリレーションシップが変更されてもその無効化はトリガーされません。

8.8 問合せ結果キャッシュについて

EclipseLinkの問合せ結果キャッシュでは、オブジェクトがキャッシュされる場合と同じように、名前付き問合せの結果をキャッシュできます。

EclipseLinkのデフォルトでは、IDまたはキャッシュの索引付けされたフィールドを使用する場合を除き、すべての問合せでデータベースにアクセスします。結果の行はキャッシュで解決され、オブジェクトがキャッシュされている場合、リレーションシップに対する追加の問合せは回避されますが、元の問合せは常にデータベースにアクセスします。EclipseLinkには、キャッシュを問い合せるオプションがありますが、EclipseLinkではデータベースのすべてのオブジェクトがキャッシュ内に存在するとは想定されないため、これらのオプションはデフォルトでは使用されません。問合せ結果キャッシュでは、索引付けされていない結果リスト問合せでもキャッシュから利点を得ることができます。

問合せ結果キャッシュは、問合せの名前と問合せのパラメータで索引付けされます。結果をキャッシュできるのは名前付き問合せのみで、動的問合せでは問合せ結果キャッシュを使用できません。同様に、ヒントやプロパティを設定するなど、実行前に名前付き問合せを変更すると、キャッシュされた結果を使用できません。

問合せ結果キャッシュでは、オブジェクト・キャッシュのように、アプリケーションからコミット済の変更が選択されません。これは、読取り専用オブジェクトをキャッシュする場合にのみ使用する必要があります(または、失効した結果のキャッシュを回避するために無効化ポリシーを使用する必要があります)。結果セットのオブジェクトに対するコミット済の変更は、選択されますが、結果セットに影響する変更(結果セットから追加または削除する必要のある新規または変更済オブジェクトなど)は選択されません。

問合せ結果キャッシュでは、固定サイズ、キャッシュ・タイプおよび無効化オプションがサポートされます。

8.9 キャッシュ・コーディネーションについて

すべてのアプリケーションのデータを最新の状態に維持する必要性は、分散アプリケーションを構築する際の設計上の大きな課題です。環境内のサーバー数が増加するにつれて、この課題の難しさも増していきます。EclipseLinkには、分散アプリケーションのデータを最新の状態に維持する、分散キャッシュ・コーディネーション機能が用意されています。

キャッシュ・コーディネーションにより、分散アーキテクチャで発生するオプティミスティック・ロック例外の数は減少し、アプリケーションで失敗するトランザクションや繰り返されるトランザクションの数も減少します。とはいえ、キャッシュ・コーディネーションを行っても、効果的なロック・ポリシーが不要になることはありません。最新データが効率的に使用できるように、キャッシュ・コーディネーションはオプティミスティックまたはペシミスティック・ロックとともに使用する必要があります。キャッシュ・コーディネーションは、オプティミスティック・ロック・ポリシーとともに使用することをお薦めします。

EclipseLinkキャッシュをクラスごとにチューニングすると、分散キャッシュ・コーディネーションが不要になります。この設定のチューニングは、キャッシュ・コーディネーションを実装する前に必ず行ってください。詳細は、Oracle TopLinkのソリューション・ガイドのTopLink対応アプリケーションのモニタリングおよび最適化に関する項を参照してください。

キャッシュの無効化を使用すると、キャッシュ・コーディネーションが高速になります。詳細は、Oracle TopLinkのソリューション・ガイドのエンティティ・キャッシュの有効期限の設定に関する項を参照してください。

図8-2に示すように、キャッシュ・コーディネーションは、セッションの複数のインスタンス(大部分の場合、分散されている)が相互にオブジェクト変更をブロードキャストできるようにするセッション機能であり、これにより、各セッションのキャッシュは、最新の状態に保たれるか、次回読み取るデータ・ソースを基にオブジェクトを更新する必要があることを通知されます。

注意:
独立クライアント・セッションは、キャッシュ・コーディネーションと組み合せて使用することはできません。詳細は、8.1.3項「共有、独立、保護、弱参照および読取り専用キャッシュ」を参照してください。

図8-2 コーディネートされた永続性ユニット(セッション)・キャッシュ

「図8-2 コーディネートされた永続化ユニット(セッション)・キャッシュ」の説明

セッションが分散されている場合、つまり、アプリケーションに複数のセッションが含まれている場合(同一JVM内、複数JVM内、あるいは複数サーバー上)、セッションをホスティングしているサーバーがネットワーク上で相互接続されているかぎり、セッションはキャッシュ・コーディネーションに参加できます。検出サービスを必要とするタイプのコーディネート・キャッシュでは、サーバーでユーザー・データグラム・プロトコル(UDP)通信およびマルチキャスト構成がサポートされることも必要です。詳細は、8.10.1項「JMSおよびRMIキャッシュのコーディネーション」を参照してください。

8.9.1 キャッシュ・コーディネーションの使用が必要な場合

キャッシュ・コーディネーションにより、パフォーマンスが向上し、次の特性を持つアプリケーションに対して失効データが発生する可能性が低下します。

- 変更はすべて、複数の分散セッションで実行されている同一Javaアプリケーションにより実行されます。

- 読取り中心です。

- 同一オブジェクトを定期的にリクエストおよび更新します。

これらの特性を持たないアプリケーションでは、パフォーマンスを最大化するため、キャッシュ・コーディネーションを使用しないでください。

失効データの発生頻度を削減する他のオプションについては、8.4項「失効したデータの処理について」を参照してください。

8.10 クラスタリングおよびキャッシュ・コーディネーション

アプリケーション・クラスタは、単一のアプリケーションまたはアプリケーション・セットへのリクエストに対応する中間層サーバー・マシンまたはVMのセットです。複数のサーバーを使用して、アプリケーションのスケーラビリティの向上、またはフォルト・トレランスと高可用性の提供(あるいはその両方)を行います。通常は、同じアプリケーションがクラスタ内のすべてのサーバーにデプロイされ、アプリケーション・リクエストはサーバーのセット全体でロード・バランシングされます。アプリケーション・クラスタは、単一のデータベースまたはデータベース・クラスタにアクセスします。アプリケーション・クラスタでは、新しいサーバーを追加してスケーラビリティを向上したり、更新やサービス提供などのためにサーバーを削除できます。

アプリケーション・クラスタは、Java EEサーバー、WebコンテナまたはJavaサーバー・アプリケーションで構成されます。

EclipseLinkは、任意のクラスタ化環境で動作できます。クラスタ化環境での主な問題は、共有永続性ユニット(L2)・キャッシュの使用です。共有キャッシュ(EclipseLinkプロジェクトではデフォルトで有効)を使用している場合、各サーバーは独自のキャッシュを維持し、各キャッシュ・データは他のサーバーおよびデータベースとの同期を失うことがあります。

EclipseLinkでは、サーバー・キャッシュの同期を保証するために、クラスタ化環境でキャッシュ・コーディネーションが提供されます。

クラスタ化環境でのキャッシュについては、次のように他の多くの解決策があります。

- 共有キャッシュを無効化します(@Cacheable(false)または@Cache(isolation=ISOLATED)の設定を使用)。

- キャッシュ読取り専用のオブジェクトのみを使用します。

- 失効したデータを減らすためにキャッシュ無効化タイムアウトを設定します。

- フレッシュ・データが必要な場合にオブジェクトまたは問合せに対してリフレッシュを使用します。

- 書込み整合性を保証するためにオプティミスティック・ロックを使用します(失効したデータに対する書込みは失敗し、キャッシュは自動的に無効化されます)。

- 分散キャッシュを使用します(TopLink GridによるTopLinkとOracle Coherenceの統合など)。

- データベース・イベントを使用して、キャッシュ内の変更データを無効化します(EclipseLinkによるOracle Query Change Notificationのサポートなど)。

キャッシュ・コーディネーションによって、クラスタ内の異なるサーバー(または同じサーバー)にデプロイされた永続性ユニットのセットで変更を同期できます。キャッシュ・コーディネーションは、クラスタ内の各サーバーの永続性ユニットごとに動作し、トランザクション・オブジェクトの変更通知をクラスタ内の他の永続性ユニットにブロードキャストできます。EclipseLinkでは、RMIおよびJMSを介したキャッシュ・コーディネーションがサポートされます。キャッシュ・コーディネーション・フレームワークは、拡張可能なため、他のオプションを開発することもできます。

EclipseLinkでは、デフォルトで、読取りまたは書込み操作中のキャッシュ・ロックを最小限に抑えるために同時実行性が最適化されます。非常に明確な理由があって変更する場合を除き、EclipseLinkのトランザクション分離構成はデフォルトのまま使用してください。

キャッシュ・コーディネーションは、各トランザクションの変更をクラスタ内の他のサーバーにブロードキャストすることで動作します。他のサーバーは、それぞれ変更通知を受信し、キャッシュ内の変更済オブジェクトを無効化するか、キャッシュ済オブジェクトの状態を変更によって更新します。キャッシュ・コーディネーションは、データベースのコミット後に発生するため、コミット済の変更のみがブロードキャストされます。

キャッシュ・コーディネーションは、アプリケーションが失効データを取得する可能性を大幅に低減しますが、その可能性が排除されることはありません。オプティミスティック・ロックは、引き続きデータの整合性を保証するために使用する必要があります。単一のサーバー・アプリケーションでも、ペシミスティック・ロックが使用される場合を除き、失効データは永続性コンテキスト内で発生する可能性があります。オプティミスティック(またはペシミスティック)・ロックは、任意のマルチユーザー・システムでデータの整合性を保証するために常に必要です。

キャッシュの同期化など、キャッシュ・コーディネーションに関する詳細は、Oracle TopLinkのソリューション・ガイドのキャッシュ・コーディネーションの使用に関する項を参照してください。

8.10.1 JMSおよびRMIキャッシュのコーディネーション

JMSコーディネート・キャッシュの場合は、特定のセッションのコーディネート・キャッシュが起動されると、そのセッションは、自身のJNDIネーミング・サービス情報を使用してJMSサーバーへの接続を検索および作成します。すべての参加セッションが同一JMSサーバー上の同一トピックに接続されると、コーディネート・キャッシュが準備完了状態になります。この時点で、セッションはオブジェクト変更メッセージの送受信を開始できます。この後、同一JMSおよびJNDIネーミング・サービス情報を使用して、同一コーディネート・キャッシュに参加しているすべてのセッションを構成できます。

RMIコーディネート・キャッシュでは、特定のセッションのコーディネート・キャッシュが起動すると、セッションによってネーミング・サービスの接続がバインドされ(RMIレジストリまたはJNDI)、独自のネーミング・サービス情報を含む通知メッセージが作成され、その通知がマルチキャスト・グループにブロードキャストされます。同じマルチキャスト・グループに属するセッションでこの通知が受信されると、通知メッセージのネーミング・サービス情報が使用され、新しく通知されたセッションのコーディネート・キャッシュとの双方向接続が確立されます。この方法ですべての参加セッションが相互接続されると、コーディネート・キャッシュの準備が完了し、その時点でセッションはオブジェクト変更メッセージの送受信を開始できます。その後、セッションがデプロイされているホストを識別するネーミング情報を使用して各セッションを構成できます。

JMSおよびRMIキャッシュ・コーディネーションの構成の詳細は、Oracle TopLinkのソリューション・ガイドの永続性プロパティを使用したJMSキャッシュ・コーディネーションの構成に関する項および永続性プロパティを使用したRMIキャッシュ・コーディネーションの構成に関する項を参照してください。

8.10.2 カスタム・キャッシュのコーディネーション

EclipseLinkのorg.eclipse.persistence.sessions.coordinationパッケージのクラスを使用して、コーディネート・キャッシュに対する独自のカスタム・ソリューションを定義できます。

8.11 クラスタリングおよびキャッシュの一貫性

アプリケーション・サーバー・クラスタにデプロイされたEclipseLinkアプリケーションは、クラスタのスケーラビリティ、ロード・バランシングおよびフェイルオーバーのメリットを受けることができます。これらの機能は、EclipseLinkアプリケーションの可用性を高め、アプリケーションの需要拡大に伴ってスケーリングできます。EclipseLinkのアプリケーションは、アプリケーション・サーバー・クラスタへも、スタンドアロンのサーバー環境と同様にデプロイできます。ただし、アプリケーション・サーバー・クラスタの場合には、キャッシュの一貫性を確保するために、その他に計画や構成を実行する必要があります。

キャッシュの一貫性を確保するために、エンティティ・キャッシュの無効化、キャッシュのリフレッシュ、エンティティ有効期限の設定およびキャッシュのオプティミスティック・ロックの設定などのタスクを実行します。詳細は、Oracle TopLinkのソリューション・ガイドのタスク1: キャッシュの一貫性の構成を参照してください。

8.12 キャッシュ・インターセプタ

EclipseLinkでは、非常に機能的で、高性能な統合されたキャッシュが用意されています。ただし、EclipseLinkのCacheInterceptor注釈を使用して、サードパーティの外部キャッシュを統合することができます。

8.13 Coherenceキャッシュの使用

Oracle TopLink Gridは、EclipseLink JPAおよびCoherenceキャッシュの統合を可能にするOracle TopLinkの機能です。標準のJPAアプリケーションは、プライマリ・データ・ストア(一般的にリレーショナル・データベース)と直接対話します。ただし、TopLink Gridの場合、ドメイン・モデルの一部またはすべてをCoherenceデータ・グリッドに格納できます。この構成は、グリッド基盤のJPAとも呼ばれています。

CoherenceキャッシュおよびTopLink Gridを使用して可用性を高め、アプリケーションをスケール・アウトする方法については、Oracle TopLinkのソリューション・ガイドのTopLink GridでのOracle Coherenceを使用したJPAアプリケーションのスケーリングに関する項を参照してください。

TopLink Gridの構成の完全な詳細およびTopLink Gridを使用したアプリケーション開発については、『Oracle Coherenceの統合』のTopLink GridとOracle Coherenceの統合に関する項を参照してください。Oracle TopLink Java APIリファレンスのoracle.eclipselink.coherence.* APIに関する項も参照してください。

9 問合せの理解

この章では、EclipseLinkを使用し、リレーショナルや非リレーショナルのデータ・ソースに対して、Java EEおよびJava EE以外のアプリケーションの両方で問合せを使用して、永続オブジェクトまたはデータを作成、読取り、更新および削除する方法について説明します。

この章の内容は次のとおりです。

- 問合せの概念

- JPQL問合せについて

- SQL問合せ言語について

- Criteria APIについて

- ネイティブSQL問合せについて

- ネイティブ問合せサポートに対するEclipseLinkの拡張機能

- 問合せヒントについて

- 問合せのキャストについて

- 問合せ用のOracle拡張機能について

9.1 問合せの概念

一般的に、データ・ソースの問合せとは、データ・ソースの内容に対する操作の実行、データ・ソースの内容との相互作用を意味します。これを行うには、次のことができる必要があります。

- 問い合せるデータ・ソースのネイティブな構文で操作を定義します。

- 制御された方法で操作を適用します。

- 操作によって結果が返された場合は、それを管理します。

問合せがEclipseLinkキャッシュにどのような影響を与えるのかも考慮する必要があります。

この項では、次の内容を含む、EclipseLinkに固有の問合せの概念について説明します。

- Callオブジェクト

- DatabaseQueryオブジェクト

- データ・レベルとオブジェクト・レベルの問合せ

- サマリー問合せ

- ディスクリプタ問合せマネージャ

- 問合せキー

9.1.1 Callオブジェクト

Callオブジェクトは、データ・ソースに対する操作またはアクションをカプセル化します。EclipseLink APIによって、Structured Query Language (SQL)、Java Persistence Query Language (JPQL)、Extensible Markup Language (XML)などの様々なCallタイプが提供されます。

Callは、直接実行することも、あるいはEclipseLinkのDatabaseQueryオブジェクトのコンテキストで実行することもできます。

9.1.2 DatabaseQueryオブジェクト

DatabaseQueryオブジェクトは、追加のカスタマイズ・オプションや最適化オプションとCallでカプセル化した操作を関連付ける抽象オブジェクトです。EclipseLinkでは、これらのオプションをCallから分離することによって、すべてのCallタイプにわたって高度な問合せ機能を利用できます。

9.1.3 データ・レベルとオブジェクト・レベルの問合せ

問合せは、オブジェクトまたはデータに対して次のように定義できます。

- オブジェクト・レベルの問合せは、オブジェクト固有で、データをドメイン・モデルのオブジェクトとして返します。これは、マップ済データ向きの問合せです。オブジェクト・レベルのDatabaseQuery問合せは、EclipseLinkで最も頻繁に使用されます。

- データ・レベルの問合せは、データベース表を直接問い合せるために使用され、アンマップ・データを操作する場合に適切な方法です。

9.1.4 サマリー問合せ

データ・レベルの問合せはRAWデータを返し、オブジェクト・レベルの問合せはドメイン・モデルのオブジェクトを返しますが、サマリー問合せはオブジェクトに関するデータを返します。EclipseLinkでは、特定の属性のみが移入されたオブジェクトのセットを返す部分オブジェクト問合せと、オブジェクトのセットの特定の属性に関する要約(ロールアップ)データを返すレポート問合せが提供されます。

9.1.5 ディスクリプタ問合せマネージャ

特定のクラスに適用できる名前付き問合せを保存できるのみでなく、一般的なデータ・ソース操作用にEclipseLinkで定義されているデフォルトの操作をDescriptorQueryManagerによってオーバーライドすることもできます。

9.1.6 問合せキー

問合せキーとは、データベース・フィールド名の、スキーマ非依存の別名です。問合せキーを使用する場合、スキーマに依存しない別名を使用したフィールドを参照できます。リレーショナル・プロジェクトにかぎっては、EclipseLinkではマップした属性すべてに対して問合せキーを自動的に作成します。問合せキーの名前は、オブジェクト・モデルで指定されたクラス属性の名前です。

問合せキーは、クラス・ディスクリプタまたはインタフェース・ディスクリプタで構成できます。問合せキーは、式で使用することや、可変1対1マッピングを問い合せるために使用できます。

デフォルトでは、EclipseLinkによって、マップされたすべての属性の問合せキーが作成されますが、一部の環境では独自の問合せキーを追加すると役立つこともあります。

9.2 JPQL問合せについて

Java Persistence Query Language (JPQL)は、JPAによって定義された問合せ言語です。JPQLは、SQLとほぼ同じですが、表や列のかわりにオブジェクト、属性およびリレーションシップに対して動作します。JPQLは、読取り(SELECT)に加え、バルク更新(UPDATE)や削除(DELETE)のために使用できます。JPQLは、(注釈またはXMLを通じて) NamedQueryで使用するか、EntityManager createQuery() APIを通じて動的問合せで使用できます。

JPQLの短所は、動的問合せで、Webフォームや動的コンテンツから文字列を動的に連結して問合せを作成する必要があることです。また、JPQLは実行時までチェックされないので、タイプミスが多くなります。これらの短所は、9.4項「About the Criteria APIについて」で説明する問合せ基準APIを使用すればある程度補えます。

9.2.1 JPQLに対するEclipseLinkの拡張機能

EclipseLinkは、SELECT問合せ、更新および削除文、WHERE句、リテラル値およびデータベース関数など、JPA仕様の「Query Language」に記載されているあらゆる文および句をサポートしています。詳細は、JPA仕様を参照してください。

http://jcp.org/en/jsr/detail?id=338

EclipseLinkでは、標準のJPA JPQLに対する多くの拡張機能が提供されています。これらの拡張機能によって、その多くがSQL標準の一部である追加のデータベース機能に対するアクセス、ネイティブのデータベース機能および関数に対するアクセス、およびEclipseLink固有の機能に対するアクセスが提供されます。

EclipseLinkのJPQL拡張機能には次のものが含まれます。

- JPQLより少ない制限で、LIKE、IN、ORDER BY、コンストラクタ、関数などの操作内で下位選択および関数を使用可能

- <>のかわりに!=を使用可能

- データベース固有の関数をコールできるFUNCTION操作

- 継承のある関連エンティティをダウンキャストできるTREAT操作

- EclipseLinkのデータベースに依存しない関数をコールできるOPERATOR操作

- SQLとJPQLを組み合せることができるSQL操作

- CASTおよびEXTRACT関数

- 正規表現による問合せのためのREGEXP関数

- SELECTおよびFROM句での下位選択の使用

- JOINおよびLEFT JOIN条件を定義するためのON句のサポート

- 独立エンティティ間の結合

- JOIN FETCHでの別名の使用

- マップされていない列での問合せを可能にするCOLUMN操作

- マップされていない表での問合せを可能にするTABLE操作

- UNION、INTERSECT、EXCEPTのサポート

- =、<>、IN、IS NULLおよびORDER BYでのオブジェクト変数の使用

これらの拡張機能の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のEclipseLinkの問合せ言語に関する項を参照してください。

9.2.2 JPQLでのEclipseLinkの特殊な演算子

EclipseLinkでは、基本的なJPQLでは使用できないデータベース操作を実行できる特殊なJPQL演算子がいくつか定義されています。これには次のものがあります。

- COLUMN

- FUNCTION

- OPERATOR

- SQL

これらの演算子の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の特殊な演算子に関する項を参照してください。

9.3 SQL問合せ言語について

EclipseLinkを使用すると、次の問合せ言語を使用して問合せを表現できます。

- SQL問合せ

- EclipseLinkの式(第10章「EclipseLinkの式の理解」を参照)

- ストアド・プロシージャ

SQLは、リレーショナル・データベース・データ・ソースを使用するアプリケーションで最も一般的な問合せ言語です。ほとんどの場合、特定の問合せ言語で問合せを直接構成できますが、可能であれば、適切なCallを使用してDatabaseQueryを構成し、Expressionオブジェクトを使用して選択基準を指定することをお薦めします。SQLで問合せを直接構成する方法が最も簡単な方法(簡単な操作またはアンマップ・データに対する操作)であるように思われますが、DatabaseQueryを使用した方法の場合、問合せをドメイン・オブジェクト・モデルに限定し、データ・ソース・スキーマ実装の詳細に依存しなくて済むという大きな利点があります。

問合せの構成には、Expressionを使用することをお薦めします。

SessionのメソッドexecuteSelectingCallおよびexecuteNonSelectingCallを使用してカスタムSQLを直接実行したり、適切なCallを使用してDatabaseQueryを構成することができます。

EclipseLinkでは、ストアド・プロシージャ、およびOracle Database、ストアド・ファンクションとともに使用できる様々なSQL Callオブジェクトを用意しています。EclipseLinkでは、PLSQLデータ・タイプを持つOracleストアド・プロシージャのPLSQLコールもサポートします。

9.3.1 ストアド・プロシージャ

JPA仕様(http://jcp.org/en/jsr/detail?id=338)の「Stored Procedures」の項に記載されているとおり、ネイティブSQLでは、動的に、またはNamedStoredProcedureQuery注釈で指定された名前付きストアド・プロシージャを使用できます。注釈を使用する場合、データベースにストアド・プロシージャが存在する必要があります。注釈を使用して、ストアド・プロシージャに対するすべてのパラメータのタイプ、対応するパラメータ・モードおよび結果セットのマッピングを指定できます。

StoredProcedureParameter注釈を使用して、すべてのパラメータに対してメタデータを提供する必要があります。パラメータは、ストアド・プロシージャのパラメータ・リストに記載されている順序で指定する必要があります。パラメータ名が使用される場合、パラメータ名を使用してパラメータ値をバインドし、出力値を抽出します(パラメータがINOUTまたはOUTパラメータの場合)。

ストアド・プロシージャがメタデータを使用して定義されていない場合は、パラメータおよび結果セット情報を動的に提供する必要があります。

9.3.1.1 ストアド・プロシージャに対するEclipseLinkの拡張機能

EclipseLinkには、PLSQLのストアド・プロシージャ(@NamedPLSQLStoredProcedureQueryなど)およびストアド・ファンクション(@NamedPLSQLStoredFunctionQueryなど)を使用できる、注釈の拡張機能が定義されています。PLSQL注釈により、JDBCからアクセスできないRECORDおよびTABLEなどの複合PLSQLタイプを使用できます。注釈には、ファンクション(またはプロシージャ)名、ストアド・ファンクションの戻り値、問合せヒント、ストアド・ファンクションのパラメータおよびSQLResultMappingの名称を指定するための属性が含まれています。

ストアド・ファンクション(またはプロシージャ)に対するパラメータは、@PLSQLParameter注釈とともに指定します。@PLSQLRecord注釈は、PLSQLプロシージャで使用するための、データベースPLSQLのRECORDタイプを定義します。

EclipseLinkには、PLSQLではないストアド・プロシージャ(@NamedStoredProcedureQueryなど)およびストアド・ファンクション(@NamedStoredFunctionQueryなど)を使用できる、注釈の拡張機能も定義されています。

ストアド・プロシージャに対するEclipseLinkの拡張機能のリストおよび説明へのリンクは、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のストアド・プロシージャおよびファンクションの注釈に関する項を参照してください。

9.4 Criteria APIについて

Java Persistence Criteria APIを使用すると、JPQLの文字列ベースのアプローチを使用せずに、オブジェクトベースの問合せ定義オブジェクトを構成して動的問合せを定義できます。Criteria APIによって、文字列ベースの第4世代言語アプローチよりJava言語との統合が容易になる動的問合せをプログラム的に作成できます。

Criteria APIには、タイプ制限モードとタイプなしモードという2つのモードがあります。タイプ制限モードでは、JPAメタモデルで生成されたクラスのセットを使用して、クラスの問合せ可能な属性を定義します。タイプなしモードでは、文字列を使用してクラスの属性を参照します。

Criteria APIは、動的問合せ専用で、メタデータまたは名前付き問合せでは使用できません。基準問合せは、動的問合せであり、静的な名前付き問合せや、EclipseLinkの解析キャッシュの利点を得ることができるパラメータ化された動的JPQLほどのパフォーマンスは得られません。

詳細は、JPA仕様の第6章「Criteria API」を参照してください。

http://jcp.org/en/jsr/detail?id=338

CriteriaBuilderは、Criteria APIの主要インタフェースです。CriteriaBuilderは、getCriteriaBuilder() APIを使用してEntityManagerまたはEntityManagerFactoryから取得されます。CriteriaBuilderを使用して、CriteriaQueryオブジェクトとその式を作成できます。Criteria APIでは、現在、選択問合せのみがサポートされます。

CriteriaQueryは、データベースの選択問合せを定義します。CriteriaQueryは、JPQL選択問合せのすべての句をモデル化します。あるCriteriaQueryの要素は、他のCriteriaQuerysで使用できません。CriteriaQueryは、EntityManager createQuery() APIとともに使用して、JPA問合せを作成できます。

where句は、返される結果をフィルタする条件(述語)を定義するため、通常は問合せの主要部分です。where句は、任意のPredicateオブジェクトでCriteriaQueryに対してwhere APIを使用することで定義されます。Predicateは、CriteriaBuilderに対して比較操作または論理操作を使用することで取得されます。isNull、isNotNullおよびin操作は、Expressionオブジェクトに対してもコールできます。not操作は、Predicateオブジェクトに対してもコールできます。

副問合せは、Criteria APIのselect、where、order、group byまたはhaving句で使用できます。副問合せは、subquery操作を使用してCriteriaQueryから作成されます。ほとんどのsubqueryの使用法では、CriteriaBuilderのexists、all、anyまたはsome操作か、in操作とともに使用しないかぎり、副問合せは単一の結果および値を返すように制限されます。

パラメータは、CriteriaBuilderでparameter APIを使用することで定義できます。JPAでは、名前付きパラメータと位置パラメータが定義されています。名前付きパラメータでは、パラメータのタイプと名前が指定されます。位置パラメータでは、パラメータのタイプのみが指定されます。位置パラメータは、位置0ではなく1から開始します。

Criteria APIでは、いくつかのデータベース関数がサポートされます。サポートされるすべての関数は、CriteriaBuilderで定義されます。一部の関数は、SQL準拠でない場合、一部のデータベースでサポートされないことがあり、同等の関数も提供されません。

Criteria APIでは、データベース関数ではない特殊な操作がいくつか定義されていますが、これらはJPAでは特殊な意味を持ちます。これらの操作の一部はCriteriaBuilderで定義され、一部は特定のExpressionインタフェースで定義されます。

JPAでは、ORMマッピング・メタデータの情報を問い合せるために実行時に使用できるメタモデルが定義されています。メタモデルには、クラスのマップ済属性のリストや、そのマッピングのタイプおよびカーディナリティが含まれます。メタモデルは、文字列を使用してクラス属性を参照するかわりに、Criteria APIと組み合せて使用できます。

JPAでは、コンパイル時にメタモデルにアクセスできる、JPAプロバイダ(IDE)によって生成される一連の"_"クラス(_MyEntity.javaなど)が定義されています。これによって、Criteria APIで型指定の静的変数を使用できます。これによって、テスト時ではなくコンパイル時に問合せの問題を捕捉することで、タイプミスの発生やアプリケーション・コードでの無効な問合せを削減できます。ただし、この場合、メタモデルの静的クラスを生成して開発サイクルの一部にする必要があるため、開発プロセスが複雑になります。

タプルでは、複数選択の問合せ結果が定義されます。通常、オブジェクト配列は、JPAの複数選択問合せによって返されますが、オブジェクト配列はそれほど有益なデータ構造ではありません。タプルは、名前または索引で結果を取得できるマップ状の構造です。

9.4.1 Criteria APIに対するEclipseLinkの拡張機能

EclipseLinkのCriteria APIサポートにおける制限は、JPAの指定より少なくなっています。一般的に、副問合せおよびオブジェクト・パス式は、次のようにほとんどの場所で許可されます。

- select、group byおよびorder句での副問合せ

- 関数と組み合せた副問合せの使用

- オブジェクト・パス式と組み合せた使用

- オブジェクト・パス式と組み合せたOrder byの使用

EclipseLinkのCriteria APIサポートは、EclipseLinkのネイティブExpression APIを基盤として成立しています。EclipseLinkには、JPA Expressionオブジェクトを対象としたネイティブのExpressionオブジェクトの変換を可能にするJpaCriteriaBuilderインタフェースが用意されています。これによって、EclipseLinkのネイティブのExpression APIをJPAのCriteria APIと組み合せることができます。

EclipseLinkのネイティブのExpression APIでは、次の追加機能が提供されます。

- 追加のデータベース関数(80を超えるデータベース関数のサポート)

- カスタムのExpressionOperatorsの使用

- Expression問合せ内へのSQLの埋込み

- from句での下位選択の使用

- ON句のサポート

- マップされていない列および表へのアクセス

- 履歴問合せ

EclipseLinkのExpressionsは、EclipseLinkのDatabaseQuerysと組み合せて追加機能を提供できます。

- union、intersectおよびexcept句

- 句による階層接続

- 一括フェッチ

9.5 ネイティブSQL問合せについて

JPAでは、エンティティ・オブジェクトまたはデータの問合せにSQLを使用できます。SQL問合せは、変換されずにデータベースに直接渡されます。SQL問合せは、データベース固有の構文を必要とする高度な問合せのために使用するか、JPQLやJavaよりSQL言語に慣れているユーザーによって使用できます。

SQL問合せは、createNativeQuery APIまたは名前付き問合せを使用してEntityManagerから作成されます。問合せオブジェクトは、他の任意のJPA問合せと同じように返され、実行されます。SQL問合せは、エンティティ・クラス用に作成することや、データのオブジェクト配列を返すことができます。エンティティを返す場合、SQL問合せによってエンティティのマッピングが予期している列名を返す必要があります(または、SqlResultSetMappingを使用できます)。SqlResultSetMappingでは、SQLの結果セットをエンティティ(またはエンティティおよびデータのセット)にマップできます。

SQL問合せを使用して、SQLまたはDML (データ操作言語)文を実行できます。結果を返すSQL問合せでは、getSingleResultまたはgetResultListを使用できます。結果を返さないSQL問合せでは、executeUpdateを使用する必要があります。executeUpdateは、トランザクション内でのみ使用できます。SQL問合せを使用して、データベース操作と、一部のストアド・プロシージャおよびファンクションを実行できます。出力パラメータを返すストアド・プロシージャまたは一部の複雑なストアド・プロシージャは、SQL問合せでは実行できません。

SQL問合せのパラメータは、疑問符(?)を使用して区切る必要があります。索引付きパラメータのみがサポートされ、名前付きパラメータはサポートされません。索引は、?1などのデリミタで使用できます。パラメータ値は、setParameter APIを使用して問合せに設定されます。索引付きパラメータは、索引0ではなく1から開始します。

ネイティブSQL問合せは、NamedNativeQuery注釈または<named-native-query> XML要素を使用して注釈またはXMLで名前付き問合せとして定義できます。名前付きのネイティブSQL問合せは、任意の名前付き問合せと同じように実行されます。

結果列の名前が、エンティティ・マッピングで予期されている内容と一致しない場合、SqlResultSetMappingを使用してSQL問合せの結果をエンティティにマップできます。これは、単一のSQL問合せから複数のエンティティ(またはエンティティおよびデータ)を返す場合にも使用できます。EntityResultおよびFieldResultを使用して、エンティティ属性にSQL問合せの結果列をマップできます。ColumnResultを使用して、結果にデータ要素を追加できます。

SqlResultSetMappingsは、@SqlResultSetMapping注釈または<sql-result-set-mapping> XML要素を使用して、注釈またはXMLを通じて定義されます。これらは、名前を通じてネイティブSQL問合せから参照されます。

9.5.1 ネイティブ問合せサポートに対するEclipseLinkの拡張機能

EclipseLinkの式を使用すると、ドメイン・オブジェクト・モデルに基づいて問合せの検索基準を指定できます。問合せを実行する際、EclipseLinkではこれらの検索基準を、使用しているプラットフォームに適した問合せ言語に変換します。

EclipseLink APIは、式をサポートする次の2種類のパブリック・クラスを提供します。

- Expressionクラスは、単純な定数からブール・ロジックを伴う複雑な句まで、あらゆる式を表します。式の操作、グループ化および統合を行うことができます。

- ExpressionBuilderクラスは、新しい式を構成するためのファクトリです。

選択基準は、DatabaseQueryのメソッドsetSelectionCriteria,を使用してExpressionとして指定したり、Expressionを取るファインダに指定できます。

EclipseLinkの式の使用方法の詳細は、第10章「EclipseLinkの式の理解」を参照してください。

9.6 問合せヒントについて

問合せヒントを使用して、JPA問合せをカスタマイズまたは最適化できます。NamedQuery注釈を使用して、Java永続性問合せ言語で名前付き問合せを指定します。この注釈には、問合せプロパティおよびヒントの指定に使用できる、hints要素が含まれます。この注釈の詳細は、JPA仕様の「NamedQuery Annotation」を参照してください。

http://jcp.org/en/jsr/detail?id=338

問合せヒントの定義はベンダー固有です。次の各項では、JPA問合せヒントおよびEclipseLink問合せヒントを説明します。

- JPAのキャッシュ問合せヒント

- キャッシュ問合せヒントに対するEclipseLinkの拡張機能

9.6.1 JPAのキャッシュ問合せヒント

JPAの問合せヒントでは、問合せまたはfind()演算は共有キャッシュをバイパスまたはリフレッシュできます。JPAのキャッシュ問合せヒントは、名前付きまたは動的問合せにセットすることも、find()操作に渡されるプロパティ・マップにセットすることもできます。

JPA 2.0は、共有キャッシュと問合せの対話を構成するため、次の問合せヒント・プロパティを定義しています。

- javax.persistence.cache.retrieveMode

- javax.persistence.cache.storeMode

9.6.2 キャッシュ問合せヒントに対するEclipseLinkの拡張機能

EclipseLinkのキャッシュ問合せヒントでは、問合せまたはfind()演算は、次の方法でキャッシュと対話することができます。

- キャッシュ・チェックをバイパスし、データベースへのアクセスを強制しますが、まだキャッシュにより解決しています。

- データベース結果からキャッシュをリフレッシュします。

- キャッシュおよび永続性ユニットをバイパスし、デタッチされたオブジェクトを返します。

- 永続性コンテキストをバイパスし、読取り専用オブジェクトを返します。

- 問合せがIdフィールドおよびその他のフィールドを使用して、キャッシュ・ヒットを取得できるようにします。

- 最初にキャッシュの問合せを行い、オブジェクトが見つからない場合のみ、データベースにアクセスします。

- キャッシュの問合せのみを行い、データベースへのアクセスを回避します。

- 問合せを永続性コンテキストのフラッシュされていない変更に適合させます。

キャッシュにアクセスする問合せには、次の制限事項があります。

- サブセレクトはサポートされていません。

- サポートされないデータベース関数もあります。

- 問合せはオブジェクトの単一セットである必要があります。

- グループ化はサポートされていません。

- インスタンス化されていないLAZYリレーションシップに対する問合せを行うことはできません。

EclipseLinkのすべての問合せヒントは、org.eclipse.persistence.configパッケージのQueryHintsクラスで定義されます。ヒントを設定する場合、次のようなorg.eclipse.persistence.configパッケージの適切な構成クラスのpublic static finalフィールドを使用して、値を設定できます。

- HintValues

- CacheUsage

- PessimisticLock

- QueryType

@QueryHint注釈を使用して、orm.xmlまたはeclipselink-orm.xmlファイルにヒントを含めて、または名前付きまたは動的問合せ(JPQLまたはCriteria)の実行時にsetHint()メソッドを使用して、EclipseLinkの問合せヒント(JPA問合せ拡張機能)を指定できます。

生成されるSQLに影響する問合せ設定および問合せヒントは、SQL問合せではサポートされません。サポートされない問合せヒントには、次のものがあります。

- batch

- history.as-of

- inheritance.outer-join

- sql.hint

- join-fetch: join-fetchはサポートされますが、SQLですべての結合列を選択する必要があります。

- fetch-group: fetch-groupはサポートされますが、SQLですべてのフェッチ列を選択する必要があります。

- pessimistic-lock: pessimistic-lockはサポートされますが、SQLで結果行をロックする必要があります。

これらの拡張機能の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のEclipseLinkの問合せ言語に関する項を参照してください。

9.7 問合せのキャストについて

問合せのキャストを使用して、JPAまたはORMの使用時にサブクラスの属性全体を問い合せます。この機能は、JPQL、EclipseLinkの式およびCriteria APIで使用できます。

JPA 2.0以上では、結果または問合せを特定のサブクラスのものに制限できます。たとえば、式フレームワークでは、Expression.type(Class)が提供されます。

JPQLでは、ダウンキャストは、JOIN句のTREAT...ASを使用して、FROM句で実行されます。

JPA Criteria APIには、キャスト演算子のExpression.as(type)が含まれます。この式では、汎用内でタイプの一致を可能にする単純なキャストが実行されます。

JOINノードでキャストをコールすると、そのノードは永続的に変更されます。たとえば、前述の例では、join.as(LargeProject.class)のコール後に、結合はLargeProjectを参照します。

9.7.1 ダウンキャスト用のEclipseLinkの式のサポート

EclipseLinkは、Expression.as(type)を使用してキャストを実行できるようにCriteria APIを拡張しています。asメソッドによって階層が確認され、タイプがコールされている式のタイプのサブクラスである場合、キャストが実装されます。

Expression.as(Class)は、ダウンキャストにも使用できます。Expression.as(Class)を使用する場合の動作は、次のとおりです。

- キャスト先のクラスが、キャスト対象の問合せキーのクラスのサブクラスではない場合、問合せ実行時に例外がスローされます。

- キャストは、ObjectExpressions (QueryKeyExpressionおよびExpressionBuilder)でのみ許可されます。キャストの親の式は、ObjectExpressionとする必要があります。

- キャストでは、変更されるObjectExpressionと同じ外部結合設定を使用します。

- キャストでは、親の式を変更します。その結果、パラレル式でキャストを使用する場合、親の式の新しいインスタンスを使用する必要があります。

- キャストは、TablePerClass継承ではサポートされません。

- キャストを実行する問合せでは、タイプを慎重に確認してください。

- EclipseLinkでは、キャストで単一のタイプが生成される場合、自動的にタイプ情報が追加されますが、階層の中間にあるクラスの場合、タイプ情報はSQLに追加されません。

9.8 問合せ用のOracle拡張機能について

EclipseLinkをOracle Databaseとともに使用する場合は、EclipseLinkアプリケーション内から次のOracle固有の問合せ機能を使用できます。

- 問合せヒント

- 階層問合せ

- フラッシュバック問合せ

- ストアド・ファンクション

9.8.1 問合せヒント

Oracleでは、データベース・サーバーのSQLオプティマイザの動作を変更できる、ヒントというSQL問合せの追加機能を指定できます。これを使用すると、通常オプティマイザで行われる設定を変更できます。ヒントを使用して、結合文の結合順序やSQLコールの最適化方法などを指定します。

ヒントを指定するには、EclipseLinkのDatabaseQueryのメソッドsetHintStringを使用します。

詳細は、使用しているデータベースのパフォーマンス・チューニング・ガイドを参照してください。

9.8.2 階層問合せ

Oracleデータベースの階層問合せメカニズムを使用すると、階層順序に基づいてデータベースの行を選択できます。たとえば、特定の従業員の行、その従業員が管理する人々の行、その人々に管理される従業員の行などの順序で読取りを行う問合せを設計できます。

EclipseLinkに表示される、DatabaseQueryのサブクラスReadAllQueryのメソッドsetHierarchicalQueryClauseを使用して、階層問合せ句を指定します。

9.8.3 フラッシュバック問合せ

EclipseLinkをOracle9i Database以降とともに使用する場合、特別な履歴セッションを取得できます(このセッションでは、過去の特定時刻までのすべてのオブジェクトが読み取られ、ある期間にどのようにオブジェクトが変更されているかについての条件を付けた読込み問合せを表現できます)。詳細は、Oracle Databaseアドバンスト・アプリケーション開発者ガイドのOracle Flashback Technologyの使用に関する項を参照してください。

9.8.4 ストアド・ファンクション

ストアド・ファンクションは、ストアド・プロシージャは、値を返すことに加え、すべての機能を提供するOracle Databaseのメカニズムです。ストアド・プロシージャとともに使用する注釈だけでなく、ストアド・ファンクションとともに使用する多数の注釈をも提供します。ストアド・ファンクションおよびプロシージャに対するEclipseLinkの注釈の拡張機能のリストおよび説明へのリンクは、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のストアド・プロシージャおよびファンクションの注釈に関する項を参照してください。

10 EclipseLinkの式の理解

この章では、EclipseLinkの式フレームワークを使用して、ドメイン・オブジェクト・モデルに基づいて問合せの検索基準を指定する方法について説明します。

この章の内容は次のとおりです。

- 式フレームワークについて

- 式の構成要素について

10.1 式フレームワークについて

EclipseLinkの式フレームワークは、次のクラスを通じてメソッドを提供します。

- Expressionクラスは、toUpperCaseなど、最も一般的な関数を提供します。

- ExpressionMathクラスは、数値演算メソッドを提供します。

このように機能を分けることで、EclipseLinkの式は、java.lang.Mathクラスに類似した数値演算機能を提供しながらも、ExpressionおよびExpressionMathクラスが必要以上に複雑になることを防ぐことができます。

データベースにアクセスする場合、式は次の点でSQLよりも優れています。

- データベースが抽象化されるため、式の方が管理が容易です。

- ディスクリプタまたはデータベース表に変更を加えても、アプリケーションの問合せ構造に影響を与えません。

- 式では、Javaの通常のコール方法に似せてQueryインタフェースを標準化するため、読みやすさが向上します。

- 式を使用すると、読取り問合せによって、同じリレーションシップを共有する2つのクラスの間で問合せを透過的に行うことができます。これらのクラスがデータベース内の複数の表に格納されている場合、EclipseLinkは適切な結合文を自動的に生成し、両方の表から情報を返します。

- 式は複雑な操作を単純化します。

10.2 式の構成要素について

通常、単純な式は次の3つの部分で構成されています。

- 属性: 永続クラスの問合せキーまたはマップされた属性を表します。

- 演算子: GreaterThan、EqualまたはLikeなどのブール・ロジックを実装する式メソッドです。

- 定数または比較: オブジェクトの選択に使用される値を参照します。

次のコード・フラグメントでは、属性はlastName、演算子はequal、定数は文字列"Smith"です。expressionBuilderには、データベースから読み取られる1つ以上のオブジェクトに置き換わります。この例では、expressionBuilderは従業員を表しています。

expressionBuilder.get("lastName").equal("Smith");

Expressionを作成する場合、次の構成要素を使用できます。

- ブール・ロジック

- データベース関数および演算子

- Oracle XMLType関数

- プラットフォーム関数とユーザー定義関数

- 1対1および集約オブジェクトのリレーションシップを表す式

- 結合リレーションシップと複雑なリレーションシップを表す式

10.2.1 ブール・ロジック

式では、標準のブール演算子(AND、OR、NOTなど)を使用し、複数の式を結合してより複雑な式を作成できます。

10.2.2 データベース関数および演算子

EclipseLinkでは、様々なデータベースに変換される標準の演算子名を使用して、多くのデータベース関数がサポートされます。EclipseLinkの演算子は、同等の関数(関数のセット)を持つ任意のデータベースでサポートされます。サポートされるすべての関数と演算子の詳細およびリストは、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の「OPERATOR」および「FUNCTION」を参照してください。

EclipseLinkの式は、Expressionクラスに記載された、様々なデータベース関数をサポートしています。データベース関数を使用すると、より柔軟な問合せを定義できます。これらの関数は、SELECT句を使用したレポート問合せで、またはWHERE句を使用した問合せの選択基準の比較で使用できます。

注意:
一部の関数はデータベース・プラットフォームに固有です。

演算子は、2つの値を比較する関係演算子です。EclipseLinkの式演算子は、ExpressionOperatorクラスに記載されています。

数値演算関数は、ExpressionMathクラスを通じて使用できます。式における数値演算関数のサポートは、Javaクラスjava.lang.Mathによるサポートに似ています。

10.2.2.1 Oracle XMLType関数

OracleデータベースXMLType列にマップされたデータに対する問合せを構成する場合は、次の演算子を使用できます。

- extract: XPath文字列をとり、元のドキュメントのうち、XPathに一致する部分のXMLTypeを返します。

- extractValue: XPath文字列をとり、XPathが指すノードの内容に基づいて、数値または文字列の値を返します。

- existsNode: XPath式をとり、XPathに一致するノードの数を返します。

- getStringVal: XMLTypeオブジェクトの文字列表現を取得します。

- getNumberVal: XMLTypeオブジェクトの数値表現を取得します。

- isFragment: XMLが整形式文書である場合、0に評価します。文書がフラグメントである場合、1に評価します。

10.2.3 プラットフォーム関数とユーザー定義関数

ExpressionのメソッドgetFunctionを使用すると、EclipseLinkで直接サポートされていないデータベース関数にアクセスできます。Expression APIには、引数を指定できる、他の形式のgetFunctionメソッドもあります。独自のカスタム関数も作成できます。詳細は、Oracle TopLink Java APIリファレンスを参照してください。

10.2.4 1対1および集約オブジェクトのリレーションシップを表す式

式には、別の永続クラスとの1対1リレーションシップを持つ属性を含めることができます。当然、1対1リレーションシップは単一行を返すSQL結合に変換されます。

10.2.5 結合リレーションシップと複雑なリレーションシップを表す式

1対多、多対多、ダイレクト・コレクション、集約コレクションなどの複雑なリレーションシップに対して問合せを行うことができます。このようなタイプのリレーションシップはオブジェクトごとに単一行を返す結合に直接マップされないため、これらのリレーションシップを表す式は作成方法が複雑です。

この項の内容は次のとおりです。

- 結合について

- 結合でのEclipseLink Expression APIの使用

10.2.5.1 結合について

結合は、2つ以上の表からの行を組み合せるリレーショナル・データベース問合せです。問合せのFROM句に複数の表を記述すると、必ずリレーショナル・データベースでは結合が実行されます。問合せの選択リストでは、これらの表のうちの任意の表から任意の列を選択できます。

内部結合(単純結合とも呼ばれる)は、2つ以上の表の結合で、結合条件を満たす行のみを返します。

外部結合は、内部結合の結果を拡張します。外部結合は、結合条件を満たすすべての行と、結合条件を満たす行を除いた、一方の表のすべての行を戻します。外部結合は、右または左に分類できます。

- 表AおよびBの左外部結合を実行する問合せでは、A内の行をすべて返します。B内に一致する行を持たないA内のすべての行に対し、Bの列を含む選択リストの式にはデータベースによりnullが返されます。

- 表AおよびBの右外部結合を実行する問合せでは、B内の行をすべて返します。A内に一致する行を持たないB内のすべての行に対し、Aの列を含む選択リストの式にはデータベースによりnullが返されます。

結合式で問合せを行うと、EclipseLinkは結合を使用して、他のオブジェクトの値、または同じオブジェクトの一部を表す他の表の値をチェックすることができます。これはほとんどの状況でうまくいきますが、リレーションシップの一方が存在しない1対1リレーションシップに対して問合せを行った場合に問題が発生することがあります。

たとえば、Employeeオブジェクトは、Addressオブジェクトを保持できますが、Addressが不明の場合、これはオブジェクト・レベルではnullで、データベース・レベルではnullの外部キーを持ちます。リレーションシップを横断する読取りを試行すると、欠落したオブジェクトが原因で、問合せで予期しない結果が返されます。次の式について考えます。

(emp.get("firstName").equal("Steve")).or(emp.get("address"). get("city").equal("Ottawa"))

この場合、住所を持たない従業員は、名前に関係なく結果セットには含まれません。オブジェクト・レベルでは明白ではありませんが、この動作はリレーショナル・データベースの特性の基本となります。

外部結合をサポートしているデータベースでは、外部結合によってこの問題が解決します。この例では、外部結合を使用することで、住所が不明であってもSteveという名前のすべての従業員が結果セットに含まれるという、予期した結果が得られます。

外部結合を実装するには、ExpressionのメソッドgetのかわりにgetAllowingNullを使用します。同様に、ExpressionのメソッドであるanyOfのかわりにanyOfAllowingNoneを使用します。

次に例を示します。

(emp.get("firstName").equal("Steve")).or(
emp.getAllowingNull("address").get("city").equal("Ottawa"))

外部結合のサポートと構文は、データベースとデータベース・ドライバによって大きく異なります。EclipseLinkでは、ほとんどのデータベースの外部結合がサポートされています。

10.2.5.2 結合でのEclipseLink Expression APIの使用

結合は、選択基準、順序付け、レポート問合せ、部分オブジェクト、1対1リレーショナル・マッピング、結合読取りなど、式が使用されている任意の場所で使用できます。

表10-1に示すExpression APIを使用して、内部および外部結合式を構成します。

表10-1 結合用のExpression API

Expression API

結合のタイプ

マッピングのタイプ

get

内部

1対1

getAllowingNull

外部

1対1

anyOf

内部

1対多、多対多

anyOfAllowingNone

外部

1対多、多対多

1対多または多対多のリレーションシップに対して問合せを行うには、anyOf操作を使用します。その名前が示すように、この操作では問合せ基準を満たすリレーションシップの多くの側面ですべての項目を返す問合せがサポートされます。

11 非リレーショナル・データ・ソースの理解

この章では、非リレーショナル・データ・ソースと連携するようにJPAアプリケーションを設定する方法について説明します。非リレーショナル・データ・ソースには多くのタイプがあります。これには、ドキュメント・データベース、キー/値ストア、および他の様々な非標準データベース(MongoDB、Cassandra、Google BigTableなど)が含まれます。この章では、主にNoSQLデータ・ストアについて説明します。NoSQLは、SQL標準をサポートしないデータベース・システムの類型です。EclipseLinkでは、Java Persistence API (JPA)を通じたNoSQLデータベースに対するJavaオブジェクトの永続化がサポートされます。EclipseLinkのネイティブAPIも、NoSQLデータベースでサポートされます。

この章の内容は次のとおりです。

- NoSQLプラットフォームの概念

- NoSQL永続性ユニットについて

- NoSQLプラットフォームのJPAアプリケーションについて

- NoSQLオブジェクトのマッピングについて

- 問合せおよびNoSQLプラットフォームについて

- トランザクションおよびNoSQLプラットフォームについて

11.1 NoSQLプラットフォームの概念

NoSQLは、SQL標準をサポートしないデータベース・システムの類型です。NoSQLの類型は、アプリケーション・データベース、レガシー・データベース、メッセージ・システム、トランザクション処理モニターなど(たとえば、IMS、VSAMおよびADABASE)のEnterprise Information Systems (EIS)を含めるように拡張できます。

EclipseLinkのNoSQLサポートには、次のものが含まれます。

- MongoDB

- Oracle NoSQL

- XMLファイル

- JMS

- Oracle AQ

EclipseLinkによるNoSQLサポートの詳細は、A.3項「非SQL標準データベースのサポート: NoSQL」を参照してください。

NoSQLおよびEISデータ・ソースには、Java Connector Architecture Common Client Interface (JCA CCI)をサポートするJava Connector Architecture (JCA)リソース・アダプタがあります。

NoSQLおよびEISデータ・ソースにアクセスする場合、多くの異なる方法があります。多くのNoSQLデータ・ソースで、Java APIが提供されています。EISデータ・ソースに対しては、サード・パーティ製およびカスタムの多くのJavaアダプタがあります。これらのAPIは、通常、非標準かつ低レベルで、JDBCに類似します。EclipseLinkのNoSQLサポートは、このようなAPIを基盤に作成され、高機能で高レベルな標準のJPA APIを提供しています。

一部のNoSQLデータ・ソースでは、JDBC APIと、SQL言語のサブセットがサポートされます。多くのサード・パーティ・ベンダーによって、EISデータ・ソース用のJDBCドライバが提供されています。EclipseLinkの通常のJPAサポートは、任意の準拠JDBCドライバで使用できます。つまり、JDBCアクセスがオプションの場合、EclipseLinkの標準JPAサポートを使用できるため、EclipseLinkのNoSQLサポートは必要ありません。

一部のNoSQLデータ・ソースでは、JCAがサポートされます。JCAは、JDBCより一般的なシステムに接続できるJava Enterprise Edition APIです。JCAは、リソース・アダプタ・レイヤーとCommon Client Interface (CCI)という2つの部分で構成されます。EclipseLinkのNoSQLおよびEISサポートは、JCA CCIに基づいています。MongoDB、Oracle NoSQL、XMLファイル、JMSおよびOracle AQについては、EclipseLinkにJCAアダプタと、EclipseLink EISPlatformクラスおよびConnectionSpecクラスが用意されています。サード・パーティのJCAアダプタも、CCIをサポートしている場合は、EclipseLinkとともに使用できます。Attunityなどのサード・パーティJCAベンダーでは、様々なEISデータ・ソース(IMS、VSAM、ADABASEなど)をサポートしています。

11.2 NoSQL永続性ユニットについて

NoSQL永続性ユニットは、JPA永続性ユニットと同じように構成します。persistence.xmlファイルを使用して、永続性ユニットを定義します。NoSQL永続性ユニットは、通常のJPA永続性ユニットと同じように、永続性を通じたアプリケーション管理、JTA管理、インジェクションまたは作成が可能です。NoSQL永続性ユニットには、必要とされる特定の永続性ユニット・プロパティがあり、一定の制限があります。

NoSQLでは、次の永続性ユニット・プロパティが定義されています。

- eclipselink.nosql.connection-spec

- eclipselink.nosql.connection-factory

- eclipselink.nosql.property

- eclipselink.target-database: これを使用してNoSQLプラットフォーム・クラスを設定するか、汎用プラットフォームに対してorg.eclipse.persistence.eis.EISPlatformを使用します。

これらのプロパティの詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の永続性プロパティの拡張機能リファレンスに関する項を参照してください。

NoSQL永続性ユニットには、次の制限があります。

- <jta-data-source>、<non-jta-data-source>: これらの要素は、JDBC DataSourcesを参照するため、サポートされません。

- JTA: JTA管理の永続性ユニットはサポートされますが、NoSQL JCAリソース・アダプタでJTAがサポートされないかぎり、XAトランザクションは提供されない場合があります。

- javax.jdbc、eclipselink.jdbc: NoSQLではJDBCを使用しないため、JDBC固有のプロパティはサポートされません。

11.2.1 NoSQLプラットフォーム用の永続性ユニット・プロパティ

NoSQLプラットフォームを使用するには、接続指定クラス名をeclipselink.nosql.connection-specに、プラットフォーム・クラス名をeclipselink.target-databaseに設定する必要があります。各NoSQLプラットフォームでは、eclipselink.nosql.propertyを使用して設定できるプラットフォーム固有のプロパティもサポートされます。MongoDB、Oracle NoSQL、XML、JMSおよびOracle AQの値の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@NoSqlに関する項を参照してください。A.3項「非SQL標準データベースのサポート: NoSQL」も参照してください。

11.3 NoSQLプラットフォームのJPAアプリケーションについて

NoSQLデータへのマッピングは、EclipseLink @NoSql注釈および<no-sql> XML要素を通じて構成します。@NoSqlでは、非リレーショナル・データへのマッピングとしてクラスを定義します。@NoSqlは、@Entityまたは@Embeddableクラスとともに指定できます。

@NoSql注釈では、dataTypeおよびdataFormat属性を定義します。dataType属性は、エンティティの構造の名前で、dataTypeの意味はNoSQLプラットフォームに依存します。MongoDBでは、これはJSON文書が格納されるコレクション名です。Oracle NoSQLでは、dataTypeは主要なキー値の最初の部分です。XMLファイル・アダプタでは、これはファイル名です。

dataFormat属性では、データが格納される場合の構造のタイプを指定します。dataFormat属性は、DataFormatType enumによって定義されます。

@NoSql注釈を使用してアプリケーションを構成する例は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@NoSqlに関する項を参照してください。

11.3.1 JPA注釈に対するマッピングの制限

NoSQLでは、ほとんどのJPA注釈がサポートされますが、一部にリレーショナル・データのマッピングとは異なる制限があります。

サポートされるマッピング注釈:

- @Entity: NoSQLデータ・ストアのルート・レベル・オブジェクトを定義します。

- @Embeddable: 別のオブジェクトのデータ構造に埋め込まれたオブジェクトを定義します。

- @Basic、@Temporal、@Enumerated、@Lob

- @Convert、@Converter、@TypeConverter、@ObjectTypeConverter

- @Access、@Transient、@Mutable

- @Id、@EmbeddedId

- @GeneratedValue、@UuidGenerator

- @Version: サポートされますが、バージョン書込み競合を検証するためにNoSQLデータ・ソースに依存します。

- @Embedded: ネストした構造として親のデータ構造に埋め込まれる参照を定義します。

- @ElementCollection: ネストした構造のリストとして親のデータ構造に埋め込まれる値または埋込み可能オブジェクトのコレクションを定義します。

- @OneToOne、@ManyToOne: ソース・オブジェクトのデータ構造に外部キーとして格納される別のルート・レベル・オブジェクトに対するリレーションシップを定義します。

- @OneToMany、@ManyToMany: ソース・オブジェクトのデータ構造に外部キーのリストとして格納される他のルート・レベル・オブジェクトのコレクションに対するリレーションシップを定義します。

- @Inheritance、@MappedSuperclass、@ClassExtractor

- @Cacheable、@Cache、@ReadOnly、@Noncacheable

- @NamedQuery: 問合せに対応するNoSQLデータ・ソースでサポートされます。

- @NamedNativeQuery: ネイティブ問合せに対応するNoSQLデータ・ソースでサポートされます。問合せ言語は、SQLではなく、NoSQLデータ・ストアに固有です。

- @EntityListeners、@PrePersist、@PreUpdate、@PreRemove、@PreLoad、@PostPersist、@PostUpdate、@PostRemove、@PostLoad

- @Customizer

サポートされないマッピング注釈:

- @Table、@SecondaryTable: オブジェクトは表にマップされないため、サポートされません(これは@NoSql注釈でdataTypeによって置換されます)。

- @Column: データは表の列に格納されないため、@Fieldを使用する必要があります(@Columnは使用できますが、単に名前が使用されます)。

- @JoinColumn: サポートされません(これは@JoinFieldによって置換されます)。

- @JoinTable: 必要ではないか、サポートされません(OneToManyおよびManyToManyは、ソース・オブジェクトのデータ構造に埋め込まれたIDのコレクションとして格納されます)。

- @CollectionTable: 必要ではないか、サポートされません(ElementCollectionは、親オブジェクトのデータ構造に埋め込まれます)。

- @MapKeyColumn、@MapKeyClass、@MapKeyJoinColumn: 現在サポートされていません。

- @OrderBy、@OrderColumn: 順序は一般的にオブジェクトのデータ構造によって管理されるため、通常は必要ではないか、サポートされません。

- @SequenceGenerator、@TableGenerator: 直接サポートされません。

- @AttributeOverride、@AssociationOverride: 継承ではサポートされますが、埋込みオブジェクトはリレーショナル・データの場合のようにフラット化されず、親オブジェクトのデータ構造でネストされるため、埋込みリレーションシップではサポートされないか、必要ではありません。

- @JoinFetch、@BatchFetch: サポートされません。

11.4 NoSQLオブジェクトのマッピングについて

NoSQLは、オブジェクトをXMLやJSONなどの構造化データにマップします。NoSQLは、埋込みデータ、埋込みコレクション、およびすべての既存のJPAマッピング注釈をサポートします。

NoSQLオブジェクトをマップするには、ID、マッピング、埋込みオブジェクト、リレーションシップおよびロックを定義する必要があります。詳細は、Oracle TopLinkのソリューション・ガイドのソリューションの実装に関する項を参照してください。

11.5 問合せおよびNoSQLプラットフォームについて

問合せがNoSQLでサポートされるかどうかは、使用しているNoSQLプラットフォームに応じて異なります。一部のNoSQLデータ・ソースでは、独自の問合せ言語を通じて動的問合せがサポートされますが、それ以外では問合せはまったくサポートされません。NoSQLでは次のタイプの問合せがサポートされます。

- JPQL問合せ

- ネイティブ問合せ

- 対話型問合せ

これらの問合せのサポートの詳細は、Oracle TopLinkのソリューション・ガイドの問合せの定義に関する項を参照してください。

11.6 トランザクションおよびNoSQLプラットフォームについて

JPAトランザクションAPIは、NoSQLデータ・ソースでサポートされます。一部のNoSQLデータ・ソースでは、トランザクションがサポートされないことがあるため、トランザクション・サポートのレベルはNoSQLプラットフォームに依存します。JTA永続性ユニットおよびトランザクションもサポートされますが、NoSQLアダプタがJTAに統合されていない場合、XAまたはトランザクション・サポートは使用できません。

NoSQLデータ・ソースでトランザクションがサポートされない場合、flush()などのデータベースの変更は、直接データベースにコミットされ、rollback()は何の効果もありません。コミット操作に失敗しても、エラーの前に書き込まれた正常な変更はロールバックされません。JPAは、通常、コミットまたはflush()がコールされるまでデータベースに書込みを行わないため、永続性コンテキストによって提供される一定レベルのトランザクション・サポートが引き続き存在します。

JPA操作のpersist()、merge()およびremove()がサポートされます。

- MongoDB: トランザクションはサポートされません。

- Oracle NoSQL: トランザクションはサポートされません。

A データベースおよびアプリケーション・サーバーのサポート

この付録では、EclipseLinkでサポートされているデータベース・プラットフォームおよびアプリケーション・サーバーについて説明します。

この付録の構成は、次のとおりです。

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

- アプリケーション・サーバーのサポート

- 非SQL標準データベースのサポート: NoSQL

A.1 データベースのサポート

EclipseLinkでは、SQLに準拠し、準拠JDBCドライバが存在する任意のリレーショナル・データベースがサポートされます。EclipseLinkは、複数のデータベース・プラットフォームに拡張サポートを提供しています。拡張サポートは、主に、ネイティブ順序付けサポート、スキーマ作成、および特定のデータベース関数の提供で構成されます。

表A-1のデータベースがサポートされます。Javaクラスは、org.eclipse.persistence.platform.databaseパッケージに含まれ、Oracle TopLink Java APIリファレンスに説明があります。

表A-1 サポートされるデータベース・プラットフォーム

データベース

Javaクラス

機能

Apache Derby

org.eclipse.persistence.platform.database.DerbyPlatform

Derby固有の動作を提供します。

Attunity

org.eclipse.persistence.platform.database.AttunityPlatform

Attunityの接続JDBCドライバと連携動作するプラットフォーム・クラス。

dBASE

org.eclipse.persistence.platform.database.DBasePlatform

次のようなdBASE固有の動作を提供します。

- TimeおよびTimestampの文字列としての書込み(dBASEではTimeまたはTimestampはサポートされません)

Firebird

org.eclipse.persistence.platform.database.FirebirdPlatform

Firebird固有の動作を提供します。

H2

org.eclipse.persistence.platform.database.H2Platform

H2固有の動作を提供します。

HyperSQL DataBase (HSQL)

org.eclipse.persistence.platform.database.HSQLPlatform

HSQL固有の動作を提供します。1.8.1以上のHSQL機能をサポートします。次のような機能があります。

- DDL作成

- IDENTITY順序付け

- SEQUENCEオブジェクト

- 関数

- ページ区切り

IBM Cloudscape

org.eclipse.persistence.platform.database.CloudscapePlatform

CloudScape DBMS固有の動作を提供します。

IBM DB2メインフレーム

org.eclipse.persistence.platform.database.DB2MainframePlatform

DB2メインフレーム固有の動作を提供します。これによって、OS390上の特定のDB2バージョンで追加の互換性が実現します。次のような機能があります。

- 専用のCONCAT構文

IBM DB2

org.eclipse.persistence.platform.database.DB2Platform

DB2固有の動作を提供します。

- スキーマ作成

- byte[]、Date、TimeおよびTimestampのネイティブSQL

- 表修飾名

- ストアド・プロシージャ

- 一時表

- キャスト

- データベース関数

- ID順序付け

- SEQUENCE順序付け

IBM Informix

org.eclipse.persistence.platform.database.InformixPlatform

次のようなInformix固有の動作を提供します。

- スキーマ作成のタイプ

- @SERIALを使用したネイティブ順序付け

Microsoft Access

org.eclipse.persistence.platform.database.AccessPlatformPlatform

Microsoft Access固有の動作を提供します。

Microsoft SQL Server

org.eclipse.persistence.platform.database.SQLServerPlatform

次のようなMicrosoft SQL Server固有の動作を提供します。

- byte[]、Date、TimeおよびTimestampのネイティブSQL

- @IDENTITYを使用したネイティブ順序付け

MySQL

org.eclipse.persistence.platform.database.MySQLPlatform

次のようなMySQL固有の動作を提供します。

- Date、TimeおよびTimestampのネイティブSQL

- ネイティブ順序付け

- スキーマ・フレームワーク用のデータベース・タイプへのクラス・タイプのマッピング

- ペシミスティック・ロック

- プラットフォーム固有の演算子

Oracle

org.eclipse.persistence.platform.database.OraclePlatform

次のようなOracle Database固有の動作を提供します。

- LOB

- NChar

- XMLType

- TIMESTAMP (TZ、LTZ)

- ネイティブのバッチ書込み

- 構造化オブジェクト・リレーショナル・データ型

- PLSQLデータ型およびストアド・プロシージャ

- VPD、RAC、プロキシ認証

- XDK XMLパーサー

- 階層選択(SELECT BY PRIOR)

- RETURNING句

- フラッシュバック履歴および問合せ

- ストアド・プロシージャ、出力パラメータおよび出力カーソル

- ストアド・ファンクション

- Oracle AQ

Oracle JavaDB

org.eclipse.persistence.platform.database.JavaDBPlatform

DerbyPlatformのシノニムとしてJavaDBPlatformを使用できます。

Oracle TimesTen

org.eclipse.persistence.platform.database.TimesTenPlatform

Oracle TimesTenデータベース固有の動作を提供します。

Oracle TimesTen7

org.eclipse.persistence.platform.database.TimesTen7Platform

Oracle TimesTen 7データベース固有の動作を提供します。

PervasivePlatform

org.eclipse.persistence.platform.database.PervasivePlatform

Pervasive PSQLに固有の動作を提供します。

PointBase

org.eclipse.persistence.platform.database.PointBasePlatform

PointBaseデータベース固有の動作を提供します。

PostgreSQL

org.eclipse.persistence.platform.database.PostgreSQLPlatform

次のようなPostgreSQLデータベース固有の動作を提供します。

- Date、TimeおよびTimestampのネイティブSQL

- ネイティブ順序付け

- スキーマ・フレームワーク用のデータベース・タイプへのクラス・タイプのマッピング

- ペシミスティック・ロック

- プラットフォーム固有の演算子

- SELECT文のLIMIT/OFFSET問合せ構文

PostgreSQL (http://wiki.eclipse.org/EclipseLink/FAQ/JPA/PostgreSQL)も参照してください。

SAP MaxDB

org.eclipse.persistence.platform.database.MaxDBPlatform

MaxDBデータベース固有の動作を提供します。

SAP SyBase SQLAnywhere

org.eclipse.persistence.platform.database.SQLAnywherePlatform

SQL Anywhere固有の動作を提供します。

Sybase

org.eclipse.persistence.platform.database.SybasePlatform

次のようなSybase固有の動作を提供します。

- byte[]、Date、TimeおよびTimestampのネイティブSQL

- @IDENTITYを使用したネイティブ順序付け

Fujitsu Symfoware

org.eclipse.persistence.platform.database.SymfowarePlatform

次のようなSymfoware固有の動作を提供します。

- DDL生成

- 外部結合

- 副問合せ(制限付き)

- ストアド・プロシージャ・コール

- ストアド・プロシージャ生成

- ネイティブ順序付け/識別子フィールド

- JPAバルク更新/削除(制限付き)

- バッチ読取り

- バッチ書込み

- ペシミスティック・ロック(制限付き)

- 最初の結果/制限(制限付き)

- 式フレームワーク(制限付き)

- デリミタ

- 自動検出

EclipseLinkを拡張して、他のプラットフォームの拡張サポートを追加することも可能です。EclipseLinkインキュベータ・プロジェクトには、複数のユーザー提供プラットフォームもあります。「Platform Incubator」を参照してください。

http://wiki.eclipse.org/EclipseLink/Development/Incubator/Platform

A.2 アプリケーション・サーバーのサポート

EclipseLinkは、EclipseLink APIを通じてソフトウェア要件に一致する任意のJava EEアプリケーション・サーバーとともに使用できます。

表A-2に、EclipseLinkによって統合サポートが提供されるアプリケーション・サーバーを示します。表に示されているクラスは、サーバー固有の動作を表す役割を持つEclipseLink org.eclipse.persistence.platform.server.ServerPlatformBaseクラスの具象サブクラスです。これらのクラスによって、サーバーの次の動作が決定されます。

- 使用する外部トランザクション・コントローラ

- JTAの有効化の有無(外部トランザクション制御)

- ランタイム・サービスを登録または登録解除する方法(JMXまたはMBean)

- ランタイム・サービスの有効化の有無

- コンテナ・スレッドの起動方法

表に示されているJavaクラスの詳細は、Oracle TopLink Java APIリファレンスを参照してください。

表A-2 サポートされるアプリケーション・サーバー

サーバー名

Javaクラス

IBM WebSphere Application Server

- org.eclipse.persistence.platform.server.was.WebSphere_6_1_Platform

- org.eclipse.persistence.platform.server.was.WebSphere_7_Platform

- org.eclipse.persistence.platform.server.was.WebSpherePlatform

JBoss Application Server

- org.eclipse.persistence.platform.server.jboss.JBossPlatform

Oracle Containers for J2EE (OC4J)

- org.eclipse.persistence.platform.server.oc4j.Oc4jPlatform

Oracle Sun Application Server

- org.eclipse.persistence.platform.server.sunas

Oracle WebLogic Server

- org.eclipse.persistence.platform.server.wls.WebLogic_10_Platform

- org.eclipse.persistence.platform.server.wls.WebLogic_9_Platform

- org.eclipse.persistence.platform.server.wls.WebLogicPlatform

SAP NetWeaver Application Server

- org.eclipse.persistence.platform.server.sap.SAPNetWeaver_7_1_Platform

A.2.1 アプリケーション・サーバーのJAXBプロバイダとしてのEclipseLink MOXy

EclipseLink MOXyは、GlassFishおよびWebLogicアプリケーション・サーバーにJAXBプロバイダとして統合されます。詳細は、次のリンクを参照してください。

- GlassFish Server: http://blog.bdoughan.com/2012/02/glassfish-312-is-full-of-moxy.html

- WebLogic Server: http://blog.bdoughan.com/2011/12/eclipselink-moxy-is-jaxb-provider-in.html

A.3 非SQL標準データベースのサポート: NoSQL

EclipseLink JPAは、NoSQLデータベースとともに使用できます。Javaクラスは、@NoSQL注釈または<no-sql> XML要素を使用してNoSQLデータ・ソースにマップできます。

EclipseLinkでは、レガシー・データベースおよびシステム(CICS、ADA、VSAM、IMS、MQ、AQ)などのEIS (Enterprise Information Systems)に対して、JPAアクセスも提供します。

EclipseLinkのNoSQLサポートによって、複雑な階層データをマップできます(JSONなどのXMLの索引付き階層型マップ済データを含む)。CRUD操作、埋込みオブジェクトとコレクション、継承およびリレーションシップがサポートされます。JPQLのサブセットとCriteria APIは、NoSQLデータベースの問合せサポートに応じてサポートされます。

また、独自のEISPlatformサブクラスとJCAアダプタを定義して、他のNoSQLデータ・ソースにサポートを追加することもできます。EclipseLinkインキュベータ・プロジェクトには、複数のユーザー提供プラットフォームもあります。次のURLの「Platform Incubator」を参照してください。

http://wiki.eclipse.org/EclipseLink/Development/Incubator/Platform

表A-3に、EclipseLinkによってサポートされるNoSQLおよびEISデータ・ソースを示します。表に示されているJavaクラスの詳細は、Oracle TopLink Java APIリファレンスを参照してください。

表A-3 サポートされるNoSQLおよびEISプラットフォーム

データ・ソース

Javaクラス

機能

MongoDB

org.eclipse.persistence.nosql.adapters.mongo.MongoPlatform

次のようなMongoDBサポートを提供します。

- MAPPED JSONデータ

- JPQLおよび基準問合せ

- ネイティブ問合せ

- READ_PREFERENCE、WRITE_CONCERN、OPTIONS、SKIP、LIMIT、BATCH_SIZEのヒント

Oracle NoSQL

org.eclipse.persistence.nosql.adapters.nosql.OracleNoSQLPlatform

次のようなOracle NoSQLサポートを提供します。

- MAPPEDキー/値データ

- XMLデータ

- find()およびSELECTのすべての問合せ

- CONSISTENCY、DURABILITY、TIMEOUT、VERSIONのヒント

XMLファイル

org.eclipse.persistence.eis.adapters.xmlfile.XMLFilePlatform

XMLファイルに次のような永続性のサポートを提供します。

- XMLデータ

- find()およびSELECTのすべての問合せ

- XPathインタラクション

JMS

org.eclipse.persistence.eis.adapters.jms.JMSPlatform

JMSメッセージを通じて永続性のサポートを提供します。

- XMLデータ

- send/receive操作

Oracle AQ

org.eclipse.persistence.eis.adapters.aq.AQPlatform

Oracle AQメッセージを通じて永続性のサポートを提供します。

- XMLデータ

- enqueue/dequeue操作