ASP.NET 2.0 Session State Partitioning

SqlSessionStateStore supports a key scalability feature of ASP.NET 2.0 known as session state partitioning. By default, all sessions for all applications are stored in a single SQL Server database. However, developers can implement custom partition resolvers—classes that implement the IPartitionResolver interface—to partition sessions into multiple databases. Partition resolvers convert session IDs into database connection strings; before accessing the session state database, SqlSessionStateStore calls into the active partition resolver to get the connection string it needs. One use for custom partition resolvers is to divide session state for one application into two or more databases. Session state partitioning helps ASP.NET applications scale out horizontally, by eliminating the bottleneck of a single session state database. For an excellent overview of how partitioning works, and how to write custom partition resolvers, see "Fast, Scalable, and Secure Session State Management for Your Web Applications."


ASP.NET 2.0 provides a solution to the problems encountered when scaling up by enabling horizontal scale-out of session state stores through its state partitioning feature. State partitioning enables the session data and the associated processing load to be divided between multiple out-of-process state stores, allowing the session state load to scale as the Web farm grows and the number of concurrent sessions increases. It works by supplying a custom partitioning algorithm to SessionStateModule, which uses the algorithm to determine the state store connection string to be used for the current request based on the session ID. Both the SQLServer and the StateServer providers will then use the appropriate connection string to fetch and save the session.

You can implement a partitioning scheme by deriving a class from the System.Web.IPartitionResolver interface, and building the session ID-to-connection string mapping inside the ResolvePartition method. The basic implementation shown in Figure 5 creates an array of hardcoded connection strings corresponding to available state store partitions in the Initialize method. In the ResolvePartition method, the resolver hashes the session ID string into one of the buckets corresponding to one of the loaded connection strings, and selects the resulting connection string.

Ideally, you will want to implement either a configuration collection for specifying the available partitions that you will load in the Initialize method, or obtain the collection from a centralized location over the network on a Web farm. The simple uniform hashing implementation results in a relatively even distribution of sessions to stores over time because the session IDs are generated randomly. However, you may want to implement a load-balancing scheme where you dynamically determine the partition in which to place a given session based on current partition load. To do this, you will need to encode the partition ID into the session ID by using a custom SessionIDManager derivation together with the PartitionResolver to determine the partition for a new session, create the session ID with the partition ID encoded, and then determine the partition ID in future requests by pulling it out from the session ID in the partition resolver.
The partition resolver implementation can be deployed in the App_Code application directory, or it can be compiled into an assembly and deployed in the \Bin application directory or installed into the GAC. Finally, the resolver type has to be added to the session state configuration by specifying its fully qualified name in the partitionResolverType attribute.

Note that the partition resolver can only be used when session state is using the SQLServer or StateServer modes, and no connection string can be specified using the sqlConnectionString or stateConnectionString attributes.

Session state also provides an alternative approach for Web farm session state management, which allows the application to harness the speed of distributed InProc state storage (or out-of-process state storage for reliability purposes) provided that a session ID-encompassing affinity scheme can be used on the Web farm. The affinity scheme needs to ensure that all requests with a given session ID are passed to the same Web server, in which case each Web server can maintain its own session state store without sharing it with other Web servers.

The affinity scheme needs to be based on session IDs or other characteristics of the request that guarantee all requests containing a given session ID will be directed to the same Web server. Such schemes can be based on client IP network ranges (keeping in mind that clients may be coming from dynamically assigned Web proxies) or user agent headers. The problems with implementing such affinity schemes include the fact that they are not readily available on hardware load-balancing systems as they require HTTP-level routing of the requests (as opposed to the more common IP or TCP-level connection routing). In addition, these schemes prevent you from doing any real load balancing because routing needs to be deterministic with respect to session ID to state store mappings to preserve state.

Figure 5 Session Partitioning

public class PartitionResolver : System.Web.IPartitionResolver
{
private String[] partitions;

public void Initialize()
{
// create the partition connection string table
partitions = new String[] {
"tcpip=192.168.1.1:42424",
"tcpip=192.168.1.2:42424",
"tcpip=192.168.1.3:42424" };
}
public String ResolvePartition(Object key)
{
String sid = (String)key;
// hash the incoming session ID into
// one of the available partitions
int partitionID = Math.Abs(sid.GetHashCode()) % partitions.Length;
return partitions[partitionID];
}
}

• Tweet
• Share
• Share
• Share
• Share