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
11  1160 
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.
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.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
So just to clarify, when the browser is closed my long running thread will die.
"Kevin Spencer" wrote: 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.
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.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
> 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.
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:12**********************************@microsof t.com... So just to clarify, when the browser is closed my long running thread will
die.
"Kevin Spencer" wrote:
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.
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.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
it will not die. it will not show up in taskmanger.
-- bruce (sqlwork.com)
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.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
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" wrote: 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.
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:12**********************************@microsof t.com... So just to clarify, when the browser is closed my long running thread will
die.
"Kevin Spencer" wrote:
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.
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.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
The thread's creator is actually the ASP.Net process.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:64**********************************@microsof t.com... 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" wrote:
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.
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:12**********************************@microsof t.com... So just to clarify, when the browser is closed my long running thread
will die.
"Kevin Spencer" wrote:
> 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.
>
> "Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
> news:88**********************************@microsof t.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
>
>
>
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... 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.
-----
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...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" wrote: "Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... 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.
-----
John Saunders
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:BB**********************************@microsof t.com... 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
"John Saunders" wrote:
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... > 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.
-----
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.
"John Saunders" wrote: "Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:BB**********************************@microsof t.com... 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
"John Saunders" wrote:
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
> 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.
-----
John Saunders
"Chris Fink" <Ch*******@discussions.microsoft.com> wrote in message
news:12**********************************@microsof t.com... 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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Anthony_Barker |
last post by:
I have been reading a book about the evolution of the Basic
programming language. The author states that Basic - particularly
Microsoft's version is full of compromises which crept in along the...
|
by: Egor Bolonev |
last post by:
hi all
my program terminates with error i dont know why it tells 'TypeError:
run() takes exactly 1 argument (10 given)'
=program====================
import os, os.path, threading, sys
def...
|
by: Jon Skeet [C# MVP] |
last post by:
Please excuse the cross-post - I'm pretty sure I've had interest in the
article on all the groups this is posted to.
I've finally managed to finish my article on multi-threading - at least
for...
|
by: CK |
last post by:
I have the following code in a windows service, when I start the windows
service process1 and process2 work fine , but final process (3) doesnt get
called. i stop and restart the windows service...
|
by: Vjay77 |
last post by:
In this code:
Private Sub downloadBtn_Click(ByVal sender As Object, ByVal e As
System.EventArgs)
If Not (Me.downloadUrlTextBox.Text = "")
Then
Me.outputGroupBox.Enabled = True...
|
by: Paul Sijben |
last post by:
I am stumped by the following problem. I have a large multi-threaded
server accepting communications on one UDP port (chosen for its supposed
speed).
I have been profiling the code and found...
|
by: OlafMeding |
last post by:
Below are 2 files that isolate the problem. Note, both programs hang
(stop responding) with hyper-threading turned on (a BIOS setting), but
work as expected with hyper-threading turned off.
...
|
by: kingcrowbar.list |
last post by:
Hello Everyone
I have been playing a little with pyGTK and threading to come up with
simple alert dialog which plays a sound in the background. The need for
threading came when in the first...
|
by: Mike P |
last post by:
I am trying to write my first program using threading..basically I am
moving messages from an Outlook inbox and want to show the user where
the process is up to without having to wait until it has...
|
by: Dann Corbit |
last post by:
Rather than create a new way of doing things:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html
why not just pick up ACE into the existing standard:...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
