| Oracle® Fusion Middleware Oracle TopLinkの理解 12c (12.1.3) E56235-01 |
|
 前 |
 次 |
この章では、セッションの最も重要な機能の1つ、データ・ソースへのアクセスの提供について説明します。この章では、セッション内のデータ・アクセスの背後にある、EclipseLinkに特有の概念について説明します。
この章の内容は次のとおりです。
EclipseLinkのトランザクション・データ・ソースは、接続プールがトランザクション・サービス(アプリケーション・サーバー制御トランザクションやJTAトランザクションなど)によって管理される場合、外部管理されます。JTA管理のデータ・ソースまたは接続プールは、一般的にJava EEアプリケーションで使用され、通常はEJBアプリケーションで必要になります。外部管理の接続プールは、次のように使用します。
ExternalTransactionControllerを使用するようにセッションを構成し、EclipseLinkの永続性ユニットを外部トランザクション・サービスに統合します。eclipselink.target-server persistenceユニット・プロパティを使用して、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接続プールを使用します。
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クラスを実装し、データベースに固有のプロパティを設定できます。
認証は、データ・ソースがユーザーのアイデンティティを検証し、そのユーザーに特定のアクションを実行するために十分な権限があるかどうかを確認するための手段です。認証は、データ・セキュリティ、ユーザーのアカウンタビリティおよび監査において中心的な役割を果たします。
2層アプリケーションの場合、通常は単純なJDBC認証で十分です。
次の項では、異なる認証戦略について説明します。
ユーザー名とパスワードを使用してEclipseLinkデータベース・ログインを構成すると、EclipseLinkでは、アプリケーションで使用するように構成されているJDBCドライバにこれらの資格証明が提供されます。
デフォルトでは、EclipseLinkではpersistence.xmlファイルからパスワードが読み取られます。
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を使用しています。
例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永続性ユニットを使用することも検討してください。
接続は、アプリケーションで使用するように構成されたドライバを介してデータ・ソースにアクセスする方法を提供するオブジェクトです。リレーショナル・プロジェクトでは、JDBCを使用してデータ・ソースに接続し、EISプロジェクトではJCAを使用します。EclipseLinkでは、インタフェースorg.eclipse.persistence.internal.databaseaccess.Accessorを使用してデータ・ソース接続をラップします。このインタフェースは、特定のイベントからアクセス可能です。
通常、サーバー・セッションを使用する場合、EclipseLinkは、読取りと書込みの両方に対して異なる接続を使用します。このため、読取りには非トランザクション接続を使用し、必要ない場合は接続を維持しないようにできます。
デフォルトでは、EclipseLinkサーバー・セッションは、接続を遅延して(永続性ユニットのコミット操作時にのみ)取得します。または、クライアント・セッションの取得時に書込み接続を取得するようにEclipseLinkを構成できます。
接続は、内部または外部の接続プールから割り当てることができます。
接続プールは、1つ以上のクライアントのかわりにデータ・ソース接続の共有コレクション(プール)を作成および保持するサービスです。接続プールは、リクエストに基づいてプロセスに接続を提供し、プロセスが接続の使用を終了すると、接続をプールに返します。接続は、プールに返されると、他のプロセスで使用できます。データ・ソースへの接続の確立には時間がかかるため、接続プールのこのような接続を再使用してパフォーマンスを向上できます。
EclipseLinkは、接続プールを使用して、サーバーおよびクライアント・セッションで使用される接続を管理および共有します。この機能により、必要な接続数が減り、アプリケーションで多くのクライアントをサポートできるようになります。
EclipseLinkで提供される内部接続プール、またはJDBCドライバまたはJava EEコンテナで提供される外部接続プールを使用するようにセッションを構成できます。
EclipseLinkアプリケーションの接続プールは、読取り、書込み、順序付け、およびその他のアプリケーション固有の機能などの様々な目的に使用できます。
この項では、次の接続プールのタイプについて説明します。
Java EE以外のアプリケーションでは、通常、内部接続プールを使用します。デフォルトでは、EclipseLinkセッションは内部接続プールを使用します。
内部接続プールを使用して、デフォルト(書込み)および読取り接続プールを構成できます。オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。
内部接続プールでは、表示専用でデータの変更が頻繁ではないデータを読み取るアプリケーション用の読取り接続の作成を最適化できます。また、ワークベンチを使用して、デフォルト(書込み)および読取りの接続プールを構成したり、オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。
Java EEアプリケーションでは、通常、外部接続プールを使用します。外部接続プールとは、JDBCドライバまたはJava EEコンテナによって提供される、単一データ・ソースへの再利用可能な接続の集合です。
外部トランザクション・コントローラ(JTA)を使用する場合、外部接続プールを使用してJTAと統合する必要があります。
外部接続プールを使用して、Javaを通じてデフォルト(書込み)および読取りの接続プールを構成したり、オブジェクト・アイデンティティまたは他の目的のために追加の接続プールを作成することもできます。
外部接続プールを使用すると、EclipseLinkアプリケーションで次のことが可能になります。
Java EE対応システムへの統合
JTAトランザクションとの統合(JTAトランザクションはJTA対応のデータ・ソースを必要とします)
複数のアプリケーションが同じデータ・ソースを使用する、共有接続プールの活用
構成と管理が直接サーバーで行われるデータ・ソースの使用
サーバー・セッションでは、読取り接続プールと書込み接続プールが提供されます。これらは異なるプールとするか、または(外部接続プーリングを使用する場合は)同じ接続プールとすることが可能です。
すべての読取り問合せは読取り接続プールからの接続を使用し、データ・ソースに変更を書き込むすべての問合せは書込み接続プールからの接続を使用します。デフォルト(書込み)および読取り接続プールの属性を構成できます。
新規接続が確立されるたびに、セッションのDatasourceLoginに指定した接続構成がEclipseLinkにより使用されます。また、外部トランザクション・コントローラを使用する場合、必要に応じて読取り接続プールごとに個別の接続構成を定義することにより、余計なオーバーヘッドが発生しないようにできます。
connection-pool.readプロパティを使用して、非トランザクション読取り問合せ用の読取り接続プールを構成します。デフォルトで、EclipseLinkでは、読取り問合せにデフォルト・プールが使用され、独立した読取り接続プールは使用されません。詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のconnection-pool.readを参照してください。
オブジェクト・アイデンティティを保持するうえで重要なのは、各インスタンスを区別するために一意の値の割当ての順序付け管理をすることです。詳細は、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を参照してください。
セッションでEclipseLinkの内部接続プールを使用する場合、アプリケーションの任意の目的のために使用できる1つ以上の接続プールを作成できます。これらは名前付き接続プールと呼ばれ、名前を自由に付け、任意の目的のために使用できます。
通常、これらの名前付き接続プールを使用して、様々なセキュリティ・レベルのプールを提供します。たとえば、デフォルト接続プールの場合は特定の表にのみアクセスできますが、管理接続プールの場合はすべての表にアクセスできます。
データ・パーティション化によって、アプリケーションはそのデータを複数のデータベース・マシンにスケーリングできます。データ・パーティション化の詳細は、Oracle TopLinkのソリューション・ガイドのデータのスケールのためのデータ・パーティション化に関する項を参照してください
一部のデータベースでは、複数のマシン全体にわたるデータベースのクラスタリングがサポートされます。Oracle RACでは、単一のデータベースを複数の異なるサーバー・ノードに拡張できます。Oracle RACでは、表およびノードでデータのパーティション化もサポートされます。データベース・クラスタでは、クラスタ内の任意のノードからどのデータにもアクセスできます。ただし、特定のノードへのデータ・アクセスをパーティション化する方が、ノード間通信が減少するため、通常はより効率的です。詳細は、Oracle TopLinkのソリューション・ガイドのクラスタ化データベースおよびOracle RACに関する項を参照してください。
Oracle TopLinkでは、アプリケーションを1つ開発し、それを別の複数のクライアント(つまりテナント)に、アプリケーションの割合、データの分離度およびテナントに固有の機能を変えてデプロイできます。たとえば、規模の大きな企業が1つの給与アプリケーションを、複数の部門で使用するよう開発したとします。各部門は、独自のデータと共有データにアクセスできますが、他の部門のデータはまったく参照することができません。
EclipseLinkでは、テナントを分離する機能の設計および実装をかなり柔軟にできます。次などが可能です。
アプリケーションの分離オプション
コンテナ/サーバーの分離
同じコンテナ/サーバー内でアプリケーションを分離
同じアプリケーション内でエンティティ・マネージャ・ファクトリおよび共有キャッシュを分離
エンティティ・マネージャごとにテナントは分離し、エンティティ・マネージャ・ファクトリは共有
データの分離オプション
データベースの分離
スキーマ/表領域の分離
表の分離
表は共有し列を分離
問合せのフィルタリング
Oracle Virtual Private Database (VPD)
EclipseLinkには、データ・ソースでマルチテナンシを提供する次のオプションがあります。
単一表マルチテナントでは、テナントは表を共有できます。各テナントには、識別子列によって識別される独自の行があり、それらの行は他のテナントからは認識できません。7.8.1項「単一表マルチテナント」を参照してください。
テナントごとの表マルチテナントでは、各テナントは表テナント識別子で識別される独自の表を持ち、それらの表は他のユーザーは参照できません。7.8.2項「テナントごとの表マルチテナントの使用」を参照してください。
(VDP)マルチテナントでは、テナントは同じ表を共有する複数のテナントをサポートする機能を持つVDPデータベースを使用します。7.8.3項「VPDマルチテナント」を参照してください。
単一表マルチテナントでは、エンティティまたはマップ済のスーパークラスがマップされるすべての表(TableまたはSecondaryTable)に、複数のテナント用の行を含めることができます。テナントに固有の行へのアクセスは、指定のテナントに制限されています。
テナント固有の行は、1つ以上のテナント識別子列を使用してテナントに関連付られています。識別子列には、どのような永続性コンテンツがアクセスできるか制限するアプリケーション・コンテキスト値が使用されています。
マップされた表での問合せの結果は、プロパティ値として提供されるテナント識別子値に制限されます。これは、表のすべての挿入、更新および削除操作に適用されます。マルチテナントのメタデータがマップ済のスーパークラス・レベルで適用されると、独自のマルチテナント・メタデータを指定しないかぎり、すべてのサブエンティティに適用されます。
テナントごとの表マルチテナントでは、テナント独自の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のソリューション・ガイドのテナントごとの表マルチテナントの使用に関する項を参照してください。
仮想プライベート・データベース(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マルチテナントの使用に関する項を参照してください。
現在のリリースでは、複数の書込みのあるトランザクションを最適化するための永続性ユニット・プロパティが用意されています。eclipselink.jdbc.batch-writingプロパティは、バッチ書込みの使用を構成して、複数の書込みのあるトランザクションを最適化します。バッチ書込みを使用すると、複数の異機種間の動的SQL文を、1つの実行としてデータベースに送信することや、複数の異機種間のパラメータ化されたSQL文を、1つのバッチ実行として実行することができます。バッチ書込みをサポートしていないJDBCドライバやデータベースがあることに注意してください。
eclipselink.jdbc.batch-writing.sizeプロパティは、バッチ書込みに使用するバッチ・サイズを構成します。パラメータ化されたバッチ書込みの場合、この値にはバッチにする文の数を指定します(デフォルト: 100)。動的バッチ書込みの場合、この値はバッチの対象となるSQLバッファのサイズで、デフォルトは32kです。
バッチ書込みによる修正問合せのバッチ処理が可能な場合、eclipselink.jdbc.batch-writing永続性プロパティを問合せヒントとともに使用して構成することができます。一部のデータベースのDDLなど、問合せのタイプによってはバッチ処理ができない場合があります。バッチ書込みを無効にすると、行カウントを戻すこともできます。
シリアライズ(またはバイナリ形式)・オブジェクト・ポリシーによって、EclipseLinkは私有の(およびネストされた私有の)エンティティおよび要素コレクションとともに、データベースの追加フィールドにエンティティ・オブジェクト全体を書き出すことができます。シリアライズ・オブジェクト・ポリシーは、データベースからのフェッチを最適化し、データベース読取りを高速化し、CPUおよびネットワーク・アクセスの中間層を削減します。
シリアライズ・オブジェクト・ポリシーは、読取り専用またはほぼ読取り専用のアプリケーションに最適で、すべての依存エンティティおよび要素コレクションをロードするエンティティにのみ使用します。シリアライズ・オブジェクト・ポリシーを使用する場合、データベース書込み操作(挿入および更新)の速度は遅くなり、私有データを含まないオブジェクトに対する問合せの速度も遅くなります。
シリアライズ・オブジェクト・ポリシーは、エンティティまたはマップされたスーパークラスで@SerializedObject注釈を使用するか、SerializedObjectPolicyインタフェースの実装を渡すことにより有効化されます。このインタフェースの実装を提供する必要があります。デフォルトの実装はありません。注釈には、データベースのオブジェクトに対する列名を定義するフィールドも含まれます。
シリアライズ・オブジェクト・ポリシーが有効な場合、読取り問合せ(検索、リフレッシュなど)は、自動的にシリアライズ・オブジェクトを使用します。シリアライズ・オブジェクトにNULLまたは廃止されたバージョンのオブジェクトが含まれる場合、シリアライズ・オブジェクト・ポリシーを使用している問合せは例外をスローするか、他のフィールドすべてが同様に読み込まれている場合は、これらのフィールドを使用してオブジェクトを構築します(シリアライズ・オブジェクト・ポリシーが使用されていない場合も同様)。
シリアライズ・オブジェクト・ポリシーの詳細は、Oracle TopLinkのソリューション・ガイドのシリアライズ・オブジェクト・ポリシーに関する項を参照してください。@SerializedObject注釈の詳細は、『Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@SerializedObjectに関する項を参照してください。
自動チューニングは、特定の目的に対するJPAおよびセッション構成をアプリケーションが自動的にチューニングできるようにする最適化です。複数の構成オプションを単一のチューナで構成し、アプリケーション・デプロイメントの前後で、またセッションへの接続前にアプリケーションのメタデータが処理された後で、異なる構成を指定できます。自動チューニングにより、構成が簡単になり、動的な単一チューニング・オプションが使用可能になります。
SessionTunerインタフェースにより、テンプレートのチューニング構成が容易になります。これにより、アプリケーションを本番および開発用に、または様々なデプロイメント構成に対して簡単に調整できます。
デプロイメントの間、チューナはコールバックを受信してJPA構成をチューニングします。tunePreDeployメソッドを使用して、永続性ユニット・プロパティをチューニングでき、tuneDeployメソッドを使用して、セッションに接続する前にSessionをチューニングでき、tunePostDeployメソッドを使用して、Sessionオブジェクトが初期化され、データベースに接続された後にチューニングできます。
チューナを構成するために、eclipselink.tuning persistenceプロパティが追加されています。SafeModeTunerはデバッグ用のチューニングのために用意されており、またデフォルトのStandardTunerも用意されています。
Oracle TopLinkのソリューション・ガイドの自動チューニングに関する項を参照してください。
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をサポートしているクライアント・テクノロジーを使用してアプリケーションを開発できます。このサービスとクライアントの間には結合はありません。
