Thanks, Jason. Need time to grok all of your suggestions, but much appreciated.
On Nov 13, 8:08 am, Jason Meckley <[email protected]> wrote: > 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.
