View Cache
The View Cache feature increases the performance of the Web Service by caching the data to be published and sent to the clients. All content data as well as the hierarchies, as defined by the View and in the ACM, is evaluated and cached internally. Be aware, that this data does not encompass the physical documents linked to the objects, hence the documents have to be loaded if requested from the client.
A client's request for hierarchical data, covering two or more hierarchy levels, will be handled using the cached data. Any request covering only one hierarchy level will by-pass the view cache and be treated directly. For example, browsing through the objects using the Content Browser does not use the View Cache, whereas preparing the Offline Mode utilizes the cache to improve performance.
Once the cache has been initialized, its status and additional information can be retrieved by web service methods.
 | Up to now the View Cache needs to be initialized and updated manually after every (re)start of the web service. This can be done manually or by using an automatism! |
Contents
Using the View Cache
Initialization / Update of View Cache
The cache needs to be initialized after a web service has been (re)started by calling the method TriggerViewStateUpdate. If a client commits data via a web service having the View Cache enabled, the cached data gets updated. Consequently, any other client connected to this web service receives this updates as well.
| Be aware, that the View Cache's scope is valid only within a web service instance. A client connected to a different web service does not receive updates happening in a different web service's View Cache. |
Application Pool Settings
Any in-memory data of a web service, respectively an application pool, is lost whenever application pools are (automatically) recycled. Although there is no downtime during a recycle, this empties the View Cache's memory.
Due to the missing automatism for a periodic initialization or update, the default interval settings for recycling must be changed, such that the application pool and the related web services are not recycled automatically.
The according settings of the application pool are
| Setting | Default value | Recommended value | Comment |
|---|---|---|---|
| Advanced Settings→Recycling→Regular Time Interval (minutes) | 1740 | 0 | Application pool will be recycled after this time |
| Advanced Settings→Process model→Idle Time-out (minutes) | 20 | 0 | Application pool will be terminated after this time without any traffic |
| The value of the Idle Time-out (in minutes) property must be less than the value of the Regular Time Interval (in minutes) property (Source: Microsoft Support). |
Testing
Test the View Cache's result for a single object, given by its Guid, via the method TestViewState. The result will not retrieve the physical documents.
Web Service Interface
Use the these web service members to gain status and runtime information of the View Cache. More detailed information and a comprehensive list of all members and data types are located in the UBIK® class documentation.
GetViewStateInformation
Get information about the current state of the View Cache.
/// Gets information abut the state of view cache.
/// </summary>
/// <param name="appName">Name of the application.</param>
/// <param name="contextName">Name of the context.</param>
/// <param name="authentication">The authentication.</param>
/// <returns>Information about the state of the view cache as human readable string</returns>
[OperationContract]
[WebInvoke(UriTemplate = "GetViewStateInformation/{appName}/{contextName}/{authentication}", Method = "GET",
RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json)]
string GetViewStateInformation(string appName, string contextName, string authentication);
To call this in a web browser, one can access
to trigger a update. Please replace ContentServerAddress, ContentServicePath, AppName and ContextName with the actual service configs.
Once the view cache is ready, the response should say something like "Cache State <<ONLINE>>"
TriggerViewStateUpdate
Start or trigger reinitialization of the View Cache.
/// Triggers a refresh of the view cache.
/// The current cache stays valid until the new cache was fully built.
/// </summary>
/// <param name="appName">Name of the application.</param>
/// <param name="contextName">Name of the context.</param>
/// <param name="authentication">The authentication.</param>
/// <returns>true as the refresh was triggered successfully, false otherwise</returns>
[OperationContract]
[WebInvoke(UriTemplate = "TriggerViewStateUpdate/{appName}/{contextName}/{authentication}", Method = "GET",
RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json)]
bool TriggerViewStateRefresh(string appName, string contextName, string authentication);
To call this in a web browser, one can access
to trigger a update. Please replace ContentServerAddress, ContentServicePath, AppName and ContextName with the actual service configs.
TestViewState
Test the View Cache's result for a single object, without retrieving the physical documents.
/// Test member for testing the View Cache.
/// </summary>
/// <param name="appName">Name of the application.</param>
/// <param name="contextName">Name of the context.</param>
/// <param name="ownerUID">UID of the object the test should be executed for (e.g. root object). All data below this object will be delivered.</param>
/// <param name="authentication">The authentication.</param>
/// <returns>data stored in the view cache as BCHierarchyDeltaShipments</returns>
[OperationContract]
[WebInvoke(UriTemplate = "TestViewState/{appName}/{contextName}/{owneruid}/{authentication}", Method = "GET",
RequestFormat = WebMessageFormat.Json,
ResponseFormat = WebMessageFormat.Json)]
DTO.V211.BCHierarchyDeltaShipments TestViewState(string appName, string contextName, string ownerUID, string authentication);
