At this point, as you may guess, we will see how we can integrate Velocity in our ASP.NET applications, obtaining a valid option for centralized Session management to existing StateServer and SQL Server modes. With the former, we have all the benefits included in a centralized session that, thanks to a service running on a state server, can distribute and balance web requests on several web servers in the farm, managing sessions in a centralized and performing way.

In this scenario, all web servers rely on a single state server on which all sessions are maintained. If High Availability is a requirement, this would not be satisfied as a sudden failure of session server would cause the loss of all sessions.

A plausible alternative could be storing sessions on SQL Server database, but with it we should also accept the performance loss when accessing session data, at least 25% less.

Velocity aims to mitigate the weakness exposed by both StateServer and SQLServer modes, offering a Session Provider that emulates a distributed and redundant StateServer, using a cluster of servers running cache service.

To appreciate this feature, we must instruct our application to use Velocity's Session Provider, modifying web.config as explained in these three steps:

1) Declare dCacheClient and Fabric config sections:

Listing 3

<section name="dcacheClient" type="System.Data.Caching.DCacheClientSection, 
CacheBaseLibrary" allowLocation="true" allowDefinition="Everywhere"/>
<section name="fabric" type="System.Data.Fabric.Common.ConfigFile, FabricCommon" 
allowLocation="true" allowDefinition="Everywhere"/>

2) Configure dCacheClient section, adding available servers in the cluster and the behavior of cacheClient. Also configure the fabric section, declaring logging mechanisms that cacheClient will use:

Listing 4

<dcacheClient deployment="simple">
 <localCache isEnabled="true" sync="TTLBased" ttlValue="300"/>
 <hosts>
  <!--List of cache servers (cache cluster)  -->
  <host name="SERVER1" 
        cachePort="22233" 
        cacheHostName="DistributedCacheService"/>
   <host name="SERVER2" 
        cachePort="22233" 
        cacheHostName="DistributedCacheService"/>
 </hosts>
 </dcacheClient>
<fabric>
 <section name="logging" path="">
  <collection name="sinks" collectionType="list">
   <!--LOG SINK CONFIGURATION-->
   <!--defaultLevel Values:  -->
   <!--  -1 = no tracing -->
   <!--   0 = Errors only -->
   <!--   1 = Warnings and Errors only -->
   <!--   2 = Information, Warnings, Errors -->
   <!--   3 = Verbose (all event information)-->
   <customType className="System.Data.Fabric.Common.EventLogger,FabricCommon"
                sinkName="System.Data.Fabric.Common.ConsoleSink,FabricCommon" 
               sinkParam="" 
                defaultLevel="-1"/>
   <customType className="System.Data.Fabric.Common.EventLogger,FabricCommon"
                sinkName="System.Data.Fabric.Common.FileEventSink,FabricCommon"
                sinkParam="Dcache/dd-hh-mm" 
                defaultLevel="-1"/>
    <customType className="System.Data.Fabric.Common.EventLogger,FabricCommon"  
                sinkName="System.Data.Caching.ETWSink, CacheBaseLibrary" 
                sinkParam="" 
                defaultLevel="-1"/>
   </collection>
 </section>
</fabric>

3) Change sessionState Mode parameter, setting "Custom" and declare the Velocity Provider that will be used as Session Provider:

Listing 5

<sessionState mode="Custom" 
              customProvider="SessionStoreProvider" 
  cookieless="UseUri">
 <providers>
  <add name="SessionStoreProvider"      
        type="System.Data.Caching.SessionStoreProvider, ClientLibrary"/>
 </providers>
</sessionState>

To demonstrate the use of Velocity Session Provider, I have also set cookieless parameter to "UseUri" for convenience, to be able to access the same session data while switching from one server to another.

In the following images note that, from two different browsers, accessing the same session data from two different servers, we are able to get the same shopping cart content. This means that we are accessing a centralized session data, but we are also relying on a cluster of cache servers at the same time, on which Velocity is running, providing a performing, high available and easy to use cache.

Figure 7: Same page and session, from 2 different web servers. Notice the shopping cart on the right side.

 Server 1

 Server 2