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

 

[Jon Skeet [C# MVP]]

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.

 

[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

 

[Peter Bromberg [C# MVP]]

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_Start 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]

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.

 

[Jon Skeet [C# MVP]]

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

 

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

 

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

 

[Steven Blair]

Ok, so it seems I do have a problem with this approach.
Each call to my webservice creates an instance of a dll but I don't
think this dll is ever cleaned up (memory wise).
Is the dll still managed memory in this scenario, or have I turned of
memory allocation with the IIS settings and the number of instance keeps
pilling up?

If I stop IIS, I get lots of lines of trace that I added to a destructor
(just for debug purposes) showing the class being destroyed.

Assuming this is the case, the only way this memory can be released is
by stopping the service or by activating the recycling again?

 

[Marc Gravell]

Each call to my webservice creates an instance of a dll
Do you really mean dll? How do you mean? Do you mean your web-service
loads a few other .NET assemblies? In which case, they will only get
loaded once per AppDomain (not over and over); but an assembly will
not (and cannot) be unloaded without tearing down the AppDomain.
If you mean object instances, then that shouldn't be a problem; if you
are seeing leak-like behavior, then verify you haven't added your
objects to something longer-lived... event subscriptions (especially
static/singleton etc subscriptions) are typical offenders here, but
other things (collections etc) are possible.

If you mean something more esoteric, you'll have to add detail to give
a meaningful reply...

It would also help if you indicated how you were monitoring the
memory; simple measures (taskman, for instance) can be deceptive...

Marc

 

[Marc Gravell]

One other thing... if you are using *static* variables, you probably
want to be very careful about thread synchronisation; but this may
effectively serialize access to your service (i.e. one at a time,
please...).

If you can describe *what* you are doing with your static variables,
it might help shed light on your memory issue... personally I try to
avoid static state in services, except for configuration state loaded
(for example) once in a static ctor.

Marc

 

[Steven Blair]

A call to my webservice creates an instance of my dll:

MyWebMethod()
{
MyDll x = new MyDll();

x.DoSomeStuff();
}

In the the dll, MyDll, I wrote a destructor to prove x is always
released. This writes out a line of trace when called. It's only written
out when I stop IIS from running.

Please note that I have turned off the recycling at IIS and I assume
this is causing the problem since turning it back on (say every minute)
I start seeing my destructor code being written out.

 

[Steven Blair]

The static are used as a status.

For example.

Call to webservice sets static variable to Started state.
Next caller, this variable needs to be set to previous callers state.

The statics work as way for indicating the mode my service is (Not
Logged in, Started etc) so must be persisted.

 

[Marc Gravell]

If the static variable is just status, you should be fine (locking
aside...) - bigger problem is if you have a big collection in the
static fields - which will of course sit their consuming memory...
hence why I raised this in connection with your memory concerns.

Marc

 

[Steven Blair]

Yup, my statics are protected with a lock, so I don't think there is any
threading issues here.
The main concern is why the memory is NOT being released for the dll.

 

[Steven Blair]

Its the whole class instance that concerns me.
The static need to hang around, and I accept the memory will not be
released. But the class that I create using instance variables etc is
never cleaned up.

 

[Marc Gravell]

But the class that I create using instance variables etc is

never cleaned up.

Well, it should be. If it isn't, then you're code is almost certainly
placing those controls somewhere publicly visible. Either that, or you
are using session-state and haven't ended the session - in which case
yes: the instance of the service implementation (per client) will be
retained. That is the pain of session state (and one of the many
reasons that I never use stateful web-services...)

Marc

 

[Steven Blair]

I am pretty sure I am not using the Session (for example I have no code
which says Session["blah"] = myObj;

I just have a simple webservice which creates an instance of a dll. This
dll is not released when I turn of IIS recycle.

As a workaround, I now have a static counter and when it reaches
MAX_CALLS, run the GC :|
It cleans the memory up for me now.