> 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:)
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.) With the application scope beans in JSF I have been toying with the idea of using them instead. I was thinking that it might be possible to invalidate the bean (by setting the value to null) whenever a new item is added. I haven't worked out the details yet but thread safety is an issue that jumps to mind. Also, you'd have to have make sure that you were listening to every possible point where the list might change. Craig is doing some cool stuff with Struts Shale and backing beans. I will ask him about this because there might be some interesting possibilities there. > Rick sean
