469,890 Members | 1,412 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,890 developers. It's quick & easy.

Life of static variables in ASP.NET 2.0

I have a static variable defined something like this

private static Dictionary<string, string[]> roles = new
Dictionary<string,string[]>();

Can I safely assume that it will be live for the live of application?

Meaning that any thread/page of the application will have access to the data
in this variable.

Thank you.
May 18 '06 #1
14 17640
Yes, and that isn't necessarily a good thing. Static entities are not
necessarily thread-safe. Be careful about when you use them.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Complex things are made up of
lots of simple things.

"Shimon Sim" <sh**********@community.nospam> wrote in message
news:uB**************@TK2MSFTNGP04.phx.gbl...
I have a static variable defined something like this

private static Dictionary<string, string[]> roles = new
Dictionary<string,string[]>();

Can I safely assume that it will be live for the live of application?

Meaning that any thread/page of the application will have access to the
data in this variable.

Thank you.

May 18 '06 #2
On Wed, 17 May 2006 22:10:44 -0400, "Shimon Sim"
<sh**********@community.nospam> wrote:
I have a static variable defined something like this

private static Dictionary<string, string[]> roles = new
Dictionary<string,string[]>();

Can I safely assume that it will be live for the live of application?

Meaning that any thread/page of the application will have access to the data
in this variable.

Thank you.


Hmmm. You are asking this in the asp.net forum which makes me think
you are thinking the "live of the application" is more than one page
hit. I'll go on a little assuming this is the case, otherwise,
forgive me for rambling.

Since asp.net is stateless, nothing you declare in your local stack or
heap will persist through a postback.

So, I'm assuming you don't want to go after the data again so you
should either store it in your viewstate, Session or Cache.

One big warning that Scott Guthrie gave me once though is be very
careful when persisting security data (like role information). It can
cause some ugly security scenarios.

Good luck,

-Peter

PS: nice Dictionary Declaration! I love generics.
Peter Kellner
http://peterkellner.net
May 18 '06 #3
CS

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
that isn't necessarily a good thing.
Why ?
Static entities are not necessarily thread-safe. Be careful about when you
use them.


I say it is safe. Because it is "static". Static means "fixed", not
modifiable. Otherwise,
it is dynamic, which may not be safe. Static data only get changed when
ASP.net
recycles.

Example: Static data may be loaded in a singleton class. In this case,
whomever
references the variable 1st will load the class. The class will stay there
until Asp.Net recycles
and or web server service is restarted.

Comacho
May 18 '06 #4
I have this variable in a class
public class UserVerifier //just made up a name
{
private static roles=...
}
And then I am calling it from HttpModule for each request.
I have some issues with my app and I want to make sure that everything I did
is 100%.
Thanks.
"PeterKellner" <pk**********@73rdstreet.com> wrote in message
news:pj********************************@4ax.com...
On Wed, 17 May 2006 22:10:44 -0400, "Shimon Sim"
<sh**********@community.nospam> wrote:
I have a static variable defined something like this

private static Dictionary<string, string[]> roles = new
Dictionary<string,string[]>();

Can I safely assume that it will be live for the live of application?

Meaning that any thread/page of the application will have access to the
data
in this variable.

Thank you.


Hmmm. You are asking this in the asp.net forum which makes me think
you are thinking the "live of the application" is more than one page
hit. I'll go on a little assuming this is the case, otherwise,
forgive me for rambling.

Since asp.net is stateless, nothing you declare in your local stack or
heap will persist through a postback.

So, I'm assuming you don't want to go after the data again so you
should either store it in your viewstate, Session or Cache.

One big warning that Scott Guthrie gave me once though is be very
careful when persisting security data (like role information). It can
cause some ugly security scenarios.

Good luck,

-Peter

PS: nice Dictionary Declaration! I love generics.
Peter Kellner
http://peterkellner.net

May 18 '06 #5
Dictionary description on MSND does say that iteration operations are not
thread safe.
Shimon.
"CS" <CS@HotMeal.Com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
that isn't necessarily a good thing.


Why ?
Static entities are not necessarily thread-safe. Be careful about when
you use them.


I say it is safe. Because it is "static". Static means "fixed", not
modifiable. Otherwise,
it is dynamic, which may not be safe. Static data only get changed when
ASP.net
recycles.

Example: Static data may be loaded in a singleton class. In this case,
whomever
references the variable 1st will load the class. The class will stay there
until Asp.Net recycles
and or web server service is restarted.

Comacho

May 18 '06 #6
In web this is not going to work

"Shimon Sim" <sh**********@community.nospam> wrote in message
news:uO****************@TK2MSFTNGP05.phx.gbl...
I have this variable in a class
public class UserVerifier //just made up a name
{
private static roles=...
}
And then I am calling it from HttpModule for each request.
I have some issues with my app and I want to make sure that everything I
did is 100%.
Thanks.
"PeterKellner" <pk**********@73rdstreet.com> wrote in message
news:pj********************************@4ax.com...
On Wed, 17 May 2006 22:10:44 -0400, "Shimon Sim"
<sh**********@community.nospam> wrote:
I have a static variable defined something like this

