To cache or not to cache?

Body

Caching of reference data in Sterling can provide a performance boost when implemented correctly.
The cache manager implements a simple cache management policy that provides significant performance benefits with little management overhead.

With the peak season right around the corner, this is a good time to review if your caching properties require any changes.

When a reference data record is changed , the local cache manager notifies all the other cache managers to flush the reference data table. There is a small time-lag between when the reference data is
changed to when the last cache manager is notified. During this time interval if another API accesses a table that has the older data, there may be a problem of data inconsistency.
Caching a entity reduces database overhead but at the same time it may also cause data inconsistency. The decision to enable caching for a database table should be made after careful evaluation and testing.

Here is a set of general guidelines for cache management are -

• For tables that have infrequent changes or updates, implementing cache is recommended since the cache does not have to be dropped very often.
• Ensure that you arrive the correct cache size. Setting it too low could cause frequent cache refreshes while setting it too high can impact JVM memory.
• Monitor cache refresh statements in the logs for agents, integration servers and application servers.This calls for a review of the caching done on that table -
  • It could mean that the table is being frequently updates, which calls for a review of whether caching is needed for the table.
  • The cache limit on the table is being hit causing the cache to drop. Consider increasing the cache limit or dropping the cache if the number of cacheable records are very high.

Read more at -

https://www.ibm.com/support/knowledgecenter/SSYLSL_9.3.0/com.ibm.help.wcc.perf.doc/c_FND_PM_PerformanceFeature-ReferenceDataCaching.html