Life of static variables in ASP.NET 2.0

[Shimon Sim]

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.

[Kevin Spencer]

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.

[PeterKellner]

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

[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

[Shimon Sim]

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

[Shimon Sim]

Dictionary description on MSND does say that iteration operations are not
thread safe.
Shimon.
"CS" <[e-mail]> 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

[MSDN]

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

[Shimon Sim]

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

[Hans Kesting]

> 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

[Steven Cheng[MSFT]]

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.)

[Kevin Spencer]

> 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" <[e-mail]> 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

[Kevin Spencer]

> 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

[Flinky Wisty Pomm]

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?

[PeterKellner]

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

[Kevin Spencer]

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?