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.