• Choose a category
• All
• Classic-Fiction

Name of the cookie, if cookies are used for session IDs.

customProvider

The name of the custom session state store provider to use for storing and retrieving session state data.

mode

Specifies where to store session state.

partitionResolverType

Indicates the type and assembly of the partition resolver component to be loaded to provide connection information when session state is working in SQLServer or StateServer mode. If a partition resolver can be correctly loaded, sqlConnectionString and stateConnectionString attributes are ignored.

regenerateExpiredSessionId

When a request is made with a session ID that has expired, if this attribute is true, a new session ID is generated; otherwise, the expired one is revived. The default is false.

sessionIDManagerType

Null by default. If set, it indicates the component to use as the generator of session IDs.

sqlCommandTimeout

Specifies the number of seconds a SQL command can be idle before it is canceled. The default is 30.

sqlConnectionString

Specifies the connection string to SQL Server.

stateConnectionString

Specifies the server name or address and port where session state is stored remotely.

stateNetworkTimeout

Specifies the number of seconds the TCP/IP network connection between the Web server and the state server can be idle before the request is canceled. The default is 10.

timeout

Specifies the number of minutes a session can be idle before it is abandoned. The default is 20.

useHostingIdentity

True by default. It indicates that the ASP.NET process identity is impersonated when accessing a custom state provider or the SQLServer provider configured for integrated security.

In addition, the child section lists custom session-state store providers. ASP.NET session state is designed to enable you to easily store user session data in different sources, such as a Web server’s memory or SQL Server. A store provider is a component that manages the storage of session state information and stores the information in an alternative media (for example, Oracle) and layout. We’ll return to this topic later in the chapter.

Lifetime of a Session

The life of a session state begins only when the first item is added to the in-memory dictionary. The following code demonstrates how to modify an item in the session dictionary. “MyData” is the key that uniquely identifies the value. If a key named “MyData” already exists in the dictionary, the existing value is overwritten.

Session["MyData"] = "I love ASP.NET";

The Session dictionary generically contains object types; to read data back, you need to cast the returned values to a more specific type:

var tmp = (String) Session["MyData"];

When a page saves data to Session, the value is loaded into an in-memory dictionary—an instance of an internal class named SessionDictionary. (See Figure 17-1 to review session state loading and saving.) Other concurrently running pages cannot access the session until the ongoing request completes.

The Session_Start Event

The session startup event is unrelated to the session state. The Session_Start event fires when the session-state module is servicing the first request for a given user that requires a new session ID. The ASP.NET runtime can serve multiple requests within the context of a single session, but only for the first of them does Session_Start fire.

A new session ID is created and a new Session_Start event fires whenever a page is requested that doesn’t write data to the dictionary. The architecture of the session state is quite sophisticated because it has to support a variety of state providers. The overall schema has the content of the session dictionary being serialized to the state provider when the request completes. However, to optimize performance, this procedure really executes only if the content of the dictionary is not empty. As mentioned earlier, though, if the application defines a Session_Start event handler, the serialization takes place anyway.

The Session_End Event

The Session_End event signals the