The key that is used to put entities into the FinderCaches (used by a.o. ExpandoValuePersistence) is not guaranteed to be unique per entity. Because the FinderCaches do not distinguish between colliding keys, this leads to wrong entities being fetched from these caches. A concrete example of such a collision can be found in the accompanying testcase.
The testcase uses the id's from an actual cache-corruption that we encountered:
- a Layout-ExpandoValue A is inserted in the cache.
- another Layout-ExpandoValue B (differing in its columnId and its primaryKey) is requested from the cache
- because B's key, generated by HashCodeCacheKeyGenerator, is the same as A's, A will be returned.
Note that this happens highly frequently in our setup: I haven't done the math, but it's probable that the more ExpandoValues you define on a single Model, the likelier occurences of this issue will be. We've got 4 different expando's on Layout, and that seems to trigger the problem in approx. 1 out of 20 cases.
Either the FinderCaches should take the key-collision possibility into account (seems quite a hassle), or the KeyGenerator used should guarantee unique keys.
We'll implement the latter approach as a workaround: create a SimpleCacheKeyGenerator that concatenates all of its arguments into one big String and inject that Generator in util-spring.xml. However, I guess there must have been a reason to go through the complexities of generating a hashcode - memory-usage most likely ... Any caveats are most welcome.