2
votes

We are trying to change our ASP.NET Session State timeout in Azure and have noticed a disconnect between the way ASP.NET sessions expire and the Named Cache Settings. Will it suffice to change the web.config sessionState timeout property for Azure's custom Session State provider or do we need to change the Named Cache Settings in the service configuration to influence session timeout?

According to MSDN, the HttpSessionState.Timeout property is the amount of time, in minutes, allowed between requests before the session-state provider terminates the session. That means that all Session objects get a new lease on life after each request that bears its SessionID.

Our Windows Azure ASP.NET app is supported by two production instances and configured to maintain Session State in the distributed co-located cache via the Session State Provider for Windows Azure Caching. Here is the web.config file snippet that configures the custom Session State provider:

    <!-- Windows Azure Caching session state provider -->
    <sessionState mode="Custom" customProvider="AFCacheSessionStateProvider">
        <providers>
            <add name="AFCacheSessionStateProvider" type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache" cacheName="default" dataCacheClientName="default" applicationName="AFCacheSessionState"/>
        </providers>
    </sessionState>

    <!-- Windows Azure Caching output caching provider -->
    <caching>
        <outputCache defaultProvider="AFCacheOutputCacheProvider">
            <providers>
                <add name="AFCacheOutputCacheProvider" type="Microsoft.Web.DistributedCache.DistributedCacheOutputCacheProvider, Microsoft.Web.DistributedCache" cacheName="default" dataCacheClientName="default" applicationName="AFCacheOutputCache" />
            </providers>
        </outputCache>
    </caching>

The above setting are defined at ASP.NET Session State Provider Configuration Settings (Windows Azure Caching). We are using the default dataCacheClientName. The default cache and any other named caches are configured on the Caching tab of the web role properties. A GUI provides a friendly way of maintaining Named Cache Settings that are stored in a highly unreadable manner in the .cscfg file for the selected Service Configuration. Notice the Eviction Policy, Expiration Type and Time to Live properties of the default cache. These properties are defined at How to Use Windows Azure Caching. They imply that each cached object has its own life cycle while Session objects should all persist until the ASP.NET Session expires. Do I need to change the Named Cache Settings in order to extend my sessionState timeout to 60 minutes or will the Session Provider do the right thing regardless of the default Named Cache Settings? If I need to also adjust the Named Cache Settings, what should they be?

1
An trustworthy Azure Tech Support guy wrote me: "As you are likely aware the session object is just like any other object that gets stored in cache so if you are configuring session timeout for your ASP.NET application you should also ensure that the session objects in cache do not get evicted or expired when you need them. You also need to have High Availability (HA) enabled for any disaster recovery. So yes, you should override the cache related settings, as you have done in the sample you provided, to get the best experience."CAK2
So, I changed the default named cache Eviction setting to "None", the Expiration Type to "Sliding Window" and the Time to Live to "60" minutes. Hopefully, that will keep my Session objects alive as expected.CAK2
Seems to be working. No unexpected Session timeout problems in production for a couple of months now.CAK2

1 Answers

0
votes

According to the documentation found here, the ASP.NET Session State Provider for Azure Cache explicitly sets the expiration time for each object, overriding the configured cache expiration time. Therefore, it sounds like you only need to worry about setting the appropriate eviction policy, and the state provider manages expiration and time to live. Here's the pertinent excerpt:

In Shared Caching, expiration is always Absolute and there is no way to set a default expiration time. Items in Shared Caching expire after 48 hours. However, you can use the Put and Add methods to set explicit expiration times in code. Note that the ASP.NET providers automatically use these overloads to provide explicit timeouts for session state and output caching. In either case, when your cache size exceeds the limits of your Shared Caching offering, the least recently used items in the cache are evicted.