static field lifespan

[abCSharp]

I understand that static variables have app-domain scope. Till the app-domain
is in memory, the static variable will be in memory. When are the app-domains
unloaded is the question. I have read somewhere in this forum that statics
live till the asp.net process is recycled. Please clarify if someone can.
Thanx!

"David Jessee" wrote:

I'd be VERY careful about using a shared page member for state management.
its true that there is only that single value for all instances of that
type, but there is no way of knowing what the context of that value is
doing. E.g. I set PageX.StaticValue1...its value is retained unless there
are no longer any instances of PageX in the application's memory.

"Mark" <fi******@idonotlikejunkmail.umn.edu> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

I am well aware of state management techniques like Session, Application,
View State, Cookies, etc.. However, I recently discovered that a static
field (variable) essentially acts like an Application variable. If you

set

the value of a static field on one page of your ASP.NET application, it is
suddenly avaiable to every session.

Are there any general guidelines for using this technique? I don't recall
ANY mention of this in training, or documentation online regarding options
for maintaining state.

Thanks in advance.
Mark

[Karl Seguin]

The ASP.Net worker process can be recycled under a number of scenarios. You
can control these normal scenarios by going to:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFI G

(c:\winnt on 2000 and framework version might be different) and opening
machine.config (don't mess around in there!). Find "processModel
Attributes" and you'll find documentation describing a number of settings -
some of which are used for controlling when the worker process is recycled.
In IIS 6.0, there's an ASP.net tab which controls much of these things
(maybe even all,dont' remember).

basically the worker process can recycle itself at certain times/intervals,
when the memory reaches a certain amount, after being idle for too long and
so on. The worker process also terminates when IIS is restarted, or the
web.config file touched

Of course, the worker process can abnormally termniate...like if the system
crashed ;) or some cltr-alt-deletes the process...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"abCSharp" <ab******@discussions.microsoft.com> wrote in message
news:39**********************************@microsof t.com...

I understand that static variables have app-domain scope. Till the app-domain is in memory, the static variable will be in memory. When are the app-domains unloaded is the question. I have read somewhere in this forum that statics
live till the asp.net process is recycled. Please clarify if someone can.
Thanx!

"David Jessee" wrote:

I'd be VERY careful about using a shared page member for state management. its true that there is only that single value for all instances of that
type, but there is no way of knowing what the context of that value is
doing. E.g. I set PageX.StaticValue1...its value is retained unless there are no longer any instances of PageX in the application's memory.

"Mark" <fi******@idonotlikejunkmail.umn.edu> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

I am well aware of state management techniques like Session, Application, View State, Cookies, etc.. However, I recently discovered that a static field (variable) essentially acts like an Application variable. If you

set

the value of a static field on one page of your ASP.NET application,

it is suddenly avaiable to every session.

Are there any general guidelines for using this technique? I don't recall ANY mention of this in training, or documentation online regarding options for maintaining state.

Thanks in advance.
Mark

[abCSharp]

Karl,
I undertand that. My question was more to do with the lifespan of a "static"
variable. When does the statc variable really becomes unreachable?

"Karl Seguin" wrote:

The ASP.Net worker process can be recycled under a number of scenarios. You
can control these normal scenarios by going to:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFI G

(c:\winnt on 2000 and framework version might be different) and opening
machine.config (don't mess around in there!). Find "processModel
Attributes" and you'll find documentation describing a number of settings -
some of which are used for controlling when the worker process is recycled.
In IIS 6.0, there's an ASP.net tab which controls much of these things
(maybe even all,dont' remember).

basically the worker process can recycle itself at certain times/intervals,
when the memory reaches a certain amount, after being idle for too long and
so on. The worker process also terminates when IIS is restarted, or the
web.config file touched

Of course, the worker process can abnormally termniate...like if the system
crashed ;) or some cltr-alt-deletes the process...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"abCSharp" <ab******@discussions.microsoft.com> wrote in message
news:39**********************************@microsof t.com...

I understand that static variables have app-domain scope. Till the

app-domain

is in memory, the static variable will be in memory. When are the

app-domains

unloaded is the question. I have read somewhere in this forum that statics
live till the asp.net process is recycled. Please clarify if someone can.
Thanx!

"David Jessee" wrote:

I'd be VERY careful about using a shared page member for state management. its true that there is only that single value for all instances of that
type, but there is no way of knowing what the context of that value is
doing. E.g. I set PageX.StaticValue1...its value is retained unless there are no longer any instances of PageX in the application's memory.

"Mark" <fi******@idonotlikejunkmail.umn.edu> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
> I am well aware of state management techniques like Session, Application, > View State, Cookies, etc.. However, I recently discovered that a static > field (variable) essentially acts like an Application variable. If you set
> the value of a static field on one page of your ASP.NET application, it is > suddenly avaiable to every session.
>
> Are there any general guidelines for using this technique? I don't recall > ANY mention of this in training, or documentation online regarding options > for maintaining state.
>
> Thanks in advance.
> Mark
>
>

[Karl Seguin]

the lifespan of static variables is directly tied to the lifespan of worker
process. Static variables are tied to the appDomain...whenever a worker
process recycles, it stops its parent appdomain and starts a new one - state
is not transfered from one to another. This should be useful:
http://odetocode.com/Articles/305.aspx

I'm not sure if this was mentioned in the initial thread, but the real risk
with static variables is that you risk having serious race conditions..check
out: http://odetocode.com/Articles/313.aspx

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"abCSharp" <ab******@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.com...

Karl,
I undertand that. My question was more to do with the lifespan of a "static" variable. When does the statc variable really becomes unreachable?

"Karl Seguin" wrote:

The ASP.Net worker process can be recycled under a number of scenarios. You can control these normal scenarios by going to:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFI G

(c:\winnt on 2000 and framework version might be different) and opening machine.config (don't mess around in there!). Find "processModel
Attributes" and you'll find documentation describing a number of settings - some of which are used for controlling when the worker process is recycled. In IIS 6.0, there's an ASP.net tab which controls much of these things
(maybe even all,dont' remember).

basically the worker process can recycle itself at certain times/intervals, when the memory reaches a certain amount, after being idle for too long and so on. The worker process also terminates when IIS is restarted, or the
web.config file touched

Of course, the worker process can abnormally termniate...like if the system crashed ;) or some cltr-alt-deletes the process...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"abCSharp" <ab******@discussions.microsoft.com> wrote in message
news:39**********************************@microsof t.com...

I understand that static variables have app-domain scope. Till the

app-domain

is in memory, the static variable will be in memory. When are the

app-domains

unloaded is the question. I have read somewhere in this forum that statics live till the asp.net process is recycled. Please clarify if someone can. Thanx!

"David Jessee" wrote:

> I'd be VERY careful about using a shared page member for state

management.

> its true that there is only that single value for all instances of that > type, but there is no way of knowing what the context of that value is > doing. E.g. I set PageX.StaticValue1...its value is retained unless

there

> are no longer any instances of PageX in the application's memory.
>
>
>
> "Mark" <fi******@idonotlikejunkmail.umn.edu> wrote in message
> news:%2****************@TK2MSFTNGP15.phx.gbl...
> > I am well aware of state management techniques like Session,

Application,

> > View State, Cookies, etc.. However, I recently discovered that a

static

> > field (variable) essentially acts like an Application variable.

If you

> set
> > the value of a static field on one page of your ASP.NET

application, it is

> > suddenly avaiable to every session.
> >
> > Are there any general guidelines for using this technique? I

don't recall

> > ANY mention of this in training, or documentation online regarding

options

> > for maintaining state.
> >
> > Thanks in advance.
> > Mark
> >
> >
>
>
>

[abCSharp]

Thank you!

"Karl Seguin" wrote:

the lifespan of static variables is directly tied to the lifespan of worker
process. Static variables are tied to the appDomain...whenever a worker
process recycles, it stops its parent appdomain and starts a new one - state
is not transfered from one to another. This should be useful:
http://odetocode.com/Articles/305.aspx

I'm not sure if this was mentioned in the initial thread, but the real risk
with static variables is that you risk having serious race conditions..check
out: http://odetocode.com/Articles/313.aspx

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"abCSharp" <ab******@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.com...

Karl,
I undertand that. My question was more to do with the lifespan of a

"static"

variable. When does the statc variable really becomes unreachable?

"Karl Seguin" wrote:

The ASP.Net worker process can be recycled under a number of scenarios. You can control these normal scenarios by going to:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFI G

(c:\winnt on 2000 and framework version might be different) and opening machine.config (don't mess around in there!). Find "processModel
Attributes" and you'll find documentation describing a number of settings - some of which are used for controlling when the worker process is recycled. In IIS 6.0, there's an ASP.net tab which controls much of these things
(maybe even all,dont' remember).

basically the worker process can recycle itself at certain times/intervals, when the memory reaches a certain amount, after being idle for too long and so on. The worker process also terminates when IIS is restarted, or the
web.config file touched

Of course, the worker process can abnormally termniate...like if the system crashed ;) or some cltr-alt-deletes the process...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"abCSharp" <ab******@discussions.microsoft.com> wrote in message
news:39**********************************@microsof t.com...
> I understand that static variables have app-domain scope. Till the
app-domain
> is in memory, the static variable will be in memory. When are the
app-domains
> unloaded is the question. I have read somewhere in this forum that statics > live till the asp.net process is recycled. Please clarify if someone can. > Thanx!
>
> "David Jessee" wrote:
>
> > I'd be VERY careful about using a shared page member for state
management.
> > its true that there is only that single value for all instances of that > > type, but there is no way of knowing what the context of that value is > > doing. E.g. I set PageX.StaticValue1...its value is retained unless
there
> > are no longer any instances of PageX in the application's memory.
> >
> >
> >
> > "Mark" <fi******@idonotlikejunkmail.umn.edu> wrote in message
> > news:%2****************@TK2MSFTNGP15.phx.gbl...
> > > I am well aware of state management techniques like Session,
Application,
> > > View State, Cookies, etc.. However, I recently discovered that a
static
> > > field (variable) essentially acts like an Application variable. If you
> > set
> > > the value of a static field on one page of your ASP.NET application, it is
> > > suddenly avaiable to every session.
> > >
> > > Are there any general guidelines for using this technique? I don't recall
> > > ANY mention of this in training, or documentation online regarding
options
> > > for maintaining state.
> > >
> > > Thanks in advance.
> > > Mark
> > >
> > >
> >
> >
> >