command object cache invalidation

Question

I've got an app that implements a command object pattern to get data from a server. Now I'd like to implement a client side cache and I need some pointers on how to deal with cache eviction invalidating.

The problem

To get an object I pass the GetObject(id) command and receieve a GetObjectResponse with the results for that id. I've got a cache going that can cache the GetObject(id) command nicely.

However, when I see a command like DeleteObject(id) or UpdateObject(id), the cache for GetObject(id) needs to be invalidated.

I should say that the reality is not necessarily this simple as with a single id parameter. Some response objects depend on more than one parameter in the command object. Also, passing one command object could invalidate more than one response objects.

Any thoughts on how to accomplish this? Thanks in advance!

Answer 1

Firstly, the problem is called cache invalidation, not eviction. (I see you use both terms.) Cache eviction means removing elements from the cache when the cache is full. This is a completely different topic.

Secondly, I don't see the connection between the command pattern and the cache. Anyway, let's focus on the cache.

When invalidating an element you have to find it in the cache. This works the same way as for retrieving the element: by looking up the value using a cache key. Such a key can be the id you mention, or some other unique tuple of values. How this id, or tuple looks like depends on your domain (the way you use the command pattern).

Regarding your last issue, there has to be a rule that tells you which elements are to be invalidated when a certain other element is invalidated. This depends on the logic behind your command pattern application. I can't tell from your description how exactly such a rule would look like.

Answer 2

As far as I understand, your client needs to have a local cache of a server state. When the server state changes, your client needs to be notified and updated. My suggestion is to start with the extreme case of invalidating the whole cache and then work down smaller and finer ways of updating the cache without sending the whole state of the server. An idea on doing finer updates would be to "tag" each change on the server state so the client can send his last tag, and then the server can compute the best way of updating the client based on his current tag (whole updating or just fields).