Symptoms:

You could run into below exceptions when using Windows Azure In-Role Cache as the store for ASP.Net Session State, High CPU can be noticed as well sometimes.

#1 ErrorCode<ERRCA0013>:SubStatus<ES0001>:The DataCacheLockHandle passed is invalid.

#2 ErrorCode<ERRCA0012>:SubStatus<ES0001>:Object being referred to is not locked by any client.

 

Possible Cause:

The ASP.NET session object has an exclusive lock by design.

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatestoreproviderbase.getitemexclusive(v=vs.110).aspx

Excerpt from the above link:

 “The SessionStateModule object calls the GetItemExclusive method at the beginning of a request, during the AcquireRequestState event, when the EnableSessionState attribute is set to true, which is the default. If the EnableSessionState attribute is set to ReadOnly, the SessionStateModule object instead calls the GetItem method.”

If there are several request for the same session object within a period of time, the first request gets the lock and the rest of the requests will wait for the lock.  When the first request completes, it releases the lock. The next request in line gets the lock. The other requests still wait for the lock. If each request takes 1 second to complete, 110 seconds (default execution timeout) gets passed by the time 110 requests complete.

http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.executiontimeout(v=vs.110).aspx

The rest of the requests will all timeout and fail with the cache errors listed above. Also, the requests waiting for the lock would consume CPU leading to high response times.

 

Resolution:

Setting EnableSessionState attribute to ReadOnly on the pages that does not write to the Session State store, would make the SessionStateModule object call GetItem method and mitigate the issue.

<%@ Page EnableSessionState="ReadOnly" %>

You can also make the default behavior of the application to be read-only by using the <pages> configuration element in your Web.config file. Then you can explicitly enable write access in only the pages that need it by setting the page EnableSessionState attribute, as shown below:

<configuration> <system.web> <pages enableSessionState="ReadOnly" /> </system.web> </configuration>

 Then on pages that require write access, you can explicitly enable with the following configuration.

<%@ Page EnableSessionState="True" %>

Here's a good MSDN magazine article that talks about Best Practices for Session State Management in ASP.Net Web Applications.

http://msdn.microsoft.com/en-us/magazine/cc163730.aspx

 

If the above suggestion doesn't fix the problem, please follow the blog below to collect the cache logs/traces and contact Windows Azure Support at Microsoft.

http://blogs.msdn.com/b/cie/archive/2014/03/07/windows-azure-in-role-cache-diagnostics-data-collection.aspx