Hey Chris

cb> 1.  Is performing DB heavy-lifting operations in ServletContextListener a 
"reasonable" practice?
cb> 2.  Is there a "better" way of caching said items at application startup?

cs> IMHO there is no better way than using a ServletContextListener to load 
things at startup.

OK, good to know that using SCL is "reasonable".

cs> Your only other spec-compliant option is to use a Servlet with 
load-on-startup set
cs> and do your work in the init() method, which is ... ugly.

I was thinking of a servlet request (or something) that is called on startup 
that could also be called later on-demand(?).

cs> Another option would be to perform "lazy loading" instead of a-priori 
loading of this data.
cs> You will take the hit of loading the data when it is first requested, which 
may negatively
cs> impact user experience. It might also mean that you have to be more careful 
about
cs> cross-thread synchronization, etc. since you can't guarantee that the work 
has already
cs> been done before a client tried to access the cache.

cs> If you are concerned about startup times, lazy-loading is a good solution.
cs> It can also improve your memory usage if that data is never actually needed.

+1.  I like this.  "Smarter" caching.  Only load the data you need when you 
need it.

cs> We have a primary application at $work where we need to have a lot of 
information
cs> in mrmoey to be able to do important stuff.  [...] We loaded 100% of it 
every time at startup.
cs> [...] I switched to loading things on-demand and it made not only a 
significant performance
cs>  improvement on startup [...] it significantly reduced the memory footprint 
of the
cs> in-memory cache of data

How were you "careful about cross-thread synchronization", synchronized blocks?

cs> We also have a user-initiatable process to "reload" the data

Where do you do the loading and reloading, a in a servlet request?

cs> [Now] it just empties the cache and does nothing else. More faster. :)

"More faster"  :-)

--
Cris Berneburg
CACI Senior Software Engineer


________________________________

This electronic message contains information from CACI International Inc or 
subsidiary companies, which may be company sensitive, proprietary, privileged 
or otherwise protected from disclosure. The information is intended to be used 
solely by the recipient(s) named above. If you are not an intended recipient, 
be aware that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited. If you have received this 
transmission in error, please notify the sender immediately.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to