| Oracle Fusion Middleware Oracle TopLink開発者ガイド 11gリリース1（11.1.1） B56246-01 |
|
 戻る |
 次へ |
セッションの作成および構成後は、実行時にセッション・マネージャを使用してセッション・インスタンスを取得できます。
この章の内容は次のとおりです。
Oracle JDeveloper TopLinkエディタまたはTopLink Workbenchから1つ以上の一意名のsessions.xmlファイルにセッション・インスタンスをエクスポートし、セッション・マネージャを使用してこれらのsessions.xmlファイルからセッションをロードすることをお薦めします。
TopLinkのセッション・マネージャを使用すると、1つのエンティティの下で保持される一連のセッションを作成できます。セッション・マネージャは、静的ユーティリティ・クラスです。TopLinkのセッションをsessions.xmlファイルからロードし、名前によってセッションをメモリーにキャッシュし、TopLinkのセッションに対して1つのアクセス・ポイントを提供します。セッション・マネージャでは、次のセッション・タイプをサポートします。
サーバー・セッション
データベース・セッション
セッション・ブローカ
これらの使用可能なセッションの詳細は、第87章「TopLinkセッションの概要」を参照してください。
セッション・マネージャには、2つの主な機能があります。すなわち、セッションのインスタンスを作成することと、各名前付きセッションの1つのインスタンスのみがセッション・マネージャの任意のインスタンスに対して存在することを保証することです。
セッション・マネージャは、EJBアプリケーションでは特に便利です。Enterprise Beanがセッション・マネージャを取得でき、そこから目的のセッションを取得できるためです。
クライアント・アプリケーションでは、セッションが必要なときに、TopLinkのセッション・マネージャにセッションをリクエストします。セッション・マネージャの2つの主な機能は、サーバーに対するTopLinkのセッションをインスタンス化すること、およびアプリケーションが存続する間セッションを保持することです。セッション・マネージャでは、sessions.xmlファイルの構成情報に基づいて、データベース・セッション、サーバー・セッション、またはセッション・ブローカをインスタンス化します。
セッション・マネージャでは、次のようにセッションをインスタンス化します。
クライアント・アプリケーションが名前を使用してセッションを要求します。
セッション・マネージャは、sessions.xmlファイルでセッション名を検索します。セッション名がある場合、セッション・マネージャは指定されたセッションをインスタンス化します。セッション名がない場合、例外をスローします。
インスタンス化の後、セッションは、アプリケーションが停止されるまで実行可能です。
セッション・マネージャからセッションを取得し、クライアント・セッションまたはセッション内の作業ユニットを使用してすべての永続性操作を実行することをお薦めします。
サーバー・セッションまたはサーバー・セッションを含むセッション・ブローカの場合は、セッションを取得した後、そこからクライアント・セッションを取得します。所定のサーバー・セッション（またはサーバー・セッションを含むセッション・ブローカ）から、存在するクライアントと同じ数だけクライアント・セッションを取得できます。
各クライアントでは、そのクライアント・セッションから作業ユニットを取得し、その作業ユニットを使用してすべての永続性操作を実行することで、容易に同時アクセスと参照制約を管理できます。
TopLinkでは、セッション・マネージャ・クラスのインスタンスを1つのみ保持します。シングルトン・セッション・マネージャでは、実行時、すべてのTopLinkの名前付きセッションを保持します。アプリケーションがセッションを名前で要求すると、セッション・マネージャは、指定されたセッションを該当する構成ファイルから取得します。
例90-1に示すように、セッション・マネージャ・インスタンスにアクセスするには、oracle.toplink.tools.sessionmanagement.SessionManagerメソッドgetManagerを使用します。次に、セッション・マネージャのインスタンスを使用して、TopLinkのセッションをロードできます。
セッション・マネージャは、そのキャッシュに未格納のセッションをロードする際、該当するセッション・タイプのインスタンスを作成し、sessions.xmlファイルの構成に基づいて構成します。
|
注意: インスタンス化されるセッション・タイプに関連付けられたメソッドを完全に活用するには、getSessionメソッドから返されるセッションをキャストします。このタイプは、名前付きセッションのsessions.xmlファイルに定義されているセッション・タイプと一致する必要があります。 |
この項の内容は次のとおりです。
Oracle JDeveloperまたはTopLink Workbenchによって作成されたセッション・インスタンスをすべて含んだ、単一のセッション構成ファイル（sessions.xml）がある場合は、セッションを名指しでロードできます（例90-2を参照）。
例90-2 デフォルトを使用したセッション・マネージャからの名前付きセッションの取得
// Load a named session (mysession) defined in the sessions.xml file
SessionManager manager = SessionManager.getManager();
Session session = manager.getSession("mysession");
この例では、セッション・マネージャの次のデフォルト構成が適用されます。
クラス・ローダー: スレッドベースのクラス・ローダーを使用してsessions.xmlリソースを検索、ロードし、sessions.xmlおよびproject.xmlファイル内で参照されているクラスを解決します。
アプリケーション・クラスでセッションを取得する場合、クラス・ローダーにはアプリケーションのクラス・ローダーを使用することが一般的ですが、これは間違いではありません。Java EEアプリケーションの場合には、sessions.xmlファイルがデプロイされているのと同じJARファイルに含まれるクラスにあるクラス・ローダーを使用するのが最も適しています。
ファイル: デフォルトでは、クラス・ローダーのルート・ディレクトリにあるsessions.xmlという名前のファイルが使用されます。
このファイルに別の名前が付けられているかこのルート・ディレクトリにない場合は、そのルート・ディレクトリからの相対パスを指定する必要があります。Javaでの相対リソース・パスには、\ではなく、/を使用する必要があります。
セッション名: getSessionコールに渡される名前。
この名前は、そのアプリケーション内のみでなくアプリケーション・サーバー全体で一意である必要があります。
ログイン: true。セッションはデフォルトで接続されます。
ログイン前に手動でセッションを構成する場合は、このオプションをfalseに設定します（90.3.4項「ログインなしでのセッションのロード方法」を参照）。
リフレッシュ: false。すでにロード済の場合は、同じセッションが返されます。
リフレッシュを使用するのは、既存のセッションが使用されていないことがわかっており、Java EE環境への再デプロイなど構成が変更された場合のみにしてください。
クラス・ローダーの検証: false。クラス・ローダーが変更されている場合、セッション・マネージャはセッションをリフレッシュしません。
これは通常、trueに設定する必要があります。Java EE環境では、稼働中のアプリケーション・サーバーへのホット・デプロイまたは再デプロイが必要な場合には、trueに設定する必要があります（90.3.6項「クラス・ローダー変更時のセッションのリフレッシュ方法」を参照）。
代替クラス・ローダーを使用してセッションをロードできます。これは、TopLinkアプリケーションがJava EEコンテナと統合される場合に一般的です。セッション・マネージャでは、クラス・ローダーを使用してsessions.xmlリソースを検索、ロードし、sessions.xmlおよびproject.xmlファイル内で参照されているクラスを解決します。
通常、現在のスレッド・コンテキストのクラス・ローダーを使用します（例90-3を参照）。この例では、セッションmysessionは、現在のスレッド・コンテキストのクラス・ローダーを使用して、アプリケーション・クラスパスにおいて最初に遭遇するsessions.xmlという名前のファイルを使用してロードされます。
例90-3 現在のスレッド・コンテキストのクラス・ローダーを使用したセッションのロード
/* Use the specified ClassLoader to load a session (mysession) defined in the sessions.xml file */ SessionManager manager = SessionManager.getManager(); Session session = manager.getSession( "mysession", // session name to load Thread.current().getContextClassLoader() // ClassLoader instance to use );
ただし、Java EEコンテナがこのスレッド・コンテキスト・クラス・ローダーの使用をサポートしていない場合は、現在のクラスのクラス・ローダーを使用できます（例90-4を参照）。
例90-4 現在のクラスのクラス・ローダーを使用したセッションのロード
/* Use the specified ClassLoader to load a session (mysession) defined in the sessions.xml file */ SessionManager manager = SessionManager.getManager(); Session session = manager.getSession( "mysession", // session name to load this.getClass().getClassLoader() // ClassLoader instance to use );
|
注意: Oracle Containers for Java EEでは、現在のスレッドのクラス・ローダーの使用がサポートされています。 |
セッション・インスタンスが一意名を持った複数のセッション構成ファイル（sessions.xmlファイル）に含まれている場合は、XMLSessionConfigLoaderオブジェクトを明示的に作成する必要があります。このオブジェクトは、sessions.xmlファイルの名前で初期設定され、SessionManagerメソッドgetSessionにそのXMLSessionConfigLoaderを渡します（例90-5を参照）。
指定するファイルのパスは、クラス・ローダーのルート・ディレクトリからの相対パスです。Javaでの相対リソース・パスには、バックスラッシュ（\）ではなく、スラッシュ（/）を使用する必要があります。
この例では、セッションmysessionは、アプリケーション・クラスパスにおいて最初に遭遇するtoplink-sessions.xmlという名前のファイルを使用して、指定されたクラス・ローダーによってロードされます。
XMLSessionConfigLoader（90.3.3項「代替セッション構成ファイルからのセッションのロード方法」を参照）を使用すると、Sessionメソッドloginを起動せずに、SessionManagerメソッドgetSessionを使用して、セッションをコールできます（例90-6を参照）。これにより、アプリケーションにログインしたまま、使用するセッションを準備できます。
例90-6 ログインなしのセッションのオープン
SessionManager manager = SessionManager.getManager();
Session session = manager.getSession(
new XMLSessionConfigLoader(), // XMLSessionConfigLoader (sessions.xml file)
"mysession", // session name
YourApplicationClass.getClassLoader(), // class loader
false, // do not log in session
false); // do not refresh session
sessions.xmlファイルを基に既存のセッションをリフレッシュするよう、セッション・マネージャに指示できます。通常、この方法はこれまで、Java EE環境での再デプロイ時、または稼働サーバーのリセット後にのみ使用されていました。このオプションは、既存のセッションが使用されていないことがわかっている場合にのみ使用してください。
例90-7 sessions.xmlファイルの再分析の実行
//In this example, XMLSessionConfigLoader loads sessions.xml from the classpath SessionManager manager = SessionManager.getManager(); Session session = manager.getSession( new XMLSessionConfigLoader(), // XMLSessionConfigLoader (sessions.xml file) "mysession", // session name YourApplicationClass.getClassLoader(), // class loader true, // log in session true // refresh session );
管理対象外（POJO）のJava EE環境では、稼働中のアプリケーション・サーバーへのホット・デプロイまたは再デプロイが必要な際に、クラス・ローダーが変更された場合にセッションをリフレッシュするよう、セッション・マネージャに指示する必要があります（例90-8を参照）。この方法を使用すると、アプリケーションを再デプロイするときに発生するクラス・ローダー変更の際に、セッション・マネージャによりセッションがリフレッシュされます。このオプションをtrueに設定した場合は、常に同じクラス・ローダーを使用してセッションが取得されます。
例90-8 sessions.xmlファイルの再分析の実行
//In this example, XMLSessionConfigLoader loads sessions.xml from the classpath SessionManager manager = SessionManager.getManager(); Session session = manager.getSession( new XMLSessionConfigLoader(), // XMLSessionConfigLoader (sessions.xml file) "mysession", // session name YourApplicationClass.getClassLoader(), // class loader true, // log in session false, // do not refresh session when loaded true // do refresh session if class loader changes );
CMP Java EE環境では、これは、TopLinkランタイムとCMPの統合により自動的に処理されます。
クライアント・セッションを取得するには、最初にセッション・マネージャを使用してサーバー・セッション、またはサーバー・セッションを含んだセッション・ブローカを取得する必要があります（90.3項「セッション・マネージャからのセッションの取得」を参照）。
表90-1では、サーバー・セッションおよびサーバー・セッションを含んだセッション・ブローカから各種のクライアント・セッションを取得するメソッドを示します。
表90-1 クライアント・セッションを取得するメソッド
| クライアント・セッション | サーバー・セッションのメソッド | セッション・ブローカ・セッションのメソッド |
|---|---|---|
|
通常または独立 |
|
|
|
通常または独立 |
|
適用しない |
|
履歴 |
|
acquireHistoricalSession(AsOfClause) |
acquireClientSessionメソッドではタイプClientSessionのセッションが返されます。
acquireClientSessionBrokerメソッドではタイプSessionBrokerのセッションが返されます。
いずれの場合も、返されたオブジェクトをタイプSessionにキャストし、他のセッションと同様の方法で使用してください。
詳細は、次を参照してください。
TopLinkプロジェクトのすべてのクラスを独立として（117.11項「プロジェクト・レベルでのキャッシュ分離機能の構成」を参照）、または1つ以上のクラスを独立として（119.13項「ディスクリプタ・レベルでのキャッシュ分離機能の構成」を参照）構成すると、親サーバー・セッションから取得するすべてのクライアント・セッションが独立クライアント・セッションになります（87.5項「独立クライアント・セッション」を参照）。
ConnectionPolicyを使用すると、排他接続を使用する独立クライアント・セッションを取得できます（90.4.2項「排他接続を使用するクライアント・セッションの取得方法」を参照）。この独立クライアント・セッションは、Oracle Virtual Private Database（VPD）機能で使用する接続プロパティを使用して構成できます（90.4.3項「接続プロパティを使用するクライアント・セッションの取得方法」を参照）。通常、ユーザーの資格証明をOracleデータベースに渡す場合は、Oracleデータベースのプロキシ認証を使用します。Oracleデータベースのプロキシ認証の詳細は、96.1.4.2項「Oracleデータベースのプロキシ認証」を参照してください。
VPDの詳細は、87.5.1項「独立クライアント・セッションとOracle Virtual Private Database（VPD）」を参照してください。
例90-9は、排他接続を使用するクライアント・セッションを取得するようにConnectionPolicyを構成して、そのポリシーを使用する方法を示します。
例90-9 接続プロパティを使用するクライアント・セッションの取得
ConnectionPolicy connectionPolicy = new ConnectionPolicy(); // Use an exclusive connection for the session connectionPolicy.setShouldUseExclusiveConnection(true); Session clientSession = server.acquireClientSession(connectionPolicy); // By default, an exclusive connection will be acquired lazily
排他接続は、共有接続プールから割り当てられます。排他接続は、それを取得するクライアント・セッション専用です。
|
注意: 通常、クライアント・セッションのライフ・サイクルは、サーバー・リクエストの持続期間に相当します。ただし、JTAを使用する場合は、JTAトランザクションのライフ・サイクルになります。クライアント・セッションは、JTAトランザクション境界にまたがって維持できません。トランザクションで作業ユニットを使用せず、排他接続を使用するようクライアント・セッションを構成する場合（第92章「Virtual Private Database用の排他独立クライアント・セッションの構成」を参照）、セッションを明示的に取得し、使用後に解放する必要があります。ガベージ・コレクションの実行時にセッションを解放するファイナライザをクライアント・セッションが保持していても、ファイナライザに依存してアプリケーションで排他クライアント・セッション（または非遅延セッション）を解放し、データ・ソース接続を解放しないでください。このセッション解放の要件は、JTAに固有のものではありません。 作業ユニットを使用する場合は（第115章「作業ユニットの拡張APIの使用」を参照）、JTAトランザクションの終了時に作業ユニットが常に自動的にクライアント・セッションを解放するため、クライアント・セッションの解放について考慮する必要はありません。 |
名前付き問合せでも排他接続を使用できます（119.7.1.10項「名前付き問合せの詳細オプションの構成」を参照）。
詳細は、次を参照してください。
例90-10は、接続プロパティを使用するクライアント・セッションを取得するようにConnectionPolicyを構成して、そのポリシーを使用する方法を示します。この例では、接続プロパティはOracle VPD機能によって使用されています（87.5.1項「独立クライアント・セッションとOracle Virtual Private Database（VPD）」を参照）。接続プロパティは他のアプリケーション用にも使用できます。
例90-10 接続プロパティを使用する独立セッションの取得
ConnectionPolicy connectionPolicy = new ConnectionPolicy();
// Set VPD specific properties to be used in the events
connectionPolicy.setProperty("userLevel", new Integer(5));
Session clientSession = server.acquireClientSession(connectionPolicy);
詳細は、89.12項「接続ポリシーの構成」を参照してください。
名前付き接続プールを使用するクライアント・セッションを取得する場合は、最初に名前付き接続プールを使用するセッションを構成する必要があります。名前付き接続プールの詳細は、96.1.6.5項「アプリケーション固有の接続プール」を参照してください。名前付き接続プールの作成の詳細は、100.1項「内部接続プールの作成の概要」を参照してください。
名前付き接続プールを使用するクライアント・セッションを取得するには、ServerメソッドacquireClientSessionに、目的の接続プールを指定したConnectionPolicyを渡します。取得されたClientSessionでは、指定されたプールからの接続を書込み用に使用します（読取りはまだServer読取り接続プールからの接続を使用して行われます）。
例90-11は、名前付き接続プールmyConnectionPoolを使用するようにConnectionPolicyを構成する方法を示します。
例90-11 名前付き接続プールを使用するクライアント・セッションの取得
// Assuming you created a connection pool named "myConnectionPool"
Session clientSession = server.acquireClientSession(
new ConnectionPolicy("myConnectionPool")
);
詳細は、89.12項「接続ポリシーの構成」を参照してください。
デフォルトではサーバー・セッションは、トランザクションが開始されるまでクライアント・セッションに対してデータ・ソース接続を割り当てません（遅延データ・ソース接続）。あるいは、ただちに接続を割り当てるクライアント・セッションを取得することもできます。
例90-12は、ConnectionPolicyを構成して、遅延接続割当てを使用しないように指定する方法を示します。
例90-12 遅延接続を使用しないクライアント・セッションの取得
ConnectionPolicy connectionPolicy = new ConnectionPolicy(); connectionPolicy.setIsLazy(false); Session clientSession = server.acquireClientSession(connectionPolicy);
詳細は、89.12項「接続ポリシーの構成」を参照してください。
履歴データにアクセスするようにTopLinkを構成すると（93.1項「履歴セッション構成の概要」を参照）、任意のセッション・タイプを使用して履歴データを問合せできます。
通常のクライアント・セッションまたはデータベース・セッションを使用して履歴データを問い合せるときは、セッション・キャッシュが古い（履歴）データで破損されないように常にObjectLevelReadQueryメソッドmaintainCacheをfalseに設定する必要があります。なお、現在のオブジェクト・バージョンと履歴のオブジェクト・バージョンのどちらについても、問い合せることは可能です。
TopLinkでは、このプロセスを簡素化する便を計るため、履歴セッションが用意されています。履歴セッションを使用して履歴データを問い合せるときは、ObjectLevelReadQueryメソッドmaintainCacheをfalseに設定する必要はありません。ただし、問合せできるのは、指定した時刻時点で存在していたオブジェクトのみです。
履歴セッションを取得する場合は、最初にセッション・マネージャを使用してサーバー・セッションを取得します。
ServerメソッドacquireHistoricalSessionをAsOfClause付きで使用して、履歴セッションを取得します。
AsOfClauseには時刻を指定します。履歴セッションに対して実行されるすべての問合せと式では、この時刻以降に存在していたオブジェクトが問合せ対象になります。履歴セッションのキャッシュは、指定された時刻の時点で存在する各オブジェクト・バージョンの読取り専用スナップショットです。そのキャッシュは、親サーバー・セッションの共有オブジェクト・キャッシュからは分離しています。
セッションを使用するには、最初にSessionメソッドloginを使用してセッションにログインする必要があります。
デフォルトでは、セッション・マネージャを使用してセッションをロードすると、TopLinkではゼロ引数のloginメソッドを使用してセッションに自動的にログインします。セッションに自動ログインせずにセッションをロードする方法については、90.3.4項「ログインなしでのセッションのロード方法」を参照してください。
ログインなしでセッションをロードするには、loginメソッドの次のいずれかのシグネチャを選択します。
login(): 対応するsessions.xmlファイルで定義されたLogin、ユーザー名およびパスワードを使用します。
login(Login login): 対応するsessions.xmlファイル内に定義済のLoginを、指定されたLoginでオーバーライドします。
login(String username, String password): 対応するsessions.xmlファイル内に定義済のユーザー名およびパスワードを、指定されたユーザー名およびパスワードでオーバーライドします。
セッション・ブローカにログインすると、セッション・ブローカは、含まれるセッションすべてにログインし、セッションのディスクリプタを初期化します。ログイン後、セッション・ブローカは標準のセッションのように見え、機能します。TopLinkでは、複数データベース・アクセスが透過的に処理されます。
セッションAPIを使用したキャッシュの詳細は、第102章「キャッシュの概要」を参照してください。
セッションAPIを使用した問合せの詳細は、第108章「TopLink問合せの概要」を参照してください。
セッションAPIを使用したトランザクションの詳細は、第113章「TopLinkトランザクションの概要」を参照してください。
サーバー・セッション、セッション・ブローカ・セッションまたはデータベース・セッションの使用後は、Sessionメソッドlogoutを使用してセッションからログアウトする必要があります。セッション・ブローカからログアウトすると、セッションは、セッション・ブローカに登録されたすべてのセッションからログアウトします。
クライアント・セッションの使用後は、Sessionメソッドreleaseを使用してセッションを解放する必要があります。
SessionメソッドsetIsFinalizersEnabled(true)を使用してセッションが解放されるように、ファイナライザを使用してSessionを構成できます。デフォルトでは、ファイナライザは無効になっています。セッションに対してファイナライザを有効にするのは、あくまで最後の手段です。必ずセッションからログアウトまたはセッションを解放することをお薦めします。
Oracle JDeveloperまたはTopLink Workbenchのセッション・インスタンスはすべて、1つ以上のsessions.xmlファイルにエクスポートすることをお薦めしますが、こうするかわりに、アプリケーションにセッションを手動で作成して、SessionManagerメソッドaddSessionでセッション・マネージャに手動で格納することもできます（例90-13を参照）。これにより、SessionManagerメソッドgetSessionを使用してセッションを名指しで取得できます。
|
注意: セッション構成ファイルからセッションをロードする場合、addSessionメソッドは必要ありません。 |
例90-13 セッション・マネージャでの手動によるセッションの格納
// create and log in to the session programmatically Session theSession = project.createDatabaseSession(); theSession.login(); // store the session in the SessionManager instance SessionManager manager = SessionManager.getManager(); manager.addSession("mysession", theSession); // retrieve the session Session session = SessionManager.getManager().getSession("mysession");
セッションを個々に名指しで破棄することも、すべてのセッションを破棄することもできます。
|
注意: これを実行するのは、Java EEアプリケーションがアンデプロイされたときか、アプリケーション全体が停止されたとき、およびセッションが使用されていないことがわかったときのみにしてください。破棄する前にセッションからログアウトしてください（90.8項「セッションからのログアウト」を参照）。セッションからログアウトしない場合は、セッションを破棄するために使用しているセッション・マネージャにより、セッションからログアウトさせられます。 |
特定のセッション・インスタンスを名指しで破棄するには、SessionManagerメソッドdestroySessionを使用します（例90-14を参照）。指定したセッションがセッション・マネージャのキャッシュにない場合は、ValidationExceptionがスローされます。
例90-14 セッション・マネージャでのセッションの破棄
SessionManager manager = SessionManager.getManager();
Server server = (Server) manager.getSession("myserversession");
…
// Destroy session by name. If the session named myserversession is not in the
// session manager cache, throw a ValidationException
manager.destroySession("myserversession");
すべてのセッション・インスタンスを破棄するには、SessionManagerメソッドdestoryAllSessionsを使用します（例90-15を参照）。
例90-15 セッション・マネージャでのすべてのセッションの破棄
SessionManager manager = SessionManager.getManager();
Server server = (Server) manager.getSession("myserversession");
SessionBroker broker = (SessionBroker) manager.getSession("mysessionbroker");
…
// Destroy all sessions stored in the session manager
manager.destroyAllSessions();
