Q: How do I store global variables?
A: Any good developer
will tell you that global variables should be used sparingly. Even so, sometimes
they are the most efficient way to get data everywhere it is needed. There are a
few ways to store variable values globally in ASP.NET. The most common approaches
involve use of the Application, Cache, and Session objects.
The Application object has been available since the inception of ASP, and its sturdy
foundations are as reliable now as they were back then. The Application object stores
data that is meant to be shared across all user sessions — so don’t put data in
it that applies only to a particular user. One notable syntax quirk is the need
to lock the application item before setting it. This prevents more than one page
request from writing to the same item at the same time. Don’t forget to unlock the
item again after you’ve set it:
'Page1.aspx
places the data in
ns="urn:schemas-microsoft-com:office:smarttags" prefix="st1" ?>
Application State
Application.Lock()
Application("MyValue")
= Textbox1.Text
Application.UnLock()
Response.Redirect("Page2.aspx")
'Page2.aspx
retrieves the value from
Application State
MyString = Application("MyValue").ToString
The similar (but more modern) Cache object has a simplified syntax that negates
the need for manually locking and unlocking. Notice how similar the syntax is compared
to the ViewState approach mentioned earlier:
'Page1.aspx
Caches the value
Cache("MyValue")
= Textbox1.Text
Response.Redirect("Page2.aspx")
'Page2.aspx
retrieves the value from the Cache
MyString = Cache("MyValue").ToString
Like the Application object, the Cache object stores data that is meant to be shared
across all user sessions — so don’t put data in it that applies only to a particular
user. However, the Cache object has richer functionality than the Application object.
The Cache object can automatically expire cached content after specified time periods
or once memory consumption has reached a peak. Cache items can also be set to expire
whenever a given file changes or when a related Cache item changes. Cache values
can be prioritized and automatically refreshed.
The Session object has been around since the early days of ASP. This classic and
reliable technique is great for storing a user’s data during the length of their
visit to your Web site:
'Page1.aspx
stores the user’s name in Session state
Session("UserName") = txtName.Text
Server.Transfer("Page2.aspx")
'Page2.aspx
retrieves the user’s name from Session state
MyString = Session("UserName").ToString
ASP.NET tracks each user’s session, helping to ensure that one user’s data is never
displayed to another user. By default, each session value is stored in server memory.
If you multiply each session variable times the number of active users in your Web
site you might realize that memory usage can add up very quickly. For this reason,
Web applications that need to be highly scalable tend not to use session variables
much, if at all. For smaller applications, the convenience of Session variables
is simply irresistible.
What if you want to store variables across a user’s entire visit but for scalability
reasons you don’t want to use Session variables? There’s really no simple answer,
but the most obvious fallbacks are cookies and databases. Cookies are tidbits of
data stored in the user’s browser; therefore, they don’t really use any server memory.
However, cookies have gotten a bad rap over the years, so many users have them turned
off. For this reason I recommend that you don’t rely on them. Another technique
is to store the data in a back-end database and retrieve required data upon each
page request. Although this conserves the Web server’s memory, it increases network
and database traffic. A more complex technique is to create your own custom business
objects that cache the data in ways that are efficient for your specific application.
Session state can be configured to be automatically stored in a SQL Server database,
or it can be configured to be stored centrally in a state server within a server
farm.
By default, a user’s session ends 20 minutes after their last page request and their
data goes out of scope, freeing it from memory.