Caching, Spring and Reducing the 'first hit' Time

Caching, Spring and Reducing the 'first hit' Time

recently a colleague was working on a Jdbc Caching issue.  The underlying database supporting was of a similar nature to SQLFire; that is, distributed with a cache on top.  What was the pain was that the 'first hit' to the database triggered the underlying service to go and gather all the information from the distribution and cache the query's result set.  This lead to about a 6x performance cost compared to subsequent caches.  The question was, how to reduce this from the poor user who hits it first?


ApplicationListener is feature in Spring that allows you to create your own implementation and received the context just after it's started up.  In this case, this would allow the application context to have all the accessible beans fully populated and initialized.  This allows us, in the case above, to call the respective Service during startup time, triggering the underlying data service to run the 'first hit'.  The end result is that the 'first hit' is taken care of on startup, and, depending on how caching is managed, the user shouldn't experience the 'first hit' lag (as it's already completed) when they access their services.

here's a sample