Threading in Web App

[Guest]

If I create a new thread in a web app and the user closes the browser before
this long running thread is finisihed, does the thread die? If so, is there
a way to prevent it from dying and keep the thread running till
execution....without significant redesign.

Do new threads show up in the task mgr?

Thanks

 

[Kevin Spencer]

The server has no persistent connection to the browser. Therefore, anything
that happens on the client is of no consequence to the server, unless it is
a Request. This is why Sessions time out. There is no way to know when the
client browser has been closed.

New threads do not show up in Task manager. Only the top-level process
thread is displayed.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[Guest]

So just to clarify, when the browser is closed my long running thread will die.

 

[Kevin Spencer]

So just to clarify, when the browser is closed my long running thread will
die.

Just to clarify, the server has no way to know when the client browser has
been closed. Let's say that you write a letter to your Mother, inviting her
to come for a visit. After sending the letter, you decide to paint your
living room in preparation for her visit. Meanwhile, your Mother has died.
She never even receives your letter, but neither do you receive any
information back from her, as nobody has discovered her body. As you have
heard nothing from your (now deceased) Mother, do you stop painting your
living room?

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[bruce barker]

it will not die. it will not show up in taskmanger.

-- bruce (sqlwork.com)


| If I create a new thread in a web app and the user closes the browser
before
| this long running thread is finisihed, does the thread die? If so, is
there
| a way to prevent it from dying and keep the thread running till
| execution....without significant redesign.
|
| Do new threads show up in the task mgr?
|
| Thanks

 

[Guest]

soooo, the thread will not die....it will continue even when the webpage is
closed. I thought that when the thread's creator dies all child threads die
with it....

 

[Kevin Spencer]

The thread's creator is actually the ASP.Net process.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[John Saunders]

The server has no persistent connection to the browser. Therefore,
anything
that happens on the client is of no consequence to the server, unless it
is
a Request. This is why Sessions time out. There is no way to know when the
client browser has been closed.

Not only doesn't the server have any connection to the browser, but your
thread has no "connection" to the page from which it was created, nor to the
request whose execution caused the page to be created. Anything your thread
does with the Page, Request, Response, or Context objects is almost
certainly incorrect, since the request will likely have ended before your
thread executes.

Please tell us what you're trying to accomplish by using threads with
ASP.NET. Threads are almost certainly the wrong way to go about
accomplishing it.

 

[Guest]

John,

I have a web app that performs and upload to a database. After the insert
is complete, I spawn off a new thread that runs some SQL to validate the
entries...freeing up the user from this potentially long running process by
spawning a new thread. I can't use a trigger or any other clever tools that
DB's typically present since I do not have proper permissions; So an SQL
update is the only option. The three options I see are 1. run the upload
then the validation in a serial fashion. Con is the user will have to wait
2x as long before UI is available. 2. run the upload then free the user by
spawing new thread for validation. Pro is faster UI. 3. Move the validation
process into another backend app on a scheduled basis. Con more work and more
maintenance. It is a requirement that the file upload part not be spawn into
a sep thread...it is better to make the user wait for it to complete so they
can identify and correct erros.

Is this the wrong design approach?

 

[John Saunders]

John,

I have a web app that performs and upload to a database. After the insert
is complete, I spawn off a new thread that runs some SQL to validate the
entries...

Do I understand you correctly? You're putting invalid data into your
database?

freeing up the user from this potentially long running process by
spawning a new thread. I can't use a trigger or any other clever tools
that
DB's typically present since I do not have proper permissions; So an SQL
update is the only option. The three options I see are 1. run the upload
then the validation in a serial fashion. Con is the user will have to
wait
2x as long before UI is available. 2. run the upload then free the user by
spawing new thread for validation. Pro is faster UI. 3. Move the
validation
process into another backend app on a scheduled basis. Con more work and
more
maintenance. It is a requirement that the file upload part not be spawn
into
a sep thread...it is better to make the user wait for it to complete so
they
can identify and correct erros.

Is this the wrong design approach?

It's probably wrong, but I can't tell from what you wrote. Does your
background thread do anything to the UI, or does it depend on the request in
any way? If so, then it is incorrect.

Please give some detail on the interaction between the upload, the
validation, and the user. Right now, I have no idea what the user sees if
it's valid vs. invalid, or what the thread does other than issue some SQL
calls.

John

 

[Guest]

Part of our process is data validation, so we have no control over what data
is entered into our staging table. Data is pharmaceutical information,much
complexity and lots of room for error. Regardless, the business requirement
is to validate the data after the load.


"Does your background thread do anything to the UI, or does it depend on
the request in any way? If so, then it is incorrect."
Answer is No for both.

All the thread does is issue an update command when the upload is complete.
While this thread is running, the UI is free for users to continue with other
uploads. All of the data reporting is done through a different front end /
different users.

Seems like our debate is revolving more around business requirements than
the actual best practice. The way is stands now, all is working fine and the
thread accomplishes the task it is set to do, more importantly freeing up the
user to peform more uploads. No tie to the request or the user/browser in any
way.

 

[John Saunders]

Part of our process is data validation, so we have no control over what
data
is entered into our staging table. Data is pharmaceutical
information,much
complexity and lots of room for error. Regardless, the business
requirement
is to validate the data after the load.


"Does your background thread do anything to the UI, or does it depend on
the request in any way? If so, then it is incorrect."
Answer is No for both.

All the thread does is issue an update command when the upload is
complete.
While this thread is running, the UI is free for users to continue with
other
uploads. All of the data reporting is done through a different front end
/
different users.

Seems like our debate is revolving more around business requirements than
the actual best practice. The way is stands now, all is working fine and
the
thread accomplishes the task it is set to do, more importantly freeing up
the
user to peform more uploads. No tie to the request or the user/browser in
any
way.

I have no opinion on business practices. You hadn't previously mentioned a
"staging table", so it sounded like you were putting invalid data into the
database.

If your background thread doesn't interact with the original request at all,
then it should be fine. The only question I'd have has to do with
scalability. Does the update of the database take long enough that you could
run out of threads because of the number of users doing uploads? If so, then
perhaps you should "queue" the update to a single background thread (not
running in the web application), which would loop and update the database
with each set of uploaded data when the data arrives?

John Saunders