Prevent session timeout during database update

Dave Jarvis picture Dave Jarvis · May 11, 2011 · Viewed 10.4k times · Source

Background

A web application calls a stored procedure to perform an intensive database update. The relevant portion of web.xml was updated to four hours:

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

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

Problem

The update takes about an hour to run, however a configuration value of four hours is against corporate standards (for good reason). A four hour timeout configuration is not permitted in production.

Question

What will ensure that the request does not time out while the database update executes?

Ideas

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

Page Refresh

  1. Spawn the database update process as a background task.
  2. Have a Servlet continually refresh the page to check for completion.

JavaScript Ping

  1. Spawn the database update process as a background task.
  2. Have JavaScript code ping the server for a while.

Similar to Preventing session timeout during long processing time in JSF, but without jQuery.

Update Server

Write a simple server that listens for requests:

  1. The Servlet sends a request to the listener.
  2. The listener runs the update.

Since the server runs independently of Tomcat, the session timeout cannot occur. The database update will run to completion without being killed. This has numerous issues (error handling not the least of my concern) and is likely the option of last resort.

Optimization

Optimizing the query to finish in under 30 minutes (the maximum permitted timeout) is possible, but it is likely the query cannot be optimized sufficiently.

Hardware

Upgrading the database hardware is not an option, unfortunately.

Many thanks!

Answer

Pierre picture Pierre · May 12, 2011

In my opinion, no user would want to sit in front of screen monitoring a background job for 4 hours. Few years ago, I had to implement report generation which took hours. the implemented solution was the following:

  • Generate the report in a background thread. The thread was monitored and available via application context List. The thread contained information about the owner and their progress.
  • Users can list their own threads and see progress.
  • Upon completion the report thread would store the report for offline access, send an email notification to owner with a link to download the generated report.