データ・アクセスの理解

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

EclipseLinkのトランザクション・データ・ソースは、接続プールがトランザクション・サービス(アプリケーション・サーバー制御トランザクションやJTAトランザクションなど)によって管理される場合、外部管理されます。

JTA管理のデータ・ソースまたは接続プールは、一般的にJava EEアプリケーションで使用され、通常はEJBアプリケーションで必要になります。外部管理の接続プールは、次のように使用します。

ExternalTransactionControllerを使用するようにセッションを構成し、EclipseLinkの永続性ユニットを外部トランザクション・サービスに統合します。eclipselink.target-server永続性ユニット・プロパティを使用して、ExternalTransactionControllerインタフェースを実装するクラスの名前を構成します。
永続性ユニットのブール型オプションexternal-transaction-controllerを使用して、トランザクションがトランザクション・マネージャーにより管理されており、EclipseLinkが管理できないことを示します。また、データ・ソースがトランザクションをサポートしていない場合、接続のログインを指定し、接続が外部コントローラによって保持されていることをEclipseLinkに通知するために使用します。
状況によっては、トランザクションのオーバーヘッドを回避するために、JTA以外の接続プールを使用するようにEclipseLinkの読取り接続プールまたはシーケンス接続プールを構成する必要があります。詳細は、「デフォルト(書込み)および読取り接続プール」および「シーケンス接続プール」を参照してください。

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

セッションに関連付けられたログイン(存在する場合)によって、EclipseLinkランタイムがプロジェクトのデータ・ソースに接続する方法が決まります。

データ・ソースに永続化しないプロジェクトの場合、ログインは必要ありません。データ・ソースに永続化するプロジェクトの場合、ログインは常に必要です。ログインには、認証、接続プールの使用、および外部トランザクション・コントローラの使用などのデータ・ソース・アクセスの詳細が含まれます。Loginは、データ・ソース・プラットフォームを所有します。

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

ログインは様々なロールで使用できます。ログインのロールにより、ログインを作成する場所と方法が決まります。選択するログインのロールは、作成対象のプロジェクトのタイプやログインの使用目的によって異なります。

データ・ソースに永続化するプロジェクト・タイプごとに、独立したセッション・ログイン・タイプがあります。

XMLログインは存在しません。EclipseLink XMLプロジェクトはXMLデータ・トランスフォーメーションに対する非永続的なインメモリー・オブジェクト用として使用されるため、ログインするデータ・ソースは存在しません。

リレーショナル・データベースにアクセスするプロジェクトを作成する場合、DatabaseLoginを使用してプロジェクトを構成する必要があります。DatabasePlatformでの選択により、プロジェクトを特定のタイプのデータベース向けにさらにカスタマイズすることができます。永続性ユニット・オプションdatasource-loginを通じて構成できます。このオプションには、ユーザー名、パスワード、データ・ソース・プラットフォームを実装しているクラスの名前などを構成するための属性が含まれます。

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

EclipseLinkは、データ・ソース・プラットフォームのクラスを使用して基礎となるデータ・ソースの詳細を抽出します。

データ・ソース・プラットフォームは、プロジェクトのLoginによって所有されます。データベース・プラットフォームは、すべてのセッションに対してプロジェクト・レベルで指定するか、このプロジェクト・レベルの構成をセッション・レベルでオーバーライドします。

ほとんどのプラットフォーム・オプションを構成するには、修正メソッドまたはpreLoginイベント・リスナーを使用する必要があります。

EclipseLinkでは、Structured Query Language (SQL)を使用してデータベースと対話します。各データベース・プラットフォームでは、基本SQL言語の独自のバリエーションが使用されるため、EclipseLinkでは、データベースとの通信に使用するSQLを調整し、アプリケーションが円滑に実行されるようにする必要があります。

選択するデータベース・プラットフォームのタイプによって、使用されるJava Database Connectivity (JDBC)ドライバのタイプなど、EclipseLinkランタイムがデータベースにアクセスする場合の特定の手段が決定されます。JDBCは、Javaアプリケーションによるデータベースへのアクセスを可能にするアプリケーション・プログラミング・インタフェース(API)です。EclipseLinkリレーショナル・プロジェクトは、データベースを対象にオブジェクトの読取りや書込みを行うために、JDBC接続に依存します。EclipseLinkアプリケーションでは、アプリケーション・アーキテクチャに応じて個別のJDBC接続を使用するか、JDBC接続プールを使用します。

DataPlatformクラスはデータベース・プラットフォーム(Oracle、Sybase、DBaseなど)固有の動作をカプセル化し、この動作にEclipseLinkがアクセスするためのプロトコルを提供します

