asp webservice variables and persistence

[Bob]

Hi,
How does one initiate and persist variables between users in an asp
webservice or is that even possible? For instance, I did a very
simple test case below. I would like the timeStart variable to be
initialized once at server startup and have all users who subsequently
call the webservice get the initial time, not the time when they call
the service. It seems like the whole process is restarted everytime
the service is called, with a new timeStart being generated each tme.

Thanks,
Bob

public class Service1 : System.Web.Services.WebService
{
DateTime timeStart = new DateTime();

public Service1()
{

timeStart = DateTime.Now;
}
[WebMethod]
public string HelloWorld()
{
return "Hello World"+timeStart;
}
}

 

[Arne Vajhøj]

How does one initiate and persist variables between users in an asp
webservice or is that even possible? For instance, I did a very
simple test case below. I would like the timeStart variable to be
initialized once at server startup and have all users who subsequently
call the webservice get the initial time, not the time when they call
the service. It seems like the whole process is restarted everytime
the service is called, with a new timeStart being generated each tme.

public class Service1 : System.Web.Services.WebService
{
DateTime timeStart = new DateTime();

public Service1()
{

timeStart = DateTime.Now;
}
[WebMethod]
public string HelloWorld()
{
return "Hello World"+timeStart;
}
}

Make it static.

Or save it in Application object.

Arne

 

[Mr. Arnold]

Hi,
How does one initiate and persist variables between users in an asp
webservice or is that even possible? For instance, I did a very
simple test case below. I would like the timeStart variable to be
initialized once at server startup and have all users who subsequently
call the webservice get the initial time, not the time when they call
the service. It seems like the whole process is restarted everytime
the service is called, with a new timeStart being generated each tme.

<http://msmvps.com/blogs/omar/archiv...2-0-profile-object-from-web-service-code.aspx>

You could also use an Application Object too or possibly writing an XML file
out with the Date and read it back into the Web service.

 

[Arne Vajhøj]

<http://msmvps.com/blogs/omar/archiv...2-0-profile-object-from-web-service-code.aspx>

You could also use an Application Object too or possibly writing an XML
file out with the Date and read it back into the Web service.

Reading and writing a XML file combined with the locking to make it
thread safe would have a devastating effect on performance of the web
service.

Arne

 

[Marc Gravell]

In the specific case you mention (wanting to record the time the
service is first accessed), then a static variable (initialized in a
static constructor) would be a reasonable option. However, this is not
a good option for the general case:
* this doesn't handle app-pool recycling
* this doesn't work in a cluster
* this doesn't provide connection granularity
* this doesn't address the real issues of thread safety

You can have stateful services, but they don't really scale to
clusters in any way... in an enterprise setup, you'd probably want to
look at a session-state database, probably keyed by a guid held as a
header on the request. If you want something simpler (but less scale),
then WCF can handle a lot of this for you in-memory (on a single
machine - not a cluster) by keeping an instance of the service object
per client.

Marc

 

[Bob]

In the specific case you mention (wanting to record the time the
service is first accessed), then a static variable (initialized in a
static constructor) would be a reasonable option. However, this is not
a good option for the general case:
* this doesn't handle app-pool recycling
* this doesn't work in a cluster
* this doesn't provide connection granularity
* this doesn't address the real issues of thread safety

You can have stateful services, but they don't really scale to
clusters in any way... in an enterprise setup, you'd probably want to
look at a session-state database, probably keyed by a guid held as a
header on the request. If you want something simpler (but less scale),
then WCF can handle a lot of this for you in-memory (on a single
machine - not a cluster) by keeping an instance of the service object
per client.

Marc

Great, thanks. As a start I am using the Application object.

 

[Bob]

Great, thanks. As a start I am using the Application object.

Is this the correct way to do it?


Application.Add("ws", ws);
in the construction and then

objectClass ws = Application.Get("ws") as objectClass;

Thanks,
Bob