I just answered essentially the same question on myfaces-user ... the mail archive link doesn't work, so here's a cut-n-paste of an approach where the app does this itself, when you use a getter method on an application scope bean to provide the SelectItem[] list to populate a dropdown (or whatever):
----- Begin Cut ----- You can have your cake and eat it too. Consider the following getter method on an application scoped bean (it's from org.apache.shale.usecases.view.Domains in the Shale example app): public SelectItem[] getSupportedCategories(); Normally, during the execution of the app, I would just load this once and be done with it. Remember, though, that the getter is a method that can do anything it wants. Assume, for example, that you have an administrative app that adds or updates category information. Whenever someone makes a change, you want to cause the cached list to get updated. Why not have this administrative app set a flag somewhere (perhaps even a method call on this same application scoped bean) that says "the next time someone asks, go grab the data from the database again." That way, you stil get the performance benefit of caching without giving up the ability to update these lists dynamically. Other alternatives: * Have the administrative app set some data element in the database that the getter method looks at on each call (less expensive than reading the entire table again). * If the data changes so often that the reload-on-change would basically eliminate caching's performance benefit, add logic that says "if it has been more than X minutes since you last updated, read the data again. This way, you get the caching benefit for X minutes at a shot, at the cost of not having absolutely up-to-date data for that period. The key to this is that the JSF component you bound to this property getter has no idea whether the data was cached or not, or updated or not -- and it doesn't care. It just wants an array of SelectItem that it can use to construct the options list. ----- End Cut ----- It's not clear to me that this is really a framework issue, although some examples of various techniques would certainly be useful to people. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
