Static properties

  • Thread starter Thread starter Mantorok
  • Start date Start date
M

Mantorok

Hi

I have an ASP app which references a few static properties in some of the
classes. I understand that you should use Session variables, but is it
"possible" to have each session "not" reference the same static members.

For example if I update the static member on one session this change will be
reflected on somebody elses session, which I don't want.

I hope there's an easy solution for this as changing to session variables
may prove to be a pain.

Thanks
Kev
 
No. You could use instance properties instead, but then you'd have to carry
around the instance in the session for it to persist from request to
request. You'll likely need to explain your needs in more detail in order
to get any useful help..specifically with respect to why you can't use
sessions and what you are trying to do..

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
 
Karl Seguin said:
No. You could use instance properties instead, but then you'd have to
carry
around the instance in the session for it to persist from request to
request. You'll likely need to explain your needs in more detail in order
to get any useful help..specifically with respect to why you can't use
sessions and what you are trying to do..
Click to expand...

No is all I needed to know, the reason I asked is because the ASP.Net is
using a framework we developed for use on a windows forms client, obviously
if you fire up the app more than once you get a clean slate, but with
ASP.Net it is session-based.

So rather than relying on the static member used by the framework, I'll need
to adjust to Session variables.

Thanks
Kev
 
I have an ASP app which references a few static properties in some of the
classes. I understand that you should use Session variables,
Click to expand...

Actually, the problem is that you DON'T understand. A blanket statement like
"you should use Session variables" indicates that you don't understand, but
have heard people say this. Session variables, Static properties and
methods, and other means of storing data in a more or less global fashion
are tools. A good carpenter understand his tools; otherwise he can't use
them properly.

So, let me see if I can help you understand your tools better.

Anything that is static is stored in the heap, rather than the stack. There
are 2 basic memory areas in any applicaiton. 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 app.

Session is an object, or rather, an instance of an object. It is a managed
memory space (Collection) that you can use in a thread-safe manner. Static
data is in the heap, and there is only one instance of it (hence the term
"singleton"). For this reason, it is not thread-safe. It is entirely
possible for more than one thread to be accessing the data at the same time.

Static data is NOT stored in Session. Session is on the Stack; static data
is in the heap. If yoiu PUT a static member into Session, it still remains
in the heap, and the Session variable points to it.

In addition, static data is by nature global to the entire app. Session data
is only global to a single user Session.

And BTW, you also have the Application Cache to store global data in. The
Application Cache is similar to Session, but global to the entire app, and
it is thread-safe. You also have ViewState, which is scoped to a Page.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.
 
Static members are also not thread-safe..which is dangerous in ASP.Net.

What I've seen most people do is use a smart provider.


public interface IStateInformation
void Add(object key, object value);
void Remove(object key);
...
end interface


interneal class WebState : IStateInformation
public void Add(object key, object value){
HttpContext.Current.Session.Add(key, value);
}
public void Remove(object key){
HttpContext.Current.Session.Remove(key);
}
}

internal class WindowsState : IStateInformation
private static Hashtable _state = new Hashtable;
public void Add(object key, object value){
WindowsState._state.Add(key, value);
}
public void Remove(object key){
WindowsState._state.Remove(key);
}
}


public class StateProvider{
public statc IStateInformation GetProvider{
get {
return (HttpContext.Current != null) ? new WebState() : new
WindowsState();
}
}
}

Anyways, I have no doubt my implementation is bogus..but hopefully it gets
you off in the right direction....I think my WindowState is really
screwed...I'm stuffy..can't tthink...

karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
 
Back
Top