Sascha Preibisch

Tip of the week: local cache assertion

Blog Post created by Sascha Preibisch Employee on Mar 13, 2017

Hi everybody!

Some of you who have build policies have also used assertions called Look Up In Cache and Store to Cache. Usually they are used to improve performance or to keep track of session data across multiple requests and responses. Those assertions work very good for that. But there is something you need to know about them ... .


Here is the tip: using Cache ID and Maximum entry age correct!

When using Store to Cache the following values can be configured:

  • Cache ID: the name of your cache
  • Cache entry key: the key used to identify a specific entry
  • Maximum entries: the number of entries this cache should accept
  • Maximum entry age: the lifetime of an entry
  • Maximum entry size: the size per entry


At a first glance this makes sense and does not raise any questions.

But there is the catch:

The assertion will always maintain exactly one Maximum entry age per Cache ID

Look at this example:

  • Cache ID: myCacheID, Cache entry key: myKey, Maximum entry age: 300
    • the entry for myKey will be cached for 300 seconds
  • Cache ID: myCacheID, Cache entry key: myNewKey, Maximum entry age: 600
    • the entry for myNewKey will be cached for 600 seconds

At this point the entry of myKey got removed from the cache since the new lifetime for this cache is 600!


How to use the local cache

It is important that you are aware of the described behaviour from above. Otherwise your caching strategy does not work as expected. The simplest solution is to always use the same Maximum entry age per Cache ID. A simple solution is to create a Cache ID always in combination with the used Maximum entry age. If you are using variables that contain the values do the following:

  • Cache ID: ${cacheID}${lifetime}
  • ...
  • Maximum entry age: ${lifetime}


I hope this helps building better policies!