Agatha Feature Suggestion: Caching
Posted by Davy Brion on December 12th, 2009
Someone recently asked me if it would be possible to cache responses with an Agatha service layer and just send back the cached responses when matching requests are sent to the service layer. I’ve been thinking about this a bit lately, and i think it would be a tremendous feature. In this post, i just want to list a couple of ideas on how it could work and what we’d need to take into account to make it work. Please feel free to leave your suggestions/thoughts on this since i can definitely use all of the feedback i can get to implement a feature like this.
The idea is basically to implement a caching layer which works very similar to NHibernate’s Second Level Cache. You would need to be able to define which request/response combination is eligible for caching. When a request/response combination is eligible for caching, Agatha should check to see if a cached response is already available for a particular incoming request. That would mean that the request type would need to override the Equals method to compare the values. If a previous request has already been processed which is equal to the current request, the corresponding cached response could be sent back immediately without having to handle it again. Obviously, this check would only happen for requests which have been made eligible for caching.
We’d also need to provide a way to invalidate the cache. Both time-based expiration and explicit removal from the cache should be possible. For time-based expiration we could just provide some sort of time-out setting in the same place where you enable the caching for the request. I’d probably do that through a .NET attribute which you can put on your Request type, and the time-out would simply be a property of the attribute. For explicit removal, i’d probably go with a ‘region’-approach, similar to the regions in NHibernate’s Second Level Cache. For instance, when declaring a request to be eligible for caching, one of the properties of the caching attribute could be a region name, and then we’d need to give you the ability to clear a certain region of the cache in your request handlers when it’s necessary to do so.
That’s pretty much all i can think of for now. It’s not much yet, but i do think it could really be a tremendous improvement to Agatha. The performance benefits for requests that deal with mostly static data, or data that doesn’t change frequently could be huge. And the required coding effort for developers using Agatha would be minimal… simply put the correct attribute on your request type and explicit clearing of the right cache region when necessary would be all there is to it.
Thoughts?
December 12th, 2009 at 6:48 pm
I think its an overall solid idea
. And I agree that using Attributes would provide the best solution.
December 12th, 2009 at 7:06 pm
Perhaps the request/response classes which are deterministic could be decorated with an attribute to indicate this. In this way, the service handling the request can return the cached response for subsequent requests. There could also be additional meta associated which specifies lifetime behavior for the cached responses.
December 13th, 2009 at 2:54 am
Davy,
One of the things that makes NH caching works really well is that it understand when to handle expiry based on the tables involved in a query.
That is a hugely important issue for caching, because it means you don’t have to explicitly handles this.
December 13th, 2009 at 12:35 pm
@Ayende
i know, but i don’t think that’s possible for this kind of caching… having to handle it explicitly in some cases probably won’t be an issue for most people i think.
December 13th, 2009 at 2:33 pm
I assume that the caching is completely server-side, as it would be the most logical place to invalidate cache regions etc., but would it also be useful to have some kind of client-side caching? The main advantage of client-side caching would be to reduce remote calls (via WCF or something else), but can get pretty complex while batching requests.
Any thoughts on this? (I’m just thinking out loud here…)
December 13th, 2009 at 2:38 pm
@TomC
yeah that has crossed my mind but then there would be no way to invalidate client-side cached responses
(yes, you could do it with wcf duplex channels but that would be wcf specific which i want to avoid)
December 14th, 2009 at 10:41 am
[...] Agatha Feature Suggestion: Caching – Davy Brion starts investigating response caching capabilities for his Agatha Service Layer Implementation and already has a post’Agatha’s Caching Layer Implementation: First Draft‘ providing the first draft (in code) of such a feature [...]
March 24th, 2010 at 1:45 pm
Looks like a good idea! But will it work in a practical environment …………. The main advantage of using NHibernate over this sort of caching is that NHibernate has some proven result. There are some cache providers which offer support for second level caching and NCachebeing the most famous one.