EclipseLinkには、ターゲット・データベースに応じてプロジェクトをカスタマイズするために様々なデータベース固有のプラットフォームが用意されています。サポートされているデータベース・プラットフォームのリストについては、org.eclipse.persistence.config.TargetDatabaseクラスおよび「データベースのサポート」を参照してください。

サポートされているアプリケーション・サーバーのリストについては、org.eclipse.persistence.config.TargetServerおよび「アプリケーション・サーバーのサポート」を参照してください。使用するアプリケーション・サーバーの名前は、eclipselink.target-server.persistenceユニット・プロパティで指定できます。

datasource-login永続性ユニット・オプションには、ユーザー名、パスワード、接続プーリングなどの構成可能なその他のデータ・ソース・プロパティが含まれます。Loginクラスを実装し、データベースに固有のプロパティを設定できます。

単純なJDBC認証

ユーザー名とパスワードを使用してEclipseLinkデータベース・ログインを構成すると、EclipseLinkでは、アプリケーションで使用するように構成されているJDBCドライバにこれらの資格証明が提供されます。

デフォルトでは、EclipseLinkではpersistence.xmlファイルからパスワードが読み取られます。

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構成を簡略化する。

監査

選択する認証のタイプとは関係なく、EclipseLinkは、すべてのデータベース操作に関連するユーザーの名前をログに記録します。

例7-1は、CONFIGレベルのEclipseLinkログを示し、ServerSessionがサンプル・ユーザーscottのメイン接続を介して接続し、ClientSessionがプロキシ接続jeffを使用しています

データベース・サーバーによっては、別のユーザー監査オプションが用意されている場合があります。詳細は、データベース・サーバーのドキュメントを参照してください。

または、監査目的でデータベース・スキーマと組み合せてEclipseLink永続性ユニットを使用することも検討してください。

例7-1 Oracle Databaseのプロキシ認証のログ

[EclipseLink 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)) 
[EclipseLink Config]--ServerSession(13)--Connection(34)--Thread(Thread[main,5,main])--Connected: jdbc:oracle:thin:@localhost:1521:orcl User: SCOTT 
[EclipseLink 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)) 
[EclipseLink Config]--ClientSession(53)--Connection(56)--Thread(Thread[main,5,main])--Connected: jdbc:oracle:thin:@localhost:1521:orcl User: jeff

認証について

認証は、データ・ソースがユーザーのアイデンティティを検証し、そのユーザーに特定のアクションを実行するために十分な権限があるかどうかを確認するための手段です。

認証は、データ・セキュリティ、ユーザーのアカウンタビリティおよび監査において中心的な役割を果たします。

2層アプリケーションの場合、通常は単純なJDBC認証で十分です。

トピック

単純なJDBC認証

ユーザー名とパスワードを使用してEclipseLinkデータベース・ログインを構成すると、EclipseLinkでは、アプリケーションで使用するように構成されているJDBCドライバにこれらの資格証明が提供されます。

デフォルトでは、EclipseLinkではpersistence.xmlファイルからパスワードが読み取られます。

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構成を簡略化する。

監査

選択する認証のタイプとは関係なく、EclipseLinkは、すべてのデータベース操作に関連するユーザーの名前をログに記録します。

例7-1は、CONFIGレベルのEclipseLinkログを示し、ServerSessionがサンプル・ユーザーscottのメイン接続を介して接続し、ClientSessionがプロキシ接続jeffを使用しています

データベース・サーバーによっては、別のユーザー監査オプションが用意されている場合があります。詳細は、データベース・サーバーのドキュメントを参照してください。

または、監査目的でデータベース・スキーマと組み合せてEclipseLink永続性ユニットを使用することも検討してください。

例7-2 Oracle Databaseのプロキシ認証のログ

[EclipseLink 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)) 
[EclipseLink Config]--ServerSession(13)--Connection(34)--Thread(Thread[main,5,main])--Connected: jdbc:oracle:thin:@localhost:1521:orcl User: SCOTT 
[EclipseLink 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)) 
[EclipseLink Config]--ClientSession(53)--Connection(56)--Thread(Thread[main,5,main])--Connected: jdbc:oracle:thin:@localhost:1521:orcl User: jeff

接続について

接続は、アプリケーションで使用するように構成されたドライバを介してデータ・ソースにアクセスする方法を提供するオブジェクトです。リレーショナル・プロジェクトでは、JDBCを使用してデータ・ソースに接続し、EISプロジェクトではJCAを使用します。EclipseLinkでは、インタフェースorg.eclipse.persistence.internal.databaseaccess.Accessorを使用してデータ・ソース接続をラップします。このインタフェースは、特定のイベントからアクセス可能です。

