SharePoint 2010 uses two services related to session state that have similar names but are separate and have different purposes.
ASP.NET session state may be used on SharePoint 2010 pages. This service is automatically disabled in normal installations of SharePoint 2010; it may be enabled using the instructions below. Once enabled, it appears on the Service Applications page as “SharePoint Server ASP.NET Session State Service.”
The State Service service application is designed for and only available to Office internal components such as InfoPath Forms Services and Visio Services. This service is automatically enabled in typical installations of SharePoint 2010 and is not related to ASP.NET session state. It appears on the Service Applications page as “State Service.”
To enable ASP.NET session state:
Enter the following PowerShell command in the SharePoint 2010 Management Shell window:
On each web application for which you want to use session state, edit the web.config file and set the enableSessionState property of the pages element as follows:
Guidelines for using SharePoint Server ASP.NET Session State:
1.This session state may be used by custom code in web parts and other page-hosted controls.
2.Session state information is stored in a configurable SQL database; this implies the following:
a.Load-balancer affinity is not required.
b.Heavy use of session state must be included in database/capacity planning. By default, the session state database is created on the same database server hosting the SharePoint 2010 farm configuration database. This can be changed to place it on another server; this can be done at a later date if necessary. To move it to another SQL server, it should first be disabled, then enabled again with different configuration that points to the other server.
3.When enabled, Session state is available to the whole 2010 farm. Each web application can choose to enable it for use on ASP.NET pages (enableSessionState="true").
4.Session state is partitioned using the root URL. This means that different web applications will have different session state objects; a web part can only access the session state object available to it. If host header site collections are used, then different session objects will be used for each site collection (the browser will have multiple session ids in different cookies).