Fundamental ASP.NET question

[maneeshkhare]

I have a doubt regarding the architecture, and working of the ASP.NET
framework. I haven't been able to satisfy myself with any answer.

I do understand that for each request for a resource (let's talk page),
we have 1 HttpApplication object from a pool that is managed by
HttpApplicationFactory. My question is this. After all the objects
that are created to service 1 request, is the same dll referenced for 1
page.
Let's say 3 people are trying to access Page1.aspx. Each of their
requests will be handled by 3 separate HttpApplication objects, but
will all their requests be delegated to 1 dll corresponding to
Page1.aspx, or 3 separate dlls.
The reason I'm asking is because if there is only 1 dll being used, I
will think twice before using any static properties/fields, to avoid
synchronization issues, when the properties are read/write.

Thanks in advance.
Maneesh

 

[Erik Funkenbusch]

I have a doubt regarding the architecture, and working of the ASP.NET
framework. I haven't been able to satisfy myself with any answer.

I do understand that for each request for a resource (let's talk page),
we have 1 HttpApplication object from a pool that is managed by
HttpApplicationFactory. My question is this. After all the objects
that are created to service 1 request, is the same dll referenced for 1
page.
Let's say 3 people are trying to access Page1.aspx. Each of their
requests will be handled by 3 separate HttpApplication objects, but
will all their requests be delegated to 1 dll corresponding to
Page1.aspx, or 3 separate dlls.
The reason I'm asking is because if there is only 1 dll being used, I
will think twice before using any static properties/fields, to avoid
synchronization issues, when the properties are read/write.

Thanks in advance.
Maneesh

There is seldom any valid reason to use static data anyways. Why would you
even want to? Each HTTP Request is it's own universe. It may have data
saved via Session or page variables that is carried over from one request
to the next, but it must be a self contained unit in and of itself because
requests are stateless.

This means that you can't expect any data in a static variable to exist
after a round trip. It might, or it might not. It depends on whether the
web server unloads your DLL or not, and you don't really have any control
over that.

So, because the very idea of using static data is largely pointless in the
first place, I think your question about whether it's safe to do so is
irrelevent. And, that's not even getting into the issues with AppDomains
and how the framework works at a lower level.

 

[Maneesh]

Erik, Thanks for your reply.
The reason is this. I usually try to have a backend class library
providing me utility functions/DAL functionality to be used by the Web
Application.
Now, I want to store the connection string in the Web.config file, and
then set some static property of the backend class (where I cannot get
a handle to the Session variable) with it, so that I can re-use it
throughout the application, whenever I want to make a connection,
instead of passing it to a backend method each time.
I'm not sure if this is a good practice, or what would be a good
practice in such a case, i.e. when you want to have a class library at
the back, but want to use some data from Web.config throughout the
lifetime of the Web Application.
Do let me know if you can shed some light on this.

regards,
Maneesh

 

[Juan T. Llibre]

re:

I do understand that for each request for a resource (let's talk page),
we have 1 HttpApplication object from a pool that is managed by
HttpApplicationFactory.

Incorrect.

For *all* pages served, within an application,
there's 1 HttpApplication object which serves as their "home".

re:

will all their requests be delegated to 1 dll corresponding to
Page1.aspx, or 3 separate dlls.

One assembly...unless you're not caching or unless the Cache dies before the next request.
In any case, if the Cache dies...you'll *still* have only one assembly, which will be recreated.

You can fine-tune this by smart use of the Cache feature.

re:

The reason I'm asking is because if there is only 1 dll being used, I
will think twice before using any static properties/fields, to avoid
synchronization issues, when the properties are read/write.

Static data is global to the application.

You cannot change static properties unless the application is restarted.
That's why they are called *static*.

Kevin Spencer explained this quite well some time ago :

Anything that is static is stored in the heap, rather than the stack.

There are 2 basic memory areas in any application.
The heap is where all the code for the app is initially loaded.

The stack is where instances (copies) of variables, functions, etc. are kept when they are
instantiated.
Data in the stack is volatile; When it goes out of scope, it is removed from the stack.

When you call a function, for example, a copy (instance) of that function is placed on the stack.
When the function exits, it is pulled off the stack.

The heap, on the other hand, is not volatile.
It remains in memory for the lifetime of the application.

 

[Maneesh]

Juan,

Thanks for your answer. So if static stuff is class level, if I end up
having 1 method (static) in a utility class in the backend, which is a
class library, I'm pretty sure I will end up having synchronization
issues when multiple requests from the GUI pages cause the call to this
static method in the class library.

Am I correct, because if that is so, I will have to place appropriate
locking in the critical sections of the code.

Maneesh

 

[Juan T. Llibre]

That depends on the type of method.

Scott Allen has explained this well :

If each thread operates on data specific to the thread, then no locks are needed.

For example:

public static string GetCookieName(Cookie c)
{
return c.Name;
}

...no problem.

If, on the other hand, multiple threads can access a shared object,
you need to be very careful:

static ArrayList cookieList = new ArrayList();

public static void AddToCookieList(Cookie c)
{
cookieList.Add(c);
}

No matter how fast the above method looks, the chance of corruption exists
because it doesn't prevent multiple threads from getting inside the Add method.

---000---

So, the issue is whether multiple threads can access the same shared object/data.

If the static method accesses and modifies data, that data would
have to be locked for the duration of the modification procedure.





Juan,

Thanks for your answer. So if static stuff is class level, if I end up
having 1 method (static) in a utility class in the backend, which is a
class library, I'm pretty sure I will end up having synchronization
issues when multiple requests from the GUI pages cause the call to this
static method in the class library.

Am I correct, because if that is so, I will have to place appropriate
locking in the critical sections of the code.

Maneesh

 

[Guest]

Your "Backend method" can access the appSettings or ConnectionStrings
sections of the web.config just as the page class can. Provided it has a
reference to System.Web, its running in the same AppDomain.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

 

[sonic]

Maneesh,
your page implements IhttpHandler. This is the interface that needs to
be implemented by any handler of a incoming request and Page is one of
them.
IHttpHandler comes with IsReuseable property which is set to false in
Page class. This method tells application factory to whether it should
be using the existing IHttpHandler object or creating a new one. So in
the case of Page, a new page object will be created every time for a
incoming request so i don't think you should have any issues with
sharing static variables.
but this would be very easy to test and remove all doubt

 

[Maneesh]

Thanks Sonic.

I'll spike it and see what happens.