At 06:04 PM 12/2/2002 -0600, you wrote:
I think you'll find when you experiment that you can pretty easily cache the most often used drop down lists without seriously affecting memory. There are a couple of options that haven't been mentioned: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?
-Commons-Collection has a LRUMap as well if you don't want to use JDK 1.4
-You can try Expresso's CacheManager which gives you the ability to tweak cache sizes per name as well as to provide 'listening' capabilities, where if some underlying data is changed that might change the contents of the dropdown, the dropdown cache will be cleared for next use.
-Turbine has a Cache component as well. I haven't used it myself, but it looks pretty capable.
To be honest, I'd use either option #2 or #3 rather than just a LRUMap. The issues dealing with changed caches, as well as high performance threading on a singleton object can get complicated. [Not that it can't be done, but I'm just thinking in terms of how much time you would have to invest]
HTH!
-Mike
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