private static Dictionary<string, string[]> roles = new
Dictionary<string,string[]>();

Can I safely assume that it will be live for the live of application?

Meaning that any thread/page of the application will have access to the
data
in this variable.

Thank you.


Hmmm. You are asking this in the asp.net forum which makes me think
you are thinking the "live of the application" is more than one page
hit. I'll go on a little assuming this is the case, otherwise,
forgive me for rambling.

Since asp.net is stateless, nothing you declare in your local stack or
heap will persist through a postback.

So, I'm assuming you don't want to go after the data again so you
should either store it in your viewstate, Session or Cache.

One big warning that Scott Guthrie gave me once though is be very
careful when persisting security data (like role information). It can
cause some ugly security scenarios.

Good luck,

-Peter

PS: nice Dictionary Declaration! I love generics.
Peter Kellner
http://peterkellner.net


May 18 '06 #7
Usually it is working here.
Do you have any specifics why not?
Thanks

"MSDN" <sq**********@hotmail.com> wrote in message
news:uO**************@TK2MSFTNGP05.phx.gbl...
In web this is not going to work

"Shimon Sim" <sh**********@community.nospam> wrote in message
news:uO****************@TK2MSFTNGP05.phx.gbl...
I have this variable in a class
public class UserVerifier //just made up a name
{
private static roles=...
}
And then I am calling it from HttpModule for each request.
I have some issues with my app and I want to make sure that everything I
did is 100%.
Thanks.
"PeterKellner" <pk**********@73rdstreet.com> wrote in message
news:pj********************************@4ax.com...
On Wed, 17 May 2006 22:10:44 -0400, "Shimon Sim"
<sh**********@community.nospam> wrote:

I have a static variable defined something like this

private static Dictionary<string, string[]> roles = new
Dictionary<string,string[]>();

Can I safely assume that it will be live for the live of application?

Meaning that any thread/page of the application will have access to the
data
in this variable.

Thank you.
Hmmm. You are asking this in the asp.net forum which makes me think
you are thinking the "live of the application" is more than one page
hit. I'll go on a little assuming this is the case, otherwise,
forgive me for rambling.

Since asp.net is stateless, nothing you declare in your local stack or
heap will persist through a postback.

So, I'm assuming you don't want to go after the data again so you
should either store it in your viewstate, Session or Cache.

One big warning that Scott Guthrie gave me once though is be very
careful when persisting security data (like role information). It can
cause some ugly security scenarios.

Good luck,

-Peter

PS: nice Dictionary Declaration! I love generics.
Peter Kellner
http://peterkellner.net



May 18 '06 #8
> I have a static variable defined something like this

private static Dictionary<string, string[]> roles = new
Dictionary<string,string[]>();

Can I safely assume that it will be live for the live of application?

Meaning that any thread/page of the application will have access to the data
in this variable.

Thank you.


That same "roles" Dictionary will be available to all users (Sessions)
of your application, until the application recycles. The data in it
could be modified by any thread accessing it, so there you will need
some locking mechanism.

Hans Kesting
May 18 '06 #9
Hi Shimon,

As for static variables, they'll live during the lifetime of its host
AppDomain. And as for ASP.NET application, if you're not using webgarden or
webfarm to load balacne it, each application instance will be hosted in a
single AppDomain in the worker process. The static variables will be
available during the application's lifetime.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

May 18 '06 #10
> I say it is safe. Because it is "static". Static means "fixed", not
modifiable. Otherwise,
it is dynamic, which may not be safe. Static data only get changed when
ASP.net
recycles.
You can say anything you want. You can believe anything you want. As far as
the facts are concerned, it doesn't make a lick of difference. Facts are not
matters of opinion, nor does opinion affect facts. "Static" does not mean
"fixed." A static member or class is a single-instance entity that is not
instantiable is scoped to an application. It can certainly be changed. If
you have a static integer, for example, you can assign any value to it.

As to thread-safety, you may (or may not) want to read the following MSDN
Magazine article:

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

It actually contains a lot more information about statics than thread
issues, but discusses that as well.

The following resources may also be of use:

http://msdn.microsoft.com/library/de...rfstaticpg.asp
http://msdn2.microsoft.com/en-us/library/79b3xss3.aspx

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Complex things are made up of
lots of simple things.

"CS" <CS@HotMeal.Com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
that isn't necessarily a good thing.


Why ?
Static entities are not necessarily thread-safe. Be careful about when
you use them.


I say it is safe. Because it is "static". Static means "fixed", not
modifiable. Otherwise,
it is dynamic, which may not be safe. Static data only get changed when
ASP.net
recycles.

