Thread on web method

Elementary,

In dotNet it is forever
Ask get answer Ask get answer etc

So I see this as
Ask get answer "I am started wait for answer" that it is not is not
important for your client
Ask and start your process (you have tested if there is connection in your
previous question), and when it is ready give it back.

I don't see as often not any need for a thread in this because all that you
do in the main thread is the proces.

Just my thought,

Cor

Cor Ligthert wrote:

I don't see as often not any need for a thread in this because all that
you do in the main thread is the proces.

Sorry, Cor, actually this is for a completely different application...I
should have explained.

The situation is:

1) A web service that runs a Sql Server sproc and outputs a text file.
2) The sproc can take up to 10 minutes to run.
3) The consumer of the web service does not need to know if the file is
produced -- it just needs to kick off the process.

So, I thought the web service could:

1) Receive the request.
a. Spawn a thread to run the sproc and output the file

2) Immediately return a response to the consumer that says "message
received". And then the consumer would be released ( not subject to http
timeouts and so on. )
--
Texeme
http://texeme.com

The thread will continue to run but you need to be careful about a few
things. With IIS6 the worker process can be recycled at various times
causing all of the threads to be stopped.

If the IsBackground property of the thread is true then the thread will be
aborted if the worker process recycles. If IsBackground is false then the
thread will prevent IIS6 from restarting.

--
Ross Donald
..NET Code Generation - http://www.radsoftware.com.au/codegenerator/
"Elementary Penguin" <si*****@hare.krishna> wrote in message
news:d2*****************@newsread1.news.pas.earthl ink.net...

Cor Ligthert wrote:

I don't see as often not any need for a thread in this because all that
you do in the main thread is the proces.

Sorry, Cor, actually this is for a completely different application...I
should have explained.

The situation is:

1) A web service that runs a Sql Server sproc and outputs a text file.
2) The sproc can take up to 10 minutes to run.
3) The consumer of the web service does not need to know if the file is
produced -- it just needs to kick off the process.

So, I thought the web service could:

1) Receive the request.
a. Spawn a thread to run the sproc and output the file

2) Immediately return a response to the consumer that says "message
received". And then the consumer would be released ( not subject to http
timeouts and so on. )
--
Texeme
http://texeme.com

Elementary,

I think I see it now.
You want the thread in your "calling" program

However than I see no problems at all.

You call setup the webservice and shows in your calling program a message
as, "busy the file will be delivered in about 10 minutes keep the program
running".

Than you start (as you want that which for me depends if the program has
more purposes) an extra thread which starts the method of the webservice.
When the calling program gets the data, than when it is an extra thread, it
throws an event that can be catched by the main program and you go on.

I don't like extra threads which are not necessarry, therefore I like it
more just let the mainthread freeze with a waitcursor and by intance a
rolling gif on it, however about this are different opinions in these dotnet
newsgroups. (The last has nothing to do if it is difficult, because with an
extra thread this is also very simple, for me it is more the dependency
which has to be watched forever when using threads).

Is this what you mean?

Cor