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.