Example: Static data may be loaded in a singleton class. In this case,
whomever
references the variable 1st will load the class. The class will stay there
until Asp.Net recycles
and or web server service is restarted.

Comacho

May 18 '06 #11
> Hmmm. You are asking this in the asp.net forum which makes me think
you are thinking the "live of the application" is more than one page
hit. I'll go on a little assuming this is the case, otherwise,
forgive me for rambling.

Since asp.net is stateless, nothing you declare in your local stack or
heap will persist through a postback.
I hope you're not referring to static entities here. They exist for the
lifetime of the application. The application lifetime extends well beyond
the scope of a single instance of a Page.

ASP.Net is not stateless. HTTP is a stateless protocol. An ASP.Net Page
instance lasts for the time it takes to respond to a single Request. The
application lasts from the first Page Request from any client until 20
minutes after the last Page Request from any client.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

The man who questions opinions is wise.
The man who quarrels with facts is a fool.

"PeterKellner" <pk**********@73rdstreet.com> wrote in message
news:pj********************************@4ax.com... On Wed, 17 May 2006 22:10:44 -0400, "Shimon Sim"
<sh**********@community.nospam> wrote:
I have a static variable defined something like this

private static Dictionary<string, string[]> roles = new
Dictionary<string,string[]>();

Can I safely assume that it will be live for the live of application?

Meaning that any thread/page of the application will have access to the
data
in this variable.

Thank you.


Hmmm. You are asking this in the asp.net forum which makes me think
you are thinking the "live of the application" is more than one page
hit. I'll go on a little assuming this is the case, otherwise,
forgive me for rambling.

Since asp.net is stateless, nothing you declare in your local stack or
heap will persist through a postback.

So, I'm assuming you don't want to go after the data again so you
should either store it in your viewstate, Session or Cache.

One big warning that Scott Guthrie gave me once though is be very
careful when persisting security data (like role information). It can
cause some ugly security scenarios.

Good luck,

-Peter

PS: nice Dictionary Declaration! I love generics.
Peter Kellner
http://peterkellner.net

May 18 '06 #12
Interesting remark on the thread-safety of iteration; what exactly does
that mean in the context of:

static ICollection<T> myCollection;

....

foreach(T member in myCollection)
{
doSomethingWithMember(...);
}

Will each foreach have a separate iterator? Is the thread-safety issue
simply due to values being changed/appended or are there subtler
problems?

Is it possible to have a readonly iterator on a collection in .Net like
the T::const_iterator in C++, and would a collection accessible only by
such an iterator be thread safe?

May 18 '06 #13
On Thu, 18 May 2006 06:09:53 -0400, "Kevin Spencer"
<ke***@DIESPAMMERSDIEtakempis.com> wrote:
Hmmm. You are asking this in the asp.net forum which makes me think
you are thinking the "live of the application" is more than one page
hit. I'll go on a little assuming this is the case, otherwise,
forgive me for rambling.

Since asp.net is stateless, nothing you declare in your local stack or
heap will persist through a postback.


I hope you're not referring to static entities here. They exist for the
lifetime of the application. The application lifetime extends well beyond
the scope of a single instance of a Page.

ASP.Net is not stateless. HTTP is a stateless protocol. An ASP.Net Page
instance lasts for the time it takes to respond to a single Request. The
application lasts from the first Page Request from any client until 20
minutes after the last Page Request from any client.

Good point. thanks for correcting me.
Peter Kellner
http://peterkellner.net
May 18 '06 #14
Static members are accessible across classes, instances, and threads.
Because .Net is multi-threaded, you can run into a situation where 2 or more
threads are trying to access and/or change a static variable at the same
time, with unexpected consequences. Static members should therefore be
locked when accessing. The following is a good article that provides a
number of helpful threading "rules" -

http://www.anticipatingminds.com/Con...ledgePack.aspx

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

The man who questions opinions is wise.
The man who quarrels with facts is a fool.

"Flinky Wisty Pomm" <Pa********@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...
Interesting remark on the thread-safety of iteration; what exactly does
that mean in the context of:

static ICollection<T> myCollection;

...

foreach(T member in myCollection)
{
doSomethingWithMember(...);
}

Will each foreach have a separate iterator? Is the thread-safety issue
simply due to values being changed/appended or are there subtler
problems?

Is it possible to have a readonly iterator on a collection in .Net like
the T::const_iterator in C++, and would a collection accessible only by
such an iterator be thread safe?

May 18 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Natalia DeBow | last post: by
2 posts views Thread by Eirik WS | last post: by
9 posts views Thread by ur8x | last post: by
25 posts views Thread by Sahil Malik [MVP] | last post: by
8 posts views Thread by Simone Chiaretta | last post: by
4 posts views Thread by David Buck | last post: by
15 posts views Thread by kj | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.