David Johnson wrote the following on 2/14/2005 12:54 PM:
I have a need in an app I'm working on to cache data that is valid and shared across users, like standard country codes, region codes, industry codes... stuff like that.
Everyone has given you good suggestions, but I still think you should rarely use Application scope unless you are
a) certain the information will not change and/or
b) you can afford the server stop/restart if the data needs to be refreshed or you create code that can apply updates on the fly and repopulate your Application scoped items without the server restart.
I opt now to not bother with worrying much application scope for things other than constants that are application specific to my code. For things that could possibly change from external sources (ie some DBA enters in or changes a new region code) I don't bother using Application scope. Even though it might be unlikely that a list of region codes will change, it could happen, and when it does what is going to be your business process to make sure you application scoped items get refreshed? There are ways to get this done, but I'd start out not really worrying about it and code a layer that hides how you are handling it so you can swap out the implementation later.
For example, when you need region codes in your view, I'd make sure that you always populate them into request(sometimes session) scope before you get to the page with something like...
List regionCodes = myServiceLayer.getRegionCodes(); request.setAttribute("regionCodes", regionCodes );
How your MyServiceLayer object actually gets the region codes could then vary. You could make a call to your persistence layer (maybe iBATIS) or maybe if you are sure they won't change you could get them out of Application scope. The nice thing is you won't be tied to doing it one way or the other (ie your Action doesn't care how 'myServiceLayer' gets the region codes).
If you use a persistence framework like iBATIS you can set the query to cache so that you don't even have to worry about using Application scope. You make the same call as if you are getting fresh data and the framework will take care of whether it can give you a cached copy. The nice thing is later on if you realize "Wow, the company just added a bunch of new stores and changed all the region codes, so we shouldn't assume they are static" you could just turn the caching off. If, on the hand, you went with an approach where you pulled your list on your JSP right out of ApplicationScope.. you'd be in for a lot more coding changes. For the simple addition of two lines of code (as above), you end up with a lot more flexibility. You'll still be able to use Application scope, but you'll also have a much easier time adapting if requirements change.
-- Rick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
