static variable lifetime in WebService

[Steven Blair]

Hi,

I have webservice which holds a static variable.
I send my first message into the webservice and the static variable gets
a value. If I queried the webservice at a later time (say after 1 hour)
would the static variable still hold the same value, or would the code
be re-initialised and the static variable back to the default value:

//static variable is default 0
//Call webservice
//static variable is set to 1
//Call webservice 1 hour later
//What value is static variable?

My understanding of the webservice process space (in terms of static
vars) was that it matched a windows service, where a static variable
value persisted for the lifetime of the service.

Thanks in advance.

Steven

*** Sent via Developersdex http://www.developersdex.com ***

[Jon Skeet [C# MVP]]

On Jan 10, 10:04 am, Steven Blair <steven.bl...@b tinternet.comwr ote:

<snip>

My understanding of the webservice process space (in terms of static
vars) was that it matched a windows service, where a static variable
value persisted for the lifetime of the service.

It's persisted for the lifetime of the AppDomain. However, ASP.NET may
recycle AppDomains for various reasons, at which point the value of
your variable will be lost.

Jon

[Steven Blair]

Jon

Thanks, I have now turned off the recycling in IIS and seems to be
working fine now.

*** Sent via Developersdex http://www.developersdex.com ***

[Marc Gravell]

Just remember that IIS recycling is there for a reason... if you need
persisted state, then perhaps consider using a database? Or
alternatively host via a windows service, not IIS. The latter is easy
to do for WCF, but a little tricker for an "asmx" style web-service.

But a database would be my first instinct...

Marc

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

As Marc indicated, just "turning off recycling" in IIS is not a very good
guarantee that your app won't lose a static variable's value. If this is the
approach, you may want to modify the Application_Sta rt handler in global.asax
to restore the value on a restart, or use a database or other reliable
persistence mechanism as was suggested.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com
"Steven Blair" wrote:

Jon

Thanks, I have now turned off the recycling in IIS and seems to be
working fine now.

*** Sent via Developersdex http://www.developersdex.com ***

[Steven Blair]

Well from what I see this is exactly what I want. The application really
does need to be a webservice (for a number of reasons) and I just need
to preserve the application at all times.

What concerns would you have by this approach. Is there soemthing I have
missed?

The overhead of the AppDomain surely its negligible (its a very simple
webservice with a few statics that on each call, creates an instance of
a dll, does some work (consults the static variables) and finishes.
*** Sent via Developersdex http://www.developersdex.com ***

[Jon Skeet [C# MVP]]

Steven Blair <st**********@b tinternet.comwr ote:

Well from what I see this is exactly what I want. The application really
does need to be a webservice (for a number of reasons) and I just need
to preserve the application at all times.

What concerns would you have by this approach. Is there soemthing I have
missed?

The overhead of the AppDomain surely its negligible (its a very simple
webservice with a few statics that on each call, creates an instance of
a dll, does some work (consults the static variables) and finishes.

1) If your server falls over (e.g. power cut) you've got problems if
you've got no more persistence than memory

2) Changes to the application or its configuration will require
AppDomain recycling

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Marc Gravell]

well, reboot would be the obvious one...

But also; if your state management is in memory, you have no
opportunity to load-balance / failover. For me, that would be a big
problem. A database (especially on a dedicated server) provides an
abstraction to this, allowing all your servers to share state, and
allowing you to change the cluster on the fly without affecting the
data that people see. Maybe you don't need this level of complexity.

Also - the fact is that occasionally apps die, and it would be
simplistic to assume that the single appdomain is going to run
indefinitely within IIS. A vanilla windows service (since it is much
simpler) will probably run for much longer, but eventually (either due
to an OS restart, or just karma) it will have to be restarted. State
gone.

Marc

[Steven Blair]

Rebooting / crashing is something we considered so we have a primary,
secondary and a tertiary site for such events.
If the box is down, communication is moved over to secondary etc.
If a next communcation came in after a box was rebooted therefore still
accessed the primary, the statics would be lost, but we have a process
in place for this scenario.

Thanks for the advice, and perhaps the next time I appraoch a similar
problem a Database might be considered.
*** Sent via Developersdex http://www.developersdex.com ***

[Steven Blair]

Rebooting / crashing is something we considered so we have a primary,
secondary and a tertiary site for such events.
If the box is down, communication is moved over to secondary etc.
If a next communcation came in after a box was rebooted therefore still
accessed the primary, the statics would be lost, but we have a process
in place for this scenario.

Thanks for the advice, and perhaps the next time I appraoch a similar
problem a Database might be considered.
*** Sent via Developersdex http://www.developersdex.com ***