A few questions in response:
Is the data querying time such that it constitutes caching, albeit the
frequency that the data changes?
When caching is brought up, ask yourself how often is the data accessed as
opposed to how often it changes. If you are using up memory in the servlet
context for queries that aren't needed every minute, then you wasting your
memory. That's why I prefer to create softly referenced caches that allow
the garbage collector to clean out old beans if the application needs more
memory. Essentially, the GC dictates cache life with some business logic.
Object bean = null;
// see if we already have a bean in memory
if ( (bean = softCache.get(uid)) != null )
{
// ask the dao if the data has been changed
if (bean.lastModified() >= dao.getLastModified(uid))
{
return bean;
}
}
// fall through
bean = dao.getObject(uid);
softCache.put(uid, bean);
return bean;
| -----Original Message-----
| From: Ashish Kulkarni [mailto:[EMAIL PROTECTED]
| Sent: Thursday, March 13, 2003 9:11 PM
| To: Struts Users Mailing List
| Subject: RE: Caching Drop Down List Box Strategies?
|
| Hi,
| One question about caching data in servletcontext,
| u said some thing about timestamp, what this timestamp
| do exactly, how will i come to know when to reload the
| data using this timestamp,
|
| Also suppos the data i ahve to cache does not modify
| so often , but it modifies once in 15 - 20 days, but
| by some different application , so how will i refresh
| data in cache??
|
| Ashish
|
| --- Wendy Smoak <[EMAIL PROTECTED]> wrote:
| > Joshua wrote:
| > > I thought I would be slick an attempt to cache the
| > Collections used to
| > > populate my forms drop down list boxes instead of
| > hitting the database
| > every
| > > time (The values may change daily).
| >
| > Assuming you don't reload (or stop/start) your
| > webapp daily, in which case a
| > ServletContextListener could be employed to place
| > the Collections into
| > application scope where they would live until the
| > next reload...
| >
| > I assume that Struts uses the iterator() method of
| > the Collection/List in
| > order to write out the <option> tags. Maybe it's
| > the toArray() method. In
| > any case...
| >
| > What if you implemented Collection (or List) and
| > held a timestamp, so that
| > when the iterator() method was called, you would
| > check to see if the data
| > was "expired" and if so, go read it from the
| > database before returning the
| > Iterator. That's going to cause a delay for the one
| > person who's unlucky
| > enough to request the page after the expiration, but
| > if you stagger the
| > expiration times, it'll only delay one person per
| > day per drop-down.
| >
| > I use the ServletContextListener approach, but the
| > contents of my dropdowns
| > don't change that often.
| >
| > --
| > Wendy Smoak
| > Applications Systems Analyst, Sr.
| > Arizona State University PA Information Resources
| > Management
| >
|
|
| __________________________________________________
| Do you Yahoo!?
| Yahoo! Web Hosting - establish your business online
| http://webhosting.yahoo.com
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
