Reputation: 1633
For a long time before asp.net days, when I had a long task I would just have the task run on a page and use some sort of flush to send output to the user. No separate threads or anything. Since asp.net, I've been doing long tasks the same way. I have an aspx page with response.flush to flush output. This seems to be working fine for me (and I have some tasks that run for a couple hours or more) but I keep reading that this is bad but I am wondering why? What are some issues that have happen to you that you wouldn't do this?
Upvotes: 0
Views: 116
Reputation: 9020
Suppose a user accidentally or unwittingly navigated away from the page that is performing the long process. This could potentially cause an interruption, cause panic to the user who would then potentially kick off another long process by resubmitting.
Suppose you had to go to your bank account online, and you wanted to generate some financial reports which could take a long time. You would then have to leave your page open and would probably walk away from your desk (for example). Someone might go to your desk, hop in your comfy chair and hit the back button while the process is running - they've just discovered you've got a million bucks in your account. "Johnny, looks like you're buying lunch for all of us today!"
The standard way to handle such cases, particularly in your situation, is to have a windows service take care of the processing, and the page can periodically ask for the current state of the process through the database, event log, or some other means. This is generally the approach I take when, for example, my users initiate an invoicing process which could potentially take 5 minutes to run. User may revisit the page to check if its ready, or the service can optionally kick off an email, send a text, etc to notify the user of the status of the operation.
Upvotes: 1