if you don't want a fixed cache expiration use a sliding expiration date. This assumes the cache has the feature.
An infinite expiration is a red flag to me. Why would I store the data in the database if I keep it in memory for the life of the application? in that case i would manage the objects in memory and not bother with a database at all. There are other/better ways to boost performance than 2nd level cache. this seems to be the default answer. Probably because it's easier to enable cache, than diagnose the true bottleneck. I would start by analyzing the queries. *Can you reduce the number of queries. reduce lazy loading calls, batch reads, etc.? *Do database indexes need to be tuned to provide better throughput? *Is the data you require a complex aggregation that is expensive to calculate? If so you calculate the projection in the background and store the results in a table/view. Map the database object to an immutable object in your application. *Can you take advantage of a stateless session? this is helpful for read-only data. As a last resort, enable caching. And even then, set reasonable limits on the expiration policy. On Nov 12, 4:09 pm, Jorge <[email protected]> wrote: > What are the risks of setting an infinite cache default expiration > time > for the query cache (in the interest of boosting performance) ? > > Thanks! -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
