Cache value is overwriting the inputs

Question:We do have a service which is taking few inputs and that service will inturn calling a childservice for processing the flow.

We are seeing an issue wherein when we enable the cache property of child service to true the actual inputs which are coming from parent service is getting overwritten after the child step execution.
Since we need to enable the cache property of child step without overwriting the actual run time input of parent service.Can someone help me on this?

Kindly let me know if you need anyother details

Product/components used and version/fix level are you on:

Detailed explanation of the problem:

Error messages / full error message screenshot / log fileL

Is your question related to the free trial, or to a production (customer) instance?

Have you installed all the latest fixes for the products and systems you are using?

Hi Jerin,

when a service is set up for caching, it will always return the cached output when it is invoked with the same inputs from an earlier invocation.

Please explain, why you need the child service to be set up for caching.
Provide a screen shot with the outline of the parent flow and describe where the inputs get changed unexpectedly.


To limit Caching to the child service’s inputs and outputs, you must invoke the child as a Transformer.

Alternatively, I think the “Scope” property might also work, if your cached output is within a single document (it has been long since I developed anything).

Updated per Holger’s comment below - thanks Holger, that was my intention.




should be read as
“To limit Caching to the child service’s inputs & outputs, you must invoke the child as a Transformer.”
as caching uses the input pipeline as the key and the output pipeline as the value for the cache entry.
Even when not explicitly in the sginature of the service, the complete pipeline is used, when not invoking as a Transformer in a MAP-step instead of a normal INVOKE-step.


1 Like

As of wm 10.15 we introduced a new extended setting ‘watt.server.serviceResults.cache.strict’ that restricts the cache to only the output of the given service. It is disabled by default i.e. false.

Set this property to true to both improve efficiency and avoid having to invoked cached services via a transformer.

1 Like

This is the key aspect. The cache captures the entire pipeline – and when used restores the entire pipeline. As the others have noted, calling via transformer or with a scope lets you control that.

But people never remember to do that and so we just avoid caching. It almost never matters for speed anyway. :slight_smile:

1 Like

Unless you use watt.server.serviceResults.cache.strict as of 10.15 :slight_smile:

1 Like

Hello All,

Thanks for the valuable inputs.

We could resolve the issue by involving transformer for calling child service which is having cache property enabled.When we use transformer ,parent service inputs are not getting overwritten by child service.

1 Like

Thanks Kasi Muguda :slight_smile:

Looks like this feature was also backported to 10.5-10.11 in recent fixes

1 Like

As a side “academic interest” trip, what is prompting the use of service caching in this case? Is it because gathering metrics shows that it improves performance in a meaningful way for the overall process? Or is it simply anticipated that it will be “faster?”

I ask because over the years I’ve never had occasion where using caching (or trying to use multi-threading) would be useful in a meaningful way. Most of the integrations we implement are “behind the scenes” activities and so 5 seconds vs 3 seconds doesn’t matter.

Using caching also introduces the need to manage the cache. How long to keep it? How/when to force it to refresh? How to recover from issues because the cache was kept too long and did not refresh when it should have?

I’m interested in learning about the scenario where this added level of activity is offset by meaningful improvement in processing/response time.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.