通常、サーバー・セッションを使用する場合、EclipseLinkは、読取りと書込みの両方に対して異なる接続を使用します。このため、読取りには非トランザクション接続を使用し、必要ない場合は接続を維持しないようにできます。

デフォルトでは、EclipseLinkサーバー・セッションは、接続を遅延して(永続性ユニットのコミット操作時にのみ)取得します。または、クライアント・セッションの取得時に書込み接続を取得するようにEclipseLinkを構成できます。

接続は、内部または外部の接続プールから割り当てることができます。

接続プールについて

接続プールは、1つ以上のクライアントのかわりにデータ・ソース接続の共有コレクション(プール)を作成および保持するサービスです。

接続プールは、リクエストに基づいてプロセスに接続を提供し、プロセスが接続の使用を終了すると、接続をプールに返します。接続は、プールに返されると、他のプロセスで使用できます。データ・ソースへの接続の確立には時間がかかるため、接続プールのこのような接続を再使用してパフォーマンスを向上できます。

EclipseLinkは、接続プールを使用して、サーバーおよびクライアント・セッションで使用される接続を管理および共有します。この機能により、必要な接続数が減り、アプリケーションで多くのクライアントをサポートできるようになります。

EclipseLinkで提供される内部接続プール、またはJDBCドライバまたはJava EEコンテナで提供される外部接続プールを使用するようにセッションを構成できます。

EclipseLinkアプリケーションの接続プールは、読取り、書込み、順序付け、およびその他のアプリケーション固有の機能などの様々な目的に使用できます。

トピック

内部接続プール

Java EE以外のアプリケーションでは、通常、内部接続プールを使用します。デフォルトでは、EclipseLinkセッションは内部接続プールを使用します。

内部接続プールを使用して、デフォルト(書込み)および読取り接続プールを構成できます。オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。

内部接続プールでは、表示専用でデータの変更が頻繁ではないデータを読み取るアプリケーション用の読取り接続の作成を最適化できます。また、ワークベンチを使用して、デフォルト(書込み)および読取りの接続プールを構成したり、オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。

外部接続プール

外部接続プールとは、JDBCドライバまたはJava EEコンテナによって提供される、単一データ・ソースへの再利用可能な接続の集合です。

Java EEアプリケーションでは、通常、外部接続プールを使用します。

外部トランザクション・コントローラ(JTA)を使用する場合、外部接続プールを使用してJTAと統合する必要があります。

外部接続プールを使用して、Javaを通じてデフォルト(書込み)および読取りの接続プールを構成したり、オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。

外部接続プールを使用すると、EclipseLinkアプリケーションで次のことが可能になります。

Java EE対応システムへの統合
JTAトランザクションとの統合(JTAトランザクションはJTA対応のデータ・ソースを必要とします)
複数のアプリケーションが同じデータ・ソースを使用する、共有接続プールの活用
構成と管理が直接サーバーで行われるデータ・ソースの使用

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

サーバー・セッションでは、読取り接続プールと書込み接続プールが提供されます。

これらは異なるプールとするか、または(外部接続プーリングを使用する場合は)同じ接続プールとすることが可能です。

すべての読取り問合せは読取り接続プールからの接続を使用し、データ・ソースに変更を書き込むすべての問合せは書込み接続プールからの接続を使用します。デフォルト(書込み)および読取り接続プールの属性を構成できます。

新規接続が確立されるたびに、セッションのDatasourceLoginに指定した接続構成がEclipseLinkにより使用されます。また、外部トランザクション・コントローラを使用する場合、必要に応じて読取り接続プールごとに個別の接続構成を定義することにより、余計なオーバーヘッドが発生しないようにできます。

connection-pool.readプロパティを使用して、非トランザクション読取り問合せ用の読取り接続プールを構成します。デフォルトで、EclipseLinkでは、読取り問合せにデフォルト・プールが使用され、独立した読取り接続プールは使用されません。詳細は、『Java Persistence API (JPA) Extensions Reference for EclipseLink』の「connection-pool.read」を参照してください。

シーケンス接続プール

オブジェクト・アイデンティティを保持するうえで重要なのは、各インスタンスを区別するために一意の値の割当ての順序付け管理をすることです

詳細は、「キャッシュのタイプとサイズについて」を参照してください。

順序付けには、データ・ソースによって管理される特別な順序リソースの読取りと書込みが含まれます。

