この章では、CoherenceクラスタでASP.NETセッション状態を管理する手順について説明します。手順には、Coherenceセッション・プロバイダを有効にして構成する方法が含まれます。
注意: 以前のバージョンのCoherence for .NETに含まれていたCoherenceセッション・プロバイダは非推奨になり、この章で説明するCoherenceセッション・プロバイダに置き換えられています。 |
この章は次の各項で構成されています。
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つはセッション・オーバーフロー用)を作成します。
<cache-config> <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セッション・リモート・キャッシュ・スキームを構成します。
<cache-config> <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>9099</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セッション・プロバイダでどのように物理的に表現し、保存するかを記述します。プロバイダは、次の3つのすぐに使用できる様々なセッション・モデル実装を備えています。
トラディショナル・モデル: すべてのセッション状態を単一のエンティティとして保存しますが、属性は個別にシリアライズおよびデシリアライズします。
モノリシック・モデル: すべてのセッション状態を単一のエンティティとして保存し、すべての属性を単一の操作でシリアライズおよびデシリアライズします。
スプリット・モデル: トラディショナル・モデルを拡張したモデルですが、大きなセッション属性は独立した複数の物理エンティティに分離します。
トラディショナル・モデルがデフォルトの設定です。これはASP.NETのSessionStateItemCollection
に類似しています。アクセスされない項目のデシリアライズの問題を回避するために、セッション項目を時間をかけてデシリアライズします。ただし、モノリシック・モデルまたはスプリット・モデルを選択したほうがよい場合もあります。
各モデルおよびそれぞれの利点と欠点の詳細は、『Oracle Coherence Oracle Coherence*Webユーザーズ・ガイド』のセッション・モデルに関する項を参照してください。そこでの説明は、特定のアプリケーションに最適なモデルを決定する際に役立つ場合があります。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の使用手順の詳細は、第20章「.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を確実に共有するようにします。