All static property values persist?

  • Thread starter Thread starter Pavils Jurjans
  • Start date Start date
P

Pavils Jurjans

Hello,

I am now digging through ASP.NET, so please forgive me if I ask some
common-sense questions, as I come with long-years classic ASP background.

I was just playing with code-behind features, and found out some shocking
(at least for me) news.

This is the aspx file:

<%@ Page Language="C#" inherits="CBTest"%>
<%=counter++%>

This is the code for code-behind class:

public class CBTest : System.Web.UI.Page
{
public static int counter;
}

Now, I go to the browser, and type the local URL to see that page, and get,
of course "0", now, if I keep clicking "Refresh" button, I see the counter
growing. What is going on here? Is the static property of Page type class
persistent over requests? I tried to turn off session state, but the
behaviour is still the same. How that actually works? I did some testing to
find out that not only static properties of Page type objects, but even
self-sustained custom-made class static properties where keeping their
values over consequent requests to the same page.

I am quite surprized on this. I expected that I still have to use Session
object to keep values over requests. I have read the new paradigm of
persistent control states, but I really didn't expect that simple static
properties of any class present in my application would keep their values.

Please, someone, clear up for me what's going inside here!

Thanks,

-- Pavils
 
Static properties are as static properties elsewhere - there is one instance
of the property, for the type, and all instances of the class share that
property.

This means that not only requests for the same session will see this
property persist - but in fact all users, will all see the same value for
this property, as there is always just one instance of it per application.

So in conclusion, static members in classes that inherit from Page are no
different then any other static members anywhere else.
 
Hi Pavils,
The fields declared with static belongs to the class as a whole.Static
field exists from the moment
the assembly containing the class is loaded,and are initialized by the
runtime and is independent of whether you actually declare
any instances of the class.That is why when you refresh the counter is
growing.
Hope this helps.
Regards,
Marshal Antony
..NET Developer
http://www.dotnetmarshal.com
 
This is not as strange as it may seem. I would recommend that you
studied some OOP before you start using ASP.NET for honest. This is
not criticism, just a tip.

When you declare a field as static, as you did with counter, it
belongs to the class, not the instance of the class. This is called
the scope of the variable. Every request creates a new instance of the
page, but that doesn't reset counter because the class that your page
inherits from is still the same. When you recompile the assembly this
value is lost. Because the class has changed.

/Hugo
 
Hello Antony,

I must say I am very impressed. I really didn't expect that ASP.NET
application actually *lives* from the moment it's first used, until the
application is stopped. I was missing the idea that web application is not
any more series of requests, and the reqlested scripts do all the
application logic, but rather application lives it's own interrupted life on
server, and requests come to receive some visual representation and provide
user input. That means, the Application object from classic ASP is no more
actual for storing variables, since every static field is persistent over
all application.

That leads to another question, how the session-scope variable should be
stored? Using the Page.Session object? One of the difficulties I find in
ASP.NET, is that I have to hunt for objects like Response, Request, and
Session, as they all are accessible from Page class scope, but since my
application is split over several libraries, to make them accessible from
outside the Page class scope, I either have to store them in globally
accessible place (shady practice), pass the Page instance down as a
parameter (well, kinda boring), or, what I'd like most, there is some
globally accessible way to get reference to current users Session object, or
Request, or Response. Or, perhaps, I am still thinkgin the old way, and the
Page object instance is actually the only that holds references to these
objects, since it is the workhorse that actually processed the http request,
retrieved the session id cookie, and connected to the appropriate
HttpSessionState object.

Thanks,

-- Pavils
 
You can always get the Session and Cache cache through
System.Web.HttpContext.Current, just add a reference to System.Web if
you haven't already.

/Hugo
 
Hi Pavils,
The Application object still exists in ASP.NET.As you might already know
Application object is used to initialize variables that are available in a
session and that are same for all the users.So chaging the Application
variable value will be reflected in all the current sessions of all the
users.
Creating an Application variable is similar to creating a Session variable.
For eg :
Application["variablename"]="This is a test";
There is a concern when changing the value of an Application
variable.
At any particular session multiple sessions could be trying to change the
Application variable value,although one session
is allowed to change it.ASP.NET has a built in mutual exclusion for dealing
with these type of problems.

Application.Lock(); // Locks the application variables.
Application.Unlock(); // Unlocks the application variables.

Sessions helps to preserve data across successive accesses.This is per user
basis.Hope you already know about sessions.
For session variables,

Session["variblename"]="session test";

As Hugo pointed out you could use System.Web.HttpContext.Current

For eg :



System.Web.HttpContext.Current.Session["variblename"] for getting the value
of session variable.

But if you middle tier object writing directly to the Response
object through HttpContext it could break the encapsulation rules of n-tier
architecure.

So, System.Web.HttpContext.Current.Response.Write("Test"); will
work from your library but may not be advisable.

Hope this helps.

Regards,

Marshal Antony

..NET Developer

http://www.dotnetmarshal.com
 
Hello Antony,

Yes, I see that the Application object works quite the same as in classic
ASP. Though, I must say, I don't see a reason why should I work with
Application object, if every static property of any library from my
application keeps its value over multiple requests, for multiple
connections. So, essentially they function the same as Application object.

Also, I wanted to know is there always a "http context" ofr ASP.NET
application. Say, if my asp page code spawns new thread, that keeps
processing even after the page has been delivered to client browser, the
http party is over and there should not be any "Response", "Request", or
"Cache" objects lingering, though "Session" object would still be relevant.

Regards,

-- Pavils
 
Back
Top