デフォルトで、EclipseLinkには個別トランザクションの順序操作が含まれます。これによって、順序リソースのデッドロックを発生させる可能性のある書込みトランザクション中の複雑な操作を回避します。ただし、外部トランザクション・コントローラ(JTAデータ・ソースや接続プールなど)を使用する場合、EclipseLinkでは、順序付けで異なるトランザクションを使用できません。シーケンス接続プールを使用して、順序付け用に非JTAトランザクション・プールを構成します。これは、(ネイティブ順序付けではなく)表の順序付けの場合にのみ必要です。

各サーバー・セッションで、EclipseLinkが順序付け用に排他的に使用する、シーケンス接続プールと呼ばれる1つの接続プールを作成できます。シーケンス接続プールによって、EclipseLinkは、リクエストの取得元であるトランザクションの外部にある新しいオブジェクト識別子に対するリクエストに対応できます。これによって、EclipseLinkは、順序リソースに対する更新を即座にコミットし、デッドロックを回避できます。

注意:

シーケンス接続プールの使用時に元のトランザクションが失敗しても、順序操作はロールバックされません。

次のような場合は、シーケンス接続プールを使用する必要があります。

表の順序付け(非ネイティブ順序付け)を使用する場合。
外部トランザクション・コントローラ(JTA)を使用する場合。

次のような場合は、シーケンス接続プールを使用しないようにする必要があります。

順序付けを使用しないか、データ・ソースのネイティブ順序付けを使用する場合。
デッドロックを回避するために順序表を構成した場合。
非JTAデータ・ソースを使用する場合。

永続性ユニット・プロパティeclipselink.connection-pool.sequenceを使用して、シーケンス接続プールを構成できます。このプロパティにより、接続プールは生成されたIDを割り当てることができ、また、このプロパティはTABLEの順序付けのためにのみ必要になります。デフォルトで、EclipseLinkでは、順序付けにはデフォルト・プールが使用され、独立したシーケンス接続プールは使用されません。詳細は、『Java Persistence API (JPA) Extensions Reference for EclipseLink』の「connection-pool.sequence」を参照してください。

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

セッションでEclipseLinkの内部接続プールを使用する場合、アプリケーションの任意の目的のために使用できる1つ以上の接続プールを作成できます。

これらは名前付き接続プールと呼ばれ、名前を自由に付け、任意の目的のために使用できます。

通常、これらの名前付き接続プールを使用して、様々なセキュリティ・レベルのプールを提供します。たとえば、デフォルト接続プールの場合は特定の表にのみアクセスできますが、管理接続プールの場合はすべての表にアクセスできます。

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

データ・パーティション化によって、アプリケーションはそのデータを複数のデータベース・マシンにスケーリングできます。

データ・パーティション化の詳細は、『Solutions Guide for EclipseLink』の「Using Data Partitioning to Scale Data」を参照してください。

一部のデータベースでは、複数のマシン全体にわたるデータベースのクラスタリングがサポートされます。Oracle RACでは、単一のデータベースを複数の異なるサーバー・ノードに拡張できます。Oracle RACでは、表およびノードでデータのパーティション化もサポートされます。データベース・クラスタでは、クラスタ内の任意のノードからどのデータにもアクセスできます。ただし、特定のノードへのデータ・アクセスをパーティション化する方が、ノード間通信が減少するため、通常はより効率的です。詳細は、『Solutions Guide for EclipseLink』の「Clustered Databases and Oracle RAC」を参照してください。

テナント分離について

EclipseLinkでは、テナントを分離する機能の設計および実装をかなり柔軟にできます。

Eclipselinkには次が含まれています。

アプリケーションの分離オプション

コンテナ/サーバーの分離
同じコンテナ/サーバー内でアプリケーションを分離
同じアプリケーション内でエンティティ・マネージャ・ファクトリおよび共有キャッシュを分離
エンティティ・マネージャごとにテナントは分離し、エンティティ・マネージャ・ファクトリは共有

データの分離オプション

データベースの分離
スキーマ/表領域の分離
表の分離
表は共有し列を分離
問合せのフィルタリング
Oracle Virtual Private Database(VPD)

EclipseLinkには、データ・ソースでマルチテナンシを提供する次のオプションがあります。

単一表マルチテナントでは、テナントは表を共有できます。各テナントには、識別子列によって識別される独自の行があり、それらの行は他のテナントからは認識できません。「単一表マルチテナント」を参照してください。
テナントごとの表マルチテナントでは、各テナントは表テナント識別子で識別される独自の表を持ち、それらの表は他のユーザーは参照できません。「」を参照してください。
(VDP)マルチテナントでは、テナントは同じ表を共有する複数のテナントをサポートする機能を持つVDPデータベースを使用します。「」を参照してください。

単一表マルチテナント

