On Mon, 14 Feb 2005 11:23:16 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
> I've been thinking about this issue a lot lately. We're gearing up to
> move a portion of our application to JSF and we have lots of this
> lookup data. Currently we just refresh it every request but that is
> obviously resource intensive (although very safe.)
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.
Craig
