Craig McClanahan wrote the following on 2/11/2005 11:45 AM:
My recommendation is to use request scope for backing beans in a JSF application, storing stuff in session and appiication scope only where it's needed:
* Session scope for per-user state that changes, or for passing data across requests (as an alternative to having to save and restore the data yourself).
* Application scope for caching things like arrays of SelectItems that back a dropdown list, but are shared across all users.
I haven't had much luck with the later situation for application scope. I do use Application scope for such things as having a Constants Map in scope that the front end might need access to, but for drop down lists unless it's 'definitely' not going to change I don't like application scope since any changes to the backend database aren't going to be picked up until the server restarts. I tend to opt now for making calls to the persistence layer to re-get my Lists that I need again. This lets the persistence layer worry about caching if it needs to. Sure a method call will be more expensive than using a list or array already in applicaiton scope, but to me it's a fair trade off. I've been burned too many times thinking "this list of options will never change" and sure enough someone makes a change to the backend and it's not reflected by your app and then you get the annoying phone calls:)
-- Rick
