This is the first of a three parts series.

I first stumbled upon widespread caching of objects in 2001 when I joined Calypso. At the time the idea was mostly to save time on the relational to object mapping. I did not realize at the time all the consequences of that on the design of the software. Since then, companies have flourished selling distributed caching and I discovered that I was not the only one that lacked this knowledge. So I will try to summarize my accumulated experience on this subject in the first two parts and I will try to finish wih a more speculative solution (a solution that I have not had the occasion to test personnaly).

The most important thing to remember when using caches is that objects that are cached should not have a direct reference to other cached objects. I first understood that in 2002. The reason is that if you have a reference to an instance in cache; when that instance is replaced by an updated version of the object the referencer will be holding a stale version. This obviously quickly becomes a design headache. There are two basic solutions to this (I reserver the fourth one for my speculative part).

The first one (I tried it in 2002-2003 and it works fine for a small project with few cached objects) is to actually reference the instance and never discard it. Instead, when an update comes in the existing (cached) instance is fully updated. This is a bit cumbersome to implement. In java it has the advantage of making use of garbage collection properties with very long lived cache objects and very short lived update objects.

The second one is to modify your object model to use only the identifier of the cached objects. This in tuen implies to provide access to the caches from almost everywhere in the code (whereas in the first solution few parts of the code, apart from the update mechanism, need to know about the cache). I am sure that dozens of solutions can be found to handle this. Ideally, the solution does not imply to change the interfaces (accessors) and most of the code, aside from direct referencers can ignore the mechanism. Also note that collections can become a bit trickier to handle. This is the solution the project I currently work on uses. It requires a fair amount of code to have a well polished solution.

Now there is at least third solution that I can think of. It was rejected in my current project because the team did not have a high level of comfort with it. That solution is therefore entirely speculative on my part. I will present it in part III of this series.

Next: Of the impact of caching on your design (II)

This entry was posted on Thursday, December 20th, 2007 at 11:59 pm and is filed under Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.