Scaling and configuring session state

Current version: 9.3

When contacts browse a website, data about their interactions with Sitecore is stored in session state until the end of the session, when it is committed to xConnect. xConnect then updates information about the session, and any changes in the contact's data, in the analytics and contact database.

It is, however, possible for a single contact to have two or more sessions on the same website at the same time. This can happen when a contact is using different devices or multiple browsers on the same device. You must have a session state server to keep track of all of the concurrent sessions for the contact.

Configuring the session state is particularly important if you deploy a multi-server environment with multiple processing servers or clusters of content delivery (CD) servers. Session state enables Sitecore to share data for a contact across multiple active sessions within a cluster.

Note

As of Sitecore 9.0 there is no mechanism for automatically transferring a contact session to another cluster. There is no need to collect different sessions from the same contact on one cluster as xConnect handles all updates of contact information. If you need to control which cluster a contact connects to, you must configure this in your load balancer.

This topic describes session state types, session state processes, and session state configuration scenarios.

Session state types

During a session, Sitecore writes data to two session state stores:

Store

Content

Private

Contains information about contact visit information, such as pages viewed, goals converted, or campaigns triggered. Private session state is private to the browser accessing the website.

If a contact accesses a website simultaneously from their desktop and mobile phone, each device will have its own private session state.

The default timeout of private sessions is 20 minutes,

Shared

Contains information that can be shared across multiple active sessions. This includes any contact information that has been loaded into the tracker at the start of the session.

Shared session state has a read-only copy of a contact’s data; contacts are not locked whilst a session is ongoing. If you need to update a contact with data from an active session, use the xConnect Client API.

Shared session state is not supported on Content Management (CM) servers.

The timeout of shared sessions is calculated as the private session timeout plus 1 minute making the default timeout of shared sessions 21 minutes.

You can configure shared session state to use any session-state store provider that extends the abstract class SessionStateStoreProviderBase (shipped with ASP.NET). The only additional requirement is that the session-state store provider must be able to invoke the SessionEnd event via SessionStateItemExpireCallback.

Note

The standard OutOfProcSessionStateStore class that ships with ASP.NET does not support the SessionEnd event and therefore  you cannot use it with shared session state.

On CD servers, you must configure both private and shared session states. You can use the same session provider for both. If you do, you must configure the session state providers in the correct nodes to ensure that the system can distinguish between the two session states.

Store

Configuration file

Node

Private

web.config

sessionState

Shared

\App_Config\Sitecore\Marketing.Tracking\Sitecore.Analytics.Tracking.Config

sharedSessionState

Session state processes

You can configure both private and shared session state as either in process (InProc) or out of process.

Process

Notes

In process

The default session state provider that comes with the Microsoft .NET Framework. It uses internal memory to track interactions and visits.

It is the most suitable way of handling private session state for all data related to a specific interaction (single visitor session or visit). It is the recommended mode to use for CM servers.

If you use in process in a load-balanced environment, you must configure the load balancer to use sticky sessions.

Out of process

Out of process means that you use an external ASP.NET session state provider. Sitecore comes with the following session state providers for configuring out of process session state:

  • Sitecore ASP.NET Session State Provider for Redis.

  • Sitecore ASP.NET Session State Provider for Microsoft SQL Server.

  • Sitecore ASP.NET Session State Provider for MongoDB.

You can use any custom provider that supports the Session_End event.

For shared session state, if you have two or more CD servers you must use out of process.

Out of process is not supported on CM servers.

Session state configuration scenarios

The following table shows the possible configurations of private and shared session state for different types of Sitecore CD server configurations.

Scenario

Private session state

Shared session state

Single standalone server

Out of process or In process

Out of process or In process

Single dedicated CD server

Out of process or In process

Out of process or In process

CD cluster with sticky load balancing

Out of process or In process

Out of process

CD cluster with non-sticky load balancing

Out of process

Out of process

Note

You must only configure one session state server for each CD cluster.

For private session state on dedicated CM servers you must always use in process. 

Session state providers

Depending on which database system you want to use when you configure your session state database, you must use a session state provider. Sitecore comes with the following providers:

  • Sitecore ASP.NET Session State Provider for Redis

  • Sitecore ASP.NET Session State Provider for Microsoft SQL Server

  • Sitecore ASP.NET Session State Provider for MongoDB.

You do not need a dedicated Sitecore instance to configure a dedicated session state database server.

You can store shared and private session state information in the same database. The database is able to distinguish between the types of session.

You can configure session state providers in the following ways:

Note

When you are planning a deployment of a session state database, you must remember to estimate the memory and disk state requirements.

Important

All custom classes that you use in the tracker context must be serializable. For more information, see the description of the SerializableAttribute class in the Microsoft documentation.

Do you have some feedback for us?

If you have suggestions for improving this article,