単一表マルチテナントでは、エンティティまたはマップ済のスーパークラスがマップされるすべての表(TableまたはSecondaryTable)に、複数のテナント用の行を含めることができます。

テナントに固有の行へのアクセスは、指定のテナントに制限されています。

テナント固有の行は、1つ以上のテナント識別子列を使用してテナントに関連付られています。識別子列には、どのような永続性コンテンツがアクセスできるか制限するアプリケーション・コンテキスト値が使用されています。

マップされた表での問合せの結果は、プロパティ値として提供されるテナント識別子値に制限されます。これは、表のすべての挿入、更新および削除操作に適用されます。マルチテナントのメタデータがマップ済のスーパークラス・レベルで適用されると、独自のマルチテナント・メタデータを指定しないかぎり、すべてのサブエンティティに適用されます。

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

テナントごとの表マルチテナントでは、テナント独自の1つ以上の表に、アプリケーションの複数のテナントはデータを分離できます。

複数のテナントの表は、名前に接頭辞または接尾辞が使用して区別して共有スキーマに含めるか、テナント固有の別のスキーマに含めることができます。テナントごとの表エンティティは、同じ永続性ユニットに他のタイプのマルチテナント・エンティティと混在させることができます。

テナントごとの表マルチテナント・タイプは次とともに使用します。

識別子の種類を指定するテナント表識別子(接頭辞または接尾辞付きのスキーマまたは名前)
ユーザーを識別するテナントID(永続性ユニットごとにテナントごとの表を分離する場合、エンティティ・マネージャごとに構成するか、エンティティ・マネージャ・ファクトリで構成)

単一のアプリケーション・インスタンスで永続性ユニットのEntityManagerFactoryが共有されている場合、複数のテナントのリクエストを処理できます。

またはテナントごとに、別のEntityManagerFactoryインスタンスを使用することも可能です。(これはテナントごとに拡張を使用する場合に必要です。)この場合、テナント固有のスキーマおよび表明は、eclipselink-orm.xml構成ファイルに定義します。永続性ユニットにMetadataSourceを登録する必要があります。MetadataSourceは、アプリケーション外から提供されるその他の永続性ユニット・メタデータをサポートするために使用します。『Java Persistence API (JPA) Extensions Reference for EclipseLink』の「metadata-source」も参照してください。

テナントごとの表マルチテナント・タイプでは、個々のテナント表をエンティティ・レベルで使用することができます。トランザクションの開始後、各エンティティ・マネージャでテナントのコンテキスト・プロパティを提供する必要があります。

エンティティの表(TableおよびSecondaryTable)は、テナントのコンテキストに基づく、テナントの個別の表です。結合またはコレクション表を使用するエンティティ内のリーションシップも、テナントごとの表のコンテキスト内に存在することが前提となっています。
マルチテナントのメタデータは、SINGLE_TABLEまたはJOINED継承戦略の使用時には、継承階層のルート・レベルでしか適用できません。マルチテナント・メタデータは、TABLE_PER_CLASS継承階層内に指定できます。

テナントごとの表マルチテナントの構築の詳細は、『Solutions Guide for EclipseLink』の「Using Table-Per-Tenant Multi-Tenancy」を参照してください。

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マルチテナントの構築の詳細は、『Solutions Guide for EclipseLink』の「Using VPD Multi-Tenancy」を参照してください。

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

現在のリリースでは、複数の書込みのあるトランザクションを最適化するための永続性ユニット・プロパティが用意されています。

eclipselink.jdbc.batch-writingプロパティは、バッチ書込みの使用を構成して、複数の書込みのあるトランザクションを最適化します。バッチ書込みを使用すると、複数の異機種間の動的SQL文を、1つの実行としてデータベースに送信することや、複数の異機種間のパラメータ化されたSQL文を、1つのバッチ実行として実行できます。すべてのJDBCドライバやデータベースがバッチ書込みをサポートしているとはかぎらないことに注意してください。

eclipselink.jdbc.batch-writing.sizeプロパティは、バッチ書込みに使用するバッチ・サイズを構成します。パラメータ化されたバッチ書込みの場合、この値にはバッチにする文の数を指定します(デフォルト: 100)。動的バッチ書込みの場合、この値はバッチの対象となるSQLバッファのサイズで、デフォルトは32kです。

バッチ書込みによる修正問合せのバッチ処理が可能な場合、eclipselink.jdbc.batch-writing永続性プロパティを問合せヒントとともに使用して構成することができます。一部のデータベースのDDLなど、問合せのタイプによってはバッチ処理ができない場合があります。バッチ書込みを無効にすると、行カウントを戻すこともできます。