Why another caching mechanism?

In case you are familiar with the architecture of OpenCms 4.6, you might wonder why a new cache is introduced for Flex instead of just extending the existing "Element cache" of OpenCms 4.6. Even though the "Element Cache" has a good and powerful set of features (which is kept and extended by the FlexCache), it turned out that it was not adoptable to the needs of the JSP integration because it was tightly intervowen with the OpenCms XMLTemplate mechanism, and untangling it seemed to be impossible without re-writing it almost entirely.

Moreover, the FlexCache implements a much more efficient 'Last-Recently-Used' (LRU) policy to remove objects from the cache than the old element cache. Any operations on the FlexCache can be completed in constant time (meaning O(1) in the 'big-O-notation'). That's why increasing the size of the FlexCache will usually not slow down the FlexCache. Due to the heterogeneity of the cached objects, the FlexCache also considers about the 'cache costs' of each cached object. Therefore, the 'cache costs' are approximated as the object's byte size.

For the template developer, the "Element Cache" is intrinsically complex to use, making the caching of the application not only difficult to achieve but also difficult to maintain. This is so because all changes to a cache directive require writing java code, recompilation of java classes and restarting of the webserver, and even then there is no easy way of determining what exactly is cached and what not. Also it's not possible to cache the "Offline" projects even in testing environments, which usually leads to late problems in the development cycle as errors related to the caching are discovered only after publishing.

The FlexCache addresses these issues, resulting in a much easier to use and more standards conform cache implementation.

]]>