Udostępnij za pośrednictwem

How to Use Session State Provider (Microsoft Project code named Velocity)

  • Artykuł

Microsoft Distributed Cache code named Velocity ships with a custom Session State provider that use distributed cache to spread session objects across the cluster; thus, providing scalability to your web applications.

To configure SessionStoreProvider in your web apps:

1.       Add <sessionState> element to your app’s web.config file:

 

 

<sessionState  mode="Custom" customProvider="SessionStoreProvider">

  <providers>

     <add name="SessionStoreProvider" type="System.Data.Caching.SessionStoreProvider, ClientLibrary"/>

  </providers>

</sessionState>

 

 

       This means, instead of using default session state provider that ships with asp.net, SessionStoreProvider will be used to read/write session state objects for the app.

2. As the session store provider is a client to distributed cache, it needs to have Velocity client configuration elements. After adding these client configuration elements, “web.config” should look like:

<?xml version="1.0"?>

<configuration>

<configSections>

<section name="dcacheClient" type=" System.Configuration.IgnoreSectionHandler"

allowLocation="true" allowDefinition="Everywhere"/>

</configSections>

<dcacheClient deployment="simple" localCache="false">

<hosts>

<!--List of hosts -->

<host name="<serviceHostName>" cachePort="22233" cacheHostName="DistributedCacheService"/>

</hosts>

</dcacheClient>

<system.web>

<sessionState mode="Custom" customProvider="SessionStoreProvider">

<providers>

<add name="SessionStoreProvider" type="System.Data.Caching.SessionStoreProvider, ClientLibrary"/>

</providers>

</sessionState>

</system.web>

</configuration>

Note : “serviceHostName” is the hostname where distributed cache service is running on cache port “22233”(default setting). Configure these 2 parameters appropriately. Further, this configuration uses a “simple” deployment. By using “routing”, you can further improve the cache performance. For more information on client configuration, please refer product help documentation .

3. Add Reference to dll’s that the session store provider uses , easiest way to do that in a web app is to copy dll’s to the “bin” directory of your web app. Following dll’s need to be copied: CacheBaseLibrary.dll, FabricCommon.dll, ClientLibrary.dll, CASBase.dll, CASClient.dll .

And now your web application is ready to run with the Velocity SessionStoreProvider.

Important:

1. For Velocity Session State provider to work, Cache cluster should be up and running. To learn about to how to deploy Velocity Distributed Cache Cluster, please refer the product documentation.

2. As the provider stores the session objects in out-of-proc distributed cache service, objects that you put in Session should be serializable.

Further Configuration Options:

1. Session objects can be stored on a custom created Named Cache. Using the Administration Tool (Velocity) a Named Cache can be created. Modify the <sessionState> element in your web.config file to use this new custom created Named Cache.

<sessionState mode="Custom" customProvider="SessionStoreProvider">

<providers>

<add name="SessionStoreProvider" type="System.Data.Caching.SessionStoreProvider, ClientLibrary" cacheName="<YourNamedCache>"/>

</providers>

</sessionState>

2. Similarly you can configure to store all the session objects in a region under a Named Cache. Configure the <sessionState> element in the web.config as illustrated below:

<sessionState mode="Custom" customProvider="SessionStoreProvider">

<providers>

<add name="SessionStoreProvider" type="System.Data.Caching.SessionStoreProvider, ClientLibrary"

cacheName="<YourNamedCache>" regionName="<YourRegion>" />

</providers>

</sessionState>

<YourRegion> will be created automatically. Now all the session objects will be stored in <YourRegion> of the named cache <YourNamedCache> . Objects stored on a region will not be load balanced across cache hosts, but will be located on that cache host where the region was created. For this reason, it is not a general recommended configuration and should be used when there is a special need to locate all session objects on a single node.

3. To enable logging on client side, following section needs to be added to your app’s configuration file “web.config”.

<fabric>

<section name="logging" path="">

<collection name="sinks" collectionType="list">

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Fabric.Common.ConsoleSink,FabricCommon"

sinkParam="" defaultLevel="-1"/>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Fabric.Common.FileEventSink,FabricCommon"

sinkParam="<CacheClientLog>" defaultLevel="1"/>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Data.Caching.ETWSink, CacheBaseLibrary"

sinkParam="" defaultLevel="-1" />

</collection>

</section>

</fabric>

<CacheClientLog> is the name of the file where logs will be created.Your application should have privileges to write in the location that you specify.

As we know, before any section can be used in an application config file, it has to be introduced in the <configSections>, so following needs to be added to <configSections> element in the app’s “web.config” file:

<section name="fabric" type="System.Fabric.Common.ConfigFile, FabricCommon"

allowLocation="true" allowDefinition="Everywhere"/>

Example “web.config” File:

Now let’s see how a “web.config” looks like for the app which have all the configuration elements described above. In the example below, we show the "web.config" file for an application that contacts a cache service running on a local host on port “22233” and has logging enabled.

<?xml version="1.0"?>

<configuration>

<configSections>

<section name="dcacheClient" type=" System.Configuration.IgnoreSectionHandler"

allowLocation="true" allowDefinition="Everywhere"/>

<section name="fabric" type="System.Fabric.Common.ConfigFile, FabricCommon"

allowLocation="true" allowDefinition="Everywhere"/>

</configSections>

<dcacheClient deployment="simple" localCache="false">

<hosts>

<!--List of services -->

<host name="localhost" cachePort="22233" cacheHostName="DistributedCacheService"/>

</hosts>

</dcacheClient>

<fabric>

<section name="logging" path="">

<collection name="sinks" collectionType="list">

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Fabric.Common.ConsoleSink,FabricCommon"

sinkParam="" defaultLevel="-1"/>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Fabric.Common.FileEventSink,FabricCommon"

sinkParam="CacheClientLog" defaultLevel="1"/>

<customType

className="System.Fabric.Common.EventLogger,FabricCommon"

sinkName="System.Data.Caching.ETWSink, CacheBaseLibrary"

sinkParam="" defaultLevel="-1" />

</collection>

</section>

</fabric>

<system.web>

<sessionState mode="Custom" customProvider="Velocity">

<providers>

<add name="Velocity" type="System.Data.Caching.SessionStoreProvider" cacheName="default"/>

</providers>

</sessionState>

</system.web>

</configuration>

Let’s know if you face any issues and have any suggestions.

Comments

  • Anonymous
    June 09, 2008
    Ok. Show of hands. Who has wanted to build a web application with a custom Session State provider using

  • Anonymous
    July 01, 2008
    Seem to be getting an error that cachename and regionname are not declared in the provider section of the session state config. Is there something I need to define to get those to work      <providers>            <add name="SessionStoreProvider" type="System.Data.Caching.SessionStoreProvider, ClientLibrary"                 cacheName="<YourNamedCache>" regionName="<YourRegion>" />      </providers>

  • Anonymous
    July 01, 2008
    Guys, from the config, it looks like you're using a custom logging solution. Why did you decide not to use the built in trace listeners? Cheers Matt

  • Anonymous
    February 16, 2010
    First of all using Velocity as SessionState  provider has a big disadvantage that you can't store unserializable objects in it (like other out-Proc providers) also after CTP3 you should change "SessionStoreProvider" to "DataCacheSessionStoreProvider" so your sessionState providers section should be like this: <providers>           <add name="SessionStoreProvider" type="System.Data.Caching.DataCacheSessionStoreProvider, ClientLibrary"                cacheName="<YourNamedCache>" regionName="<YourRegion>" />     </providers>