Invalidate cache manually

[AmaelN]

Hi,

I'm using CacheCow with redis for a web API.

I've done a basic configuration

var etagStore = new RedisEntityTagStore(cacheCowCnxString);
var cacheHandler = new CachingHandler(config, etagStore)
{
    AddLastModifiedHeader = false
};
config.MessageHandlers.Add(cacheHandler);`

When i'm testing, data are stored in Redis (that's cool) and it returns a 304 code. Nevertheless, it is still running the code of the WebApi to fetch the data from the database so I'm not sure if it is returning to the client the data from the database or from Redis. What is missing ?

Also I would like to know how I can manually invalidate the cache ? for a specific prefix URI (including all the sub routes or URL paramters)?

Thanks

[AmaelN]

I've looked again and it seems that on some route the cache is called, the data are coming from redis but in some case (with multiple URL parameter) it is always calling the dabtase.

How the etag are invalidate. Is it automatic ? or should I do it manually ? and how ?

[aliostad]

Hi @AmaelN

As I have explained in this blog here, I am changing the server approach. As you have found out, the API Layer cannot be trusted to handle cache validation on its own, since in most cases data does get changed outside API calls.

Having said that, even current version CacheCow is reliable in terms of invalidating caches when change is through API POST, PUT or DELETE and has means of invalidating caches manually.

Bear in mind that URL parameters and query strings are part of the URI hence any change in them means data data should come from the source. If you provide some examples or a repro code, I can help better.

In terms of manual Cache Invalidation, you can use InvalidateResourceAsync by passing a representative request. If you provide more info, I can help better.

[AmaelN]

Great thanks !

I will provide you with some example tomorrow. that end point is returning a json of 50 lines. Could it why it is not cached (May not be the reason but it is better to ask in case of)

The InvalidateResourceAsync is what I was looking for execept that I have to invalidate each case for an end point manually (case for each url parameters). It can be tricky as it is like in your example on the blog. The order will need to invalidate all the route for cars.

[AmaelN]

I've tested the InvalidateResourceAsync and it is quite slow when it is called on serveral URLs. The current case, one end point with multiple url parameters possiblity. I have to manually invalidate each of them.

Any suggestions ?

[aliostad]

Well, as I said, with the new version of CacheCow which I am working on this approach is not used - API is no longer responsible for maintaining current status of resources. A couple more days and I think I can release next version - but for now InvalidateResourceAsync is all there is I am afraid.