Lifecycle of class in web service with static member question

[ian]

Hi, I have a really simple web service

public class MyService : System.Web.Services.WebService
{
[WebMethod]
public double[] DoWork (string pFunction )
{
return IDoTheWork.GetInstance().DoWork(pFunction);
}
}

In the same project I have singleton as follows.

sealed public class IDoTheWork
{
private static readonly IDoTheWork mInstance=new IDoTheWork();
private IDoTheWork()
{
...
}
public static IDoTheWork GetInstance()
{
return mInstance;
}
...
}

My question is at what point does the static member get initialised and
how long will it survive? If a client PC consumes the webservice and
then disconnects and consumes it again in a few hours, will they get the
same instance of mInstance?

Thanks
Ian

 

[Guest]

Ian,
You could certainly perform some easy experiments to get the answer(s) for
yourself, but the bottom line is, it's never a good idea to use static
objects in an ASMX webservice because it goes through a lifecycle similar to
an ASPX web page - it does its work, sends out the response, and it is GONE.
Peter

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

The static member can be initialized any time from when the assembly is
loaded to when you access the member the first time.

The static member survives as long as the application survives. The
application could survive for years (theoretically), or it could be shut
down after a second. It depends on the settings of the server, and when
the server thinks that it's convenient to recycle or shut down the
application.

Usually an application survives for quite some time, but you can never
depend on the application surviving from one call to the next.

 

[ian]

The static member can be initialized any time from when >the assembly is
loaded to when you access the member the first time.

The static member survives as long as the application >survives. The
application could survive for years (theoretically), or >it could be shut
down after a second. It depends on the settings of the >server, and when
the server thinks that it's convenient to recycle or shut >down the
application.

Usually an application survives for quite some time, but >you can never
depend on the application surviving from one call to the >next.

That's great. The whole thing is stateless, so it doesn't matter too
much. I moved the entire worker class out of the client app because of a
3rd party license issue (We'd need a license per workstation). It's
stateless and doesn't do a great deal of work in the constructor, but it
occured to me that I had no idea how it would behave under IIS.
I had considered breaking it out again into a Windows service which
would be consumed by the web service which in turn would be consumed by
the client, but I'm happy with the above behaviour, so I won't

Thank you both for your time.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

That's great. The whole thing is stateless, so it doesn't matter too
much. I moved the entire worker class out of the client app because of a
3rd party license issue (We'd need a license per workstation). It's
stateless and doesn't do a great deal of work in the constructor, but it
occured to me that I had no idea how it would behave under IIS.
I had considered breaking it out again into a Windows service which
would be consumed by the web service which in turn would be consumed by
the client, but I'm happy with the above behaviour, so I won't

Thank you both for your time.

Just make sure that the class is thread safe, as IIS processes each
request in a separate thread.