| Oracle Fusion Middleware Oracle TopLink開発者ガイド 11gリリース1（11.1.1） B56246-01 |
|
 戻る |
 次へ |
TopLinkセッションは、TopLinkランタイムにアクセスするための主要手段となります。TopLinkセッションは、アプリケーションが永続オブジェクトが含まれるデータ・ソースに対してあらゆる永続データ操作を実行するための手段となります。
セッションにより、データ・ソース・プラットフォーム情報、データ・ソース・ログイン情報および特定のアプリケーションのマッピング・メタデータが関連付けられます。マッピング・メタデータは、各種セッションを定義することにより、様々なアプリケーションで再利用できます。
TopLinkには様々なセッション・タイプが用意されており、それぞれ異なる設計要件およびデータ・アクセス方法に向けて最適化されています。同一のアプリケーション内で様々なセッション・タイプを使用することができます。
この章の内容は次のとおりです。
表87-1は、POJO TopLinkアプリケーションで使用できるセッション・タイプを示します。それぞれ、基本タイプか詳細タイプかに分類されます。Oracle TopLinkでのCMPの使用の詳細は、87.2.11項「セッションおよびCMP」を参照してください。
表87-1 TopLinkのセッション・タイプ
| セッション・タイプ | 説明 | Oracle JDeveloper |
TopLink Workbench |
Java |
|---|---|---|---|---|
|
サーバーおよびクライアント・セッション（87.3項「サーバーおよびクライアントのセッション」を参照） |
サーバー・セッションでは、データベースやEISの各プラットフォームを使用する3層アーキテクチャの複数クライアント用に、単一のデータ・ソース（共有オブジェクトや接続プールなど）に対するセッション管理を提供します。これは最も柔軟かつスケーラブルで、最もよく使用されるセッションです。 実行時にサーバー・セッションからクライアント・セッションを取得して、クライアントごとに単一データ・ソースにアクセスします。 |
 |
