| Oracle® Fusion Middleware Oracle Coherenceリモート・クライアントの開発 12c (12.2.1.1) E77321-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
Coherence for .NETを使用すると、CoherenceクラスタでASP.NETセッション状態を管理できます。これには、Microsoftが提供する初期状態のオプションと比較して、次のようないくつかの利点があります。
可用性の高いCoherenceクラスタにセッション状態が格納されるため、Webサーバーの障害に対するセッションの回復力が高まります。
セッションがメモリーに格納されるため、SQL Serverセッション・プロバイダを使用してディスクに対してシリアライズする場合よりもアクセスが大幅に高速になります。
リレーショナル・データベースとは異なり、Coherenceクラスタは簡単にスケール・アウトして負荷の増加に対応できます。
場合によっては、Coherenceのニア・キャッシュ機能を利用することにより、インプロセス速度でセッション・データにアクセスできます。
ASP.NETアプリケーションは、web.configファイルを変更し、カスタムのセッション状態プロバイダを構成することにより、Coherenceを使用してセッション状態を管理するように構成されます。また、Coherenceセッション・プロバイダに含まれている構成オプションを使用すると、アプリケーションのパフォーマンスおよびスケーラビリティを大幅に向上できます。
Coherenceを使用してASP.NETセッションを管理するには、次の手順が必要です。
オペレーション構成、キャッシュ構成およびPOF構成ファイル(POFを使用してセッションをシリアライズする場合)を指定することにより、Coherence for .NETクライアント・ライブラリを構成します。詳細は、「Coherence .NETクライアント・ライブラリの設定」を参照してください。
ASP.NETアプリケーションおよびクラスタを適切に構成したら、アプリケーションで使用するクラスタ・サーバーとプロキシ・サーバーを起動して、ASP.NET Webアプリケーションを起動します。セッションはCoherenceクラスタ内に自動的に格納されます。
ASP.NETでは、プロバイダ・モデルを使用して、カスタムのセッション状態管理を実装できます。Coherence for .NETは、Microsoftが定義している規定を満たすカスタム・プロバイダを実装します。Coherenceプロバイダを使用するには、アプリケーションのweb.configファイルに次のプロバイダ構成を追加します。
<system.web> <sessionState mode="Custom" customProvider="CoherenceSessionProvider" cookieless="false" timeout="20"> <providers> <add name="CoherenceSessionProvider" type="Tangosol.Web.CoherenceSessionStore, Coherence"/> </providers> </sessionState> ... </system.web>
前述の例では、CoherenceSessionStoreプロバイダをデフォルト設定で使用するように、ASP.NETアプリケーションを構成します。Coherenceセッション・プロバイダは、組み込まれた機能をフル活用するために、この章で説明するようにカスタマイズできます。
Coherenceセッション・プロバイダでは、記憶域キャッシュとオーバーフロー・キャッシュの2つのキャッシュ・スキーム定義がクラスタのキャッシュ構成ファイル内に必要です。記憶域キャッシュはセッション・データの保存に使用し、オーバーフロー・キャッシュはセッションのサイズがWeb.configファイルで定義されているCoherenceSessionProviderのexternalAttributeSize属性で指定されている制限を超えた場合に使用されます。
セッションの記憶域キャッシュとセッション・オーバーフロー・キャッシュを定義するときは、サービス名はAspNetSessionCache、キャッシュ名はそれぞれaspnet-session-storageおよびaspnet-session-overflowとする必要があります。また、記憶域キャッシュは、ConfigurablePofContextクラスをシリアライザとして使用するように構成する必要があります。スキーム名とバッキング・マップ構成は、必要に応じて構成できます。
次のキャッシュ・スキーム定義では、セッション・プロバイダで使用する2つの分散キャッシュ(1つはセッションの記憶域用、1つはセッション・オーバーフロー用)を作成します。
<?xml version='1.0'?>
<cache-config xmlns="http://schemas.tangosol.com/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.tangosol.com/cache
assembly://Coherence/Tangosol.Config/cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>aspnet-session-storage</cache-name>
<scheme-name>aspnet-session-scheme</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>aspnet-session-overflow</cache-name>
<scheme-name>aspnet-session-overflow-scheme</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<distributed-scheme>
<scheme-name>aspnet-session-scheme</scheme-name>
<service-name>AspNetSessionCache</service-name>
<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>coherence-pof-config.xml</param-value>
</init-param>
</init-params>
</serializer>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<distributed-scheme>
<scheme-name>aspnet-session-overflow-scheme</scheme-name>
<scheme-ref>dist-default</scheme-ref>
<service-name>AspNetSessionCache</service-name>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>
Coherenceセッション・プロバイダでは、Extendクライアントのキャッシュ構成ファイルに、セッション記憶域キャッシュ用とセッション・オーバーフロー・キャッシュ用のリモート・キャッシュ・スキームを含める必要があります。他のリモート・キャッシュと同様に、クラスタ上のキャッシュとクライアント上のキャッシュでは同じ名前を使用する必要があります。詳細は、「リモート・キャッシュの定義」を参照してください。
次の例では、Coherenceセッション・プロバイダでクラスタにセッション・データを格納する際に使用する、クライアント側のASPセッション・リモート・キャッシュ・スキームを構成します。
<?xml version='1.0'?>
<cache-config xmlns="http://schemas.tangosol.com/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.tangosol.com/cache
assembly://Coherence/Tangosol.Config/cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>aspnet-session-storage</cache-name>
<scheme-name>extend-direct</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>aspnet-session-overflow</cache-name>
<scheme-name>extend-direct</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend-direct</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>localhost</address>
<port>7077</port>
</socket-address>
</remote-addresses>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>30s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>
Coherenceセッション・プロバイダのデフォルトの動作では、aspnet-session-storageという名前のリモート・セッション・キャッシュが使用されます。「クライアント側のASPセッション・リモート・キャッシュの構成」のリモート・キャッシュの例は、デフォルト名でリモート・キャッシュを作成しています。また、セッション・プロバイダは、デフォルト以外の名前のリモート・キャッシュを使用するように構成できます。
デフォルトのセッション・キャッシュ名をオーバーライドするには、プロバイダの構成内にcacheName属性を追加します。次の例では、my-session-cacheという名前のキャッシュを指定しています。
<system.web>
<sessionState mode="Custom"
customProvider="CoherenceSessionProvider"
cookieless="false"
timeout="20">
<providers>
<add name="CoherenceSessionProvider"
type="Tangosol.Web.CoherenceSessionStore, Coherence"/>
cacheName="my-session-cache"
</providers>
</sessionState>
...
</system.web>
セッション・モデルは、クラスタ内のセッション状態をCoherenceセッション・プロバイダでどのように物理的に表現し、保存するかを記述します。プロバイダは、次の3つの異なる即時利用可能なセッション・モデル実装を備えています。
トラディショナル・モデル - すべてのセッション状態を単一のエンティティとして保存しますが、属性は個別にシリアライズおよびデシリアライズします。
モノリシック・モデル - すべてのセッション状態を単一のエンティティとして保存し、すべての属性を単一の操作でシリアライズおよびデシリアライズします。
スプリット・モデル - トラディショナル・モデルを拡張したモデルですが、大きなセッション属性は独立した複数の物理エンティティに分離します。
トラディショナル・モデルがデフォルトの設定です。これはASP.NETのSessionStateItemCollectionに類似しています。アクセスされない項目のデシリアライズの問題を回避するために、時間をかけてセッション項目をデシリアライズします。ただし、モノリシック・モデルまたはスプリット・モデルを選択した方がよい場合もあります。
各モデルの利点と不利な点については、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のセッション・モデルに関する項を参照してください。そこでの説明は、特定のアプリケーションに最適なモデルを決定する際に役立つ場合があります。Coherence*Webを中心に説明されていますが、一般的な概念はASP.NETセッションと同じです。
スプリット・モデルは、ほとんどのアプリケーションにお薦めできるセッション・モデルです。ただし、HTTPセッション・オブジェクトが小型であることがわかっているアプリケーションには、トラディショナル・モデルの方が適してる場合があります。
モノリシック・モデルは、複数のセッション属性で1つの共有オブジェクトを参照し、そのオブジェクトを共有オブジェクトとして維持する必要がある場合、それら複数のセッション属性に関連する特定のクラスの問題を解決することを目的としています。ASP.NET InProcプロバイダからCoherenceセッション・プロバイダに移行する場合には、モノリシック・モデルを使用すると、すべての共有オブジェクトが適切にシリアライズおよびデシリアライズされます。
Coherenceセッション・プロバイダのセッション・モデルを指定するには、プロバイダの構成内にmodel属性を追加します。次の例ではsplitモデルを指定します。
<system.web>
<sessionState mode="Custom"
customProvider="CoherenceSessionProvider"
cookieless="false"
timeout="20">
<providers>
<add name="CoherenceSessionProvider"
type="Tangosol.Web.CoherenceSessionStore, Coherence"
model="split"
externalAttributeSize="512"/>
</providers>
</sessionState>
...
</system.web>
model属性の有効な値は、traditional、monolithic、split、またはTangosol.Web.ISessionModelManagerインタフェースを実装し、単一のTangosol.IO.ISerializer引数を受け入れるコンストラクタを提供するクラスの完全修飾名です。このインタフェースでは、必要に応じてカスタム・モデル実装を作成できます。
前述の例では、セッション・プロバイダはsplitモデルを使用するように構成されます。スプリット・モデルはexternalAttributeSize属性をサポートしています。この属性では、個々に保存する必要のある属性の最小サイズ(バイト数)を指定します。externalAttributeSize属性の指定を省略すると、デフォルト値である1024バイトが使用されます。
スプリット・セッション・モデルを使用すると、セッションの属性は2つのリージョンにパーティション化されます。セッションID、作成時刻、最終アクセスなどの主要なHTTPセッション属性は一方のパーティション内で管理され、大型の属性はもう一方のパーティションに分割されます。これにより、小型の属性に頻繁にアクセスすることによってオーバーヘッドが生じることなく、非常に大型のHTTPセッション・オブジェクトをサポートできます。
.NETセッション・プロバイダの実装では、主要な属性と大型の属性は別々のキャッシュに格納されます。したがって、両方のキャッシュの同期を維持するために、バッキング・マップ・リスナー(AspNetSessionStoreProvider$SessionCleanupListenerクラス)をお薦めします。これにより、セッションがユーザーによって明示的に終了された場合およびエビクションまたは失効によって削除された場合、セッションの主要セグメントと大型セグメントの両方が、2つのキャッシュから一貫して削除されます。
次の例は、クラスタ側のASP .NETセッション・キャッシュでAspNetSessionStoreProvider$SessionCleanupListenerバッキング・マップ・リスナーを登録する方法を示しています。
<caching-schemes>
<distributed-scheme>
<scheme-name>aspnet-session-scheme</scheme-name>
<service-name>AspNetSessionCache</service-name>
<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>coherence-pof-config.xml</param-value>
</init-param>
</init-params>
</serializer>
<backing-map-scheme>
<local-scheme>
<class-name>com.tangosol.net.cache.LocalCache</class-name>
<listener>
<class-scheme>
<class-name>
com.tangosol.net.internal.AspNetSessionStoreProvider$SessionCleanupListener
</class-name>
<init-params>
<init-param>
<param-type>
com.tangosol.net.BackingMapManagerContext
</param-type>
<param-value>{manager-context}</param-value>
</init-param>
</init-params>
</class-scheme>
</listener>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
Coherenceセッション・プロバイダは、特定のシリアライザを使用してセッション項目をシリアライズするように構成できます。シリアライザを指定するには、プロバイダの定義内にserializer属性を追加します。次の例では、binaryシリアライザを指定します。
<system.web>
<sessionState mode="Custom"
customProvider="CoherenceSessionProvider"
cookieless="false"
timeout="20">
<providers>
<add name="CoherenceSessionProvider"
type="Tangosol.Web.CoherenceSessionStore, Coherence"
model="split"
externalAttributeSize="512"
serializer="binary"/>
</providers>
</sessionState>
...
</system.web>
serializer属性の有効な値は、binary(デフォルト)、pof、または、Tangosol.IO.ISerializerインタフェースを実装するクラスの完全修飾名です。必要に応じて、このインタフェースを使用してカスタム・シリアライザを作成します。ただし、多くの場合は、既存のシリアライザで十分です。
Portable Object Format (POF)は、Coherenceを使用してASP.NETセッションを管理する場合に推奨されるシリアライズ形式であり、標準の.NETバイナリ・シリアライズと比べて多くの利点があります。特に、POFシリアライズの方が高速で、圧縮率の高い形式です。圧縮形式は、通常、標準のバイナリ・シリアライザの3分の1から5分の1のバイナリになります。このことは、クラスタ内のメモリーのフットプリントを小さくすることに直結し、コストを大幅に削減できます。
POFを使用するには、セッション内に直接または間接的に格納されているすべてのカスタム・クラスがPOFコンテキスト内で登録されていることを確認し、IPortableObjectインタフェースを実装するか、外部のIPofSerializerを構成します。POFの使用手順の詳細は、統合オブジェクトの構築(.NET)を参照してください。
次の説明では、POFを使用する際に考慮する必要のある実装の詳細をいくつかまとめます。POF形式の詳細は、『Oracle Coherenceでのアプリケーションの開発』の付録のPIF-POFバイナリ形式に関する項を参照してください。
セッション項目がPOFシリアライザによってデシリアライズされた場合、生成されるオブジェクトの型が元の値の型と同じになるという保証はありません。たとえば、-1から22の整数値は、元の型とは関係なくInt32の値として返されるため、適切な型へのキャストが必要になる場合があります。
コレクションも別の型にデシリアライズされる場合があります。たとえば、ArrayListがセッション内に格納されているものの、オブジェクトを読み戻した後で不変オブジェクト配列が受信される場合があります。これは必要な動作であり、POFストリームからコレクションを読み取るすべてのメソッドに対して、IPofReaderインタフェースが値を読み取るテンプレートを引数として提供する理由でもあります。
セッション項目は型指定されないため、デシリアライズ方法を指定する方法はありません。したがって、デフォルトのコレクション型がつねに受信されます。これは、コレクションから読み取る場合は通常受入れ可能です。ただし、コレクションを変更する必要がある場合は、次の2つのうちいずれかのオプションを使用できます。
必要な型の可変コレクションのインスタンスを作成し、デシリアライズしたコレクションから要素を追加します。このオプションを使用する場合は、忘れずに、対応するセッション項目を新しいコレクションで更新してください。そうしないと、変更は保存されません。
ベア・コレクションを直接格納するかわりに、必要なシリアライズ・ロジックを実装してPOFコンテキスト内で登録するラッパー・クラスを作成します。これにより、コレクションのシリアライズを完全に制御でき、前述の問題を回避できます。
この手順には追加の作業が必要ですが、パフォーマンスが向上し、メモリー・フットプリントを削減できるため、手間をかける価値はあります。
複数のASP.NETアプリケーション間でセッションを共有できると有益な場合があります。デフォルトでは、セッション・キーは、アプリケーションID (HostingEnvironment.ApplicationIDプロパティによって返される)とセッションIDを結合することによって特定されます。これにより、セッション共有を効果的に防止できます。
Coherenceセッション・プロバイダは、特定のアプリケーションIDを使用するように構成できます。アプリケーションIDを指定するには、プロバイダ定義内にapplicationId属性を追加します。次の例では、MyApplicationをアプリケーションIDとして指定します。
<system.web>
<sessionState mode="Custom"
customProvider="CoherenceSessionProvider"
cookieless="false"
timeout="20">
<providers>
<add name="CoherenceSessionProvider"
type="Tangosol.Web.CoherenceSessionStore, Coherence"
applicationId="MyApplication"
model="split"
externalAttributeSize="512"
serializer="pof"/>
</providers>
</sessionState>
...
</system.web>
アプリケーション間でセッション共有を有効にするには、同じapplicationIdで複数のアプリケーションを構成し、これらがセッションIDを含むCookieを確実に共有するようにします。
