Of the impact of caching on your design (II)

This is the second part of a three part series.

The first part was about object references. There is a second pitfall of caching I discovered while working at Calypso Technology and experienced again in my current project. And it seems it is even more overlooked than the direct reference of cached objects. It is the mutation of cached objects.

It is often overlooked because it is very subtle to detect and track down. Obviously it only causes problems in multi threaded applications when two threads concurrently use (not necessarily modify) an object. This is independent of the actual transactional properties of the cache.

The obvious solution is to make a copy of the object to modify before starting to modify it. Another, safer, solution is to put only immutable objects in the cache. This effectively enforces the check-out of the object before it can be modified. It also fits easily in any transaction scheme as the check-in essentially is to create a new immutable object and put it in the cache.

In my current project we came up with a somewhat elegant solution that uses dynamic proxy to provide the mutable side of the objects. This enables to make to implementation cost lighter and provides additional functionality such as show the exact changes, simulating changes (and even persist them) without actually applying them. The most significant advantage of that is the ease of use of that model: it requires an explicit check-out but the modified object is freely usable inside the transaction without having to knw if it is being modified or not. All this significantly reduces programmatic errors. The drawback is that it requires a significant implementation effort.

Another side of this problem is the requirement to keep track of the version of an object to enable optimistic locking rather than the more expensive pessimistic (preemptive) one.

The third and last part of this series (Of the impact of caching on your design (III)) will expand on some of these ideas to try to provide a comprehensive design pattern around caches.

Post to Twitter

One Response to “Of the impact of caching on your design (II)”

  1. One brike at a time » Blog Archive » Of the impact of caching on your design (I) Says:

    [...] « Agile Planning Of the impact of caching on your design (II) [...]

Leave a Reply