Your problem is not related to ADF ApplicationModules. AMs are returned to the pool no earlier than the end of request, so for sure they are not destroyed by the framework while the report is running. The AM timeout settings you are referring to are applicable only to idle AMs in the pool but not to AMs that have been checked out and used by some active request.
If you are using MS Internet Explorer, then most probably your problem is related to the IE's ReceiveTimeout setting, which defines a timeout for receiving a response from the server. I have had such problems with long running requests (involving DB processing running for more than 1 hour) and solved my problem by increasing this timeout. By default this timeout is as follows:
- IE4 - 5 minutes
- IE5, 6, 7, 8 - 60 minutes
I cannot find what the default value is for IE9 and IE10, but some people claim it is only 10 seconds, although this information does not sound reasonable and reliable! Anyway, the real value is hardly greater than 60 minutes.
You should increase the ReceiveTimeout registry value to an appropriate value (greater than the time necessary for your report to complete). Follow the instructions of MS Support here:
I have searched Internet for similar timeout settings for Google Chrome and Mozilla Firefox, but I have not found anything, so I instructed my customers (who execute long-running DB processing) to configure and use IE for these requests.
Its not clear how you exactly generate report.
From your description it seems that you invoke some method in AM which uses existing db connection to generate report?
Also its not clear is user blocked until report is fully generated(I suppose that this is true because you mentioned session-timeout parameter ) or he can use application?
Maybe you can offload report generation to report server(for example JasperServer) or at least to some servlet and get connection directly from data source?
For long running reports, best approach is to use some report server, or some custom asynchronous service(for example, for each user you can create folder on filesystem and keep generated reports there, then write page which will display links for generated reports in specific(user) folder)
In my opinion it is not a good idea to increase the HTTP Session timeout in web.xml to 300 minutes for all the users, because this value is too large and you may overload the server's memory with a lot of expired sessions (that are kept for too much time). If I were you, I would leave the timeout to the default value and modify session's timeout programatically to a large value only at the beginning of requests that were expected to be extra long-running and restore the session's timeout at the end of request. You can use the Java API method HttpSession.setMaxInactiveInterval(int) for this purpose.
I would like to add something related to my 1st post, where I said "AMs are returned to the pool no earlier than the end of request, so for sure they are not destroyed by the framework while the report is running". This is true if the report generation is synchronous (e.g. the server waits while the report is being generated and responds to the client browser after the report generation is done). However, If your initial request (which starts the report generation) responds back immediately (leaving the report to be generated asynchronously in background), then the AM is released and checked back in the AM pool immediately. In this way the AM instance may be (re)used by another session/request or destroyed when shrinking the AM pool, while the report in background is continuing using it. If this is your case, then you should re-design your concept because the report must not use the AM if it has already been released back into the AM pool.