After defining the data views, make sure to configure the cache correctly, so that the data view objects are not evicted from the cache immediately. An indicator for this situation is the message "Unreasonable Cache Size null for java.lang.Object" in the log file.

Cache sizes are configured as application properties, using the prefix cache.capacities. followed by the fully qualified class name of the type to configure. The value specifies the maximum number of cached instances of that type. As a minimal solution, add the following spring boot property mapping to the spring boot environment (for example the application.properties resource).

cache.capacities.com.coremedia.objectserver.dataviews.AssumesIdentity=10000

This will allow a total of 10000 data view objects to be cached.

Note

For backward compatibility, cache sizes can still be configured as <cachesize> elements in the dataview definition XML file. However, this approach is discouraged and may be removed in a future release. Prefer configuring cache sizes via cache.capacities.* spring boot properties instead. Spring boot properties take precedence over <cachesize> elements, so a value set via cache.capacities.* will always override a conflicting value from the dataview definition.

A more elaborate method would be to partition the cache according to the type of the cached objects. The type of an object is defined either by the Java type hierarchy or, if the object implements the interface com.coremedia.dispatch.HasCustomType, by the result of the method getCustomType(). For ordinary content beans, the Java type hierarchy is used.

You can configure cache sizes for different types. Each configured cache size constitutes a cache class with its own capacity and metrics. If multiple types apply for a single cached object, the most specific type is used. For example

cache.capacities.com.company.cms.SuperType=1000
cache.capacities.com.company.cms.SubType=100

would allow the caching of up to 1000 direct or indirect instances of SuperType as long as these are not also direct or indirect instances of SubType. For SubType, at most 100 instances would be cached. This can make sense if instances of SubType consume a lot of main memory, so that 1000 instances might lead to an OutOfMemoryError.

Because data views extend their bean class, it is sufficient to configure cache sizes for the bean classes. You need not reference the class names of the automatically generated data view classes.

Please note that the configured cache sizes are directly forwarded to the cache of the Unified API in the CAE. That cache is an instance of the class com.coremedia.cache.Cache. That class does not perform any type hierarchy analysis when caching objects. This is only done by the data view factory inside the CAE.

Warning

Please note that configured values for cache classes for data views may overwrite configured values for cache classes for cache keys, for example if java.lang.Object is configured. Make sure to always use com.coremedia.objectserver.dataviews.AssumesIdentity or classes higher in the class hierarchy if configuring cache classes for DataViews.