I’ve seen a few projects recently where Session State Management in Sitecore had been ignored a bit, despite the systems having multiple servers. 

Here’s what the Sitecore 6.6 Scaling Guide says:

The Sitecore CMS user interfaces require in-process ASP.NET session management. For CM
instances, the value of the mode attribute of the /configuration/system.web/sessionState element in the web.config file must be InProc.

In-process session management requires you to configure the CM load balancer for server affinity – also known as sticky sessions. You can use other values for the mode attribute in the CD environment.

Fine. This is saying that if the session management is being handled by the web server itself, you’ll have to use sticky sessions. This is because if there is a load balancer involved, and your traffic was routed to another server, well, it wouldn’t know about your existing session. Your session data would be lost – or worse, confused, as your page requests could arrive at different servers each time.

Moreover, it’s also saying that Content Management instances (CM) must use InProc session states. I don’t quite know why that should be, but I’ll believe Sitecore. Thus, if you’ve multiple CM servers, you’ll need to configure sticky sessions.

Your Content Delivery servers, though, do not have to use InProc. There are other options:

• InProc mode, which stores session state in memory on the Web server. This is the default.
• StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

So far all the projects I’ve seen just use InProc. Combined with session affinity, that’s probably fine – you should only have problems with sessions should one of the servers fail and user traffic have to be routed to another server; in this case, the session details would be lost. That should be a rare thing, but it can happen.

Therefore, I find myself intrigued by StateServer or SQLServer modes. StateServer would still concern me a little – it’s a single point of failure still, whereas SQLServer mode, talking to a session database on a clustered SQL server should be failure resistant.

EDIT: It turns out that out can’t use StateServer… at least not in 6.x versions.

The standard OutOfProcSessionStateStore that is shipped with ASP.NET does not support the SessionEnd event and therefore cannot be used with shared session state.

Also, it turns out that more recent versions of Sitecore come configured with MongoDB or SQL server for session state, and that it’s got private and shared session state management.

So the short of it is that session state management has changed a lot over the last few versions of Sitecore – and warrants consideration as part of your project.

Related:

• ASP.NET Session State support for Sitecore Client (Describes session support in versions 6.5 to 7.5)
• Walkthrough: Configuring a private session state database using the SQL Server provider
• Walkthrough: Configuring a shared session state database using the SQL Server provider
• Configuring session database servers (XDB)
• Session State
• Sitecore Items and Session State Management on Multiple CD Servers