Difference between revisions of "View Cache"
| Line 8: | Line 8: | ||
== Using the View Cache == | == Using the View Cache == | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Enabling === | === Enabling === | ||
The View Cache features needs to be enabled in the [[Configuration_File_Example#tab=web_config|web.config]] file of the corresponding web service. | The View Cache features needs to be enabled in the [[Configuration_File_Example#tab=web_config|web.config]] file of the corresponding web service. | ||
| Line 29: | Line 24: | ||
</appSettings> | </appSettings> | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| + | |||
| + | === Initialization / Update of View Cache === | ||
| + | The cache needs to be initialized after a web service has been (re)started by calling the method [[#TriggerViewStateUpdate|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. | ||
| + | {{Attention|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 are | ||
| + | Application Pool Recycle Time | ||
| + | |||
| + | Idle Time-out | ||
| + | |||
| + | [[File:UI ApplicationPool AdvancedSettings.png|thumb|Application Pool / Advanced Settings]] | ||
| + | |||
| + | |||
=== Testing === | === Testing === | ||
| Line 89: | Line 103: | ||
DTO.V211.BCHierarchyDeltaShipments TestViewState(string appName, string contextName, string ownerUID, string authentication); | DTO.V211.BCHierarchyDeltaShipments TestViewState(string appName, string contextName, string ownerUID, string authentication); | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| + | |||
| + | == See also == | ||
| + | * [http://weblogs.asp.net/owscott/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes Why is the IIS default app pool recycle set to 1740 minutes?] | ||
| + | * | ||
[[Category:Installing]] | [[Category:Installing]] | ||
[[Category:Web service]] | [[Category:Web service]] | ||
Revision as of 14:54, 7 May 2015
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 the 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, due to a missing automatism! |
Contents
Using the View Cache
Enabling
The View Cache features needs to be enabled in the web.config file of the corresponding web service.
| Area | Setting | Description |
|---|---|---|
| appSettings | UBIK.Service.EnableViewCachage | Enable (1) / Disable (0) the view cache feature for this web service |
...
<add key="UBIK.Service.EnableViewCache" value="1" />
</appSettings>
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 are Application Pool Recycle Time
Idle Time-out
Testing
Test the View Cache's result for a single object, given by its Guid, via the method . 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);
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);
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);
