Use a caching DAO layer (like iBATIS), and let it cache the data. Then, to get the data, use a filter and have it run on requests for resources that match "*.do" and "*.jsp". The filter can put the menu into request scope (remember, it is just a reference to the menu, not the entire menu structure, so it will be very lightweight).
It is then available everywhere, with a global and manageable cache. In addition, when you later decide that the menu should be application or user specific, you have both the URI and the user requesting it. Another benefit is that if you decide to use some other web framework, you have no dependency on struts for your menu. The only requirement you have is that it must be servlet based. Sorry, no .NET allowed. ;-) Larry On Wed, 16 Feb 2005 17:29:37 -0700, Mr Maillist <[EMAIL PROTECTED]> wrote: > Hello, > > I am building an application that will store menu options in a > database. These menu options will display on every page in the > application. I am interested in finding the most efficient way of > doing this. My options as I see them are: > 1. provide a base action for the entire site (similar to > struts-mailreader) that will provide me with a method to load the menu > information and store it in the request. This option is heavy on > database traffic. > 2. still use the base action but store the information in the session > when the user first visits the site. This option is an awkward type > of cache that might behave strangely with high volume to the site. > 3. load the menu options one time from the database and place in the > application scope. While this is the best memory option (and probably > the most efficient for speed), I'm not sure how I would reload this > after a change was made to the underlying database (or even detect > that a change was made). > > I suppose that there is a final option which would be to use a > chaching layer between for database transactions and go with option 1. > Is a base action the best approach? > > thanks in advance for your comments. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
