Session Timeout Prevention During Database Updates

Background

The web application calls the stored procedure to intensively update the database. The corresponding part of web.xml been updated to four hours:

 <session-config> <session-timeout>240</session-timeout> </session-config> 

Technologies available for the solution include Java 1.4.2, Struts 2, Tomcat 5.5, and Apache. Most other technologies (such as jQuery) are not allowed.

Problem

The update takes about an hour, but the configuration value of four hours complies with corporate standards (for good reason). A four-hour configuration is not permitted during production.

Question

What ensures that the query does not expire during the database upgrade?

Ideas

My problem in the first two cases is that the spawned process will eventually be killed by the Servlet container.

Page Refresh

  • Create a database update process as a background task.
  • The servlet is constantly updating the page to check completion.

Javascript ping

  • Create a database update process as a background task.
  • There is JavaScript code on which the ping server has been on for some time.

Similarly, Preventing a session timeout for long processing time in JSF , but without jQuery.

Update server

Write a simple server that listens for requests:

  • The servlet sends the request to the listener.
  • The listener starts the update.

Because the server is independent of Tomcat, a session timeout cannot occur. Database update will be completed without loss. This has numerous problems (error handling is not least my concern) and is probably the last resort.

Optimization

Optimizing the request for completion in less than 30 minutes (maximum timeout) is possible, but most likely the request cannot be optimized enough.

Equipment

Unfortunately, updating the database hardware is not an option.

Thank you very much!

+10
java tomcat session-timeout
May 11 '11 at 8:34
source share
2 answers

In my opinion, no user wants to sit in front of the screen, tracking the background task for 4 hours. A few years ago I had to implement report generation, which took hours. The implemented solution was as follows:

  • Generate a report in the background thread. The flow was controlled and accessible through a list of application contexts. The stream contained information about the owner and his progress.
  • Users can list their own streams and see progress.
  • Upon completion of the report flow, the report will be stored for offline access, send an email notification to the owner with a link to download the generated report.
+4
May 12 '11 at 14:33
source share

By reading abvoe, I can guarantee that you have two options, even if the second is complex, its best processes

1) Page refresh

  • Create a database update process as a background task.
  • The servlet is constantly updating the page to check completion.

2) Optimization

Optimizing the request for completion in less than 30 minutes (maximum timeout) is possible, but most likely the request cannot be optimized enough.

+1
May 11 '11 at 9:05 a.m.
source share



All Articles