Over a million developers have joined DZone.

RavenDB Caching Done Right (EventsZilla part II)

DZone's Guide to

RavenDB Caching Done Right (EventsZilla part II)

· Database Zone
Free Resource

Learn NoSQL for free with hands-on sample code, example queries, tutorials, and more.  Brought to you in partnership with Couchbase.

In the previous post we created the basics for an events publishing application, and discussed the modeling aspect of things.

I put some more work into the app, and now it actually works and looks pretty nice. Queries and loads are in place for the front-end, so it is time to visit one key feature of RavenDB - Caching.

Basic caching

The RavenDB Client API provides automatic out-of-the-box caching for all read operations. Every data request sent to the server is being remembered by the document store object, so subsequent  read operation that are detected as identical can return immediately.

However, it is important to beware of common pitfalls which may cause you not to take advantage of this handy feature. While there's no real way to mess up with simple Load operations, it is very easy to do that when querying.

For example, the most common query in an application like EventsZilla is to get events starting before or after a certain point in time, usually DateTimeOffset.Now. However, a query like this is guaranteed to never use the cache, since it is virtually different every time it is called.

In EventsZilla we can fix this relatively easily, by lowering the DateTimeOffset resolution when querying. Another approach will be to round up (or down) the value. The actual resolution or rounding approach we use will determine how much of caching this query will take advantage of.

Relevant code can be found here.

Aggressive caching

Basic caching is very effective, requires no action from the user's end to work, and is a great feature for automatically improving your applications performance. However, a server query is still issued with every read operation to make sure the cache never goes stale. The actual benefit with basic caching is with getting back a quick response of a thin 304 (HTTP for "I haven't changed") instead of a complete 200 response with all the requested data.

At times, we load an object - or perform a query - that we really don't care if it changes for a certain period of time, or we just don't expect it to. If we choose to, we can tell RavenDB not to query the database at all if it has a cached response that is not older than a given point in time.

This feature is called an Aggressive Caching, being aggressive in the sense of not peeking outside the cache at all. Unlike basic caching it is an opt-in feature.

In EventsZilla, this is exactly the case with a website-wide config object. We don't expect it to change a lot, and when it changes, we can bear a certain amount of time until the changes are noticeable in our website.

All we need to do to make it happen is load that object within a context of an AggressiveCache, and the RavenDB Client API will take care of the rest for us.

Using Aggressive Caching is as simple as this:

using (RavenSession.Advanced.DocumentStore.AggressivelyCacheFor(TimeSpan.FromMinutes(30)))
    var siteConfig = RavenSession.Load<SiteConfig>(SiteConfig.ConfigName);

More on caching

Is in the second part of the excellent RavenOverflow video, available here.

Source: http://www.code972.com/blog/2011/12/ravendb-caching-eventszilla-part-2/

The Getting Started with NoSQL Guide will get you hands-on with NoSQL in minutes with no coding needed. Brought to you in partnership with Couchbase.


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}