ASP.Net Persistant Object State

Eriedor · 25 Mar 2009 at 22:50

Firstly just gotta say I'm completely new to ASP.Net, used to web dev in php.

[hope this makes sense, it's hard to verbalise what I want to know]

Can ASP.Net object exist outside the scope of the page/control they were instantiated in?

As in can I instantiate an object of a .net class that persists accross multiple web pages and requests? So that each request uses exactly the same object.

Example:

I have a .Net dll which contains a class that periodically reads the current performance statistics of the server (cpu, mem, disk io etc). Can this be created upon first request and all subsequent requests use the same object? or do they have to recreate the object and thus recreate all the performance counters for every request?

This can be done by a service I know, but I would prefer to minimise the installation overhead.

mk17 · 25 Mar 2009 at 23:38

You can store this in the Application, or Session (if you've enabled sessions) - or in the Cache. A quick google should give you all the info you'll need.

hth.

Goksly · 25 Mar 2009 at 23:44

I'm not an expert by any stretch but I *think* the following is true:
* Don't use the application
* Only store user specific information in the Session
* Use the cache of application wide objects

The above, as far as I am aware, are very loose rules - but are correct for majority / non-specialised stuff. Just be aware of the scope; most will be the app domain unless you alter config (session state in sql server etc) or write your own stuff.

As I said I'm fairly new to all this, but this is what I have picked up. Hope its right

akakjs · 26 Mar 2009 at 08:15

If it's just one instance of the object (hopefully it's thread-safe!). You could pop it in the asp.net cache if you want, as that gives you some life-cycle control over it (so you know it will be disposed at some point).

A good breakdown of asp.net caching (I linked to directly to the section you want, but the whole article is worth reading).

akakjs

Haircut · 26 Mar 2009 at 09:58

akakjs said:
A good breakdown of asp.net caching (I linked to directly to the section you want, but the whole article is worth reading).

akakjs

To be honest, that whole website is invaluable for anyone learning ASP.NET

Eriedor · 26 Mar 2009 at 13:13

Goksly said:
I'm not an expert by any stretch but I *think* the following is true:
* Don't use the application
* Only store user specific information in the Session
* Use the cache of application wide objects

The above, as far as I am aware, are very loose rules - but are correct for majority / non-specialised stuff. Just be aware of the scope; most will be the app domain unless you alter config (session state in sql server etc) or write your own stuff.

As I said I'm fairly new to all this, but this is what I have picked up. Hope its right

Thanks for that.

As i understand it the application object is there for backwards compat and easy migration from legacy asp apps.

Session can only store serializable objects as it is stored in text cookies.

Cache is exactly what I need!

akakjs said:
If it's just one instance of the object (hopefully it's thread-safe!). You could pop it in the asp.net cache if you want, as that gives you some life-cycle control over it (so you know it will be disposed at some point).

A good breakdown of asp.net caching (I linked to directly to the section you want, but the whole article is worth reading).

akakjs

The object is an immutable wrapper for a few performance counters so thread safe.