Session state
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
Session state is a way of identifying contacts on your website by assigning them a unique session ID and by using cookies. Every time a contact makes a request, such as triggering a campaign or a goal this information is held in session state until the end of session.
This means that fewer server trips are needed to write data back and forth to the collection database. Instead, xDB makes one trip at the start of a session to identify the contact and a second at the end to save all the session data back to the collection database.
Tracking contact session state 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.
You should only configure one session state server for each content delivery cluster.
In xDB, there are two types of session states:
-
Private
-
Shared
You must configure both private and shared session states. You can use the same session provider for both private and shared sessions but to ensure that the system can distinguish between the two entries you must configure the sessionType attribute in the web.config and Sitecore.Analytics.Tracking.config with the correct attribute name, which can be shared or private.
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 Store Provider for MongoDB
-
Sitecore ASP.NET Session State Store Provider for Microsoft SQL Server
These providers enable you to choose whether you want to use the 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.
On content delivery servers, private session state must support the Session_End event but this is not required on content management servers.
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 MongoDB session provider 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.
On content delivery servers shared session state must support the SessionEnd event. On content management servers shared session state is not supported.
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.
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.
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 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.
Always use out of process session state if you have more than one content delivery instance in a cluster.
Sitecore comes with the following two session state providers for configuring out of process session state:
-
Sitecore ASP.NET Session State Provider for MongoDB
-
Sitecore ASP.NET Session State Store 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.