Maintaining state using static members

[dmitri.pekker]

I'm relatively new to web services and I stumbled on some code that
maintains state between calls using a class with static members. This
is not the actual code, but you get the gist:

[WebMethod]
void AddToRepository(string name, int v)
{
ClassWIthStaticMember.AddToRepository(name, v);
}

[WebMethod]
int GetFromRepository(string name)
{
return ClassWIthStaticMember.GetFromRepository(name, v);
}

It seems to work, at least in the short term, but I'm concerned that
this is a very unreliable way of doing things. I'm not sure what the
lifetime of those static methods will be.

Any thoughts?

[Kirk Allen Evans]

You should read this article to get a better understanding of the lifetime
of static members in ASP.NET.

http://blogs.msdn.com/tess/archive/2...23/516139.aspx

In short, statics are not evil, but you have to understand that they don't
die until the AppDomain dies. In ASP.NET, the AppDomain can live for quite
a long time, allowing you to build up lots of references to whatever you are
stuffing into the static in the AddToRepository method.

--
Kirk Allen Evans
Developer Evangelist
Microsoft Corporation
blogs.msdn.com/kaevans

=== This post provided "AS-IS" with no warranties and confers no rights ===
<dm***********@gmail.com> wrote in message
news:11*********************@j55g2000cwa.googlegro ups.com...

I'm relatively new to web services and I stumbled on some code that
maintains state between calls using a class with static members. This
is not the actual code, but you get the gist:

[WebMethod]
void AddToRepository(string name, int v)
{
ClassWIthStaticMember.AddToRepository(name, v);
}

[WebMethod]
int GetFromRepository(string name)
{
return ClassWIthStaticMember.GetFromRepository(name, v);
}

It seems to work, at least in the short term, but I'm concerned that
this is a very unreliable way of doing things. I'm not sure what the
lifetime of those static methods will be.

Any thoughts?

[Dmitri]

Kirk, thanks for the reply.

My concern was that they will die too soon - not too late. So, is it
correct then that unless something disturbs the IIS AppDomain, such as
IISRESET or messing with one of the .config files, the static members
of classes accessed by the web service will live on?

[Kirk Allen Evans]

Yep.

--
Kirk Allen Evans
Developer Evangelist
Microsoft Corporation
blogs.msdn.com/kaevans

=== This post provided "AS-IS" with no warranties and confers no rights ===
"Dmitri" <dm***********@gmail.com> wrote in message
news:11*********************@i39g2000cwa.googlegro ups.com...

Kirk, thanks for the reply.

My concern was that they will die too soon - not too late. So, is it
correct then that unless something disturbs the IIS AppDomain, such as
IISRESET or messing with one of the .config files, the static members
of classes accessed by the web service will live on?

[Deepak Shenoy]

Dmitri wrote:

Kirk, thanks for the reply.

My concern was that they will die too soon - not too late. So, is it
correct then that unless something disturbs the IIS AppDomain, such as
IISRESET or messing with one of the .config files, the static members
of classes accessed by the web service will live on?

The app domain runs under a worker process in IIS.

IIS 6 (Win2003) will recycle worker processes after a period (look at
hte properties on your application pool in IIS). Additionally, there
are other factors used to determine if a worker process should be
recycled: age, time spent idle, number of requests serviced, number of
requests queued, and amount of physical memory consumed.

Read: http://msdn.microsoft.com/msdnmag/is...PPipelines/#S2

--
Deepak Shenoy
http://shenoyatwork.blogspot.com