Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Save jsp page to static html for future requests  RSS feed

 
jay desi
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is what I intend to do:-

I am using spring mvc framework in my web app. I have ouput page called "TestOP.jsp",
which will essentially itearate through ArrayList of beans and dipslay results in necessary format.

Now, many queries are executed to prepare this report and hence it takes long time in generating the report.
What I want is to give user option to:-
1) view previously generated report OR
2) generate the report once again

If user goes for option-2, then "TestOP.jsp" page should display latest report as well as save that report in static HTML file, say "LastObtainedResult_MMDDYYHHmmSS.html", so that when next time, a user selects option-1 from above, "LastObtainedResult_MMDDYYHHmmSS.html" is directly fetched.

Is this possible through jsp? I believe, jsp session caching is not the solution here, as I want the static html to be available by anybody even after session is closed.

I hope I have made myself clear. Any suggestions will be most helpful..Or is there a better and different solution to this problem?

Thanks..




 
Gerardo Tasistro
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why don't you save the ArrayList in application scope and then reuse it on every request?

Every time the jsp is requested it uses the stored results instead of running the queries again. It uses more memory because it is stored, but on the other hand only one copy exists and is shared by many treads. Instead of having one copy per thread that takes forever to recreate. On top of this if your application uses some sort of decorator framework or personalization caching the jsp really won't work that well.
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One strategy would be to use a Filter. You would run a filter that:

1) Before forwarding the request, replaces the ServletResponse with a version of an HttpServletResponseWrapper. The HttpServletResponseWrapper would provide a custom SerletOutputStream that forks all output so that it gets sent both to a file for the cache on disk and to the original ServletOutputStream.

2) Checks the request parameters to see if the static cache should be used, or if a new file should be used.

3) Forwards the request either to the cached file, or calls the filterChain.doFilter() method.

See this link for examples of using Filters.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65824
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gerardo's approach has a lot of merit. As it's the queries that are to be avoided, cache the data not the generated pages. That way it's also easy to dump the cache at appropriate points.
 
jay desi
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you guys for your help..So, I should be using "application scope" to save arraylist.
I now have an additional question on this approach. What will happen if 2 different requests come at same time.

1 request for getting cached data and other for updating cache with new data. Should I take care of synchronizatiom issue here because eventually
same "application scope" cache will be used for every requests...
 
Gerardo Tasistro
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes you should get a lock on the data while it is being updated. All threads waiting on it will lock until the query is finished. This might sound like a bad thing, but it is actually good. Since one execution of the very complex queries will respond to all the thread in the server waiting for it once it completes. Instead of having each thread execute te very complex queries and really load down the application. So overall the wait from each client should be reduced significantly.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!