perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lisenberg Julian" <>
Subject Long process with ASP
Date Wed, 06 Aug 2003 13:54:04 GMT
Hi, my name is Julian Lisenberg, and I'm an ASP programmer from Argentina, South America (so
please understand that my English isn't perfect). I had the same problem that Landin Nikolay
(Apache::ASP List), and I come to the same conclusion that you did, because of the big scripttimeouts
that the multi-part process could handle.
But, after coding a really long process, I discovered something. When I close the client page
that is processing the ASP, the process keep processing à it does not finish as I supposed.
I have opened the DB after closing the client's page, and the information keeps growing. Why
is this happening? Is it good or is it bad? Do you know any way to stop a process like this?
Does this kind of process have something to do with multi-threads? 
Finally, I was able to handle this process with application variables, so I could start this
process, close the client page, and open it again and saw were it was. Is this safe?
Thank you for your time,
Julian Lisenberg
>Landin Nikolay wrote:
>> Hi, all
>> I have a problem. 
>> I am using Apache::ASP module. 
> There is a new Apache::ASP mailing list. You can subscribe
> to it at 
>> When I try to do a long process - the client page write "Page not 
>> found"
>> after some period. 
>> How can I to tell client, that server application is still working?
>If you really need to keep the client busy, then try a
>$Response->Write("\n"); $Response->Flush; 
>The web browser just needs to see something from time 
>to time. 
>> May be - I must just change some Session variables?
> No, this is all server side.
>If its a long job, like a big SQL command being executed
>then you might have to take a different approach because 
>your process will lock waiting for the SQL command execute 
>to return. In this case you might try forking a job into 
>the background and waiting for its results. You might 
>also try something like a meta refresh on itself, and 
>keep checking for whether the job is done. 
>-- Josh

View raw message