Finish execution of ASP script when client disconnects

[Boris Nikolaevich]

This is backwards of what I usually want--normally if you have a
long-running ASP script, it's a good idea to check to see whether the client
is still connected so you can cancel execution.

However, I have a script that absolutely MUST finish one it's been
started--is there a way to cause the entire script to execute, even if the
client disconnects in the middle of the process? It doesn't matter if the
script returns anything to the client, but once it starts saving values to
the database I need it to finish!

Thanks for your help!
--Boris

[aa]

Boris,
I do not know if code execution on the server depends on connection, but if
you have to force termination of the execution upon connection termination,
then it means that by default the code executes to the completion
irrespective the connection
I.e. you do not have to do anything

Andrei
"Boris Nikolaevich" <boris@nikolaevich.com> wrote in message
news:#4Kk#QecDHA.1204@TK2MSFTNGP12.phx.gbl...

> This is backwards of what I usually want--normally if you have a
> long-running ASP script, it's a good idea to check to see whether the

client

> is still connected so you can cancel execution.
>
> However, I have a script that absolutely MUST finish one it's been
> started--is there a way to cause the entire script to execute, even if the
> client disconnects in the middle of the process? It doesn't matter if the
> script returns anything to the client, but once it starts saving values to
> the database I need it to finish!
>
> Thanks for your help!
> --Boris
>
>

[Boris Nikolaevich]

That's what I'd have thought, but I have found very consistently that if I
submit the request and wait for a response (which may be up to two minutes),
the script completes its execution--but if I refresh, close the browser,
move to a different page, etc. etc. the script does not finish.

Apparently starting with IIS 5.0 the ASP engine checks to see whether the
client is still connected before executing a request from the queue. Here's
something I found on MSDN when searching for related topics:

==============================
<snipped from
http://msdn.microsoft.com/library/en-us/dnasp/html/asptips.asp>

Tip 16: Use Response.IsClientConnected Before Embarking on Long Trips

If the user gets impatient, he or she may abandon your ASP page before you
even start executing their request. If he clicks Refresh or moves to a
different page on your server, you will have a new request sitting at the
end of the ASP request queue and a disconnected request sitting in the
middle of the queue. Often this happens when your server is under high load
(so it has a long request queue, with correspondingly high response times)
and this only makes the situation worse. There's no point executing an ASP
page (especially a slow, heavyweight ASP page) if the user is no longer
connected. You can check for this condition by using the
Response.IsClientConnected property. If it returns False, you should call
Response.End and abandon the rest of the page. In fact, IIS 5.0 codifies
this practice—whenever ASP is about to execute a new request, it checks to
see how long the request has been in the queue. If it has been there for
more than 3 seconds, ASP will check to see if the client is still connected
and immediately terminate the request if it's not.
==============================

Obviously this is great for improving performance, but it doesn't help me
any... any more ideas? And BTW, this is a hosted client application where I
don't have control over server settings like AspQueueConnectionTestTime.

Thanks for your response!


"aa" <aa@virgin.net> wrote in message
news:eeBQ5zjcDHA.2820@tk2msftngp13.phx.gbl...

> Boris,
> I do not know if code execution on the server depends on connection, but

if

> you have to force termination of the execution upon connection

termination,

> then it means that by default the code executes to the completion
> irrespective the connection
> I.e. you do not have to do anything
>
> Andrei
> "Boris Nikolaevich" <boris@nikolaevich.com> wrote in message
> news:#4Kk#QecDHA.1204@TK2MSFTNGP12.phx.gbl...

> > This is backwards of what I usually want--normally if you have a
> > long-running ASP script, it's a good idea to check to see whether the

> client

> > is still connected so you can cancel execution.
> >
> > However, I have a script that absolutely MUST finish one it's been
> > started--is there a way to cause the entire script to execute, even if

the

> > client disconnects in the middle of the process? It doesn't matter if

the

> > script returns anything to the client, but once it starts saving values

to

> > the database I need it to finish!
> >
> > Thanks for your help!
> > --Boris
> >
> >

>
>

[Michael D. Kersey]

Boris Nikolaevich wrote:

> This is backwards of what I usually want--normally if you have a
> long-running ASP script, it's a good idea to check to see whether the client
> is still connected so you can cancel execution.
> However, I have a script that absolutely MUST finish one it's been
> started--is there a way to cause the entire script to execute, even if the
> client disconnects in the middle of the process? It doesn't matter if the
> script returns anything to the client, but once it starts saving values to
> the database I need it to finish!
> Thanks for your help!
> --Boris

Long-running tasks are not ASP's strength. Here's a alternative and
simple yet powerful approach for handling such tasks that I've suggested
a number of times on these forums. It's essentially a background
batch-processing system that allows submission of "jobs" from an ASP
page. Several advantages
result from separating long-running batch jobs from ASP:
a) greater interactivity for the ASP user,
b) a reduction on the load to IIS,
c) control over the number of concurrently running batch jobs, and
d) the ability to continue/restart jobs if IIS, the database or any
subsystem goes down or if a job fails (e.g., due to program error,
etc.). The result is a much more robust and flexible processing system.

