Threading in ASP.NET (C#)

[venkat]

Hi,
I have a page that calls a sql procedure and it runs for 20 - 40 min. I
use usual threading for this page.

<code>Thread objthread = new Thread(new ThreadStart(ticketingThread));
objthread.Start();</code>

As i dont know when it will end. i never abort the thread. what happens
is when user uses the page for 1 week, the page starts hanging. I dont
know what happens. When i tried debugging it works fine.

I also saw creating thread in threadpools

<code>ThreadPool.QueueUserWorkItem(new
WaitCallback(ticketingThread));</code>

Please advise which one I have to follow and what is the difference
between the two.

Thanks
Venkat

 

[Peter Morris [Droopy eyes software]]

I have a page that calls a sql procedure and it runs for 20 - 40 min.

Should this really be run from a page? I would say that the page needs to
register a "job" to do, and that a service application running on the server
should process the jobs. The website can check back for the status of the
job.


--
Pete
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
http://www.droopyeyes.com

My blog
http://blogs.slcdug.org/petermorris/

 

[venkat]

We proposed the same. but the clients want them in same web app

 

[Damien]

We proposed the same. but the clients want them in same web app

Well, definitely create your own threads rather than using the thread
pool - that's where ASP.Net draws it's threads from, so you'll be
limiting it's normal service if you use the threadpool threads.

As to the hanging, what's your memory usage like? Do you hook up any
event handlers, or other delegates which might be causing your objects
to lurk around in memory forever? Do you just throw away the thread
reference or do you store it somewhere?

The clients better have a *really* good reason for why they want this
kind of thing happening within the one web app. Services are good at
coming up when the server comes up, and staying up so long as the
server is up. Web apps are really good (assuming you don't use InProc
session) at being recycled whenever you need to, without affecting the
end users (and at being scaled out if the website usage grows beyond a
single server)

Damien

 

[bruce barker \(sqlwork.com\)]

if you use the trread pool, asp.net will know about it, and can catch
errors, or abort the thread it runs too long. thedisadvantage is that you
are tying up asp.net threads, you you could get a site too busy error. if
you are not real experienced with threading, and monitoring threads, as you
really shoudl use a queue and a pool for this application, then use the
stardard pool.

if you are using sql2005, I'd switch to broker services to run the sql
request.

-- bruce (sqlwork.com)

 

[Peter Morris [Droopy eyes software]]

We proposed the same. but the clients want them in same web app

If I want my car painted all I care about is how well it was done, I don't
add clauses like "you must use a paint brush" Page requests should be
served quickly and should *not* take long enough to have the word "minutes"
in the time.

The proper way to achieve this is to have the page register a job for a
worker process to complete. I am curious as to why they believe they want
it done this way. Surely you can convince them to change their minds within
about 30 seconds once you explain the pro/con of each approach?

Pete