(PPM) Support Tip: ksc_flush_cache and cachenames
This information applies to 9.31 and later
Recently there was a post, pointing to the Cache white paper (Understanding and Tuning the Cache). Moreover, it provided 2 queries to find workflow steps and reports, which might reference cache clearing.
This post is to add a few additional statements.
1) kRunCacheManager.sh should never be called directly from a workflow step or from command step on a report. Direct calls in this context can impact stability and performance. If there is a requirement to clear a particular cache, the method ksc_flush_cache should be utilized. With this command, you can be assured that its execution will remain local. With kRunCacheManager.sh it causes a shell (client) to be launch, a new java process, and the flushing action will be performed most likely against a remote instance and even on another physical machine. So, if in a workflow step there something like
sh kRunCacheManager.sh 37
It should change it to
2) Cleaning a cache by its cache number is NOT reliable. The cache index can change after a PPM upgrade if a new cache is introduced (or just if you change order of lines in cache.conf). After 9.31 you should always clear a cache by its name. To know the name of a cache, run kRunCacheManager.sh, and it will list the caches by index with both they “title” and their cache name within parenthesis, to be used as a parameter of the command. This is documented in the Cache White Paper.
The current cache names are : benefit, budget, calendar, ci, currency, currencycell, currencyline, datasource, defaultworkflow, demandfield, document, filedirchooser, fiscalperiod, fxupdate, globalmenu, logsummary, module, moduledistribution, optparameters, optresults , orgtree, parametersetcontext, portlet, portletcontent, portletdataset, portletpage, portlettype, region, request, requestheadertype, requestheadertypesearchfield, requesttype, requesttypesearchfield, rule, securitygroup, tablecomponent, timesheetpolicy, user, usermenu, userpagetab, userpagetab-list, userrequest, usersectionstate-list, validation, validationidfromcomponentname, validationidfromvalidationname, validationlistvalue, workflow, and pass "1" for Scoring Criteria
3) It is NOT a good practice to clean the whole cache of an entity. Most often, in a workflow you will update a single entity; if that is the case, only flush that specific entity from the cache by passing the ID as a second parameter after the cache name. This will ensure that performance doesn’t degrade after cache flush, which can have a significant performance impact under heavy load if the system must suddenly reload many objects that were just flushed. Below example is flushing request 36635.
ksc_flush_cache “request” 36635
Re: (PPM) Support Tip: ksc_flush_cache and cachenames
This was a great post and led me to an elegant solution to the problem I was working on . However, in my workflow step I had to look up (via a reference) a request ID and then flush the cache for that request (after having previously updated three of its fields.) The command I entered that finally worked is:
ksc_flush_cache request "[SQL_OUTPUT]"
Note - no quotes around the name of the cache to flush (request). When I had quotes around it, the command threw an error.