A performance consideration for AppFabric Session State Provider for ASP.NET and IHttpHandlers


By default a class which implements the IHttpHander interface does not have access to the Http Session context. For the IHttpHander to gain access to the session, it must implement the IRequiresSessionState or IReadOnlySessionState Interface.

However, recently I came across a condition where my customer’s IHttpHander was pulling the AppFabric cache for the users http session, creating a block because that session was already locked, despite the fact his IHttpHander did not have the interface marker IRequiresSessionState or IReadOnlySessionState.  When I examined the userdump for the hang, I noticed this System.Web.HttpContext for the hanging HTTP request was set to _requiresSessionStateFromHandler = true.

Class Name: System.Web.HttpContext
System.Boolean +0176         _requiresSessionStateFromHandler 1 (True)
System.Boolean +0177         _readOnlySessionStateFromHandler 0 (False)

Best Advice to avoid the possibility of this issue:

First, remember to avoid all unnecessary calls to session. However, if you require session state access implement the IReadOnlySessionState Interface over the IRequiresSessionState Interface. This would avoid the lock on the user’s session and return a read-only copy instead.

 

References:

How to: Configure the AppFabric Session State Provider for ASP.NET (AppFabric 1.1 Caching)
http://msdn.microsoft.com/en-us/library/hh361711(v=azure.10).aspx

Comments (0)

Skip to main content