Refreshing the cache

The cache can be refreshed by stopping and restarting the integration node.

In addition to this mechanism, FTM includes an active flow manager subflow deployed as part of all the main core flows:
  • PhysicalTransmissionFlow
  • EventProcessingFlow
  • LogErrorFlow
The heartbeat flow in the sample application also includes the flow manager subflow.
The FlowManager subflow contains logic that periodically polls (the default is 10 minutes) the APP_VERSION table for an indication that the loaded configuration data may be stale. This may occur for the following reasons:
  • The data for the current application version has been modified
  • An updated version of the application has been deployed
Under these circumstances, the flow manager either initiates an immediate reload or schedules a reload request for the correct time.

For reloading the current version, the AUTO_REFRESH_AFTER column of the APP_VERSION table may be used to postpone or disable reloading. A NULL value disables reloading, while a specific time stamp ensures a refresh will not occur until after that time.

For loading a new version of the application, the EFFECTIVE_DATETIME column of the APP_VERSION table is used to determine the most effective version, which is defined as the version with the latest non null value that is not in the future.

The cache reload algorithm does not reload into the existing cache; instead, it creates a new branch in the cache and loads the new data into that. Once this has completed, it publishes the existence of the new cache data to the message flow. In order that the message flow may synchronize the change of cached data at the start of its unit of work, the functions that access the cache have been extended to allow the message flow to indicate which version of the cache it is currently using.