Application Vars and Objects in them

hi,

Can I pose a quick question (I did a a search for -application variables- but didnt find anything relevant to my needs but appologise if this has been asked manytimes over....

I was taught to code in asp without (or very infrequeltly) using application and session variables. I understand they impact performance/memory usage and if objects are created, cause big issues if it not threaded appropriately...

my question is this, I wrote an NT service and ask it to be installed on a webserver. At that point our tech area said that my work was overkill and I should re-write my app as script/dll and using application variable.. Management agreed and I change my design.


I have now quite alot on info as application vars including a couple of objects (ado resordsets) and am concerned that I will encounter problems..

If I used session vars then I would have one ser of data per user therefore would run out of memory on the server if there were alot of users...

Am I right is saying that I only have one set of data when using app vars? Therefore there is no problem and I am being to cautious (IIS doesnt do anything stupid like copy them per usage....)

Im not quite sure.... any better perspective would be appreciate.

Cheers, A.J.P. Ext 4290.

In my experience, I basically try to use session and application variables sparingly, basically only when necessary. I try to pass as much as I can through forms and/or querystrings.

And... NEVER store objects (especially ADO objects) in the session or application object. There is only one exception to that and that is for generating Crystal Reports using asp. Their rptserver.asp requires the rs and rpt objects reside in the session object.

Hi,

Thanks both - your comments pretty are much along the lines - dont do it, which i was expecting :)

I was really asking why?

Having changed what I was doing and told to use app vars..... (actually the objects i mentioned are indeed ado objects - ouch!!)

If I use app vars (expecting there to be one set for all users) - What is the problem providing my data isnt huge??

many thanks, AJP.

There are several reasons to not do this.

o State. Whenever possible, your application should remain stateless. If it must maintain state at all, it should do it client side using cookies. The biggest thing people use session object for is maintaining state such as has the user logged in, etc.

o Server Resources. Each instance of an ADO object takes up server resources. If it is not destroyed explicitly using Set object = Nothing, the object continues to eat up server memory. Once the server runs out of physical memory, it used the pagefile same as your desktop pc. This is really bad for servers because they severely slows down the ability to serve up pages because swap file activity typically slows down overall performance.

o Scalability. Let's say you write a web application. Your company likes it and uses it in house. Then someone gets a great idea. Let's allow our customers to access it and charge for the service (this sort of thing is happening where I work RIGHT NOW). If you are going to have a outward facing application, it will most likely reside on a fault tolerant, load balanced server farm. Application objects and Session objects live only on the server they are instantiated on. But with load balancing, you can't guarantee which server will get the request each time. It depends on which one isn't busy. You could create a session on server 1 and the request for the next page is sent to server 3. If a server gets a request that needs a session object, if it didn't start the session, it can't access it.

o Even Microsoft recomends not putting ADO objects into session and application objects. (Which is probably the biggest reason not to do it since they wrote them).

Splendid!

Thankyou Monte - Very much appreciated.

Cheers, A.J.P.

I just got this info from http://msdn.microsoft.com/library/de...tml/aspwsm.asp

I'm refering mostly to ASP Session Aware Load-Balancing that is mentioned towards the end of this text.

has anyone tried this with success?


Web Farms and ASP Session State
ASP session information is stored in memory on the Web server, which creates a challenge for using Active Server Pages in a Web farm environment, where requests are load balanced among a number of Web servers. In order to use the ASP Session object, the same Web server must handle all requests from a user for the life of the session. Most load balancing schemes do not ensure that requests return to the same server.

To use ASP in a load-balanced environment, there are a number of options available, some of which are outlined below:

Do not use the session management provided by ASP. You can write your own session management logic that keeps session state in a centralized place, such as a database server. This is a good solution; however, you lose the benefits of ASP session management.
Use a third-party session management ActiveX component. Because ASP can support ActiveX components, it is feasible that a commercial component will be available for ASP that supports session management in a Web farm.
Load-balance all new requests across your server farm; but once a session begins, make sure that all subsequent requests for that session return to the same server. This technique allows you to load-balance at a logical session level rather than load-balancing each individual request, and is sometimes called "ASP session aware load-balancing."
ASP Session Aware Load-Balancing
There are a number of possibilities to implement ASP session aware load-balancing. One simple technique is to load-balance all new requests using current load-balancing mechanisms (for example, round-robin DNS or dedicated IP load balancers). The load balancer will distribute all requests to a site's well known URL. For example, a site could be known by a DNS name such as example.microsoft.com. Any Web requests to this site will be load balanced among the active servers in the Web farm. In the Session_OnStart event that is fired for each new session, the ASP script can use the ASP Response object to send the user an HTTP redirect response. This response can redirect the browser to request an ASP page from the specific server that the user's session is running on. For instance, the redirect URL could specify the IP address, or unique name, of the machine on which the user's session was running. Then all future requests based on relative URLs would return to the machine specified by the redirect.

When a user first comes to a Web application by clicking a hyperlink, or typing a URL such as http://example.microsoft.com/Webapp/, a load balancer routes the request to a specific machine in the Web farm. For example, the load balancer selects a machine named w10.asite.com to handle this request. ASP will create a new session for the request running on this specific machine. In the Session_OnStart event, the ASP script can redirect the user,

<% Response.Redirect("http://w10.sample.com/Webapp/firstpage.asp"
%>

The browser will request the specified page, and can run the application. The only requirement is that all URLs embedded in each page (as hyperlinks or form actions) should be relative URLs, for example:

<FORM METHOD="POST"
ACTION="ProcessForm.ASP"></FORM>

<A HREF="nextpage.asp">

While the user is using the application, all requests will return to the same Web server on which the session is running. This technique may not be appropriate for all Web applications. If users save URLs using favorites or bookmarks, they may save a URL to a specific machine and when they return for a new session, they will not be properly load-balanced. The Session_OnStart logic can choose to accept these requests or intelligently return the user to the well-known URL (http://example.microsoft.com/Webapp/) for load-balancing. This is only an example technique to allow ASP session management to work in a Web farm. Other methods are available. You don't have to do it using a redirect; you can get the same effect by using full URLs in your start page that specify the server the session is on.

''*********** authors name below.....*******
Michael P. Levy specializes in Internet and client-server application development. His current focus is helping Microsoft's New York customers design and deploy Internet and intranet solutions.
*********** end author name ******


I think we are leaning towards using a DB to maintain state for the app we are building now but some of what is mentioned above may be more effeciant.

thanks