Struts2 static data storage / access

Question

I am trying to find what is the usual design/approach for "static/global"! data access/storage in a web app, I'm using struts 2. Background, I have a number of tables I want to display in my web app.

Problem 1. The tables will only change and be updated once a day on the server, I don't want to access a database/or loading a file for every request to view a table. I would prefer to load the tables to some global memory/cache once (a day), and each request get the table from there, rather than access a database. I imagine this is a common scenario and there is an established approach? But I cant find it at the moment. For struts 2, Is the ActionContext the right place for this data. If so, any link to a tutorial would be really appreciated.

Problem 2. The tables were stored in a XML file I unmarshalled with JAXB to get the table objects, and so the lists for the tables. For a small application this was OK, but I think for the web app, its hacky to store the xml as resources and read in the file as servlet context and parse, or is it? I realise I may be told to store the tables to a database accessing with a dao, and use hibernate to get the objects. I am just curious as to what is the usual approach with data already stored in XML file? Given I will have new XML files daily.

Apologies if the questions are basic, I have a large amount of books/reference material, but its just taking me time to get the higher level design answers.

Answer 1

Not having really looked at the caching options I would fetch the data from the DB my self but only after an interval has passed.

Usually you work within the Action scope, the next level up is the Session and the most global is the Application. A simple way to test this is to create an Action class which implements ApplicationAware. Then you can get the values put there from any jsp/action... anywhere you can get to the ActionContext (which is most anyplace) see: http://struts.apache.org/2.0.14/docs/what-is-the-actioncontext.html

Anyways, I would implement a basic interceptor which would check if new data should be available and I have not looked it up already, then load the new data (the user triggering this interceptor may not need this new data, so doing this in a new thread would be a good idea).

This method increases the complexity, as you are responsible for managing some data structures and making them co-operate with the ORM.

I've done this to load data from tables which will never need to be loaded again, and that data stands on it's own (I don't need to find relationships between it and other tables). This is quick and dirty, Stevens solution is far more robust and probably would pay you back at a later date when further performance is a requirement.

Answer 2

This isn't really specific to Struts2 at all. You definitely do not want to try storing this information in the ActionContext -- that's a per-request object.

You should look into a caching framework like EHCache or something similar. If you use Hibernate for your persistence, Hibernate has options for caching data so that it does not need to hit the database on every request. (Hibernate can also use EHCache for its second-level cache).

Answer 3

As mentioned earlier, the best approach would be using EHCache or some other trusted cache manager.

Another approach is to use a factory to access the information. For instance, something to the effect of:

public class MyCache {
  private static MyCache cache = new MyCache();

  public static MyCache getCache() {
    return cache;
  }

  (data members) 

  private MyCache() {
    (update data members)
  }

  public synchronized getXXX() {
    ...
  }

  public synchronized setXXX(SomeType data) {
    ...
  }
}

You need to make sure you synchronize all your reads and writes to make sure you don't have race conditions while updating the cache.

synchronized (MyCache.getCahce()) { 
  MyCahce.getCache().getXXX();
  MyCache.getCache().getTwo();
  ...
} 

etc

Again, better to use EHCache or something else turn-key since this is likely to be fickle without good understanding of the mechanisms. This sort of cache also has performance issues since it only allows ONE thread to read/write to the cache at a time. (Possible ways to speed up are to use thread locals and read/write locks - but that sort of thing is already built into many of the established cache managers)