Killing a long processing conversation

[frer]

Hello,

I'm not sure the title of my post is correct but here is my problem:

- My application has a report generation page.  The user can select different parameters of his report.  When done, he hits generate and a CSV report is generated. 
- This generation process can take from 1 second up to 30 minutes. 
- Once the report generated, the user might want to modify some parameters and generate another report

Knowing this, my questions are:

1- What kind of settings would you recommend for session, conversation-timeout, concurrent-request-timeout, etc ?

2- If after 2 minutes, the user realizes he generated the wrong report and wants to cancel it, how can this be done?   Ideally I would put a cancel button on the page but how can this stop a method that is currently executed.  At this point it would even be acceptable to simply kill the conversation and start a new one for the user.  Can this be done?  Will killing the conversation stop the process?

Thank you for your help.

François

[kragoth]

The short answer to your question is...No, killing a conversation will not stop the process. (As far as I can tell anyways).

I guess I would recommend you really think about what you are asking for here. A 30 minute report is going to be putting a lot of stress on your system. So what happens if 3 or 4 people run these type of reports at the same time? Can your database handle this without causing you deadlocks etc. Will this cause Denial of Service to other users?

Now, that all being said I'm involved with an application with pretty much the same requirements. We are writing a queueing system for these potentially large reports. The user will submit the request for the report to be generated to the queue. We'll have a way of allowing a user to see the reports they have in the queue, and the ability to delete them from the queue or stop their in progres report. Each report will be fired off in its own thread thus with a bit of thread management I can kill and in progress report. Once a report is done the output is stored (db/filesystem) and the user can then access it via a link emailed to them or another page in the system with details of the reports they have generated.

[frer]

Hey Tim thanks for your post,

I agree with what you said.  My problem is 90% of the reports take less than 30 seconds to generate...therefore its more practical for my users to get them directly online.  I am considering the email after option but I'm still debating it.

I like your queuing and thread system though...I'll definetely look into that.  Haven't worked with threads in years but I guess its time I got back to them ;)