Here are the 3 major pieces of such a system:

1. Job Requestor Page:
Let the ASP page request a job by adding an entry to a "job table" in
the database. The ASP page stores the necessary data (job input
parameters and user information) in the job table. Once the job is
entered into the table, the ASP page merely tells the user his/her job
is queued and exits (or redirects to the Job Monitor ASP page, below).

2. Job Scheduler:
Use a stored procedure, Windows Task Scheduler, SQL Server Agent or a
VBScript script started by the @ (AT) processor to periodically examine
the job table. If no job is currently running and a new job has been
submitted then get the input parameters for the new job from the job
table and start it. Once a job completes, the status of the job should
be marked as "complete" in the job table and a URL for the result (if
required) provided in that same table.

3. Job Monitor:
This is an ASP page that displays the status of jobs and each job's
location in the job queue. The user can display this page to determine
the status of his/her job. Once a job is complete, it's status is marked
as such in the job table along with any resultant URL (a report, a DOC
file, an HTML page or other file). The user can click on that URL to
view the result of his/her batch run.

You can add operator/user functions such as
a. terminate job,
b. put job on temporary hold (cease processing),
c. restart job (in case of system reboot, database shutdown, etc.),
d. allow a variable number of concurrent jobs to run, thus controlling
the background job load.

These require that the code for the various jobs be written in such a
manner that they cooperate with the Job Monitor program.

Good Luck,
Michael D. Kersey

[Michael D. Kersey]

Boris Nikolaevich wrote:

>
> "Michael D. Kersey" <mdkersey@hal-pc.org> wrote in message
> news:3F5669C4.13C5DBA2@hal-pc.org...
> <snip>

> > 2. Job Scheduler:
> > Use a stored procedure, Windows Task Scheduler, SQL Server Agent or a
> > VBScript script started by the @ (AT) processor to periodically examine
> > the job table. If no job is currently running and a new job has been
> > submitted then get the input parameters for the new job from the job
> > table and start it. Once a job completes, the status of the job should
> > be marked as "complete" in the job table and a URL for the result (if
> > required) provided in that same table.

>
> Michael,
>
> Of course your suggestion is perfect, and it's one of the first dozen things
> I tried--but I quickly ran into a big problem. Since the ASP application
> runs on the client's ISP's web server, I don't have the ability to create &
> schedule a Windows task. The ISP has also disabled--and refuses to
> enable--SQL Server Agent, so I can't schedule (or even start) a SQL Server
> job. I don't know of any other way to regularly poll my tables for new jobs
> in such a way that the user can continue working while the job is processed
> asynchronously. For example, if I execute a stored procedure from within my
> ASP page, the script always waits for the stored proc to complete before
> continuing. If I move the code to global.asa so that the "waiting jobs"
> table is checked every time a new session is started, I find that every time
> a new job is waiting the user has to wait extra long for their first page to
> load. (Plus, as much as I'd like to, I have no way to guarantee that there
> will be new visitors every five minutes!)
>
> So, since I have no way to interact with Task Scheduler or SQL Server Agent,
> can you suggest another way to regularly poll the jobs table and execute
> waiting jobs WITHOUT causing a delay for the user? (Something like async
> execution of a stored proc from the ASP would be great, but I don't know how
> to do that.)
>
> Thanks so much!

Perhaps create a trigger that runs sp_start_job xxx after inserts to the
job table? But that may not be possible; sounds like your ISP has the
system tightened down.

There are lots of posts at
[url]http://www.google.com/groups?q=asynchronous+stored+procedure+microsoft.p ublic.sqlserver.*&hl=en&lr=&ie=UTF-8&scoring=r&selm=3b0d06ce%240%2412241%24ed9e5944%4 0reading.news.pipex.net&rnum=7[/url]
but I don't know if any would work for you.

Finally, since you can't put a service or program on the ISP's system I
can only think of one other way. It's a real kludge and I'm almost
embarrassed to mention it (but I've heard that it has been used in some
quarters in desperation):

Set up a separate secure ASP page, call it MYPAGE.ASP, whose whole
purpose is to check for and execute the long-running jobs one at a time.
Set the Session.timeout appropriately for that page and put a META
REFRESH tag on it, e.g., <META HTTP-EQUIV="REFRESH"
CONTENT="5;URL=MYPAGE.ASP;5">
so that, once it returns, it executes again 5 or so seconds later. Set
up a browser whose whole purpose is to keep MYPAGE.ASP in execution.
Effectively MYPAGE.ASP becomes the "Job Scheduler" spoken of above.
Problem is that such a scheduler won't be nearly as reliable as a
Windows program, scheduled task, or asynchronous SP. Losing a network
connection could stop such a scheduler.

Given the constraints, your solution may be the only reasonable one.

Good Luck,
Michael D. Kersey