This option applies only to cluster environments. The option helps to solve the problem that when a task is updated, there is a small (up to 2 second) delay until other nodes in the cluster reflect the change. This is normally is not an issue for standard task interfaces, but it can present a problem for remote Task Engine web service APIs, including APIs from the WmTaskClient package and REST web services.

Unless the end-point is set to single cluster node, the API call can be routed by a load-balancer to any node in a My webMethods Server cluster. In this case, it is possible that a call to updateTask() followed immediately by getTask() may return incorrect (out of date) data, because the cluster node has not been updated yet. In this case setting this flag will ensure that up-to-date data is always returned. The option is:

The default value is false. If set to true, any task update operation will attempt to synchronously refresh caches on all other cluster nodes and wait until other cluster nodes report back that their caches have been updated

A disadvantage to setting this option to true is that any task update operation will have to wait until all cluster nodes are refreshed. This does not introduce any additional load on the server, but it does increase task update operation response time