The long and short of it is - I wouldn't ever attempt to do it that way. Period. I know that sounds harsh, but due to a number of specific circumstances, it's just simply not a good idea. You have to rely on a few specific timeout periods that may or may not be within your control. First off, you have the SQL Timeout period - which obviously you can override. On top of that you have the Web Request Timeout, which you can also override. Next Up, the Session Timeout, which may or may not fire during your three hour window depending on the size of the sessions and competition for resources. On top of that you have the IIS Host Process which can reset unexpectedly at any time due to many environmental factors.
Rule #1 of web requests. They are stateless, and should remain such.
So - how would I do this? Well - I do something very similar to this in many sites that have long running processes, or reporting systems. You need to build an additional piece. It doesn't have to be beautiful, and once you build it, you can use it on dozens of projects.
So - what is this magical piece? It's either a Windows Service, or a Command Line Batch Process, depending on how you want to maintain the runtime. The logic is simple, on a scheduled basis, the process will execute a SQL statement to look in a batch table for Tasks to complete. At the time it pulls the Task from the table, it marks it as processing. The process then performs the task, and once completed, executes a SQL statement to set the Task Completion Date, and trigger any additional statements that would be necessary. If this is done as a windows service, you can simply have the thread go to sleep for a period of time and then start the process all over again. If its a command line process, you can use the Task Scheduler to fire it on a scheduled basis. There is a larger advantage to the Windows Service in that you can have any number of threads processing any number of tasks at the same time.
So - you would rely on Windows to handle this process, not IIS. Since it appears that this process is fired from the Scheduler anyway, it doesnt matter specifically what happens with the results I suppose. When I do this for reporting purposes, I simply have the front end trigger the service task record, and then the browser continually checks the status of the task until it is completed, then returns the result that the task stored in the database.