|
Understanding Applications and State
What's New in 2.0
- Session State Extensibility - Session State is now built upon a fully extensible, provider-based storage model.
ASP.NET 2.0 ships with providers for in-process, out-of-process and Sql Server storage. However developers can implement
custom providers that work against other data stores by deriving from
SessionStateStoreProviderBase. The Session
State feature also allows developers to create custom session ID generators as well as custom HttpModules to use instead of
the default SessionStateModule. For scalability, the Sql Server and out-of-process Session State providers
allow a developer to dynamically determine on a per-request basis the session state server that should load and store session
data. This allows session state data to be spread across multiple backend session state servers.
- Control State - In addition to ViewState, controls can now use a ControlState dictionary for round-tripping
state information using the client. The ControlState dictionary is intended to store limited size information that is
critical to the functionality of the control, that should not be disabled when EnableViewState is false.
- Encrypted ViewState - ASP.NET 2.0 enables encryption of ViewState through the Page directive's EncryptViewState
attribute. This can be used to protect sensitive data that needs to be roundtripped in viewstate that should not be exposed
to the client user. A common use for this feature might be to encrypt the DataKeyNames values from a GridView control.
This section discusses these and other application and state management features in ASP.NET 2.0.
What is an ASP.NET Application?
ASP.NET defines an application as the sum of all files, pages, handlers, modules,
and executable code that can be invoked or run in the scope of a given virtual
directory (and its subdirectories) on a Web application server. For example,
an "order" application might be published in the "/order" virtual directory on a
Web server computer. For IIS the virtual directory can be set up in the Internet
Services Manager; it contains all subdirectories, unless the subdirectories are
virtual directories themselves.
Each ASP.NET Framework application on a Web server is executed within
a unique .NET Framework
application domain, which guarantees class isolation (no versioning or naming conflicts),
security sandboxing (preventing access to certain machine or network resources),
and static variable isolation.
ASP.NET maintains a pool of HttpApplication instances over the course of a Web
application's lifetime. ASP.NET automatically assigns one of these instances to
process each incoming HTTP request that is received by the application.
The particular HttpApplication instance assigned is responsible for managing
the entire lifetime of the request and is reused only after the request has
been completed. This means that user code within the HttpApplication does not
need to be reentrant.
Creating an Application
To create an ASP.NET Framework application you can use an existing virtual directory or
create a new one. For example, if you installed Windows 2000 Server including
IIS, you probably have a directory C:\InetPub\WWWRoot. You can configure IIS
using the Internet Services Manager, available under
Start -> Programs -> Administrative Tools.
Right-click on an existing directory and choose either New (to create a new
virtual directory) or Properties (to promote an existing regular directory).
By placing a simple .aspx page like the following in the virtual
directory and accessing it with the browser, you trigger
the creation of the ASP.NET application.
<%@Page Language="C#"%>
<html>
<body>
<h1>hello world, <% Response.Write(DateTime.Now.ToString()); %></h1>
</body>
</html>
C#
Now you can add appropriate code to use
the Application object--to store
objects with application scope, for example. By creating a
global.asax file you also can
define various event handlers--
for the Application_Start event, for example.
Lifetime of an Application
An ASP.NET Framework application is created the first time a
request is made to the server; before
that, no ASP.NET code executes. When the first request is made,
a pool of HttpApplication
instances is created and the Application_Start event
is raised. The HttpApplication
instances process this and subsequent requests, until the
last instance exits and the
Application_End event is raised.
Note that the Init and Dispose methods of
HttpApplication are called per instance and
thus can be called several times between Application_Start
and Application_End. Only
these events are shared among all instances of HttpApplication
in one ASP.NET application.
A Note on Multiple Threads
If you use objects with application scope, you should be aware that
ASP.NET processes requests concurrently and that the Application object can be
accessed by multiple threads. Therefore the following code is dangerous and might
not produce the expected result, if the page is repeatedly requested by
different clients at the same time.
<%
Application["counter"] = (Int32)Application["counter"] + 1;
%>
C#
To make this code thread safe, serialize the access to the
Application object using
the Lock and UnLock methods. However, doing so
also means accepting a considerable
performance hit:
<%
Application.Lock();
Application["counter"] = (Int32)Application["counter"] + 1;
Application.UnLock();
%>
C#
Another solution is to make the object stored with an application scope
thread safe. For example, note that the collection classes
in the System.Collections namespace
are not thread safe for performance reasons.
|