Asp.net – Managing State

Managing State of an ASP.NET Application

We will focus on the following topics:
Store and Retrieve Application State
Store and Retrieve Session State
Configure Session State Storage
Client Side Cookies for State Storage

Store and Retrieve Application State

Advanced applications use pieces of data or variables that need to be maintained
over multiple requests or multiple users. This data is known as "STATE".

Application State is any data that is shared among multiple users of an application.

Application State Storage is supplied by .NET Framework = HttpApplication-State
class (Resides in System.Web namespace.

Every ASP.NET page inherits from the Page class.

Synchronize Access to Application State
Multiple users that update information simultaneously  could cause corruption
of state. Classic ASP did not offer a way to over come this, but current ASP.NET
offers the ASP.NET Application object. The Application object  provides
lock & unlock methods to ensure only a single user can modify stored data at any
given instance at any given time.

Application State Limitations:
Durability – Lasts only as long as Web Application is running. Information that
needs to persist between app restarts(Server restart for example) should be stored
in a database.
Web Farms – Not shared across multiple servers. Shared hosting would not properly
store application state where as dedicated hosting would.
Memory – Server has limited physical memory. Overuse of application state can force
use of virtual memory, and would slow application response time down to an inexcusable
rate.

Using Session State

Managing application-state information is especially challenging utilizing
http.

The web server must first identify a series of requests as coming from some
user. The web server must link these requests with the app state information for
that user.

Classis asp met these challenges with a session object.

Classic asp session state could not be scaled across multiple servers such as
a web farm.

State & Scalability

The scalability of an application is impacted greatly by where you choose to
store store state information. Scalability refers to the ability of an
application to service requests from an increasing number of users without a
decrease in performance.

The following conditions negatively affect application scalability:

Failure to Disable Session State – If not in use disable via
the web.config vile with Visual Studio. For limited use insure that pages that
do not use session state include the "enable session state=false" as part of the
@Page directive.

Misuse of Application.Lock

Storing references to single(or apartment) threaded objects.

In-Process Session State – It may be necessary to utilize a web farm to
allow multiple servers to handle requests. In this instance set application
session to StateServer or SQLServer.

Overuse of session or application storage – Storing multiple object
references or data sets at application level can exhaust web servers physical
memory.

Configuring Session State Storage

* In-process (InProc)
   Acts similar to Classic ASP

* Out-of-process (StateServer)
   Session state is stored by a server running the ASP.NET state
service.

* SQL Server (SQLServer)
   Session state is stored in a Microsoft SQL Server database.

* Cookie less Sessions
   This setting maintains state even if browsers do no support
cookies.

* ASP.NET Server Control State
    Resolves problems of unstable HTML forms. HTML does maintain
the state of individual from elements, in classic ASP developers would have to
develop work-around for storing HTML form input data. ASP.NET resolved this
problem with server control architecture., All ASP.NET server controls can
maintain there own state through ViewState. In some instances this is enhanced
further with use of browser side scripting such as Ajax or JavaScripts.

By default .net applications will store session state "in-process".

 

0
  Related Posts