REST Service Storage Overview
When configuring the REST Reporting Service you must provide an IStorage interface implementation. An instance of the provided implementation will be used from the service to store its internal state (like active clients, interactivity state, and rendered reports).
The interface also exposes a method called AcquireLock which is used from the service to enforce serialized access to all stored resources from each thread of the application and between the instances of the application in case of multi-instance environment (i.e., Web Farm). This requires selecting a suitable interface implementation when embedding the Reporting REST Service within your application.
IStorage implementation suitable for deploying both on single instance application hosting and in Web Farms
The following implementations of the IStorage interface allow service multiple instances support. They also have better overall performance.
- MsSqlServerStorage object - See How to Configure an MSSQL Database Storage. It supports storage server side locks to achieve inter-machine resources serialized access by its Sql Server transactions feature.
- RedisStorage object - See How to Use Redis storage. It supports storage server side locks to achieve inter-machine resources serialized access by its distributed locks feature.
IStorage implementation suitable for deploying on a single instance application only
The following implementations of the IStorage interface support the service to be deployed as a single instance only. For the locking mechanism, they use OS-specific synchronization primitives which only enable inter-thread serialized resources access in the boundaries of a single machine.
- FileStorage - Use the FileStorage constructor to create a storage instance. All Visual Studio item templates for adding the Reporting REST service use the default FileStorage constructor. The second overload of the FileStorage constructor allows you to specify a folder, and it is recommended for usage in a production environment.
- DatabaseStorage - Use the DatabaseStorage constructor to create a storage instance. This storage option requires reference to Telerik.Reporting.Cache.Database.dll that has dependencies on Telerik Data Access which can be checked in the version corresponding Upgrade article.
Cleaning the Reporting REST Service Storage
The REST Service Storage keeps all the information about the registered clients/viewers. For example, the generated report documents, the images embedded in the reports, etc. Therefore, with each generated report the occupied storage space increases. To prevent the storage from growing unnecessarily, when a client expires, the Reporting Service triggers a cleanup routine deleting its assets.
You may control the assets’ expiration using the ClientSessionTimeout and ReportSharingTimeout properties of the service configuration.
When a viewer gets closed, there is no notification, and the service does not know about that. Therefore, periodically (every 5 minutes), the REST Service performs cleaning of the expired data. You may prevent the expiration of an active viewer by setting the viewer's option keepClientAlive to true (default). The service triggers this logic only when awakened by a request from an active client/viewer.
The assets cached when a report gets rendered are generated in hierarchical manner with each resource holding reference to its parent resource. To release a particular resource, the system counts the child resources that depend on this resource and if there are none, it is considered as expired and gets released. Here are the resources from child to parent:
-
client session - Kept for
ClientSessionTimeoutminutes (15 by default) after the last request from the originating client. The client session keeps the requested document refreshes alive. - document refresh - A representation of report document rendered at particular moment in time. Contains the actual rendering assets like pages, images, docs (for the export format). Keeps the originating report instance alive
- report instance - this is the report definition with particular report parameter values, i.e., the report address.
You may reuse document refreshes by assigning the ReportSharingTimeout a positive value (the default is 0). For example, when two clients request the same report with the same parameter values and states of its actions within ReportSharingTimeout minutes, the second client will reuse the document refresh created upon the first client's request. Thus, there will be two clients holding reference to this document refresh, and the latter will remain even if one of these clients expires.