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 ***

[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?
*** Sent via Developersdex http://www.developersdex.com ***

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

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

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

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

[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.
*** Sent via Developersdex http://www.developersdex.com ***

[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.
*** Sent via Developersdex http://www.developersdex.com ***

[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.
*** Sent via Developersdex http://www.developersdex.com ***