| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11gリリース1（11.1.1） B61006-01 |
|
 戻る |
 次へ |
この章では、EclipseLinkに対して使用可能なパフォーマンス・チューニング機能について説明します。EclipseLinkは、Oracle TopLinkとともに使用するオープンソースの永続性フレームワークです。この章の内容は次のとおりです。
|
注意: これらの分野におけるパフォーマンス・チューニングの詳細は、次のドキュメントを参照してください。
|
Oracle TopLinkには、オープンソースのEclipseLinkがJava Persistence API（JPA）実装として含まれています。Oracle TopLinkは、Oracle Application Serverへの高度な統合によってEclipseLinkを拡張します。
Java Persistence API（JPA）は、Java EEアプリケーションおよびJava SEアプリケーションの永続性に関する仕様です。JPAでは、永続クラスをエンティティと呼びます。エンティティとは、データベースにマップされ、注釈または永続性XML、あるいはその両方を使用してJPA経由で使用するよう構成されたPlain Old Java Object（POJO）クラスです。この章では、EJB3.0およびJava EE環境に則したJPAのチューニングに焦点を当てます。
この章の内容は、読者がEclipseLinkの基本的な機能を熟知しているものと想定して書かれています。チューニングを始める前に、次のサイトの概論に目を通すことを検討してください。
『EclipseLink Developer's Guide』の「Introduction to Java Persistence API」（http://wiki.eclipse.org/Introduction_to_Java_Persistence_API_(ELUG)）
『EclipseLink Developer's Guide』の「Introduction to EclipseLink JPA」（http://wiki.eclipse.org/Introduction_to_EclipseLink_JPA_%28ELUG%29）
「Considering JPA Entity Architecture」（http://wiki.eclipse.org/Introduction_to_EclipseLink_Application_Development_(ELUG)#Considering_JPA_Entity_Architecture）
『Introduction to EclipseLink Queries』（http://wiki.eclipse.org/Introduction_to_EclipseLink_Queries_(ELUG)）
『Introduction to Cache』（http://wiki.eclipse.org/Introduction_to_Cache_(ELUG)）
『Introduction to Mapping and Configuration』（http://wiki.eclipse.org/Introduction_to_EclipseLink_Mapping_and_Configuration_(ELUG)）
Oracle TopLinkの詳細は、OTNのTopLinkページ（http://www.oracle.com/technology/products/ias/toplink/index.html）を参照してください。[Oracle TopLinkリリース11gで、旧Toplink APIは非推奨となりました。詳細は、TopLinkのリリース・ノート（http://www.oracle.com/technology/products/ias/toplink/doc/11110/relnotes/toplink-relnotes.html#CHDGAEDJ）を参照してください。]
|
注意: この章は、Java EE環境に則したJPAのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。この章では、パフォーマンス・チューニングに関する一般的な考慮事項と関連のドキュメント・リソースを示しますが、チューニングが必要な分野をすべて網羅してはいません。 |
この項では、効率的なSQL文およびSQL問合せの使用について説明します。表8-1と表8-2に、SQL文およびSQL問合せに関連したチューニング・パラメータとパフォーマンス上の推奨事項を示します。
表8-1 EJB/JPAでの効率的なSQL文およびSQL問合せの使用
| チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
|---|---|---|
|
パラメータ使用のSQLのバインディング |
パラメータ使用のSQLおよびプリコンパイル文のキャッシュを使用すると、コール頻度の高い問合せのSQLがデータベースのSQLエンジンによって解析およびプリコンパイルされる回数が減少し、パフォーマンスが向上します。EclipseLinkでは、パラメータ使用のSQLがデフォルトで有効になります。ただし、データベースやJDBCドライバの中には、このオプションをサポートしないものもあります。Oracle Application ServerにバンドルされているOracle JDBCドライバは、このオプションをサポートしていませんので注意してください。これを構成するには、persistence.xmlの永続性プロパティeclipselink.jdbc.bind-parametersを使用します。 関連項目: 「Using EclipseLink JPA Extensions - Bind Parameters」（ デフォルト値: PERSISTENCE_UNIT_DEFAULT（デフォルトでtrue） |
選択したデータベースやJDBCドライバが前述のオプションをサポートしている場合は、パラメータ使用のSQLのバインディングを有効のままにしてください。 |
|
JDBC文キャッシュ |
文キャッシュは、カーソル作成の繰返しと文の解析および作成の繰返しがパフォーマンスに与える影響を軽減するために使用します。文キャッシュによって、データベースを使用するアプリケーションのパフォーマンスが向上します。 注意: J2EEアプリケーションには、データ・ソースの文キャッシュを使用します（JB3.0/JPAのEclipseLink文キャッシュは使用しません。例: Oracle Weblogicデータ・ソースでこのオプションを設定するには、構成オプション 『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』の文キャッシュによるパフォーマンスの向上に関する項も参照してください。 デフォルト値: Oracle Weblogic Serverデータ・ソースのデフォルトの文キャッシュ・サイズは、1接続当たり文10個です。 |
ご使用のJDBCドライバがこのオプションをサポートしている場合は、文キャッシュを必ず有効にしてください。Oracle JDBCドライバは、このオプションをサポートしています。 |
|
フェッチ・サイズ |
JDBCフェッチ・サイズは、JDBCドライバにとって、追加の行が必要な場合にデータベースからフェッチする行数のヒントとなります。 多数のオブジェクトを返す大規模な問合せに対しては、問合せで使用される行フェッチ・サイズを構成すると、選択条件を満たすのに必要なデータベース・ヒット数が少なくて済み、パフォーマンスが向上します。 関連項目: 「Using EclipseLink JPA Extensions - Fetch Size」（ ほとんどのJDBCドライバは、デフォルトのフェッチ・サイズとして10を使用します。1000個のオブジェクトを読み取る場合、フェッチ・サイズを256に増やすと、問合せ結果のフェッチに要する時間が大幅に短縮されます。 注意: デフォルト値の場合、JDBCドライバのデフォルト値が使用されます。Oracle JDBCドライバでは、通常10行です。 これを構成するには、問合せヒント デフォルト値: 0 |
最適なフェッチ・サイズが常に明白であるとはかぎりません。通常は、予想される総結果サイズの半分または4分の1がフェッチ・サイズとして最適です。結果セットのサイズが不確かな場合に、誤ってフェッチ・サイズの設定を大きく、または小さくしすぎると、パフォーマンスが低下する可能性がありますので、注意してください。 |
|
バッチ書込み |
バッチ書込みでは、 これを構成するには、persistence.xmlの永続性プロパティ 関連項目: 「How to Use Batch Writing for Optimization」（ デフォルト値: Off |
永続性ユニットに対して有効にします。 |
|
変更追跡 |
これは、EclipseLinkによるエンティティ変更の検出方法をチューニングするための最適化機能です。 関連項目: 「Using EclipseLink JPA Extensions for Tracking Changes」（ デフォルト値: ウィービングを使用する場合はAttributeLevel（J2EEのデフォルト）、それ以外の場合はDeferredです。 |
最適なパフォーマンスを得るには、デフォルトのAttributeLevelのままにします。 |
|
ウィービング |
persistence.xmlのプロパティ デフォルト値: On |
最適なパフォーマンスを得るには、Onのままにします。 |
|
読取り専用 |
EJB3.0 JPAエンティティを読取り専用に設定すると、そのエンティティは変更できなくなり、作業ユニットのパフォーマンスが最適化されます。 問合せヒントeclipselink.read-onlyを使用して設定します。
関連項目: 「Using EclipseLink JPA Extensions - Read Only」（ デフォルト値: False |
最適なパフォーマンスを得るために、結果オブジェクトが変更されない問合せには読取り専用を使用します。 |
|
firstResultとmaxRows |
これらは、大規模な問合せのページングに使用するJPA問合せプロパティです。通常、これらのプロパティは、多数の行を返す問合せの結果セット全体が必要ではない場合に使用できます。たとえば、ユーザーが特定の結果を求めて結果セットを（一度に1ページずつ）スキャンし、レコードが見つかってしまえば残りのデータは破棄するような場合です。 関連項目: 「How to Use Result Set Pagination」（ |
大きな結果セットが得られるが、オブジェクトのサブセットのみが必要になるような問合せに対して使用します。 |
|
順序番号の事前割当て |
順序番号の事前割当てを行うと、一連のIDをデータベースに対して同時に問い合せることができ、挿入のたびにデータベースにアクセスしてIDを取得する必要がなくなります。 関連項目: 「Sequencing and Pre-allocation Size」（ デフォルト値: 50 |
常に順序番号の事前割当てを使用すると、挿入のパフォーマンスが最適化されます。最適なパフォーマンスを得るには、事前割当てが行えない |
表8-2に、パフォーマンス・チューニング用のエンティティ・リレーションシップ問合せパラメータを示します。
表8-2 EJB3.0エンティティ・リレーションシップ問合せのパフォーマンス・オプション
| チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
|---|---|---|
|
バッチ読取り |
eclipselink.batchヒントは、EclipseLinkにバッチ処理情報を提供します。これにより、関連オブジェクトに対する後続の問合せがバッチ内で最適化されるため、オブジェクトを1つずつ取得したり、大規模な1つの結合読取りで取得したりすることを回避できます。 バッチ処理は、SELECT句にオブジェクトが1つしかない問合せに対してのみ実行できます。これを構成するための問合せヒントはeclipselink.batchです。 関連項目: 『EclipseLink User's Guide』の「Using EclipseLink JPA Extensions - Batch」（ デフォルト値: Off |
必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ読取りまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。 バッチ読取りは、重複したデータの読取りを回避できるため、結合より効率的です。したがって、バッチ読取りがサポートされている問合せのパフォーマンスを最適化するには、結合読取りではなくバッチ読取りを使用することを検討してください。 |
|
結合 |
結合読取りとは、あるクラスの1回の問合せで、そのクラスと関連オブジェクトのインスタンス作成に必要なデータが返されるようにする、問合せ最適化機能です。 この機能は、データベース・アクセスを減らして問合せのパフォーマンスを改善するために使用します。デフォルトでは、リレーションシップに対して結合読取りは行われません。遅延ロードを使用している場合は、各リレーションシップがアクセス時に別々にフェッチされ、遅延ロードを使用していない場合は、別々のデータベース問合せとしてフェッチされます。 結合の使用は、 結合はJPA仕様の一部ですが、バッチ読取りは違います。また、結合の対象となるのは、バッチ読取りが行えない問合せです。たとえば、結合は、SELECT句に複数のオブジェクトを含む問合せ、単一の結果を返す問合せ、カーソルおよび最初/最大の結果に対して機能しますが、バッチ読取りは機能しません。 関連項目: 「Using EclipseLink JPA Extensions - Join Fetch」（ デフォルト値: 使用しない |
必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ読取りまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。SELECTのパフォーマンスを最適化するために、バッチ読取りがサポートされていない場合は結合を使用することをお薦めします。 |
|
遅延ロード |
遅延ロードをOnにしていない場合、永続オブジェクトの取得の際に、そのオブジェクトの参照する従属オブジェクトがすべて取得されます。リレーションシップ・マッピングによってマップされた属性に対して遅延読取り（インダイレクション、遅延ロード、ジャストインタイム読取りとも呼びます）を構成すると、被参照オブジェクトのプレースホルダとしてインダイレクション・オブジェクトが使用されます。 その属性にアクセスするまで、従属オブジェクトの読取りは遅延されます。その結果、アプリケーションにとって重要なのは取得されたオブジェクトの内容のみであり、関連オブジェクトの内容は重要でないという場合は特に、パフォーマンスが大幅に向上します。 関連項目: 「What You May Need to Know About EclipseLink JPA Lazy Loading」（ デフォルト値: コレクション・マッピングの場合はOn（ToManyマッピング、@OneToMany、@ManyToMany） デフォルト値: 参照の場合はOff（ToOneマッピング、@OneToOne、@ManyToOne） （@OneToOneおよび@ManyToOneに対して遅延ロードをOnに設定するには、ウィービングが必要です。J2EEの場合、ウィービングはデフォルトでOnになっています。） |
すべてのマッピングに対して遅延ロードを使用します。遅延ロードを使用し、バッチ読取りまたは結合を使用して被参照オブジェクトを問い合せるほうが、即時ロードより効率的です。 |
この項では、EclipseLinkに付属しているデフォルト内部キャッシュのチューニングについて説明します。Oracle Toplink/EclipseLinkは、Oracle Coherenceとも統合できます。Oracle Coherenceを使用したEclipseLinkエンティティ・キャッシュの構成およびチューニングの詳細は、8.4項「Coherenceとの統合」を参照してください。
EclipseLink永続性マネージャおよびキャッシュとともに使用するEJB3.0/JPAのデフォルト設定は、ロックなし、キャッシュ・リフレッシュなしで、キャッシュの使用方法はDoNotCheckCacheです。（排他的アクセス権限がない場合に）アプリケーションでキャッシュを使用し、失効したデータをキャッシュから読み取らないようにするには、これらの設定に加えて、その他の分離関連の設定を適切に構成する必要があります。表8-3に、キャッシュ構成オプションを示します。
|
注意: デフォルトでは、アプリケーションが使用データへの排他的アクセス権限を持つ（つまり、EclipseLink以外の外部アプリケーションがデータを変更することはない）ものと想定されます。アプリケーションがデータへの排他的アクセス権限を持たない場合は、表8-3に示すデフォルト値を一部変更する必要があります。 |
表8-3 EJB3.0 JPAエンティティとキャッシュ構成オプション
| チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
|---|---|---|
|
オブジェクト・キャッシュ |
EclipseLinkセッションには、オブジェクト・キャッシュが用意されています。EclipseLink永続性マネージャを使用するEJB3.0 JPAアプリケーションでは、このキャッシュをデフォルトで使用するEclipseLinkセッションが作成されます。セッション・キャッシュと呼ばれるこのキャッシュには、データベースとの間で読み書きされたオブジェクトの情報が格納されます。セッション・キャッシュは、EclipseLinkアプリケーションのパフォーマンスを改善するための重要な要素の1つです。 通常、サーバー・セッションのオブジェクト・キャッシュは、そのセッションから取得されたすべてのクライアント・セッションで共有されます。分離セッションは、共有オブジェクト・キャッシュから分離された固有のセッション・キャッシュを備えています。 オブジェクトをキャッシュしない場合は、（ 関連項目: 「Session Cache」（ 「How to Use the Persistence Unit Properties for Caching」（ デフォルト値: 有効（sharedがTrue） |
一般に、キャッシュは有効にしておくことをお薦めします。常にデータベースから読み取られるオブジェクト（ペシミスティック・ロックの対象となるオブジェクトなど）がある場合は、そのエンティティのキャッシュを無効にしてください。例: |
|
問合せ結果セット・キャッシュ |
EclipseLinkでは、オブジェクト・キャッシュに加えて、問合せキャッシュもサポートされています。
問合せキャッシュの問合せヒントには次のものがあります。
関連項目: 「How to Cache Query Results in the Query Cache」（ デフォルト値: 使用しない |
主キー以外のキーで頻繁に実行される問合せのうち、結果セットがあまり変わらないものに使用します。キャッシュ無効化タイムアウトとともに使用すると、必要に応じてリフレッシュができます。 |
|
キャッシュ・サイズ |
キャッシュ・サイズは、次の永続性プロパティを使用して構成します。
関連項目: 「Using EclipseLink JPA Extensions for Caching」（ 「JPA Best Practices - Configure the Cache」（ デフォルト値: タイプ |
使用可能なメモリーの量、使用するクラスのインスタンス数、エンティティのアクセス頻度、および失効したデータの許容度に基づいたキャッシュの必要量を基準に、キャッシュ・サイズを設定します。 アクセス頻度の高いインスタンスが多いエンティティや、失効したデータが大した問題にはならないエンティティについては、サイズの大きなキャッシュを作成することを検討してください。 更新頻度が高く、常に最新のデータが必要とされるエンティティや、アクセス頻度の低いエンティティには、小さなキャッシュ・サイズを使用するか、キャッシュをまったく使用しないことを検討してください。 |
|
ロック |
Oracleでは、表8-4に示すロック・ポリシー（ロックなし、オプティミスティック、ペシミスティック、読取り専用）をサポートしています。 ロックは、JPAの@Versionアノテーションeclipselink.read-onlyを使用して設定します。 関連項目: 「Introduction to EclipseLink Application Development - Locking」（ 「Using EclipseLink JPA Extensions Pessimistic Lock」（ 「How to Use EclipseLink Locking」（ 「Configuring Locking」（ デフォルト値: ロックなし |
同時に更新可能なエンティティには、ユーザーが他のユーザーの変更を上書きできないようなロック・ポリシーを使用することを検討してください。読取り専用エンティティのパフォーマンスを最適化するには、エンティティを読取り専用として定義するか、読取り専用の問合せヒントを使用することを検討してください。 |
|
キャッシュの使用方法 |
デフォルトでは、どのタイプの問合せも、まずデータベースを検索してからキャッシュと同期を取ります。問合せにリフレッシュが設定されている場合を除き、キャッシュされたオブジェクトはデータベースからリフレッシュされずに返されます。特定の問合せを、メモリー内キャッシュ、データベース、その両方のうち、いずれに対して実行するかを指定できます。 すでにキャッシュにあるオブジェクトがデータベースで検索されるのを防いでパフォーマンスを向上させるには、検索の際に必要なオブジェクトをまずキャッシュから取得し、オブジェクトがキャッシュに存在しない場合にのみデータ・ソース内を検索するよう構成します。主キーに基づいて単一オブジェクトを検索する問合せについては、問合せヒント 関連項目: 「Using EclipseLink JPA Extensions - Cache Usage」（ デフォルト値: |
通常はデータがキャッシュにあり、リフレッシュ処理をそれほど必要としない場合に、主キー問合せのパフォーマンスを高速化するには、まず主キー問合せでキャッシュをチェックすることをお薦めします（ これにより、まずデータベースからオブジェクトを取得した後、すでにキャッシュにあるオブジェクトを検索し、キャッシュされた値（問合せにリフレッシュが設定されている場合を除き、データベース・アクセスによって更新されていない）を返すというデフォルト動作を回避できます。 |
|
分離 |
EclipseLinkを使用するJPAアプリケーションには、特定のデータベース・トランザクションの分離レベルを単独で設定するチューニング・パラメータはありません。 一般的なEJB3.0 JPAアプリケーションでは、データベース・トランザクションの分離レベルが適用されるタイミング、および特定のデータベース・トランザクションを分離できる程度には、次のような様々な要素が影響を与えます。
関連項目: 「Database Transaction Isolation Levels」（ |
|
|
キャッシュのリフレッシュ |
デフォルトでは、EclipseLinkはデータ・ソースから読み取ったオブジェクトをキャッシュします。このオブジェクトに対する後続の問合せではキャッシュへのアクセスが行われるため、データ・ソースへのアクセスが減るとともに、オブジェクトとそのリレーションシップを再構築するコストも発生せず、パフォーマンスが向上します。問合せでデータ・ソースにアクセスする場合でも、返されたレコードに対応するオブジェクトがキャッシュに存在すれば、キャッシュ内のオブジェクトが使用されます。このデフォルトのキャッシュ・ポリシーは、失効したデータがアプリケーション内に生じる原因となります。 リフレッシュは、エンティティ・レベル（ 詳細は、8.3.1項「キャッシュ・リフレッシュのシナリオ」を参照してください。 関連項目: 『EclipseLink User's Guide』の「Configuring Cache Refreshing」および「How to Use the @Cache_Annotation」 デフォルト値: キャッシュのリフレッシュなし |
エンティティ・レベルでのキャッシュのリフレッシュはできるかぎり避け、かわりに次の構成を検討してください。
|
キャッシュでのデータのリフレッシュに関して、考慮すべきシナリオがいくつかあります。これらのシナリオはいずれも、パフォーマンスに影響を与えます。
キャッシュされたデータではなく、最新のデータが常に必要な場合は、分離キャッシュ（Shared=False）を使用することを検討してください。これに当てはまるのは、アプリケーション内の特定のデータが頻繁に変更されるため、競合が検出されたときにのみデータをリフレッシュするのではなく、常にデータをリフレッシュすることが望ましいような場合です。
失効したデータは使用したくないが、失効したデータを取得することになっても大した問題ではないという場合は、解決策としてキャッシュ失効ポリシーを使用することをお薦めします。この場合は、ロック・エラー発生時に失効したオブジェクトを自動的にリフレッシュする、オプティミスティック・ロックも使用してください。オプティミスティック・ロックを使用する場合は、エンティティの@Cache属性であるalwaysRefreshおよびrefreshOnlyIfNewerをさらに有効にすると、データベースにアクセスする問合せで、返された失効オブジェクトをリフレッシュできるとともに、無効なオブジェクトが変更されていない場合はリフレッシュしないようにできます。また、リフレッシュされたデータが必要であることがわかっている場合に、特定の問合せ操作に対してリフレッシュを有効にしたり、クライアントから取得したデータをリフレッシュするオプション（リフレッシュ問合せをコールするもの）を提供したりすることもできます。
データが失効していても問題ない場合は、オプティミスティック・ロックを使用してください。そうすると、ロック・エラーの際にキャッシュ内の失効したオブジェクトが自動的にリフレッシュされます。
表8-4に示すロック・モードを、EclipseLinkのキャッシュ使用方法および問合せリフレッシュのオプションとともに使用すると、JPAを使用するEJBエンティティのデータ一貫性が保証されます。どの組合せも機能とパフォーマンスの両面に影響を与えますが、これらのオプションの設定は、たとえパフォーマンスのコストが発生したとしても、データを最新で一貫した状態に保つための機能上の要件を優先して決めるのが一般的です。
詳細は、「Configuring Locking」（http://wiki.eclipse.org/Introduction_to_EclipseLink_JPA_(ELUG)#Configuring_Locking）を参照してください。
表8-4 ロック・モード・ポリシー
| ロック・オプション | 説明 | パフォーマンス上の注意点 |
|---|---|---|
|
ロックなし |
ユーザーが別のユーザーの変更内容を上書きできます。これはデフォルトのロック・モードです。エンティティが同時に更新されることがない場合や、read-committedセマンティクスによる同じ行の同時読取りおよび更新で十分な場合は、このモードを使用します。 関連項目: 「Introduction to EclipseLink Application Development」（ デフォルト値: ロックなし |
通常はロックなしのほうが高速ですが、データ一貫性のニーズには対応できない場合があります。 |
|
オプティミスティック |
すべてのユーザーがデータへの読取りアクセス権限を持ちます。ユーザーが変更を加えようとした場合、そのユーザーがデータを読み取った後にデータが変更されていないか、アプリケーションによってチェックされます。 関連項目: 「Introduction to EclipseLink Application Development: Locking」（ |
同じ行に対する同時更新を頻繁には実行しないと予想される場合、オプティミスティック・ロックを使用すれば、最適なパフォーマンスを得ながら、データの一貫性も保証することができます。 |
|
ペシミスティック |
更新目的でデータにアクセスした最初のユーザーによって、更新処理が完了するまでデータがロックされます。 関連項目: 「Introduction to EclipseLink Application Development: Locking」（ |
同じ行に対して頻繁に同時更新を実行することが予想される場合、同時アクセスの例外および再試行が多数発生するオプティミスティック・ロックより、ペシミスティック・ロックのほうが高速になることがあります。 エンティティ・レベルでペシミスティック・ロックを使用する場合は、最適なパフォーマンスを得るために、分離キャッシュ（Shared=False）を併用することをお薦めします。 |
|
読取り専用 |
EJB3.0 JPAエンティティを読取り専用に設定すると、そのエンティティは変更できなくなり、作業ユニットのパフォーマンスが最適化されます。 @ReadOnlyクラス・アノテーションを使用して、エンティティ・レベルで設定します。問合せヒント 関連項目: 「Introduction to EclipseLink Application Development: Locking」（ 「Using EclipseLink JPA Extension - Read Only」（ |
エンティティを読取り専用として定義すると、読取り専用として定義されていないが、挿入、更新または削除を行わないエンティティよりも、パフォーマンスが向上します。これは、作業ユニットのパフォーマンスが最適化されるためです。すべての読取り専用操作に対して、常に読取り専用を使用してください。 |
Oracle Toplinkは、Oracle Coherenceと統合できます。この統合は、Oracle TopLink Grid機能によって実現されます。TopLink Gridを使用したEclipseLink JPAとの統合には、いくつかの種類があります。
次に例を示します。
EclipseLinkのデフォルトL2キャッシュをCoherenceに置き換えます。こうすることで、クラスタ・ノード全体をカバーする非常に大きなL2キャッシュがサポートされます。EclipseLinkのデフォルトL2キャッシュは、Java EEでホストされたマルチスレッド・アプリケーションが単一のJVMで稼働する場合のパフォーマンスを高めます。これをクラスタ全体で使用する場合は、特殊なキャッシュ調整機能を構成する必要があります。
データベースではなく、Coherenceのデータ・グリッド内で問合せを実行するよう、エンティティを構成します。こうすると、クラスタ化されたアプリケーション・デプロイメントを、データベースがボトルネックとなるような操作を越えて拡張できます。
EclipseLink JPAとCoherenceキャッシュの併用の詳細は、グリッド上のJPA手法に関する項（http://www.oracle.com/technology/products/ias/toplink/doc/11110/grid/tlgug003.htm）を参照してください。
Oracle ToplinkとOracle Coherenceとの統合の詳細は、Oracle TopLinkとCoherenceグリッドとの統合ガイド（http://www.oracle.com/technology/products/ias/toplink/doc/11110/grid/toc.htm）を参照してください。
EclipseLinkでは、オブジェクト表現とデータ・ソース固有の表現との間でデータのトランスフォーメーションを実行できます。このトランスフォーメーションをマッピングと呼びます。マッピングは、EclipseLinkプロジェクトの中核をなしています。
マッピングはそれぞれ、ドメイン・オブジェクトの単一データ・メンバーに対応しています。マッピングによって、オブジェクト・データ・メンバーをそのデータ・ソース表現と関連付け、オブジェクトとデータ・ソースの間の双方向変換を実行する手段を定義します。
マッピングの詳細は、『EclipseLink User Guide』の「Optimizing Mappings and Descriptors」（http://wiki.eclipse.org/Optimizing_the_EclipseLink_Application_(ELUG)#Optimizing_Mappings_and_Descriptors）を参照してください。
ディスクリプタの詳細は、「Configuring Common Descriptor Options」（http://wiki.eclipse.org/Configuring_a_Descriptor_(ELUG)#Configuring_Common_Descriptor_Options）を参照してください。
この項では、JPAアプリケーションのパフォーマンス分析に役立つEclipseLinkの機能をいくつか示します。
パフォーマンスのプロファイリングについては、『EclipseLink User's Guide』の「Measuring EclipseLink Performance with the EclipseLink Profiler」を参照してください。このツールは、シングルスレッドの限定的なユースケースでの使用を想定しています。
パフォーマンスの問題のデバッグおよびテストを行う場合、EclipseLinkから生成されたSQLを確認できます。SQLを確認するには、ロギング用のEclipseLink JPA拡張機能を使用して、ロギング・レベルをFINEに上げます。
ログ・レベルの設定の詳細は、「Using EclipseLink JPA Extensions for Logging」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#Using_EclipseLink_JPA_Extensions_for_Logging）を参照してください。
最適なパフォーマンスを得るために、プロファイリングまたはデバッグが終了したら、必ずロギング・レベルをデフォルト・レベルに戻してください。