|
|
|
作業ユニット・セッション（87.4項「作業ユニット・セッション」を参照） |
任意のセッション・タイプから取得され（直接、または外部トランザクション・コントローラを使用）、オブジェクトをトランザクションで変更します。 |
|
|
|
|
独立クライアント・セッション（87.5項「独立クライアント・セッション」を参照） |
クライアント・セッションの特殊なタイプで、その親サーバー・セッションの共有オブジェクト・キャッシュから独立したセッション・キャッシュを使用します。 |
|
|
|
|
履歴セッション（87.6項「履歴セッション」を参照） |
クライアント・セッションの特殊なタイプで、指定された時刻の時点で存在するオブジェクトのバージョンの読取り専用スナップショットを提供し、その親サーバー・セッションの共有オブジェクト・キャッシュから独立したセッション・キャッシュを使用します。 |
|
|
|
|
セッション・ブローカおよびクライアント・セッション（87.7項「セッション・ブローカおよびクライアント・セッション」を参照） |
2つ以上のサーバー・セッションを集約することで、複数クライアントの複数データ・ソースに対するセッション管理を提供します（データベース・セッションで使用することもできます）。 実行時にセッション・ブローカからクライアント・セッションを取得して、クライアントごとにセッション・ブローカによって管理されているすべてのデータ・ソースにアクセスします。 |
|
|
|
|
データベース・セッション（87.8項「データベース・セッション」を参照） |
単純または2層アプリケーションに適した単独クライアントの単独データベースに対するセッション管理を提供します。3層アプリケーションではこのセッション・タイプは推奨しません。サーバー・セッションと同等の柔軟性とスケーラビリティを備えていないためです。 |
|
|
|
|
リモート・セッション（87.9項「リモート・セッション」を参照） |
クライアント側セッションの1つで、対応する専用クライアント・セッションおよび共有サーバー・セッションとRMI経由で通信します。リモート・セッションでは、クライアント側とサーバー側との間で、オブジェクト・アイデンティティとマーシャリングおよびアンマーシャリングを処理します。 |
|
|
|
詳細は、次を参照してください。
この項では、次のようなTopLinkセッションに固有の概念について説明します。
図87-1に示すように、セッション・インスタンスは次のコンポーネントで構成されます。
これらのセッション・コンポーネントの実装方法やそれらコンポーネント間の対話方法は、セッション・タイプに応じて異なります。たとえば、サーバーおよびクライアント・セッション用に、サーバー・セッションは、接続プールを提供し、接続プールから取得したすべてのクライアント・セッションのために共有オブジェクト・キャッシュを提供します。
TopLinkのセッションでは、オブジェクト・キャッシュを提供します。このキャッシュは、セッション・キャッシュと呼ばれますが、データベースとの間で読み書きされたオブジェクトの情報を保持するため、TopLinkアプリケーションのパフォーマンスを向上させるための重要な要素です。
サーバー・セッションのオブジェクト・キャッシュは、通常、そこから取得されたすべてのクライアント・セッションによって共有されます。つまり、サーバー・セッションmyServerSessionの場合は、サーバー・セッション・メソッドacquireClientSessionをコールすることにより取得された各クライアント・セッション間で、myServerSessionと同じオブジェクト・キャッシュが共有されます。
独立および履歴セッションは、その親サーバー・セッションの共有オブジェクト・キャッシュとは分離した、独自のセッション・キャッシュを備えています。詳細は、87.5項「独立クライアント・セッション」および87.6項「履歴セッション」を参照してください。
いずれかのセッションから取得した作業ユニット・セッションを使用すれば、この共有キャッシュへの同時アクセスは容易に管理できます。詳細は、87.4項「作業ユニット・セッション」を参照してください。
詳細は、87.10項「セッションとキャッシュ」を参照してください。
接続プールは、単一データ・ソースへの再利用可能な接続の集合です。
|
注意: 1つのセッション内から複数のデータベースに同時にアクセスするには、セッション・ブローカを使用します。詳細は、87.7項「セッション・ブローカおよびクライアント・セッション」を参照してください。 |
通常、データ・ソース接続の作成は負荷が高いため、適切に構成された接続プールによりパフォーマンスが大幅に向上します。
TopLinkで提供される内部接続プール、またはJDBCドライバまたはJava EEコンテナで提供される外部接続プールを使用するようにセッションを構成できます。デフォルトでは、TopLinkは内部接続プールを使用します。
内部接続プールは通常、非EJBアプリケーションで、あるいは外部トランザクション・コントローラ（JTA）が使用されていないときに使用されます。内部接続プールを使用するようにセッションを構成する場合、そのデフォルトの読取りおよび書込み接続プールを構成できます。アプリケーション固有の用途（名前付き接続プール）または順序付け専用（シーケンス接続プール）の特定用途接続プールを作成できます。詳細は、96.1.6.1項「内部接続プール」を参照してください。
外部接続プールは通常、EJBアプリケーションで、あるいは外部トランザクション・コントローラ（JTA）が使用されているときに使用されます。詳細は、96.1.6.2項「外部接続プール」を参照してください。
全般的なデータ・アクセス構成の詳細は、第96章「データ・アクセスの概要」を参照してください。
アプリケーションは、実行時にセッションを使用してすべての永続データ操作（オブジェクトの作成、読取り、更新および削除）を実行します。このような操作は、セッション問合せAPIとともにTopLinkの問合せと式を使用して行います。
詳細は、第108章「TopLink問合せの概要」を参照してください。
TopLinkでのセッション構成には2つ方法があります。1つはSession APIを使用するJavaコードを介したものであり、もう1つはTopLink Workbenchを使用してセッション構成ファイルであるsessions.xmlファイルを作成するものです。
通常は、sessions.xmlファイルを使用してアプリケーション用のセッションを構成します。このファイルはeXtensible Markup Language（XML）ファイルで、アプリケーションに関連するすべてのセッションが含まれます。sessions.xmlファイルには、多数のセッションおよびセッション・タイプを含めることができます。
次の利点があるため、sessions.xmlファイルを使用してTopLinkアプリケーションをデプロイすることをお薦めします。
TopLink Workbenchで作成およびメンテナンスを行うのが容易であること。
簡単にトラブルシューティングできること。
ほとんどのセッション構成オプションにアクセスできること。
デプロイされたアプリケーションを再コンパイルなしで変更する機能など、柔軟性に優れていること。
sessions.xmlファイルでのセッション作成の詳細は、88.1項「セッション作成の概要」を参照してください。
セッション・カスタマイザを指定することで、実行時のセッションのカスタマイズができます。セッション・カスタマイザはJavaクラスの1つで、oracle.toplink.tools.sessionconfiguration.SessionCustomizerインタフェースを実装し、デフォルト（ゼロ引数）コンストラクタを備えています。
CMPプロジェクトではsessions.xmlファイルは使用されないため、CMPプロジェクトを作成してデータベース・ログイン情報を指定する場合、カスタマイザとしてoracle.toplink.ejb.cmp.DeploymentCustomizationインタフェースを使用します。
セッション・カスタマイザを使用することで、コードAPIを介して実行時にセッションがカスタマイズされます。その方法は、修正メソッドを使用してディスクリプタをカスタマイズする方法と似ています（16.2.7項「修正メソッドとロード後メソッド」を参照）。
詳細は、89.8項「セッション・カスタマイザ・クラスの構成」を参照してください。
TopLinkのセッション・マネージャを使用すると、セッション・マネージャと呼ばれるシングルトン・オブジェクトの下で保持される一連のセッションを作成できます。
セッション・マネージャは、静的ユーティリティ・クラスです。TopLinkのセッションをsessions.xmlファイルからロードし（87.2.2項「セッションの構成とsessions.xmlファイル」を参照）、名前によってセッションをメモリーにキャッシュし、各TopLinkセッションに対して1つのアクセス・ポイントを提供します。
TopLinkでは、実行時に2つのデフォルト・リソース名であるsessions.xmlおよびMETA-INF/sessions.xmlからsessions.xmlファイルのロードを試みます。詳細は、第10章「TopLinkアプリケーションのパッケージ化」を参照してください。
セッション・マネージャでは、次のセッション・タイプをサポートします。
ServerSession（87.3項「サーバーおよびクライアントのセッション」を参照）
SessionBroker（87.7項「セッション・ブローカおよびクライアント・セッション」を参照）
DatabaseSession（87.8項「データベース・セッション」を参照）
セッション・マネージャには、2つの主な機能があります。すなわち、これらのセッションのインスタンスを作成することと、各名前付きセッションの1つのインスタンスのみがセッション・マネージャの任意のインスタンスに対して存在することを保証することです。
セッション・マネージャでは、次のようにセッションをインスタンス化します。
クライアント・アプリケーションが名前を使用してセッションを要求します。
セッション・マネージャは、sessions.xmlファイルでセッション名を検索します。セッション名がある場合、セッション・マネージャは指定されたセッションをインスタンス化します。セッション名がない場合、例外が発生します。
インスタンス化の後、セッションは、アプリケーションが停止されるまで実行可能です。
セッション・インスタンスの設定後は、それを使用して特別タスク用にセッションの追加タイプを取得できます。たとえば、任意のセッションから作業ユニットを取得してトランザクション操作を実行できます。サーバー・セッションからクライアント・セッションを取得して、3層アーキテクチャでクライアント操作を実行できます。
詳細は、第90章「実行時のセッションの取得と使用」を参照してください。
セッションでは、ほとんどのセッション操作に対してセッション・イベントが発生します。セッション・イベントは、複数のセッションのアクションをデバッグまたは調整する際に使用すると便利です。
セッション・イベント・マネージャは、セッション・イベントに関する情報を処理します。アプリケーションでは、セッション・イベントを受信するために、セッション・イベント・マネージャにセッション・イベント・リスナーを登録します。
たとえば、セッション・イベント・リスナーは、独立セッションの構成で重要な役割を果します（第92章「Virtual Private Database用の排他独立クライアント・セッションの構成」を参照）。独立セッションでは、TopLinkランタイムによりSessionEvent.NoRowsModifiedイベントが発生すると、SessionEventListenerによって処理されます（92.4項「NoRowsModifiedSessionEventイベント・ハンドラの使用」を参照）。このイベント・リスナーにより、更新の失敗がセキュリティ違反によるものか（この場合は操作を再実行しないでください）、オプティミスティック・ロックの問題（この場合は再試行が適切なことがあります）によるものかを突き止めることができます。イベント・リスナーにロギングを追加する方法の詳細は、87.2.6項「ロギング」を参照してください。
もう1つの例は、Oracle Databaseでのプロキシ認証を構成するためのセッション・イベント・リスナーの使用です。（98.8項「Oracleデータベースのプロキシ認証の構成」を参照してください。）
セッション・イベント・マネージャでは、次の表に示したセッション・イベントをサポートします。
表87-2 セッション・イベント
| イベント | 説明 |
|---|---|
|
MissingDescriptor |
永続化されているクラスでディスクリプタが欠落している場合に発生します。このイベントを使用して、ディスクリプタまたは一連のディスクリプタを遅延登録できます。 |
|
MoreRowsDetected |
|
|
NoRowsModified |
更新または削除後、SQLがデータベースに送付され、ゼロの行数が返されると発生します。 |
|
OutputParametersDetected |
出力パラメータが指定されたストアド・プロシージャ・コールが実行された後に発生します。このイベントにより、結果セットおよび出力パラメータを1つのストアド・プロシージャから取得できます。 |
|
PostAcquireClientSession |
clientSessionが取得された後に発生します。 |
|
PostAcquireConnection |
接続を取得した後に発生します。 |
|
PostAcquireExclusiveConnection |
分離データのあるクライアント・セッションが排他接続を取得すると発生します。 |
|
PostBeginTransaction |
データベース・トランザクションが開始した後に発生します。 |
|
PostCommitTransaction |
データベース・トランザクションがコミットした後に発生します。 |
|
PostConnect |
データベースに接続した後に発生します。 |
|
PostExecuteQuery |
すべての問合せがセッションで実行された後に発生します。 |
|
PostLogin |
セッションが接続を初期化して取得した後に発生します。 |
|
PostReleaseClientSession |
クライアント・セッションが解放された後に発生します。 |
|
PostRollbackTransaction |
データベース・トランザクションがロールバックした後に発生します。 |
|
PreBeginTransaction |
データベース・トランザクションが開始する前に発生します。 |
|
PreCommitTransaction |
データベース・トランザクションがコミットする前に発生します。 |
|
PreExecuteQuery |
すべての問合せがセッションで実行される前に発生します。 |
|
PreLogin |
セッションが接続を初期化して取得する前に発生します。 |
|
PreReleaseClientSession |
クライアント・セッションが解放される前に発生します。 |
|
PreReleaseConnection |
接続が解放される前に発生します。 |
|
PreReleaseExclusiveConnection |
分離データのあるクライアント・セッションが排他接続を解放する前に発生します。 |
|
PreRollbackTransaction |
データベース・トランザクションがロールバックする前に発生します。 |
表87-3 作業ユニットのイベント
| イベント | 説明 |
|---|---|
|
PostAcquireUnitOfWork |
|
|
PostCalculateUnitOfWorkChangeSet |
|
|
PostCommitUnitOfWork |
|
|
PostDistributedMergeUnitOfWorkChangeSet |
|
|
PostMergeUnitOfWorkChangeSet |
|
|
PostReleaseUnitOfWork |
解放された後に |
|
PostResumeUnitOfWork |
再開された後に |
|
PreCalculateUnitOfWorkChangeSet |
|
|
PreCommitUnitOfWork |
|
|
PreDistributedMergeUnitOfWorkChangeSet |
|
|
PreMergeUnitOfWorkChangeSet |
|
|
PrepareUnitOfWork |
|
|
PreReleaseUnitOfWork |
解放される前に |
セッション・イベント・リスナーは2通りの方法で作成できます。1つはSessionEventListenerインタフェースの実装で、もう1つはSessionEventAdapterクラスの拡張です。
セッション・イベント用にSessionEventListenerを登録するには、SessionEventManagerメソッドaddListenerを使用してセッションに登録します。
詳細は、89.10項「セッション・イベント・リスナーの構成」を参照してください。
TopLinkログに実行時情報を書き込むようにセッションを構成できます。この情報には、ステータス、診断、SQLおよび（プロファイリングを有効にした場合）パフォーマンス・データがあります（12.3項「TopLinkプロファイラを使用したTopLinkパフォーマンスの測定」または12.4項「Oracle Dynamic Monitoring System（DMS）を使用したTopLinkパフォーマンスの測定」を参照）。
ロギング・オプションはセッション・レベルで構成可能です（89.4項「ロギングの構成」を参照）。
|
注意: デバッグ作業を効率化するため、ロギングをリスナーに追加して、使用中のアプリケーションにとって意味のあるイベントのみを記録できます。セッション・コンテキスト内では、次のロギング・ユーティリティを使用します。
セッション・コンテキスト外では、次のロギング・ユーティリティを使用します。 AbstractSessionLog.getLog().log(int level, String message)
セッション・イベント・リスナーの詳細は、87.2.5.2項「セッション・イベント・リスナー」を参照してください。 |
TopLinkネイティブ・ロギングは、デフォルトのセッション・ログ・タイプです。oracle.toplink.logging.DefaultSessionLogによって実装されます。例87-1は、典型的なTopLinkネイティブ・ログ・メッセージを示します。
TopLinkネイティブ・ロギング・オプションはTopLink Workbenchを使用して構成できます（89.4.1項「TopLink Workbenchを使用したロギングの構成方法」を参照）。
例87-1 TopLinkログ・メッセージのサンプル
[TopLink Info]: DATE TIME-DatabaseSession(12345)-Thread(12345)-TopLink, version: Oracle TopLink - 10g (Build 031203) [TopLink Config]: DATE TIME-DatabaseSession(12345)-Thread(12345)-Connection(12345)- connecting(DatabaseLogin( platform=>Oracle9Platform user name=> "username" datasource URL=> "jdbc:oracle:thin:@144.23.214.115:1521:toplink" )) [TopLink Config]: DATE TIME-DatabaseSession(12345)-Thread(12345)-Connection(12345)- Connected: jdbc:oracle:thin:@144.23.214.115:1521:toplink User: USERNAME Database: Oracle Version: Oracle9i Enterprise Edition - Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.3.0 - Production Driver: Oracle JDBC driver Version: 9.2.0.3.0 [TopLink Info]: DATE TIME-DatabaseSession(12345)-Thread(12345)-loggingTestSession login successful
このロギング・タイプを使用すると、TopLinkがjava.util.loggingパッケージに準拠するようになります。oracle.toplink.logging.JavaLogによって実装されます。ロギング・オプションは、<JRE_HOME>/lib/logging.propertiesファイルで構成されます。メッセージは、この構成に基づいて多数の宛先に書き込まれます。例87-2は、典型的なjava.util.loggingログ・メッセージを示します。
java.util.loggingパッケージの使用方法の詳細は、89.4.5項「java.util.loggingパッケージを使用するためのセッションの構成方法」を参照してください。
例87-2 java.util.loggingログ・メッセージのサンプル
Dec 9, 2003 2:05:05 PM oracle.toplink.loggingTestSession DatabaseSession(32603767) Thread(10)
INFO: TopLink, version: Oracle TopLink - 10g (10.0.3) Developer Preview (Build 031203)
Dec 9, 2003 2:05:07 PM oracle.toplink.loggingTestSession.connection
DatabaseSession(32603767) Connection(927929) Thread(10)
CONFIG: connecting(DatabaseLogin(
platform=>Oracle9Platform
user name=> "coredev8"
datasource URL=> "jdbc:oracle:thin:@144.23.214.115:1521:toplink"
))Dec 9, 2003 2:05:08 PM oracle.toplink.loggingTestSession.connection
DatabaseSession(32603767) Connection(927929) Thread(10)
CONFIG: Connected: jdbc:oracle:thin:@144.23.214.115:1521:toplink
User: COREDEV8
Database: Oracle Version: Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.3.0 - Production
Driver: Oracle JDBC driver Version: 9.2.0.3.0
Dec 9, 2003 2:05:08 PM oracle.toplink.loggingTestSession
DatabaseSession(32603767) Thread(10)
INFO: loggingTestSession login successful
サーバー・ロギングは、TopLinkロギングとアプリケーション・サーバー・ログの統合に使用されます。
TopLinkランタイムでは、プロジェクトの作成時に構成されたサーバー・プラットフォームを考慮して、使用するサーバー・ログ・タイプを決定します（116.1項「プロジェクト作成の概要」を参照）。
たとえば、プロジェクトでWebLogicプラットフォームを使用する場合、TopLinkではoracle.toplink.platform.server.wls.WlsLogを使用します。OC4Jプラットフォームを使用する場合は、TopLinkでoracle.toplink.platform.server.oc4j.OjdlLogを使用します。
詳細は、次を参照してください。
TopLinkネイティブ・ロギングを使用する場合は、ファイルまたはコンソールにログ・メッセージが書き込まれるようにTopLinkを構成できます（89.4項「ロギングの構成」を参照）。
java.util.loggingを使用する場合は、TopLinkでは<JRE_HOME>/lib/logging.propertiesファイルに構成した宛先にログ・メッセージが書き込まれます（89.4.5項「java.util.loggingパッケージを使用するためのセッションの構成方法」を参照）。
サーバー・ロギングを使用する場合、TopLinkではアプリケーション・サーバーのログ・ファイルにログ・メッセージが書き込まれます（この場合、TopLink独自のログ・ファイルは使用されません）。
次のようにログ・レベル（情報量の昇順）を構成することで、ログ出力の量と詳細度を制御できます。
SEVERE: ログイン時に生成された例外のみでなく、TopLinkが続行できないことを示す例外を記録します。これにはスタック・トレースが含まれます。
WARNING: いくつかのレベルで記録されないすべての例外など、TopLinkを強制的に停止しない例外を記録します。これにはスタック・トレースは含まれません。
INFO（デフォルト）: サーバー・セッションごとのログイン/ログアウトを記録します（ユーザー名を含む）。セッションを取得すると、詳細情報が記録されます。
CONFIG: ログイン、JDBC接続およびデータベース情報のみを記録します。
FINE: SQL（スレッド情報を含む）を記録します。
FINER: 警告と同じです。ただし、スタック・トレースが含まれます。
FINEST: その他の低レベル情報が含まれます。
ALL: すべてを記録します。
デフォルトでは、一定の情報が記録されるように、oracle.toplink.logging.SessionLog.INFOレベルで記録されます。
実行時にSessionメソッドsetLogLevelを使用してログ・レベルを設定し、oracle.toplink.logging.SessionLogによって用意されているログ・レベル定数の1つを渡します。
リレーショナル・プロジェクトでは、TopLinkにより内部生成したSQL文字列を使用してデータベースにアクセスします。この機能により、アプリケーションでは、独自のSQL変換を実行しなくても、セッション・メソッドの使用やオブジェクトの問合せが可能になります。
データベースに送付されたSQLのレコードをデバッグ目的で確認する場合は、セッション・ログ・レベルをoracle.toplink.logging.SessionLog.FINEに設定します。これにより、そのセッションでは実行されたSQLがすべてセッション・ログに記録されます。
例87-3は、セッションのsetLogメソッドを使用してログの保存先を構成する方法を示します。
例87-3 ログ保存先の構成
private static SessionEventListener buildListener() {
return new SessionEventAdapter() {
public void preLogin(SessionEvent event) {
File file = new
File("C:\\oracle\\904\\toplink\\examples\\jdev\\2-TierEmployee\\toplink.log");
try {
System.out.println("FILE: " + file.getAbsolutePath());
FileWriter writer = new FileWriter(file);
event.getSession().setLog(writer);
} catch (IOException ioe) {
ioe.printStackTrace();
throw new RuntimeException("Failed to setup logging to: " + file.getAbsolutePath()); }
}
};
}
連鎖例外のロギング機能により、標準的な逆方向のスタック・トレースの一環として、ある例外が別の例外の原因になるときの因果関係を記録できます。原因となる連鎖が自動的にログに表示されます。
TopLink対応アプリケーションをアプリケーション・サーバーまたはEJBコンテナにデプロイする場合、TopLink CMPおよびEclipseLink JPAのデフォルトは、ログ・レベルのないServerLogに設定されるため、TopLinkではj2ee-logging.xmlでの構成が使用されます。
詳細は、89.4項「ロギングの構成」を参照してください。
TopLinkセッションでは、プロファイリングAPIが用意されており、アプリケーションのパフォーマンスのボトルネックを特定できます（89.6項「パフォーマンス・プロファイラの構成」を参照）。有効に設定されている場合、プロファイラにより、アプリケーションで実行される問合せごとにパフォーマンス統計のサマリーが記録されます。
TopLinkでは、TopLinkプロファイラまたはOracle Dynamic Monitoring System（DMS）を使用して、アプリケーションのパフォーマンスを測定できます。
TopLinkプロファイラは、高水準のロギング・サービスです。SQL文のロギングのかわりに、プロファイラは、実行する各問合せのサマリーを記録します。サマリーには、問合せのパフォーマンスの詳細が含まれるため、パフォーマンスのボトルネックを特定できます。プロファイラは、セッション全体に対する問合せのパフォーマンスをまとめたレポートも提供します。
プロファイラ・レポートおよびプロファイルには、TopLink Webクライアントの「プロファイル」タブを使用してアクセスするか、独自のアプリケーションまたはアプレットを作成してプロファイラ・ログを参照します。詳細は、12.3.2項「TopLinkプロファイラの結果へのアクセス方法」を参照してください。
詳細は、12.3項「TopLinkプロファイラを使用したTopLinkパフォーマンスの測定」を参照してください。
Oracle DMSは、アプリケーションおよびシステム開発者が様々なDMS Sensorを使用して、（Nounという）特定のソフトウェア・コンポーネント用にカスタマイズされたパフォーマンス・メトリックを測定し、エクスポートできるようにするライブラリです。
TopLinkでは、不可欠なオブジェクトにDMSインスツルメンテーションが組み込まれており、Java EEアプリケーションとJava EE以外のアプリケーションの両方を含む、TopLink対応のアプリケーションでランタイム・データを効率的に監視します。
TopLinkアプリケーションでDMSプロファイリングを有効にすることで、アプリケーション管理のタスクとパフォーマンス・チューニングに役立つランタイム・データを収集し、このデータに簡単にアクセスすることができます。
Java Management Extensions（JMX）API（12.4.2項「JMXを使用したOracle DMSプロファイラ・データへのアクセス方法」を参照）をサポートする管理アプリケーション、または任意のWebブラウザおよびDMS Spyサーブレット（12.4.3項「DMS Spyサーブレットを使用したOracle DMSプロファイラ・データへのアクセス方法」を参照）を使用して、実行時にDMSデータに簡単にアクセスできます。
詳細は、12.4項「Oracle Dynamic Monitoring System（DMS）を使用したTopLinkパフォーマンスの測定」を参照してください。
セッションにログインすると、TopLinkでは登録されたディスクリプタを初期化して検証します。整合性チェッカを構成することにより、この検証プロセスをカスタマイズできます。
詳細は、89.11項「整合性チェッカの構成」を参照してください。
例外ハンドラにより、セッションで発生する例外はすべて捕捉して処理できます。例外ハンドラはデバッグ目的にも、データベースのタイムアウトまたは障害の解決にも使用できます。
例外ハンドラを使用するには、oracle.toplink.exceptions.ExceptionHandlerインタフェースのインプリメンタをセッションに登録します（89.7項「例外ハンドラの構成」を参照）。
問合せの実行などセッションの操作時に例外が発生した場合は、その例外は例外ハンドラに渡されます。例外ハンドラで例外を再スローすることも、その例外を処理して操作を再実行することもできます。例外処理では、次の条件を満たすことが必要です。
ユーザーが書込み問合せを実行していてトランザクション内にいる場合は、操作を再実行させないこと。
ユーザーが読取り問合せを実行している場合は、操作を再実行させてもよいが、正常に終了した場合は問合せ結果を返すこと。
例外ハンドラが続行できない場合は、該当するアプリケーション固有の例外をスローする必要があります。
TopLinkでスローできる例外タイプの詳細は、付録A「TopLinkアプリケーションのトラブルシューティング」を参照してください。
セッションを使用して、TopLinkプロジェクトとして表されたTopLinkマッピング・メタデータによって記述されたオブジェクトに対して、永続性操作を実行します（第15章「プロジェクトの概要」を参照）。したがって、各セッションでは少なくとも1つのTopLinkプロジェクトのディスクリプタと関連付ける必要があります。ディスクリプタをセッションと関連付けるには、ディスクリプタをセッションに登録します。
ディスクリプタをセッションに登録するには、Oracle JDeveloper TopLinkエディタまたはTopLink Workbenchを使用してマッピング・プロジェクトでセッションを構成することをお薦めします（89.2項「プライマリ・マッピング・プロジェクトの構成」および89.5項「複数マッピング・プロジェクトの構成」を参照）。
TopLinkはJava EEアプリケーションに不可欠ですが、多くの場合、クライアントは直接TopLinkと対話しません。そのかわりに、EJBコンテナのコールバックを経由してTopLink機能が間接的に起動されます。
CMP TopLinkプロジェクトでは、明示的にセッションを作成、構成または取得しません。TopLinkランタイムでは、自身内部でセッションを作成、構成、取得および使用します。詳細は、2.9.3項「セッション・メタデータの作成」を参照してください。同様に、CMP TopLinkプロジェクトでは、メタデータがデプロイされる方法は使用されるEJBコンテナおよびアプリケーション・サーバーによって異なります（2.9.4項「メタデータのデプロイ」を参照）。
オブジェクト・アイデンティティを保持する上で重要なのは、各インスタンスを区別するために一意の値の割当てを管理することです。詳細は、15.2.6項「プロジェクトおよび順序付け」を参照してください。
sessions.xml（またはproject.xml）ファイルで構成する順序付けオプションによって、TopLinkで使用する順序付けのタイプが決定されます。
CMPプロジェクトでは、sessions.xmlファイルを直接構成しません。この場合、project.xmlファイルで順序付けのタイプを構成する必要があります（20.3項「プロジェクト・レベルでの順序付けの構成」を参照）。
POJOプロジェクトの場合、必要に応じて、セッション・レベルの順序構成を使用して、プロジェクト・レベルの順序構成をセッション単位でオーバーライドすることもできます（98.4項「セッション・レベルでの順序付けの構成」を参照）。
セッション（またはプロジェクト）レベルで順序付けタイプを構成した後、各ディスクリプタでも順序付けを使用するため、その順序付けオプションを構成する必要があります（16.2.10項「ディスクリプタと順序付け」を参照）。
サーバー・セッションでは、サーバー側のクライアント/サーバー通信を管理し、共有オブジェクト・キャッシュや単一データ・ソースへの共有接続プールなどの共有リソースを提供します。
クライアント・セッションは、サーバー側の通信メカニズムです。サーバー・セッションと連携してクライアント/サーバー接続を提供します。クライアント・セッションは、必要に応じてサーバー・セッションから取得します。デフォルトでは、クライアント・セッションは、その親サーバー・セッションのセッション・キャッシュを共有します。各クライアント・セッションは、1クライアントとして機能します。クライアント・セッションは、クライアント・アプリケーションにかわってサーバー・セッションと通信します。
各クライアント・セッションは、関連するサーバー・セッションを1つのみ保持できますが、サーバー・セッションは、任意の数のクライアント・セッションをサポートできます。
クライアント・セッションとサーバー・セッションは組み合さって3層アーキテクチャを構成しています。このアーキテクチャは、さらに多くのクライアント・セッションを追加して簡単に拡張できます。サーバー・セッションは、エンタープライズ・アプリケーションで一般的なこの3層アーキテクチャをサポートするため、最も一般的なTopLinkのセッション・タイプです。このスケーラビリティのため、3層アーキテクチャを使用してTopLinkアプリケーションを作成することをお薦めします。
この項では、次のような、TopLinkアプリケーションでサーバー・セッションおよびクライアント・セッションを使用することの利点について説明します。
詳細は、次を参照してください。
TopLinkの3層アーキテクチャでは、クライアント・セッションとサーバー・セッションはどちらもサーバー上に存在します。クライアント・アプリケーションは、クライアント・セッションを介してTopLinkアプリケーションにアクセスし、クライアント・セッションは、サーバー・セッションを使用してデータベースと通信します。
サーバー・セッションとクライアント・セッションは、2つの異なるセッション・タイプですが、どちらも3層機能をアプリケーションに提供するために必要であるため、ほとんどの場合、これらを1つの単位として扱うことができます。サーバー・セッションは、クライアント・セッションをクライアント・アプリケーションに提供し、セッション機能の大部分も提供します。
この項では、次のようなTopLinkの3層設計に関するいくつかの利点および一般的な概念について説明します。
3層設計により、複数のクライアントで持続リソースを共有できます。サーバー・セッションは、共有のライブ・オブジェクト・キャッシュ、読取りおよび書込み接続プール、パラメータ化された名前付き問合せを保有するクライアント・セッションを提供します。クライアント・セッションもディスクリプタ・メタデータを共有します。
クライアント・セッションおよびサーバー・セッションは、共有メモリーが使用でき、複数のクライアントをサポートするアプリケーション・サーバー・アーキテクチャで使用できます。この3層アーキテクチャには、HyperText Markup Language（HTML）、サーブレット、JavaServer Pages（JSP）、Remote Method Invocation（RMI）、Common Object Request Broker Architecture（CORBA）、WebサービスおよびEJBを含めることができます。
共有オブジェクト・キャッシュがサポートされるようにするには、クライアント・セッションは、次の処理を実行する必要があります。
データベースへの変更は、TopLinkの作業ユニットを使用して実装すること。
読取り用の共通データベース・ログインを共有すること（書込み用に別のログインを実装できます）。
オブジェクトをデータベースから読み取るには、クライアントは、まず、クライアント・セッションをサーバー・セッションから取得する必要があります。クライアント・セッションの取得により、セッション・キャッシュおよびデータベースへのクライアント・アクセスがサーバー・セッションを介して提供されます。サーバー・セッションは次のように動作します。
オブジェクトまたはデータがセッション・キャッシュにある場合、サーバー・セッションはクライアントにその情報を返します。
オブジェクトまたはデータがキャッシュにない場合、サーバー・セッションはデータベースから情報を読み取り、セッション・キャッシュにオブジェクトを格納します。その結果、オブジェクトをキャッシュから取得できるようになります。
サーバー・セッションは、各クライアント・リクエストを個別のスレッドで処理するため、複数のクライアントがデータベース接続プールに同時にアクセスできます。
図87-3は、複数のクライアントがサーバー・セッションを使用してどのようにデータベース読取りを行うかを示します。
図87-3 サーバー・セッションを使用した複数のクライアント・セッションによるデータベースの読取り
クライアント・セッションを使用してデータベースからオブジェクトを読み取るには、次の手順を実行します。
次のようにServerからSessionを取得します。
Server server =
(Server) SessionManager.getManager().getSession(
sessionName, MyServerSession.class.getClassLoader()
);
Session clientSession = (Session) server.acquireClientSession();
詳細は、第90章「実行時のセッションの取得と使用」を参照してください。
Sessionオブジェクトを使用して読取り操作を実行します（詳細は、第108章「TopLink問合せの概要」および第110章「TopLinkの式の概要」を参照してください）。
|
注意: サーバー・セッション・オブジェクトを使用して直接データベースからオブジェクトを読み取ることは回避することをお薦めします。 |
クライアント・セッションは、すべてのデータベース変更メソッドを無効にするため、オブジェクトを直接作成、変更または削除できません。かわりに、クライアントは、データベース変更メソッドを実行するために、クライアント・セッションから作業ユニットを取得する必要があります。
データベースに書き込むには、クライアントはクライアント・セッションをサーバー・セッションから取得し、そのクライアント・セッション内で作業ユニットを取得します。作業ユニットは、排他的なオブジェクト・トランザクション領域として機能します。また、データベースにコミットされるすべての変更がセッション・キャッシュに確実に反映されるようにもします。
|
注意: クライアント・セッションはスレッド・セーフですが、複数のスレッドにまたがった書込みに使用しないでください。同じクライアント・セッションからのマルチスレッドの書込み操作は、エラーの発生やデータの喪失を引き起こす可能性があります。詳細は、87.3.2.5項「並行性」を参照してください。 |
図87-4は、サーバー・セッションから取得したクライアント・セッションを使用して、データベースに書き込む方法を示します。
作業ユニットを使用してデータベースに書き込むには、次の手順を実行します。
次のようにサーバー・セッションからセッションを取得します。
Server server =
(Server) SessionManager.getManager().getSession(
sessionName, MyServerSession.class.getClassLoader()
);
Session clientSession = (Session) server.acquireClientSession();
詳細は、第90章「実行時のセッションの取得と使用」を参照してください。
SessionオブジェクトからUnitOfWorkオブジェクトを取得します。
UnitOfWork uow = clientSession.acquireUnitOfWork();
詳細は、87.4項「作業ユニット・セッション」を参照してください。
作業ユニットを使用して必要な更新を実行した後、UnitOfWorkをコミットします。
詳細は、次を参照してください。
いくつかの異なるサーバー・セッションをアプリケーションに定義し、様々なデータ・アクセス権によりユーザーをサポートすることができます。たとえば、アプリケーションが、給与情報へのアクセス権を持つ「Managers」という名前のグループと、そのアクセス権を持たない「Employees」という名前のグループを処理するとします。sessions.xmlファイルに定義する各セッションは、独自のログイン情報を保持するため、複数のセッションを作成し、それぞれに独自のログイン接続情報を持たせ、これらの両方のグループの要求に合せることができます。
TopLinkの内部接続プールを使用する場合（96.1.6項「接続プール」を参照）、各サーバー・セッションは、読取り接続プールおよび書込み接続プールを提供します。すべての読取り問合せは読取り接続プールからの接続を使用し、データ・ストアに変更を書き込むすべての問合せは書込み接続プールからの接続を使用します。これにより、あるセッションの接続が別のセッションに使用される接続から分離されます。
ユーザー同士をさらに分離するには、独立セッションを使用できます。これは特殊なタイプのクライアント・セッションで、その親サーバー・セッションの共有オブジェクト・キャッシュから分離された独自のセッション・キャッシュを備え、ユーザーごとのセキュリティを向上させたり、揮発性の高いデータがキャッシュされないようにすることができます。詳細は、87.5項「独立クライアント・セッション」を参照してください。
サーバー・セッションでは、各クライアントに実行の専用スレッドを提供することで、同時クライアントをサポートします。専用スレッドにより、クライアントは非同期的に操作できます。つまり、クライアント・プロセスはコールされたときに実行され、他のクライアント・プロセスが完了するのを待つことはありません。
TopLinkでは、並行性マネージャを使用してスレッド・セーフティを実現します。並行性マネージャにより、新規オブジェクトの作成、データベースに対するトランザクションの実行、ValueHolderへのアクセスなどの操作を実行する際に、2つのスレッドが互いに干渉しないことが保証されます。
並行性の問題の処理の詳細は、102.2.3項「失効したデータの処理」を参照してください。
サーバー・セッションがインスタンス化されると、データ・ソース接続のプールが作成されます。セッションで接続プールはセッション構成に基づいて管理され、接続はクライアント・セッション間で共有されます。クライアント・セッションが接続を解放すると、サーバー・セッションは接続を回復し、他のクライアント・プロセスで使用できるようにします。接続の再利用により、アプリケーションで必要な接続数が減り、サーバー・セッションでは多数のクライアントをサポートできます。
サーバー・セッションにより、必要に応じてクライアント・セッションへの接続が提供されます。デフォルトではサーバー・セッションは、トランザクションが開始されるまでクライアント・セッションに対してデータ・ソース接続を割り当てません（遅延データ・ソース接続）。あるいは、ただちに接続を割り当てるクライアント・セッションを取得できます（90.4.5項「遅延接続割当てを使用しないクライアント・セッションの取得方法」を参照）。
サーバー・セッションでは、その読取り接続プールからの読取り接続をすべてのクライアント・セッションに割り当てます。アプリケーションで複数の読取りセキュリティ・レベルが必要とされる場合は、複数のサーバー・セッションまたはTopLink独立セッションを使用する必要があります（87.5項「独立クライアント・セッション」を参照）。
サーバー・セッションでは、複数の書込み接続プールおよび非プール接続もサポートします。デフォルトでは、すべてのクライアント・セッションはデフォルトの書込み接続プールを使用します。ただし、アプリケーションで書込みアクセスに複数のセキュリティ・レベルまたはユーザー・ログインを必要とする場合は、複数の書込み接続プールを使用できます。クライアント・セッションは取得する際に構成して、特定の書込み接続プールまたは非プール接続を使用するようにできます（90.4.4項「名前付き接続プールを使用するクライアント・セッションの取得方法」を参照）。この接続は書込みのみに使用され、読取りには使用されません（読取りはあくまでサーバー・セッションの読取り接続プールを経由します）。
詳細は、次を参照してください。
作業ユニットにより、クライアントは個別のオブジェクト・トランザクション領域でオブジェクトを編集できるようになります。この機能を使用すると、クライアントはオブジェクト・トランザクションをパラレルで実行できます。トランザクションがコミットされると、作業ユニットによりデータベースに対して必要な変更が行われ、その変更はTopLinkの共有セッション・キャッシュにマージされます。その結果、変更されたオブジェクトは、他のすべてのユーザーに対して使用可能になります。
作業ユニットの作成、構成および使用の詳細は、第113章「TopLinkトランザクションの概要」を参照してください。
独立クライアント・セッションは、特殊なタイプのクライアント・セッションで、独自のセッション・キャッシュを備えています。このセッション・キャッシュは、その親サーバー・セッションの共有セッション・キャッシュからは分離されています。
TopLinkプロジェクトすべてのクラスを独立として（117.11項「プロジェクト・レベルでのキャッシュ分離機能の構成」を参照）、または1つ以上のクラスを独立として（119.13項「ディスクリプタ・レベルでのキャッシュ分離機能の構成」を参照）構成すると、親サーバー・セッションから取得するすべてのクライアント・セッションが独立クライアント・セッションになります。
図87-5は、親サーバー・セッションの共有セッション・キャッシュとその子の独立クライアント・キャッシュ間のリレーションシップを示します。
各独立クライアント・セッションでは、初めは空のキャッシュと、アクティブ時に独立クライアント・セッションがアクセスする独立オブジェクト専用のアイデンティティ・マップを所有しています。独立クライアント・セッションの独立セッション・キャッシュは、独立クライアント・セッションが解放されると破棄されます。
独立クライアント・セッションを使用して独立クラスを読み取るとき、クライアント・セッションは独立オブジェクトをデータベースから直接読み取り、そのクライアント・セッションの独立セッション・キャッシュに格納します。クライアント・セッションを使用して共有クラスを読み取るとき、クライアント・セッションは親サーバー・セッションの共有セッション・キャッシュから共有オブジェクトを読み取ります。共有オブジェクトが親サーバー・セッションの共有セッション・キャッシュにない場合は、共有オブジェクトをデータベースから読み取り、親サーバー・セッションの共有セッション・キャッシュに格納します。
独立クライアント・セッションの独立セッション・キャッシュにある独立オブジェクトは、親サーバー・セッションの共有セッション・キャッシュにある共有オブジェクトを参照することがありますが、親サーバー・セッションの共有セッション・キャッシュにある共有オブジェクトは、独立クライアント・セッションの独立セッション・キャッシュにある独立オブジェクトを参照できません。
|
注意: 共有クラスから独立クラスへはマッピングを定義できません。CMPを使用している場合は、独立Enterprise Beanから共有EJBへの参照も定義できません。 |
クライアント・セッションは、接続プールまたは排他接続を使用してデータ・ソースにアクセスできます。排他接続を使用するには、ConnectionPolicyを使用して独立クライアント・セッションを取得します（90.4.2項「排他接続を使用するクライアント・セッションの取得方法」を参照）。排他接続を使用すると、ユーザーごとの読取りおよび書込みのセキュリティが強化されます。また、排他接続は名前付き問合せでも使用できます（119.7.1.10項「名前付き問合せの詳細オプションの構成」を参照）。
|
注意: 独立セッションに排他接続が含まれる場合は、その使用を完了した後、セッションを解放する必要があります。セッションのガベージ・コレクション時、ファイナライザに依存して接続を解放することのないようにしてください。JTAトランザクション内で作業ユニットを使用する場合、クライアント・セッションを解放する必要はありません。JTAトランザクションの完了後に、作業ユニットによって解放されるためです。 |
独立クライアント・セッションは、次のような場合に使用します。
共有セッション・キャッシュでの高揮発性データのキャッシュの回避
シリアライズ可能なトランザクション分離の実現（115.15.1.5.1項「分離クライアント・セッション・キャッシュ」を参照）
TopLink対応アプリケーションでのOracle Virtual Private Database（VPD）機能の使用（87.5.1項「独立クライアント・セッションとOracle Virtual Private Database（VPD）」を参照）
詳細は、次を参照してください。
Oracle Database以上では、Virtual Private Database（VPD）と呼ばれる、サーバーで実施されるファイングレイン・アクセス制御メカニズムが提供されます。VPDは、条件付きのSQL文を動的に追加して行レベルでデータ・アクセスを制限する形で、セキュリティ・ポリシーを表に関連付けます。独自のセキュリティ・ポリシーを作成することも、Oracle Label Security（OLS）と呼ばれるVPDのOracleカスタム実装を使用することもできます。VPDとOLSの詳細は、次のサイトを参照してください。
http://www.oracle.com/technology/deploy/security/index.html
TopLink対応アプリケーションでOracle Database VPD機能を使用するには、独立クライアント・セッションを使用します。
VPDを使用する表にマップするクラスはすべて、独立として構成されたディスクリプタを備えている必要があります（119.13項「ディスクリプタ・レベルでのキャッシュ分離機能の構成」を参照）。
VPDで独立クライアント・セッションを使用するときは、通常、排他接続を使用します（90.4.2項「排他接続を使用するクライアント・セッションの取得方法」を参照）。
VPDをサポートするには、独立クライアント・セッションのライフ・サイクル中にTopLinkランタイムが起動するセッション・イベント・ハンドラを実装する必要があります（87.5.1.3項「独立クライアント・セッションのライフ・サイクル」を参照）。実装する必要のあるセッション・イベント・ハンドラは、Oracleデータベースのプロキシ認証を使用しているかどうかによって異なります（87.5.1.1項「Oracleデータベースによるプロキシ認証のあるVPD」および87.5.1.2項「Oracleデータベースによるプロキシ認証のないVPD」を参照）。
詳細は、第92章「Virtual Private Database用の排他独立クライアント・セッションの構成」を参照してください。
Oracleデータベースのプロキシ認証を使用する場合は（96.1.4.2項「Oracleデータベースのプロキシ認証」を参照）、次のセッション・イベント用のセッション・イベント・ハンドラを実装する必要があります。
noRowsModifiedSessionEvent（92.4項「NoRowsModifiedSessionEventイベント・ハンドラの使用」を参照）
Oracleデータベースのプロキシ認証を使用することによって、データベース内に完全にVPDのサポートを設定できます。つまり、独立クライアント・セッションがSQLを実行するのではなく（92.2項「PostAcquireExclusiveConnectionイベント・ハンドラの使用」および92.3項「PreReleaseExclusiveConnectionイベント・ハンドラの使用」を参照）、プロキシsession_userを使用したログイン・トリガー以降にデータベースが必要な設定を実行します。
Oracleデータベースのプロキシ認証を使用しない場合は、次のセッション・イベント用のセッション・イベント・ハンドラを実装する必要があります。
postAcquireExclusiveConnection（92.2項「PostAcquireExclusiveConnectionイベント・ハンドラの使用」を参照）: TopLinkで独立セッションに専用接続を割り当てるとき、および独立セッションのユーザーがデータベースとの対話に接続を使用する前に、VPD設定の実行に使用します。
preReleaseExclusiveConnection（92.3項「PreReleaseExclusiveConnectionイベント・ハンドラの使用」を参照）: 独立セッションの解放時、およびユーザーがデータベースとの対話を終了した後に、VPDクリーン・アップの実行に使用します。
noRowsModifiedSessionEvent（92.4項「NoRowsModifiedSessionEventイベント・ハンドラの使用」を参照）
このようなハンドラの実装で、セッションに関連付けられたConnectionPolicyから必要なユーザーの資格証明を取得します（90.4.3項「接続プロパティを使用するクライアント・セッションの取得方法」を参照）。
この項では、次のような独立セッションのライフ・サイクルの主要な段階の概要について説明します。
独立セッションを使用する前の必須の設定
独立セッション・オブジェクト間のインタラクション
独立セッション使用後の必須のクリーン・アップ
独立セッションのライフ・サイクルを有効にするには、次の手順を実行します。
データベースにVPD構成を用意します。
プロジェクトおよびセッションを構成します。
ディスクリプタを独立として指定します（119.13項「ディスクリプタ・レベルでのキャッシュ分離機能の構成」を参照）。
サーバー・セッションを構成して排他接続を割り当てます（89.12項「接続ポリシーの構成」を参照）。
必須接続イベント用にセッション・イベント・リスナーを実装します。
Oracleデータベースのプロキシ認証を使用している場合は（96.1.4.2項「Oracleデータベースのプロキシ認証」を参照）、92.4項「NoRowsModifiedSessionEventイベント・ハンドラの使用」を参照してください。
Oracleデータベースのプロキシ認証を使用していない場合は、92.2項「PostAcquireExclusiveConnectionイベント・ハンドラの使用」、92.3項「PreReleaseExclusiveConnectionイベント・ハンドラの使用」および92.4項「NoRowsModifiedSessionEventイベント・ハンドラの使用」を参照してください。
|
注意: このようなセッション・イベント・リスナーを、独立クライアント・セッションを取得するサーバー・セッションに追加する必要があります。独立クライアント・セッション自体には追加できません。詳細は、89.10項「セッション・イベント・リスナーの構成」を参照してください。 |
該当する例外用に例外ハンドラを実装します（92.5項「アクセス・インダイレクション」を参照）。
独立セッションを取得します。
Oracleデータベースのプロキシ認証を使用している場合（96.1.4.2項「Oracleデータベースのプロキシ認証」を参照）:
Session myIsolatedClientSession = server.acquireClientSession();
1つ以上のディスクリプタを独立として構成済のため、myIsolatedClientSessionは排他接続のある独立セッションになります。
Oracleデータベースのプロキシ認証を使用していない場合:
ConnectionPolicy myConnPolicy =
(ConnectionPolicy)server.getDefaultConnectionPolicy().clone();
myConnectionPolicy.setProperty("credentials", myUserCredentials);
Session myIsolatedClientSession =
server.acquireClientSession(myConnectionPolicy);
myConnectionPolicyに、必要なプロパティとしてユーザーの資格証明を設定します。1つ以上のディスクリプタを独立として構成済のため、myIsolatedClientSessionは排他接続のある独立セッションになります。
TopLinkランタイムにより、SessionEventListenerによって処理されたSessionEvent.PostAcquireExclusiveConnectionイベントが発生します（92.2項「PostAcquireExclusiveConnectionイベント・ハンドラの使用」を参照）。
myIsolatedClientSessionを使用してデータベースと対話します。
TopLinkランタイムによりSessionEvent.NoRowsModifiedイベントが発生すると、SessionEventListenerによって処理されます（92.4項「NoRowsModifiedSessionEventイベント・ハンドラの使用」を参照）。
myIsolatedClientSessionの使用が終了すると、独立セッションが解放されます。
myIsolatedClientSession.release();
TopLinkランタイムは、独立キャッシュを破棄してこの独立セッションに関連付けられている排他接続を閉じる準備をします。
TopLinkランタイムにより、SessionEventListenerによって処理されたSessionEvent.PreReleaseExclusiveConnectionイベントが発生します（92.3項「PreReleaseExclusiveConnectionイベント・ハンドラの使用」を参照）。
TopLinkの3層アプリケーションで独立クライアント・セッションを使用するときは、セキュリティのみでなく効率上からも、次のような制限事項を遵守してください。
マッピング
リレーショナル・モデルで独立セッションを使用する場合、次のマッピングとリレーションシップの制限に注意します。
独立オブジェクトは共有オブジェクトに関連付けできますが、共有オブジェクトは独立オブジェクトとはいっさいのリレーションシップを持つことができません。
表にVPDセキュリティ・ポリシーを関連付ける場合、その表にマップされたクラスは独立している必要があります。
複数の表マッピングの表のいずれかが独立している場合、メインのクラスも独立している必要があります。
TopLinkランタイムでは、ディスクリプタの初期化時にこのような制限を課します。
継承
クラスが独立している場合、それを継承するすべてのクラスが独立している必要があります。そうでない場合、独立サブクラスの備わった共有スーパークラスに共有クラスを関連付けると、独立サブクラスの一部で、独立セッションが解放されたときにオブジェクト・アイデンティティを失うことがあります。
共有クラスと独立クラスを混在させる柔軟性を与えるため、TopLinkランタイムではディスクリプタの初期化時にこのような制限を課しません。継承階層で共有クラスと独立クラスを混在させるには、予想されるオブジェクト・アイデンティティの喪失を処理するための準備をしておく必要があります。
キャッシングおよびキャッシュ・コーディネーション
独立クラスは、親サーバー・セッションの共有キャッシュにロードされません。独立クラスは、また、キャッシュ・コーディネーションで使用できません。
順序付け
順序付けオブジェクトは独立として構成しないことをお薦めします。TopLinkでは、独立セッションの専用接続を使用して順序付けオブジェクトにアクセスしません。また、このため独立セッションに対する順序値は利用できません。
CMP
CMPでは、分離データと共有データ間のリレーションシップは許可されません。これは、すべてのリレーションシップにおいて双方向の参照を持つ必要があるというリレーションシップ維持要件のためです。
トランザクションおよびJTA
使用終了後は、Javaガベージ・コレクタがファイナライザを起動するのを待つのではなく、独立セッションを明示的に解放することをお薦めします。ファイナライザは最後の手段として用意されています。ガベージ・コレクタを待っていると、JTAトランザクション処理の際にエラーが発生する可能性があります。
デフォルトでは、セッションはオブジェクトの最新バージョンの表示を表し、そのセッションで問合せを実行すると、選択したオブジェクトの最新バージョンが返されます。
データ・ソースが過去のバージョンのオブジェクトを保持している場合、TopLinkを構成して、この履歴データにアクセスし、ある期間にどのようにオブジェクトが変更されているかについての条件を付けた読込み問合せを表現できます。また、次のことも行えます。
現在の問合せ時点に存在しているオブジェクトの問合せのみでなく、任意の時刻時点で存在していたオブジェクトに対する一連の問合せ
一連の読取り操作またはレポート問合せがすべて同時に実行されたかのようにする、読取り一貫性の実現
mergeCloneメソッドにオブジェクトの過去バージョンを渡すことによる、オブジェクトの遡及的リカバリ
また、次のいずれかの方法で問合せ選択基準を表現できます。
過去の特定時点での条件。たとえば、「特定の時点で...していた従業員」など。
経時変化。たとえば、「最近...した従業員」など。
詳細は、次を参照してください。
HistoryPolicyでは、多種多様な履歴スキーマを受け入れる、きわめて柔軟な手段となります。ただし、次の制限に注意してください。
単一のスキーマで現行データと履歴データを併用する設計の場合は、HistoryPolicyは使用できません。
EJBエンティティBeanでは、履歴セッションも履歴問合せも使用できません。
TopLinkでは、オブジェクトの現行バージョンは、履歴表内で終了フィールドがNULLである行に対応するものとみなしています。
履歴表の行開始フィールドおよび行終了フィールドは、標準のスキーマには存在しないため、ダイレクト・マップすることはできません。
履歴オブジェクトの範囲に対しては問合せはできず、特定の時点で存在していたオブジェクトに対してのみできます。
TopLinkのセッション・ブローカは、クライアント・アプリケーションが単一のTopLinkセッションで複数のデータベースに透過的にアクセスできるようにするメカニズムです。
TopLinkのセッション・ブローカを使用すると、クライアント・アプリケーションでは、1つのセッションを介して複数のデータベースを参照できます。アプリケーションで複数のデータベースにオブジェクトを格納する場合、セッション・ブローカにより、クライアント・アプリケーションがシームレスに通信でき、複数のデータベースを1つのデータベースのように参照できます。
3層セッション・ブローカ・アプリケーションがサーバー・セッションを使用してデータベースと通信するとき、クライアントはデータベースにアクセスするためのクライアント・セッションを必要とします。これと同様に、セッション・ブローカを実装する場合、クライアントはデータベースにアクセスするためのクライアント・セッション・ブローカを必要とします。
クライアント・セッション・ブローカは、セッション・ブローカに関連付けられた各サーバー・セッションからのクライアント・セッションの集合です。クライアントがクライアント・セッション・ブローカを取得すると、セッション・ブローカは各関連サーバー・セッションから1つのクライアント・セッションを収集し、クライアント・セッションをラップし、クライアント・アプリケーションに対して単一のクライアント・セッションのように見えるようにします。
図87-6に示すように、セッション・ブローカは複数のサーバー・セッションまたはデータベース・セッションを介してデータベースに接続します。
図87-6 サーバー・セッションを使用するTopLinkのセッション・ブローカのアーキテクチャ
この項の内容は次のとおりです。
詳細は、次の項を参照してください。
図87-6に示すように、セッション・ブローカにはブローカ・オブジェクトが含まれ、このオブジェクトは、セッション・ブローカに追加された複数のセッションとアプリケーションの間の仲介として機能します。
セッション・ブローカを作成するには、TopLink Workbenchを使用して次のようにsessions.xmlファイルを変更します。
複数のセッションを定義します（同じタイプ。サーバー・セッションまたはデータベース・セッション）。
セッション・ブローカを定義します。
セッション・ブローカにセッションを追加します。
SessionManagerメソッドgetSession(sessionBrokerName)を使用すると（sessionBrokerNameは定義済のセッション・ブローカの名前）、セッション・マネージャにより、追加された各セッションのインスタンスが含まれる、該当するセッション・ブローカ・セッション（mySessionBroker）が返されます。mySessionBrokerメソッドloginを使用すると、このメソッドは各定義済セッションにログインします。この後は、他のセッションを使用するのと同様の方法でmySessionBrokerを使用します。TopLinkでは透過的に複数のデータベースへのアクセスを処理します。
セッション・ブローカに複数のサーバー・セッションが含まれる3層アーキテクチャの場合、セッション・ブローカ・メソッドacquireClientSessionBrokerを使用して1つのクライアント・セッションを取得します。このセッションでは、各種のサーバー・セッションによって管理されるすべてのデータ・ソースにわたって問合せができます。このクライアント・セッションは、他のクライアント・セッションと同様の方法で使用します。
デフォルトでは、セッション・ブローカ・セッションを使用してトランザクションをコミットすると、2ステージ・コミットが実行されます。
2フェーズ・コミットの利点を享受するには、JTA外部トランザクション・コントローラを組み込むのが理想的です。
セッション・ブローカを使用する場合、JTA外部トランザクション・コントローラを可能なかぎり組み込みます。外部トランザクション・コントローラには、2フェーズ・コミットが備わっており、トランザクションのコミットを必要とするSQL文をJTAドライバに渡します。JTAドライバでは、コミット・プロセス全体を処理します。
JTAでは、トランザクションに複数のデータベースが含まれる場合でも、トランザクションが完全にコミットまたはロールバックされることを保証します。いずれかのデータベースに対するコミット操作が失敗した場合は、すべてのデータベース・トランザクションがロールバックされます。2フェーズ・コミット操作は、トランザクションをデータベースにコミットするために使用できる最も安全な方法です。
2フェーズ・コミットがサポートされるようにするには、対応JTAドライバを組み込むことが必要です。
使用可能なJTAドライバがない場合は、セッション・ブローカにより2ステージ・コミット・アルゴリズムが提供されます。2ステージ・コミットは、トランザクションの最終コミット時点までのみのデータ整合性を保証するという点で、2フェーズ・コミットとは異なります。SQLスクリプトがすべてのデータベースに対して正常に実行され、その後あるデータベースでコミット操作が失敗した場合、コミットが失敗したデータベースのみがロールバックされます。
可能性は低いものの、このような例が発生することもあります。そのため、システムにJTAドライバが含まれておらず、2ステージ・コミットを使用する場合、このタイプの潜在的な問題に対応するメカニズムをアプリケーションに組み込みます。
セッション・ブローカは強力なツールで、1つのアプリケーションから複数のデータベースに分散されたデータを使用できますが、次のようにいくつかの制限事項があります。
特定の分散データ・アプリケーションのニーズを満たさないことがあります（87.7.4項「セッション・ブローカの代替手段」を参照）。
複数の表ディスクリプタをデータベースにまたがって分割できません。
各クラスは、1つのデータベース上にのみ存在する必要があります。
データベースにまたがって式による結合は使用できません。
多対多結合表は、ターゲット・オブジェクトと同じデータベース上に存在する必要があります（この制限事項の回避策については、87.7.3.1項「多対多結合表およびダイレクト・コレクション表」を参照してください）。
デフォルトでは、多対多結合表およびダイレクト・コレクション表は、ソース・オブジェクトと同じデータベースにあると想定されています。別々のデータベースにある場合は、例87-4に示すように、ManyToManyMappingまたはDirectCollectionMappingのメソッドであるsetSessionNameを使用して、マッピングのセッション名を構成する必要があります。ただし、多対多結合表の場合には、あくまでターゲット・オブジェクトと同じデータベース上に存在する必要があります。
例87-4 ディスクリプタ修正メソッドでのマッピングsetSessionNameの使用
public void addToDescriptor(ClassDescriptor descriptor) {
descriptor.getMappingForAttributeName("projects").setSessionName("branch-database");
}
データ・レベルでの問合せでこの問題に対処するには、DatabaseQueryメソッドsetSessionNameを使用します。
セッション・ブローカをアプリケーションで使用するかどうかを評価する際には、次の代替手段も考慮に入れます。
Oracleデータベースなどのほとんどのエンタープライズ・データベースでは、データベース・サーバーで他のデータベースへのリンク付けをサポートしています。これにより、リンクされたデータベースも含めた問合せと2フェーズ・コミットが可能になります。セッション・ブローカの使用は、データベースのリンク付けとは異なります。データベースでリンク付けが可能な場合は、セッション・ブローカを使用するのではなくリンク付け機能を使用した複数のデータベースへのアクセスをお薦めします。
セッション・ブローカの代替方法は、次のように複数のセッションを使用して複数のデータベースを処理することです。
各データベース上のデータが他のデータベース上のデータと無関係で、リレーションシップがデータベースの境界をまたがない場合は、データベースごとに別のセッションを作成できます。たとえば、各部門専用の個別のデータベースおよび関連するセッションを保持できます。
この仕組みでは、各セッションを手動で管理し、プロジェクトのクラス・ディスクリプタが適切なセッション内に存在することを保証する必要があります。
追加セッションを使用し、標準のバッチ・ジョブを格納できます。この場合、2つ以上のセッションを同じデータベース上に作成できます。クライアントの問合せをサポートする主セッションに加えて、システムでトラフィックが低いときに一括挿入をサポートする他のセッションを作成します。これにより、クライアント・キャッシュを維持できます。
データベース・セッションは、1つの接続で1ユーザーのすべてのデータ・ソース・リクエストを処理する単純なスタンドアロン・アプリケーションでのクライアント・アプリケーションに、単一のデータ・ソース接続を提供します。
データベース・セッションは、TopLinkによって提供される最も単純なセッションです。クライアントとサーバーの両方の通信を実現し、単一クライアントと単一データベース接続をサポートします。単純アプリケーションまたは2層アプリケーションに適しています。
|
注意: このセッション・タイプは3層アプリケーションでの使用を回避することをお薦めします。サーバーおよびクライアント・セッションほどは柔軟でもスケーラブルでないためです。かわりにサーバー・セッションおよびクライアント・セッションを使用することをお薦めします（87.3項「サーバーおよびクライアントのセッション」を参照）。データベース・セッションを使用して作成されたアプリケーションは、将来スケーラブルなアーキテクチャに移行するのが困難になる可能性があります。 |
データベース・セッションでは、次の情報が含まれ、管理されます。
ProjectおよびDatabaseLoginのインスタンス。データベースのログイン情報および構成情報が格納されます。
JDBC接続およびデータベース・アクセス
アプリケーションの永続クラスごとのディスクリプタ
詳細は、次を参照してください。
リモート・セッションは、クライアント側セッションの1つで、サーバー側の対応するクライアント・セッションおよびサーバー・セッションとRMIを介して通信します。リモート・セッションでは、クライアント側とサーバー側との間で、オブジェクト・アイデンティティとマーシャリングおよびアンマーシャリングを処理します。
リモート・セッションは、TopLinkサーバーではなくクライアントに存在します。リモート・セッションは、クライアント・セッションのかわりにはなりません。正確には、リモート・セッションでは、サーバー・セッションと通信するためにクライアント・セッションが必要です。
リモート・セッションは、クライアント・システムには存在しているものの、セッション・キャッシュも備えている完璧なTopLinkセッションです。TopLinkでは、リモート・セッション・キャッシュを管理し、クライアント・アプリケーションがサーバーで操作を実行できるようにします。
リモート・セッションを使用すると、サーバー上に存在しないクライアントがデータベースにアクセスできます。リモート・セッションはクライアント上に存在していて、RMIを介して対応するクライアント・セッションに接続します。これにより、次にクライアント・セッションがサーバーにある自身のサーバー・セッションに接続します。
この項の内容は次のとおりです。
詳細は、88.7項「リモート・セッションの作成」を参照してください。
図87-7に示すように、リモート・セッション・モデルは次の各層で構成されます。
アプリケーション層: クライアント・サイド・アプリケーションがリモート・セッションと対話
トランスポート層: 通信レイヤー（RMIまたはRMI-IIOP）
サーバー層: TopLinkのセッションがデータベースと通信
クライアント・アプリケーションからサーバーへのリクエストは、分散システムのレイヤーを縦断していきます。サーバー・セッションに要求したクライアントでは、リモート・セッションをサーバー・セッションへのパイプとして使用します。クライアントはリモート・セッションを参照し、リモート・セッションはトランスポート層を介してリクエストをサーバー・セッションへ転送します。
実行時に、リモート・セッションは、必要に応じてサーバー側からディスクリプタおよびマッピングを読み取り、ナレッジ・ベースを作成します。これらのディスクリプタおよびマッピングは、必ずしもすべての情報がリモート・セッションに渡されるわけではないため、軽量です。オブジェクト・ツリーを横断し、特定のオブジェクトから主キーを抽出するために必要な情報が、マッピングおよびディスクリプタとともに渡されます。
アプリケーション層には、アプリケーション・クライアントとリモート・セッションが含まれます。リモート・セッションはSessionのサブクラスで、セッションのすべてのパブリックなプロトコルを保持し、対応するクライアント・セッションと連携しているように見せます。
リモート・セッションは、独自のアイデンティティ・マップと、サーバーから読み取られるすべてのディスクリプタのプロジェクトを保持します。リモート・セッション単独でリクエストを処理できる場合、リクエストはサーバーに渡されません。たとえば、リモート・セッション・キャッシュにあるオブジェクトに対するリクエストはリモート・セッションで処理されます。ただし、オブジェクトがリモート・セッション・キャッシュにない場合、リクエストはサーバー・セッションに渡されます。
トランスポート層は、起動のセマンティックを伝達する役割を担っています。すべてのプロトコルの依存性をアプリケーション層およびサーバー層から見えないようにする層です。
トランスポート層には、抽象エンティティであるリモート接続が含まれます。これを介してサーバーへのすべてのリクエストが転送されます。各リモート・セッションは、クライアント側ですべてのリクエストおよびレスポンスをマーシャリングおよびアンマーシャリングするリモート接続を1つ保持します。
サーバー層にはリモート・セッション・コントローラ・ディスパッチャおよびTopLinkセッションが含まれます。図87-7は、3層サーバーとそのクライアント・セッションを示します。リモート・セッション・コントローラ・ディスパッチャは、セッションとトランスポート層間のインタフェースです。サーバー上のセッションとクライアント上のその対応するリモート・セッション間のすべてのレスポンスとリクエストをマーシャリングおよびアンマーシャリングします。
リモート・セッションは、リモート・セッション・コントローラ・ディスパッチャを誰でもアクセスできるサービスとして登録する必要があるため、潜在的なセキュリティ・リスクを示します。このため、データベース全体が不正アクセスにさらされる可能性があります。
この危険を軽減するには、サーバー・マネージャをリモート・セッション・コントローラ・ディスパッチャを保持するサービスとして実行します。その結果、すべてのクライアントは、サーバー・マネージャを介して通信することが必要になるため、リモート・セッション・コントローラ・ディスパッチャにアクセスするためのセキュリティ・モデルが実装されます。
クライアント側では、ユーザーからリモート・セッション・コントローラ・ディスパッチャが要求されます。マネージャは、サーバー・マネージャに組み込まれているセキュリティ・モデルに応じて、ユーザーがアクセス権を持っている場合にかぎり、リモート・セッション・コントローラ・ディスパッチャを返します。
システムにアクセスするには、クライアント側でリモート・セッション・コントローラ・ディスパッチャがリモート接続を作成し、そのリモート接続からリモート・セッションを取得します。リモート・セッション用のAPIは、セッション用のAPIと同一です。セッションでの動作とリモート・セッションでの動作の間に、ユーザーが見てわかる相違はありません。
リフレッシュ・メソッドをリモート・セッションでコールすると、データベース読取り操作が発生し、リフレッシュ対象のデータがデータベースで変更される場合は、キャッシュ更新も発生します。これにより、パフォーマンスが低下する可能性があります。
パフォーマンスを向上させるには、すべての問合せでキャッシュのオブジェクトが常にリモートでリフレッシュされるようにディスクリプタを構成して、サーバー・セッション・キャッシュに対して実行されるようにリフレッシュ・メソッドを構成します。この方法により、リモート・セッションに対するすべての問合せでは、データベースにアクセスせずに、サーバー・セッション・キャッシュのオブジェクトをリフレッシュすることが保証されます。
リモート・セッションでのキャッシュ・ヒットは、主キーに基づいたオブジェクト読取りの問合せでそれでも発生します。これを回避するには、主キーに基づいたオブジェクト読取りの問合せでリモート・セッション・キャッシュ・ヒットを無効にします。
詳細は、119.9項「キャッシュ・リフレッシュ機能の構成」を参照してください。
リモート・セッションでは、インダイレクション（遅延ロード）オブジェクトをサポートします。インダイレクション・オブジェクトは、クライアント側でリモートに起動できるValueHolderです。起動されると、最初にValueHolderは、要求されたオブジェクトがリモート・セッション上に存在するかどうかをチェックします。存在しない場合は、次に、サーバー上の関連するValueHolderがインスタンス化され、クライアントに返される値が取得されます。リモートのValueHolderが自動的に使用されますが、アプリケーションのコードは変更されません。
リモート・セッションでは、カーソル付きストリームとスクロール可能カーソルの両方をサポートします。
詳細は、108.5.3項「ストリームとカーソルの問合せの結果」を参照してください。
サーバー、データベース、独立および履歴の各セッションには、オブジェクト・アイデンティティを保持し、キャッシュとして動作するアイデンティティ・マップが含まれています。
この項では、次のようなセッション間でのキャッシュの差異について説明します。
詳細は、第102章「キャッシュの概要」を参照してください。
サーバーまたはデータベース・セッションでは、データベースからオブジェクトを読み取ると、インスタンス化してアイデンティティ・マップ（キャッシュ）に格納します。続いて、アプリケーションで同じオブジェクトに対して問合せを実行すると、TopLinkでは、データベースから再度オブジェクトを読み取るのではなく、キャッシュのオブジェクトを返します。
このキャッシュは、アプリケーションのパフォーマンスにおいて重要な役割を果します。
サーバー・セッションの場合、そこから取得されたすべてのクライアント・セッションでサーバー・セッションのキャッシュを共有します。
キャッシュによりオブジェクトを管理する方法を定義するには、TopLink Workbenchでキャッシュの管理方法を指定します。
独立セッション・キャッシュでは、データベースからオブジェクトを読み取ると、そのディスクリプタは独立として構成されており、そのオブジェクトはインスタンス化して独立セッションのキャッシュにのみ格納されます。親サーバー・セッションの共有オブジェクト・キャッシュには格納されません。独立セッションのキャッシュにあるオブジェクトは、親サーバー・セッションの共有オブジェクト・キャッシュにあるオブジェクトを参照することはできますが、親サーバー・セッションの共有オブジェクト・キャッシュにあるオブジェクトは、独立セッションのキャッシュにあるオブジェクトを参照できません。
セッションAPIは、次のインタフェースによって定義されます。
oracle.toplink.sessions.Session
oracle.toplink.sessions.DatabaseSession
oracle.toplink.sessions.UnitOfWork
oracle.toplink.threetier.Server
これらのAPIは、実行時にオブジェクトおよびデータ・ソースにアクセスするために使用されます。セッションのパブリック・インタフェースを必ず使用し、対応する実装クラスは使用しないでください。
Sessionインタフェースは、クライアント・セッション、セッション・ブローカ、独立クライアント・セッション、履歴クライアント・セッション、リモート・セッションおよびデータベース・セッションで読取りおよび問合せを行う際に使用します。
UnitOfWorkインタフェースは、任意のセッション・タイプから取得したあらゆる作業ユニットで使用します。
Serverインタフェースは、サーバー・セッションからクライアント・セッションを取得して構成するために使用します。
DatabaseSessionインタフェースは、データベース・セッションに使用します。サーバー・セッション、データベース・セッションおよびセッション・ブローカ・セッションは、通常sessions.xmlファイルに定義し、SessionManagerを使用して実行時に取得します。サーバー・セッションやデータベース・セッションは、Projectから取得することもできます。常に直接インスタンス化する唯一のセッションが、SessionBrokerです。ただし、SessionManagerを使用しないときにかぎります。
クライアント・セッションはサーバー・セッションから取得します。
サーバー・セッションからなるセッション・ブローカから、クライアント・セッション・ブローカを取得することもできます。
作業ユニットは、セッション・インスタンス、クライアント・セッション・ブローカ、またはDatabaseSessionインスタンスを含むセッション・ブローカから取得します。
例87-5は、oracle.toplink.sessions.Sessionインタフェースから導出されるセッション・インタフェースを示します。
