microsoft.public.dotnet.framework.aspnet.webservices

Yasser Shohoud [MS]

1/24/2003 11:45:00 PM

Ellen,

This is a big topic. Too big to be covered in this response so I'll try to
make some relative points and then point you to some docs.

ASP.Net does something called Process Recycling to help keep process in a
clean and healthy state. When this happens can be influenced by a number of
factors but in the end it's out of the hands of a Web Service.

So storing state in statics is dangerous. But ApplicationState is no better
because it is also just stored in memory. If you absolutely need your state
to be there you can use the SessionState (with appropriate backing setup).
If the data is something that must be available across sessions then you
have to do something else (i.e. use a file on disk or a database).

What you use depends on the nature of what you are storing.

There is a bunch of MSDN articles on this subject. Here is one that might
help.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/v...
vbconchoosingserverstateoption.asp

Michael Clark
Microsoft

--
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Ellen" <EKahan@Chasen.com> wrote in message
news:071901c2c3e1$a12f8860$8df82ecf@TK2MSFTNGXA02...
> I am a bit confused as to the lifetime of web services.
> When the first client calls my service it is loaded into
> memory. At what point will it be unloaded? I tried
> defining some static variables and they kept their values
> across calls.
>
> I am debating whether to save information that is used by
> all clients in static variables or via the
> HTTPApplicationState.
>
> As part of this question - how can I force the service to
> unload if I need to bring down the service? We do not
> host the application ourselves, and we share the server.
>
> Thank you!