Caching reduces both the server load and the response time of jobs. It is particularly useful for jobs exposed as a Web service or for data-intensive jobs that require a long time to complete and increase the server load.
Caching the result of a job essentially means that FlowForce Server prepares and stores the job result in some internal repository (that is, the cache). If the job has parameters, the system creates a cache entry for every parameter combination, up to a limit that can be configured. When the job with cached result is called from another job (referred to as the consumer), FlowForce Server returns the cached result to the consumer (instead of executing the job again), thus reducing the response time.
The right balance between keeping the server load under control, on one hand, and not letting the cache become too old, on another hand, depends on the specifics of your environment and the jobs used. To achieve this balance, you can experiment with the caching settings provided by FlowForce Server and then decide what works best for you.
When working with cached job results, note the following:
•It is mandatory to declare the data type returned by the job whose result is cached (see Declaring the return type of a job).
•Both the job whose result is cached and the consumer job must use the same credentials. If the credentials differ, then the job executes as if no cache were defined.
•When you change the configuration of the cached job, the existing cache data is invalidated (flushed).
Caching settings
The available caching settings are as follows.
Cache the result |
Select this check box if you want the job results to be cached. By doing so, you are instructing any consumers of the current job to read the cached result rather than execute the job. If the current job is executed directly (not through a consumer), either because a defined trigger fired or because the job's Web service is invoked, FlowForce Server refreshes the cache (or, if the job parameters are not found in the cache, it creates a new cached entry based on the supplied parameter combination). |
Initiated by consumer |
When this option is enabled, any job that is calling the current job (that is, the consumer job) will compute and populate the cache if it does not exist. Otherwise, only triggers and Web service calls will populate the cache. |
Maximum number of cache entries |
This option restricts the number of cached job results per job. When the job has parameters, you might want to set this option to the number of all possible parameter combinations (provided the combinations are finite). |
Auto create a new cache consumer job |
A cache consumer job is a Web service at the HTTP address you specify. The consumer Web service acts as a convenient way to retrieve and manage the cache of the job whose result is being cached. When invoked, the consumer job attempts to use the cached result of the main job in first place. If there is no cached result and the Initiated by consumer option is disabled, the consumer retrieves the actual result returned by the main job. If there is no cached result and the Initiated by consumer option is enabled, the consumer retrieves the actual result returned by the main job and also populates the cache. |
Refresh Cache timer |
A Refresh Cache timer controls how often the system should refresh the cache of the current job. All currently cached parameter combinations are refreshed.
|
Purge Cache timer |
A Purge Cache timer controls how often the system should purge the cache of the current job.
 |
Save and Refresh the cache |
Click this button to refresh the cache manually. |
Refresh Cache timers and Purge Cache timers can be deleted in the same way as other triggers, by clicking the Delete ( 
) button. Also, the Undo Delete ( 
) operation becomes available for them until you save or reload the page. The Duplicate button ( 
) enables you to create a copy of the current trigger, with the same settings.
See also
•Caching Job Results (example)
