Question

I have a web application written using Java servlets. I am using Tomcat 7 as my servlet engine, but have used Glassfish previously and had the exact same issue.

The page in question has a “statistics” section that is updated every 5 minutes. The statistics take about 30 seconds to generate due to the size of the MySQL tables involved.

When I get a page load, I show the cached statistics. After everything in the page has been rendered, I flush and then close the output stream. I then update the statistics. This way, no user has to ever wait ~30 seconds for the page to load and the statistics update after the page has already been completely sent.

The problem is that if I refresh the page while it’s running the query, the page doesn’t load until the query has completed, which means that although the initial user doesn’t have any delay, after that there is a long delay.

Why is the application effectively stalling? Shouldn’t Tomcat be able to use another worker thread to handle the request, even though one thread is still busy?

Thanks.

Answer 1

What might be happening is your data is being “locked for update” while the update is taking place – it depends on exactly how the data is being recalculated.

A good way to work around this is to make the new calculation into a separate data area, then switch over to using the new data after it’s all done. One way to implement this is using a database view and a version number, like this:

create table my_statistics (
  id int not null primary key auto_increment,
  version int not null,
  -- other columns with your data
);

create table stats_version (current_version int); -- holds just one row

create view stats as
select * 
from stats_version v
join my_statistics s on s.version = v.current_version);

Put your new stats into the table with a version number of current_version + 1. After all calculations have been made. Then a simple update stats_version set current_version = current_version + 1 will switch to using the new data. This last statement takes just milliseconds to execute, so locking waits are tiny.

After switching, you can delete the old stats to save space.

Using the “switch” approach makes the update and “atomic update” – the update happens “instantly and completely”, so users don’t see a partially changed dataset.