Session state

Current version: 8.2

In the Sitecore Experience Database, you can use a session state server to share all your contact sessions across different browsers and devices. Configuring session state is particularly important if you have deployed a multi-server, fully scalable environment with clusters of content delivery or processing servers.

Session state overview

Tracking the session state of your contacts is important regardless of whether you install a standalone environment or a fully scalable environment. For example, it is possible to track two simultaneous contact sessions from two different devices, such as from a desktop web browser or a mobile phone.

If you decide to deploy a large, fully scalable environment with vertical and horizontal scaling, then session state becomes even more important. For example, in a multi-content delivery cluster environment, you can share contact information between content delivery instances to ensure that contacts stay connected to the particular cluster where their interaction originated.

In xDB, there are two types of session states:

  • Private

  • Shared

Important

You must configure both private and shared session states. You can choose to use the same session provider for both but to ensure that the system can distinguish between them you must configure the correct attribute in the web.config and the Sitecore.Analytics.Tracking.config files.

Provider

Attribute

Value

SQL Server

sessionType

private or shared

MongoDB

sessionType

private or shared

Redis

applicationName

private or shared

Private session state

In private session state (ASP.NET), all analytics session data related to a specific interaction is collected and saved to the session state server.

The private session data collected during a session includes data on the interaction, and the devices used by a contact.

The default provider is the in process (inProc) session provider which uses session state stored in-memory. This is suitable for small, standalone installations used for test or development purposes.

If you have a multi-server environment you should use one of the following out of process ASP.NET session state providers:

  • Sitecore ASP.NET Session State Provider for Redis

  • Sitecore ASP.NET Session State Provider for MongoDB

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

These providers enable you to choose whether you want to use the Redis, MongoDB or SQL Server session database as your session state store. They also support the session end event that is required by the xDB to track website visits reliably. You could also choose an external session state provider so long as it supports the Session_end event.

The standard ASP.NET session state stores a cookie in the web browser. This means that if a contact uses Sitecore from two different devices, or even two different browsers on the same device, two separate sessions are created.

Note

Private session state is not required to support the Session_End event on content management servers. Private session state must support the Session_End event on content delivery servers.

Note

You should only configure one session state server for each content delivery cluster that you have.

Shared session state

Contact data is collected and stored in a dedicated Shared session state store. This works in the same way as ASP.NET session state. When you configure shared session state, you can use in process or choose the Redis, MongoDB or the SQL Server session provider to support out of process session state.

Shared session state data includes all data that is unique to a contact and that can be shared across simultaneous sessions, such as contact details, devices and engagement automation states triggered. This information needs to remain accessible to other concurrent operations, for example, interactions and background processes, and can be shared across multiple sessions.

Sitecore uses shared session state for storing information about the current contact state and related data.

In contrast to ASP.NET session state (which is exclusive to an interaction), shared session state stores a contact's session and is accessible from any visit session that is associated with the contact within the same cluster.

Note

Shared session state is not supported on content management servers. On content delivery servers shared session state must support the SessionEnd event.

Session Lifetime (Shared)

The following graph shows the lifetime of the sessions for a single contact and two concurrent interactions made from two different devices.

Note

When there is only a single standalone content delivery server, shared session state can be stored in memory because there is no need to share the session state with other servers. In this case, shared session state is still useful for handling concurrent visits by the same contact from different devices

Session state providers

A session state server stores information relevant to current contact sessions. The Sitecore xDB comes with two session state services:

  • Private session state holds information private to sessions. This is contact visit information, such as pages viewed, goals converted, or campaigns triggered.

  • Shared session state holds information that may be shared by multiple visits on the same cluster, such as contacts and devices.

You can configure session state in two different ways: as either in process (InProc) or out of process.

In process

In process (InProc) is the default session state provider that comes with the Microsoft .NET Framework. It uses internal memory to track interactions and visits.

In process 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 content management servers.

Note

You cannot use InProc in a load-balanced environment unless you configure the load balancer to use sticky sessions.

Out of process

Out of process session state means that you use an external ASP.NET session state provider such as Redis, MongoDB or SQL Server. You can also use any custom provider that supports the Session_End event. Out of process is suitable for handling shared or private session state if you have multiple content delivery servers.

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 MongoDB

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

When you configure session state on different types of Sitecore server configurations there are several different session state configuration scenarios you can follow.

Do you have some feedback for us?

If you have suggestions for improving this article,