In shared session-state, all the data that can be shared across multiple sessions, for example, the data related to contacts and devices, is collected and saved to the session state database.
You must always configure shared session state whatever your server configuration. For example, you can have a single standalone content delivery server, multiple content delivery servers, or a clustered environment, but you always need to configure session state.
Shared session state is not supported on content management servers.
A contact can make multiple parallel visits to a website in which case each visit has its own private session state. However, some data can be shared between visits, such as device and contact related information.
Information that is shared between parallel visits by the same contact is stored in the shared session-state store. This data is still private to the contact but it is accessible from all current sessions made by the same contact.
OutOfProcSessionStateStore that is shipped with ASP.NET does not support the
SessionEnd event and therefore cannot be used with shared session state.
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 can invoke the
SessionEnd event via
If you are using the xDB Cloud Edition, using the shared session state provider for MongoDB is not included as part of this service.
Follow the steps in this section to use a SQL Server database as your shared session state store using the Sitecore ASP.NET Session State Provider for SQL Server:
Deploy a SQL Server session database
The Sitecore ASP.NET Session State Provider for SQL Server enables you to use SQL Server as your session state store. This provider supports the
SessionEnd event that the xDB needs to track website visits.
To deploy the SQL Server session database:
- Start Microsoft SQL Server Management Studio 2012 or later.
- Connect to the server node that you want to install the Session database on.
- Expand the server node, right-click Databases, and then click Attach.
- In the Attach Databases dialog box, click Add.
- Browse to the Databases folder in your website root folder, select the
Sitecore.Sessions.mdfdatabase and click OK.
- In the Attach Databases dialog box, click OK. The session database now appears in your list of attached databases.
- Add the following connection string to the
<add name="sharedsession" connectionString="user id=_sql_server_user_;password=_user_password_;Data
Source=_sqlserver_;Database = _sharedSession_database_name_"/>
add namevalue can be
sharedsessiondepending on whether you are configuring private or shared session state.
You can store shared and private session state info in the same database. The database is able to distinguish between the two types of session state
Optimize SQL Server performance
For each web request, the session-state store database is accessed multiple times. This can have a significant impact on the performance of your website. Therefore, you should install enough RAM to allow Microsoft SQL Server to keep the session state database in memory. You should also put the database files on an SSD drive.
To achieve optimal performance, you can install an extension to the Sessions database.
To install the performance enhancements:
- In Microsoft SQL Server Management Studio 2012, open the
Sessions db performance boost.sqlfile.
This file is stored in the
\Databases\Scriptsfolder of your Sitecore installation.
- In the first line of the
Sessions db performance boost.sqlfile, replace
USE [Sitecore_Session]with the name of your session database.
- After you have updated the
USEstatement to point to your session database, press F5 to execute the file.
These performance enhancements move the session-state store to SQL Server tempDB which is the standard practice recommended by Microsoft. Please note that the tempdb system database is currently not supported by Azure SQL Database service.
Every user must therefore have access to tempDB. However, every time that SQL Server is restarted, it recreates tempDB and resets the access rights. For information about how to ensure that users always have access to tempDB, see this KB article.
For more information see Session-State Modes on MSDN.
Note Do not make changes directly to the configuration files. Instead, you must create a patch file that performs the required changes during runtime.
Do not make changes directly to the configuration files. Instead, you must create a patch file that performs the required changes during runtime.
To configure Sitecore to use the shared session state provider for SQL Server:
- In your website root folder, navigate to:
- Open the
- Locate the line where you can define the default shared session state provider using the following path:
- The default shared-session store uses
inProcprovider (storing data in memory and implemented in the internal ASP.NET class
<add name="inProc" type="System.Web.SessionState.InProcSessionStateStore" />
- To configure SQL Server as your shared session state store provider change the
inProcto mssql. Also, change the name attribute value to
Adjust session state settings
In Sitecore, when you configure a session state, you have the following configuration options:
Contains the connection string that Sitecore uses to connect to the session database.
Edit to specify the session state database that you want to use. In the xDB, this database is called session.
Specifies the time interval in seconds that the session-state provider uses to check if any sessions have expired.
Indicates that you want session-state data to be compressed.
The default value is true. Compressing session state data reduces the amount of data that you need to transfer between the database and the Sitecore instance. This may cause some additional CPU overhead.
Indicates whether the type of session state is private or shared.