Caching is applied manually per hierarchy definition. If you have more than one hierarchy definition, each one must be cached separately via an action on the right-click menu. And each hierarchy has a separate cache status visible in the property sheet view of the Hierarchy component.

As with the implied tag index, once the hierarchy cache is built it does not change. Subsequent changes to the station, i.e. editing a hierarchy definition or editing permissions, are not reflected in the cache until it is recreated. For example, if you take away permissions that let a particular user see some part of the hierarchy, it will continue to be visible to that user if the cache is not recreated. A best practice is that the user making such changes to the station also be responsible for clearing the existing cache and creating a new cache.

Unlike the implied tag index which it is built “on-the-fly” as tag queries are executed, the hierarchy cache is built at the time you initiate it. The job is launched and runs in a separate thread, and when the job completes a popup window displays a message confirming that hierarchy caching completed successfully. Note that you can expand a hierarchy while its caching job is running.

Figure 3.   Cache information available in Remote Spy Page view

The Remote Spy Page view for each hierarchy shows how many elements are cached and the size of the cached hierarchy. The cached hierarchy is stored in heap memory and is not persisted with the station. It must be recreated each time the station starts. The Cache On Station Started property can be set so recreating the cache when the station starts is automatic.