Community Manager changl Community Manager
Community Manager

(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) 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 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 37

It should change it to

ksc_flush_cache “tablecomponent”


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, 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

Labels (1)
Tags (2)
1 Reply
Contributor.. JimB_In_SD Contributor..

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.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.