10

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!

Community
  • 1
  • 1
Dave Jarvis
  • 30,436
  • 41
  • 178
  • 315
  • What about session in memcached? http://code.google.com/p/memcached-session-manager/ – lschin May 11 '11 at 08:58
  • I think you already answered your question, or not? As you wrote, you need to run the upgrade as a background task and either do page refreshes or ajax polling to show current status of the task. – Peter Štibraný May 11 '11 at 09:08
  • Tomcat should not kill your spawned threads or processes. Of course, if you kill entire Tomcat, then your threads are gone too. When your app is redeployed, you may run into issues with background threads, but admins should be careful with redeploys when there are background tasks running (and you can also listen for webapplication going down/up). – Peter Štibraný May 11 '11 at 09:27

2 Answers2

4

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.
Pierre
  • 1,329
  • 2
  • 12
  • 21
  • It was a in-house development effort. it was not too complicated (List of threads, generating thread which removes itself from list once completed and a monitoring page for List).If I were to build it again today, i would probably base it on Quartz scheduling framework since I can re-use the effort for a lot of other things. – Pierre May 13 '11 at 18:12
1

By reading the abvoe , i can ensure you have two options even though second one is difficult, its the best proces

1) Page Refresh

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

2) 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.

developer
  • 9,116
  • 29
  • 91
  • 150