struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [OT] caching drop-down lists
Date Tue, 03 Dec 2002 01:20:18 GMT
On Mon, 2 Dec 2002, Jarnot Voytek Contr AU HQ/SC wrote:

> Date: Mon, 2 Dec 2002 18:04:44 -0600
> From: Jarnot Voytek Contr AU HQ/SC <Voytek.Jarnot@MAXWELL.AF.MIL>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: "'struts-user@jakarta.apache.org'" <struts-user@jakarta.apache.org>
> Subject: [OT] caching drop-down lists
>
> In our application (and I'm sure most others) we've got a multitude of
> drop-down lists used for data entry.  The Collections for the drop-downs are
> populated from the database.
>
> This doesn't seem very efficient - to hit the database for a read-only data
> every time.
>
> I'd like to cache this data (Business Delegate layer in our case); but I'm
> afraid of caching all the drop-down list Collections - I don't want to use
> up too much memory.
>
> I'm thinking of implementing some sort of singleton that would cache a
> specified number of Collections and remove the least recently used ones as
> new ones are requested.
>
> Has anyone implemented this sort of thing?  Am I adding too much complexity
> (and overhead)?  Do you think I should just cache them all - after all, I'm
> not sure that there will actually be so many as to use an inordinate amount
> of memory?
>

In a commercial project, I'd say that 99.9% of the time buying a few extra
megabytes of RAM is *much* cheaper than the cost of the programming effort
to build and maintain such caches over the life of a project.  I *hope*
that's true for the military as well :-).

Of course, how much room the collections take is totally application
dependent -- I'd start by caching all of them (as servlet context
attributes) and see how much memory it actually takes.  If you're hitting
the database a lot for this purpose, you'll probably also enjoy
the improved response time due to reducing per-request database hits.

> Just thinking out loud...
> --Voytek Jarnot
>

Craig


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message