I love the sound of that product, but given the time contstraints I'm
not sure I can take on learning something new and get the thing in
place on time.
The other thing is that while I'm using the example of country codes,
there are in fact some things that will be quite large for example a
list of 15,000 companies that all users share
that puppy has to be stored somewhere where it can be
1. accessed by everyone
2. reloaded in some way without an app restart
I thought there could be some refresh method on the service I'll be
using to get the list in the first place....
I'm starting to think that it might be to much to store in the
Application Scope though. Ugh....
my goal is to keep this all as simple as possible yet still have it
work, and work well without blowing out memory on the server or
perofoming like a hog.
Does that change anything?
On Mon, 14 Feb 2005 14:47:00 -0500, Rick Reumann <[EMAIL PROTECTED]> wrote:
> 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]
>
>
--
-Dave
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
